萬億級時序數(shù)據(jù)存儲架構(gòu)設(shè)計

1、 萬億級時序數(shù)據(jù)存儲架構(gòu)設(shè)計萬億架構(gòu)設(shè)計在百度監(jiān)控系統(tǒng) TSDB 的常態(tài)工作負載下，單機每秒處理20 多萬數(shù)據(jù)點，集群每秒處理數(shù)萬次查詢，每天有幾萬億的數(shù)據(jù)點在 TSDB 中穿梭，這樣強悍的性能除了得益于 HBase 本身的性能優(yōu)勢外，架構(gòu)層面的針對性設(shè)計同樣功不可沒。面對已是萬億級別卻仍持續(xù)增長的數(shù)據(jù)規(guī)模，我們設(shè)計了讀/寫分離且無狀態(tài)的“彈性”架構(gòu)；為了在高負載下仍保證低延遲的寫入和查詢，我們將數(shù)據(jù)進行分層，分別存入 Redis、HBase 和 Hadoop；為了不間斷地為業(yè)務(wù)提供可靠的服務(wù)，我們設(shè)計了具備分鐘級自愈能力的異地冗余架構(gòu)；為了節(jié)約存儲成本，我們引入并改進了 Facebook 的

2、時序數(shù)據(jù)壓縮算法。TSDB 的整體架構(gòu)如圖 1 所示。圖1：TSDB整體架構(gòu)可擴展我們希望通過簡單地增加節(jié)點就使系統(tǒng)的處理能力線性提升，如果節(jié)點之間完全對等、互不影響，那么對整個集群而言，增加節(jié)點沒有額外的資源消耗，就可以使處理能力隨著節(jié)點數(shù)線性增長。根據(jù)時序數(shù)據(jù)寫多讀少的特點，我們將讀、寫操作分離，設(shè)計了無狀態(tài)的查詢模塊 Query-engine 和寫模塊 Saver，使得 Query-engine 或 Saver 的每個實例完全對等，并在上游應(yīng)用輪詢或者一致性哈希進行負載均衡。實例的部署是基于百度內(nèi)部的容器方案Matrix，一則可以合理地分配資源，二則由于寫入和查詢隔離開來、互不干擾，其各

3、自的性能均得到充分發(fā)揮。基于 Matrix 的虛擬化方案也使 TSDB 能夠在分鐘級完成任意數(shù)量的實例擴容。高性能在圖 2 的“水平分表”策略中，存在 HBase 里的數(shù)據(jù)被按時間劃分到了不同的 Slice，老的 Slice 訪問壓力相對較小，減輕了系統(tǒng)處理這部分數(shù)據(jù)的負載。圖2：按時間水平分表然而最新的一個 Slice 仍然會保持很高的熱度，相對集中的負載仍然給 HBase 集群帶來不小的壓力。因此，我們利用內(nèi)存緩存了部分熱點數(shù)據(jù)(查詢量相對更多的數(shù)據(jù))，以空間換取更低的查詢響應(yīng)時間，同時分流HBase 的查詢壓力。緩存能力由百度運維部 DBA 團隊的 BDRP 平臺提供。但由于數(shù)據(jù)量太大，

4、緩存一小時的數(shù)據(jù)需要較多的內(nèi)存資源，我們在性能和成本之間做了權(quán)衡，選擇只將核心指標數(shù)據(jù)寫入緩存。在大批量查詢歷史數(shù)據(jù)的場景中，查詢的頻率不高，對數(shù)據(jù)時效性的要求也較低，其目標數(shù)據(jù)通常是冷數(shù)據(jù)，因此我們把這部分數(shù)據(jù)從 Saver 的流量中復制出來，定期地灌入獨立的 Hadoop 集群，將此類查詢壓力從 HBase 分流出去。經(jīng)過 Hadoop 和 Redis 的查詢分流，HBase 仍然存儲全量的數(shù)據(jù)，但其只承接常規(guī)的趨勢圖查詢請求以及從緩存穿透的請求。低成本為了降低數(shù)據(jù)的存儲成本，我們引入了 Facebook 在論文Gorilla: A Fast, Scalable, In-Memory Ti

5、me Series Database中介紹的一種時序數(shù)據(jù)壓縮算法（見圖 3），它能夠達到 10 倍的壓縮比，我們將其進行改造后應(yīng)用到了緩存中。圖3：Facebook Gorilla中的壓縮算法示意圖Gorilla 中的壓縮算法較容易理解，其核心思想是增量壓縮，不僅針對數(shù)據(jù)點取值進行壓縮，且對時間戳應(yīng)用了一種 Delta-of-Delta 壓縮方法。經(jīng)過壓縮的數(shù)據(jù)點，其存儲空間占用可以“bit”計，算法對于周期穩(wěn)定、取值變化幅度較小的數(shù)據(jù)的壓縮效果尤其好。然而，這種增量壓縮的算法中，后一個數(shù)據(jù)點的壓縮結(jié)果依賴前一個數(shù)據(jù)點的壓縮結(jié)果，這要求在集群中為每個時間序列維護壓縮的狀態(tài)，論文未對其分布式實現(xiàn)

6、做詳細的介紹，我們將數(shù)據(jù)壓縮成Byte 流，以 Key-Value 的方式存儲在 Redis 中。此外，論文中的算法僅支持浮點型數(shù)值，而我們改造后的算法還支持整數(shù)型和統(tǒng)計型數(shù)值（即上文提到的 StatisticsValue，每一個具有 max、min、sum、count 四個統(tǒng)計值）。數(shù)據(jù)壓縮的整體方案在實際使用中為我們節(jié)省了 80% 的存儲空間，額外的 CPU 消耗不超過 10%。高可用冗余是高可用的一大法寶，我們使用了簡單有效的異地互備的方案，即冗余出一整套集群和數(shù)據(jù)來實現(xiàn)高可用。寫入時，客戶端將數(shù)據(jù)雙寫到兩個集群，查詢時通過動態(tài)路由表或百度名字服務(wù)（Baidu Naming Servic

7、e, BNS）訪問到其中一個集群（圖 4），在此基礎(chǔ)上我們具備故障自愈機制，可以實現(xiàn)分鐘級的單機房故障自愈。圖4：異地互備總結(jié)近年來，TSDB 在智慧城市、物聯(lián)網(wǎng)和車聯(lián)網(wǎng)等等領(lǐng)域都有著十分廣泛的應(yīng)用，更是成為監(jiān)控場景的標配基礎(chǔ)服務(wù)。從實際的需求出發(fā)，我們認為 TSDB 的架構(gòu)設(shè)計思路和功能側(cè)重點并不局限于文中所述。技術(shù)上，在大規(guī)模的時序數(shù)據(jù)存儲系統(tǒng)中，我們選擇了HBase作為底層存儲，但并不代表 HBase 在任何場景下都是最合適的選擇；在應(yīng)用上，TSDB 也會與分布式計算、數(shù)據(jù)挖掘、異常檢測甚至 AI 技術(shù)進行深度結(jié)合，將會面臨更加復雜和富有挑戰(zhàn)的場景。我們設(shè)想將 TSDB 抽象成各種功能組件，能夠根據(jù)不同場景的特點，靈活地搭配各個功能組件，以滿足不同的需求。例如在數(shù)據(jù)量級較小的時候可以基于 MySQL 進行單機存儲；或者作為緩存層直接基于內(nèi)存存儲；或者利用 Elasticsearch 的強大檢