數據庫

我眼中的分布式系統可觀測性

位于M87中心的特大質量黑洞示意圖(? EHT Collaboration)

作者:黃東旭

今天的文章我想從這張模糊的照片說起,相信很多小伙伴對這張照片并不陌生,這是去年人類第一次拍攝的 M87 中心黑洞的照片,從1915年,愛因斯坦提出相對論預言黑洞的存在到 2019 年我們終于第一次「看到」了黑洞的樣子,中間整整相隔了 100 多年,這對于人類認識黑洞乃至認識宇宙都是一個里程碑式的事件。人類是一個感性的動物,所謂「一圖勝千言」很多時候一張圖傳達的信息超過千言萬語。 關于黑洞我不想展開太多,今天我們聊聊「望遠鏡」。

前幾天,在 TiDB 4.0 的開發分支中,我們引入了一個新功能叫做:Key Visualizer(下面簡稱 KeyViz),說起來這個小工具也并不復雜,就是用不同顏色的方框來顯示整個數據庫的不同位置數據訪問頻度和流量。一開始我們只是僅僅將它定位為一個給 DBA 用來解決數據庫熱點問題的調優輔助小工具,但是從昨晚開始我就一直在把玩這個小東西,突然覺得它對于分布式數據庫來說背后的意義遠不及此,在 CNCF 對 Cloud Native 的定義中,有一條叫做「Observability」,通用的翻譯叫系統的「可觀測性」,過去我一直苦于尋找一個例子說明什么叫做一個「可觀測」的系統,在 KeyViz 這個項目上,我找到了對這點絕佳的體現。

舉幾個直觀的小例子,你知道 TPC-C 測試「長」什么樣子嗎?請看下圖:

(KeyViz 給 TPC-C 拍攝的「照片」)

圖中左邊零星的亮點是數據導入的過程,橫軸是時間縱軸是數據的分布,可以看到寫入分散多個區塊,右邊密集的色塊是測試在運行的時候系統的實時的讀寫狀態。越暗表示流量越小,越亮表示流量越高,從密集的色塊我們能夠看得出來,workload 基本分布均勻,但是大概有兩處是明顯偏亮色的區域,其中靠上面的一塊有一個特別明顯的局部訪問熱點(最亮的那條線)。

第二個例子,你見過 Sysbench 測試 「長」什么樣子嗎?看看下面。

左邊比較密集的黃塊是導入數據階段,后半段明暗相間的部分是進行 oltp_point_select 測試,因為選取的模式是 uniform 模式,并且導入的時候是 32 線程 32 張測試表,可以看到的數據和分布和訪問都比較均勻。    

如果你看懂了上面兩個小例子,下面是一個小作業,這是我們模擬的一個實際用戶的生產環境的照片,這個用戶的系統遇到了一些瓶頸,你能看出問題嗎?

上面幾個小例子是讓大家對 KeyViz 有個感性的認識,在介紹這個東西背后的意義前,我想先介紹一下 TiDB 這類典型的分布式數據庫的系統架構,方便大家更好的理解。

(一個典型的分布式數據庫的數據分布策略)

顧名思義,分布式數據庫,數據一定是分散在不同機器上的,對于一張表的數據,我們會在邏輯上切分成若干個連續的區間,將這些區間內的數據分給不同的機器存儲,不管是寫入還是讀取,只需要知道目標數據屬于哪個區間,就可以直接到那個機器上進行訪問。然后加上對每一個區間的數據在物理上做多副本冗余實現高可用。如下圖所示,Region 在 TiDB 的內部就是一個個連續的數據區間。

和很多分布式數據庫不太一樣的是,我們的 Region 的大小比較小(默認 96MB) ,另外數據的分布并不是靜態的,而是動態的,Region 會像細胞一樣分裂/合并,也會在不同機器之間移動進行動態的負載均衡。

現在回頭看這個設計,還是覺得無比的簡潔和優雅。對用戶而言再也不用去思考怎么分庫,怎么分表,數據在最底層的細胞就像有生命一樣繁衍和遷徙。

然后問題就來了,對于這樣的一種數據庫而言,有沒有一種辦法能夠直觀的描述的系統的運行時狀態?我怎么知道它是不是「生病」了?我能不能預測這個系統的未來?我能不能發現未知的風險?

過去,不管是業務開發者還是 DBA,衡量一個數據庫的狀態,來來回回就是幾個指標,QPS 、TPS、查詢時間、機器負載(CPU、網絡、磁盤),但是很多時候就像是盲人摸象一樣對于系統的全局我們是不清楚的,在加上在一個分布式的架構下,很多時候,我們可能會被海量的數字蒙蔽了雙眼。有經驗一些的 DBA 可能能從多個指標里通過自己的經驗模糊構建出業務全局狀態,但是到底這個經驗常常是不可描述的,這就是為什么一些老運維,老 DBA 那么值錢的原因,但是我認為這種做事方式是很難 scale 的。現代醫學有 CT 有 B 超有核磁共振,這些現代化的手段極大的促進了現代醫學的發展,因為我們第一次能「看見」我們身體的內部狀態,從而才能得出正確的判斷,在計算機的世界道理也是相通的。

過去經常有朋友問我:「你說我這個業務適不適合使用 TiDB?」這時我們只能問,你的 QPS 多少 TPS 多少,數據量多少?讀寫比?典型查詢?數據分布怎么樣?表結構是什么呀?等等一連串的靈魂拷問,而且很多術語都非常專業,不是在這個行業摸爬滾打很久的老司機可能都搞不太清楚。有些信息可能是敏感的,也不方便共享。所以到底適不適合就成了一個玄學問題,這個問題困擾了我很久,很多時候也只能憑個人感覺和經驗。

其實這個問題也并不是 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 能不能通過這種形式更加理解我們的業務?

最后,我想以我最喜歡的科幻小說《三體:黑暗森林》中的一段話結束這篇文章,大致是面壁人希恩斯在冬眠后被妻子喚醒后的一個場景:

「…與此同時,希恩斯感覺到圍繞著他們的白霧發生了變化,霧被粗化了,顯然是對某一局部進行了放大。他這時發現所謂的霧其實是由無數發光的小微粒組成的,那月光般的光亮是由這些小微粒自身發出的,而不是對外界光源的散射。放大在繼續,小微粒都變成了閃亮的星星。希恩斯所看到的,并不是地球上的那種星空,他仿佛置身于銀河系的核心,星星密密麻麻,幾乎沒有給黑夜留出空隙。

  “每一顆星星就是一個神經元。”山杉惠子說,一千億顆星星構成的星海給他們的身軀鍍上了銀邊。」

作者介紹:黃東旭 PingCAP 聯合創始人兼 CTO,資深基礎軟件工程師,架構師,曾就職于微軟亞洲研究院,網易有道及豌豆莢,。擅長分布式系統以及數據庫開發,在分布式存儲領域有豐富的經驗和獨到的見解。狂熱的開源愛好者以及開源軟件作者,代表作品分布式 Redis 緩存方案 Codis,以及分布式關系型數據庫 TiDB。2015 年創業,成立 PingCAP,在 PingCAP 的主要工作是從零開始設計并研發開源 NewSQL 數據庫 TiDB, 目前 GitHub 上該項目累積 star 數超過 22000+,成為本領域全球頂級的開源項目。

我還沒有學會寫個人說明!

為何經過40多年的發展關系型數據庫依然是主流?

上一篇

新冠肺炎疫情為ICT產業帶來了哪些影響?

下一篇

你也可能喜歡

我眼中的分布式系統可觀測性

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
大丰收注册
pk10北京赛车 我要下载大众麻将并安装 快乐十二选五辽宁一 7星彩 青海11选5查询82期 官方彩票刮刮乐下载 极速飞艇app 福彩开奖结结果 黑龙江6+1 20选8稳赚技巧十分选号万能3码 1分快3怎么玩中奖率高 香港天下彩资料下载 仙牛网配资 四川金7乐官方网站 陕西快乐十分规则 北单比分投注奖金怎么计算