位於 M87 中心的特大品質黑洞示意圖（© EHT Collaboration）
今天的文章我想從這張模糊的照片說起。
相信很多小夥伴對這張照片並不陌生，這是去年人類第一次拍攝的 M87 中心黑洞的照片，從1915年，愛因斯坦提出相對論預言黑洞的存在到 2019 年我們終於第一次「看到」了黑洞的樣子，中間整整相隔了 100 多年，這對於人類認識黑洞乃至認識宇宙都是一個里程碑式的事件。人類是一個感性的動物，所謂「一圖勝千言」很多時候一張圖傳達的資訊超過千言萬語。
關於黑洞我不想展開太多，今天我們聊聊「望遠鏡」。
前幾天，在 TiDB 4.0 的開發分支中，我們引入了一個新功能叫做：Key Visualizer（下面簡稱 KeyViz），說起來這個小工具也並不複雜，就是用不同顏色的方框來顯示整個資料庫的不同位置資料訪問頻度和流量。一開始我們只是僅僅將它定位為一個給 DBA 用來解決資料庫熱點問題的調優輔助小工具，但是從昨晚開始我就一直在把玩這個小東西，突然覺得它對於分散式資料庫來說背後的意義遠不及此。
在 CNCF 對 Cloud Native 的定義中，有一條叫做「Observability」，通用的翻譯叫系統的「可觀測性」。過去我一直苦於尋找一個例子說明什麼叫做一個「可觀測」的系統，在 KeyViz 這個專案上，我找到了對這點絕佳的體現。
舉幾個直觀的小例子。你知道 TPC-C 測試「長」什麼樣子嗎？請看下圖：
圖中橫軸是時間，縱軸是資料的分佈，左半部分是資料匯入的過程，有零星的亮點，可以看到寫入分散到多個區塊；右邊密集的色塊是測試在執行時系統的實時讀寫狀態，越暗表示流量越小，越亮表示流量越高。從密集的色塊我們能夠看得出來，workload 基本分佈均勻，但是大概有兩處是明顯偏亮的區域，其中靠近最上方，有一個特別明顯的區域性訪問熱點（最亮的那條線）。
第二個例子，你見過 Sysbench 測試 「長」什麼樣子嗎？看看下面。
左邊比較密集的明亮黃塊部分，是匯入資料階段；右半段明暗相間的部分是在進行 oltppointselect 測試，因為選取的模式是 uniform 模式，並且匯入的時候是 32 執行緒 32 張測試表，可以看到的資料和分佈和訪問都比較均勻。 如果你看懂了上面兩個小例子，下面是一個小作業：這是我們模擬的一個實際使用者的生產環境的照片，這個使用者的系統遇到了一些瓶頸，你能看出問題嗎？
上面幾個小例子是讓大家對 KeyViz 有個感性的認識，在介紹這個東西背後的意義之前，我想先介紹一下 TiDB 這類典型的分散式資料庫的系統架構，方便大家更好的理解。
分散式資料庫，顧名思義，資料一定是分散在不同機器上的。對於一張表的資料，我們會在邏輯上切分成若干個連續的區間，將這些區間內的資料分給不同的機器儲存，不管是寫入還是讀取，只需要知道目標資料屬於哪個區間，就可以直接到那個機器上進行訪問。然後加上對每一個區間的資料在物理上做多副本冗餘，實現高可用。如下圖所示，Region 在 TiDB 的內部就是一個個連續的資料區間。
和很多分散式資料庫不太一樣的是，我們的 Region 的大小比較小（預設 96MB) ，另外資料的分佈並不是靜態的，而是動態的，Region 會像細胞一樣分裂/合併，也會在不同機器之間移動進行動態的負載均衡。
現在回頭看這個設計，還是覺得無比的簡潔和優雅。對使用者而言再也不用去思考怎麼分庫，怎麼分表，資料在最底層的細胞就像有生命一樣繁衍和遷徙。
然後問題就來了，對於這樣的資料庫而言，有沒有一種辦法能夠直觀地描述系統的執行時狀態？我怎麼知道它是不是「生病」了？我能不能預測這個系統的未來？我能不能發現未知的風險？
過去，不管是業務開發者還是 DBA，衡量一個數據庫的狀態，來來回回就是幾個指標，QPS 、TPS、查詢時間、機器負載（CPU、網路、磁碟），但很多時候就像是盲人摸象一樣對於系統的全域性我們是不清楚的。再加上在一個分散式的架構下，很多時候，我們可能會被海量的數字矇蔽了雙眼。一些有經驗的 DBA 或許可以通過自己的經驗，從多個指標裡模糊構建出業務全域性狀態，但是到底這個經驗往往是不可描述的，這就是為什麼一些老運維、老 DBA 那麼值錢的原因，但是我認為這種做事方式是很難 scale 的。
CT 、B 超、核磁共振，這些現代化的手段極大地促進了現代醫學的發展，因為我們第一次能「看見」我們身體的內部狀態，從而才能得出正確的判斷。在計算機的世界道理也是相通的，最好通過某些工具讓人清晰地「看見」系統執行的健康狀態、幫助診斷病灶，從而降低經驗門檻和不確定性。
過去也經常有朋友問我：“你說我這個業務適不適合使用 TiDB？”這時我們只能問，你的 QPS 多少 TPS 多少，資料量多少？讀寫比？典型查詢？資料分佈怎麼樣？表結構是什麼呀？等等一連串的靈魂拷問，而且很多術語都非常專業，不是在這個行業摸爬滾打很久的老司機可能都搞不太清楚。而且有些資訊可能是敏感的，也不方便共享。所以「預判 TiDB 到底適不適合某項業務」就成了一個玄學問題，這個問題困擾了我很久，很多時候也只能憑個人感覺和經驗。其實這個問題也並不是 TiDB 特有，尤其是最近幾年，幾乎所有現代的分散式系統，都或多或少有類似的問題。
在過去，一個物理機器的狀態確實可以通過幾個監控指標描述，但是隨著我們的系統越來越複雜，我們的觀測物件正漸漸的從「Infrastructure」轉到「應用」，觀察行為本身從「Monitoring（監控）」到「Observability（觀測）」。雖然看上去這兩者只是文字上的差別，但是請仔細思考背後的含義。關於這個話題，我很喜歡引用下面這張圖：
上圖座標描述了我們對系統的理解程度和可收集資訊之間的關係。在 X 軸的右側（Known Knows 和 Known Unknowns）這些稱為確定性的已知和未知，圖中也給出了相對應的例子，這些資訊通常是最基礎的普適的事實，也就是在系統上線之前我們一定就能想到，一定能夠監控起來的（CPU Load、記憶體、TPS、QPS 之類的指標），我們過去已有的大多數運維監控都是圍繞這些確定的東西。
但是有一些情況是這些基礎資訊很難描述和衡量的，例如這個座標的左上角：Unknown Knowns，用通俗的話來說，叫做「假設」。舉個數據庫的例子：有經驗的架構師在設計一個基於分散式資料庫的應用時，通常不會將表的主鍵設成自增主鍵，會盡可能的用 UUID 或者其他方式打散資料，這樣在即使有突發寫入壓力的時候，系統也能很好的擴充套件。
注意在這個例子中，其實「假設」的事情（寫入壓力突然增大）並沒有發生，如果在日常壓力不大，資料量不多的情況下，即使使用自增主鍵，從已有的基礎監控中，可能也很難看出任何問題。但是到出事的時候，這個設計失誤就會變成 Unknown Unkowns（意外），這是任何人都不想看到的。有經驗的架構師能通過種種的蛛絲馬跡證實自己的推測，也從無數次翻車的 Post-mortem 中將 Unknown Unknowns 的範圍變小。但是更合理的做法是通過技術手段描繪系統更全面的狀態。在 Cloud Native 和微服務的世界裡，最近幾年一個行業的大趨勢是將「系統的可觀測性」放在一個更高的位置（監控只是可觀測性的一個子集），這是有道理的。
回到資料庫的世界，TiDB KeyViz 的意義在於，就像上面提到的，這個工具不僅僅是一個監控工具，而且它能以一個非常低門檻且形象的方式讓架構師具象化的看到自己對於業務的「假設」是否符合預期，這些「假設」不一定是能夠通過監控反映的，以獲得對業務更深刻的 Insight。
還是說回上面那個主鍵的小例子。對於兩種不同的主鍵設計，KeyViz 這邊是怎麼表現的呢？看看下面兩張圖，是不是非常一目了然？
所以現在如果有朋友問我，“這個業務適不適合 TiDB？”我只需要通過錄制線上流量，或者搭建一個從叢集，只需要把 KeyViz 的圖給我看一眼，我甚至都不需要壓力測試就能判斷這個業務是否適合，而且即使不適合，我也能準確的給出修改建議，因為 KeyViz 的圖對我的「假設」的可解釋性有了很強的支援。
我們不妨在此基礎上再放飛一下想象力，為什麼人類能夠一眼就從這圖片中理解這些資訊，這說明這些圖形背後有模式，有模式我們就可以識別——
想象一下，如果所有的 TiDB 使用者，都使用 KeyViz 將自己的系統具象化後分享出來（其實這些圖片已經高度抽象，已經不具有任何的業務機密資訊），我們是不是可以通過機器學習，挖掘背後更深層次的價值？AI 能不能通過這種形式更加理解我們的業務？
最後，我想以我最喜歡的科幻小說《三體：黑暗森林》中的一段話結束這篇文章，大致是面壁人希恩斯在冬眠後被妻子喚醒後的一個場景：
……與此同時，希恩斯感覺到圍繞著他們的白霧發生了變化，霧被粗化了，顯然是對某一區域性進行了放大。他這時發現所謂的霧其實是由無數發光的小微粒組成的，那月光般的光亮是由這些小微粒自身發出的，而不是對外界光源的散射。放大在繼續，小微粒都變成了閃亮的星星。希恩斯所看到的，並不是地球上的那種星空，他彷彿置身於銀河系的核心，星星密密麻麻，幾乎沒有給黑夜留出空隙。
“每一顆星星就是一個神經元。”山杉惠子說，一千億顆星星構成的星海給他們的身軀鍍上了銀邊。