美團OCTO萬億級數據中心計算引擎技術解析

美團點評自研的 OCTO 數據中心（簡稱 Watt）日均處理萬億級數據量，該系統具有較好的擴展能力及實時性，千臺實例集羣周運維成本低於10分鐘。本文將詳細闡述 Watt 計算引擎的演進歷程及架構設計，同時詳細介紹其全面提高計算能力、吞吐能力、下降運維成本所採用的各項技術方案。但願能給你們一些啓發或者幫助。

1、OCTO數據中心簡介

1.1 系統介紹

1.1.1 OCTO系統介紹

OCTO 是美團標準化的服務治理基礎設施，目前幾乎覆蓋公司全部業務的治理與運營。OCTO 提供了服務註冊發現、數據治理、負載均衡、容錯、灰度發佈等治理功能，致力於提高研發效率，下降運維成本，並提高應用的穩定性。OCTO 最新演進動態細節可參考《美團下一代服務治理系統 OCTO2.0 的探索與實踐》一文。

1.1.2 OCTO數據中心業務介紹

OCTO 數據中心爲業務提供了立體化的數字驅動服務治理能力，提供了多維度的精確時延 TP（Top Percent，分位數，最高支持6個9）、QPS、成功率等一系列核心指標，粒度方面支持秒級、分鐘級、小時級、天級，檢索維度支持多種複雜查詢（如指定調用端 IP + 服務端各接口的指標，指定主機 + 接口的指標等）。這些功能有效地幫助開發人員在複雜的分佈式調用關係拓撲內出現異常時，能快速定位到問題，也有助於研發人員全方位掌控系統的穩定性情況。

目前 Watt 承載日均超萬億條數據的10餘個維度精確準實時統計。而伴隨着數據量的迅猛增加，其整個系統架構也經歷了全面的技術演進。

1.1.3 OCTO原架構介紹

OCTO計算引擎在重構以前，也面臨諸多的問題，其原始架構設計以下：

1. 採集層：每一個業務應用實例部署一個採集代理，代理經過將採集數據用批量 RPC 的方式發送給路由節點。
2. 路由層：每一個路由節點隨機收到各服務的數據後，將同一服務的全部數據，用相似 IP 直連的方式經過 RPC 發送到計算層的同一個計算節點。同服務數據彙總到同計算節點才能進行特定服務各個維度的聚合計算。
3. 計算層：每一個計算節點採用 Akka 模型，節點同時負責分鐘、小時、天粒度的數據計算集。每一個計算集裏面又有10個子計算 actor，每一個子計算 actor 對應的是一個維度。採用「先計算指標，再存儲數據」的準實時模式。
4. 存儲層：準實時數據使用 HBase 存儲，元數據及較大數據採用 KV 存儲（美團內部系統Cellar）及 MySQL 存儲。

1.2 問題、目標與挑戰

1.2.1 原架構面臨的問題

1. 計算節點有狀態，異常沒法自動化遷移。計算層部署的每一個節點平均負責200+服務的統計。一個節點 OOM 或宕機時，其管理的200個服務的數據會丟失或波動，報警等依託數據的治理功能也會異常。此外計算節點 OOM 時也不宜自動遷移受影響的服務，需人工介入處理（異常的緣由多是計算節點沒法承載涌入的數據量，簡單的遷移易引起「雪崩」），每週投入的運維時間近20小時。
2. 系統不支持水平擴展。計算節點的壓力由其管理的服務調用量、服務內維度複雜度等因素決定。大致量的服務需單獨分配高配機器，業務數據膨脹計算節點能力不匹配時，只能替換更高性能的機器。
3. 系統總體穩定性不高。數據傳輸採用 RPC，單計算節點響應慢時，易拖垮全部路由層的節點並引起系統「雪崩」。
4. 熱點及數據傾斜明顯，策略管理複雜。按服務劃分熱點明顯，存在一個服務數據量比整個計算節點200個服務總數多的狀況，部分機器的 CPU 利用率不到10%，部分利用率在90%+。改變路由策略易引起新的熱點機器，大致量服務數據增加時須要縱向擴容解決。舊架構時人工維護160餘個大服務到計算節點的映射關係供路由層使用。

舊架構日承載數據量約3000億，受上述缺陷影響，系統會頻繁出現告警丟失、誤告警、數據不許、數據延遲幾小時、服務發佈後10分鐘後才能看到流量等多種問題。此外，數據體量大的服務也不支持部分二級維度的數據統計。

1.2.2 新架構設計的目標

基於上述問題總結與分析，咱們新架構總體的目標以下：

1. 高吞吐、高度擴展能力。具有20倍+的水平擴展能力，支持日10萬億數據的處理能力。
2. 數據高度精確。解決節點宕機後自愈、解決數據丟失問題。
3. 高可靠、高可用。無計算單點，全部計算節點無狀態；1/3計算節點宕機無影響；具有削峯能力。
4. 延時低。秒級指標延遲TP99<10s；分鐘指標延遲TP99<2min。

1.2.3 新架構面臨的挑戰

在日計算量萬億級別的體量下，實現上述挑戰以下：

1. 數據傾斜明顯的海量數據，數據指標的維度多、指標多、時間窗口多，服務間體量差別達百萬倍。
2. TP分位數長尾數據是衡量系統穩定性最核心的指標，全部數據要求非採樣擬合，實現多維度下精確的分佈式TP數據。
3. 架構具有高穩定性，1/3節點宕機不需人工介入。
4. 每一年數據膨脹至2.4倍+，計算能力及吞吐能力必須支持水平擴展。

5. TP 數據是衡量服務最核心的指標之一，但在萬億規模下，精確的準實時多維度分佈式 TP 數據是一個難題，緣由詳細解釋下：常規的拆分計算後聚合是沒法計算精確TP數據的，如將一個服務按 IP（通常按 IP 劃分數據比較均勻）劃分到3個子計算節點計算後彙總，會面臨以下問題：

   • 假設計算得出 IP1 的 TP99 是100ms、QPS 爲50；IP2 的 TP99 是10ms、QPS 爲50；IP3 的 TP99 是1ms，QPS爲50。那麼該服務總體 TP99 是（100ms x 50 + 10ms x 50 + 1ms x 50）/ (50 + 50 + 50) = 37ms嗎？ 並不是如此，該服務的真實 TP99 多是 100ms，在沒有全量樣本狀況下沒法保證準確的TP值。
   • 假設不須要服務全局精確的時延 TP 數據，也不能夠忽略該問題。按上述方式拆分併合並後，服務按接口維度計算的 TP 數據也失去了準確性。進一步說，只要不包含 IP 查詢條件的全部 TP 數據都失真了。分位數這類必須創建在全局樣本之上纔能有正確計算的統計值。

2、計算引擎技術設計解析

2.1 方案選型

大數據計算應用每每基於實時或離線計算技術體系建設，但Flink、Spark、OLAP等技術棧在日超萬億級別量級下，支持複雜維度的準實時精確 TP 計算，對資源的消耗很是較大，總結以下：

2.2 系統設計思路

1. 解決穩定性問題，思路是（1）將計算節點無狀態化（2）基於心跳機制自動剔除異常節點並由新節點承載任務（3）消息隊列削峯。
2. 解決海量數據計算問題，思路是（1）在線&離線計算隔離，二者的公共子計算前置只計算一次（2）高併發高吞吐能力設計（3）理論無上限的水平擴展能力設計。
3. 解決熱點問題，思路是（1）優化計算量分配算法，如均衡 Hash（2）理論無上限的水平擴展能力設計。
4. 解決水平擴展問題，思路（1）是將單節點沒法承載的計算模式改成局部分佈式子計算並彙總，但這種方式可能會對數據準確性形成較大影響，數據統計領域精確的分佈式分位數纔是最難問題，另外多維條件組織對分佈式改造也至關不利。（備註：其中在1.2.3第五條有詳細的解釋）
5. 解決海量數據分佈式多維精確 TP 計算，採用局部分佈式計算，而後基於拓撲樹組織數據計算流，在前置的計算結果精度不丟失的前提下，多階段逐級降維獲得全部的計算結果。

2.3 技術方案詳細解析

2.3.1 數據流解析

系統根據待統計的維度構建了一棵遞推拓撲樹，以下圖所示。其中黃色的部分表明消息隊列（每一個矩形表明一個 topic），綠色部分表明一個計算子集羣（消費前置 topic 多個 partition，統計本身負責維度的數據指標並存儲，同時聚合壓縮向後繼續發）。除「原始採集數據 topic 外」，其餘 topic 和 consumer 所在維度對應數據的檢索條件（如標紅二級 topic ：主機+接口，表明同時指定主機和接口的指標查詢數據），紅色箭頭表明數據流向。

拓撲樹形結構的各個子集羣所對應的維度標識集合，必爲其父計算集羣對應維度標識集合的真子集（以下圖最上面鏈路，「主機+接口+遠程服務」3個維度必定包含「主機+接口」兩個維度。「主機+接口」兩個維度包含「主機」維度）。集羣間數據傳輸，採用批量聚合壓縮後在消息隊列媒介上通訊完成，在計算過程當中實現降維。

2.3.2 計算模式解析

下面詳細介紹數據拓撲樹中分佈式子集羣的計算模式：

1. 首先，維度值相同的全部數據會在本層級集羣內落到同一計算節點。每一個計算子集羣中的各計算節點，從消息隊列消費獲得數據並按自身維度進行聚合（前置集羣已經按當前集羣維度指定分發，因此聚合率很高），獲得若干計數卡表（計數卡表即指定維度的時延、錯誤數等指標與具體計數的映射 Map）。
2. 其次，將聚合後的計數卡表與現有的相同維度合併計算，並在時間窗口存儲指標。
3. 若計算集羣有後續的子計算集羣，則基於後繼集羣的目標維度，根據目標維度屬性作散列計算，並將相同散列碼的計數卡表聚合壓縮後發到後繼 partition。
4. 離線的天級計算複用了三級維度、二級維度的多項結果，各環節前面計算的結果爲後面多個計算集羣複用，任何一個服務的數據都是在分佈式計算。此外，整個計算過程當中維護着技術卡表的映射關係，對於 TP 數據來講就是精確計算的，不會失真。

整個計算過程當中，前置計算結果會被多個直接及間接後續子計算複用（如三級聚合計算對二級和一級都是有效的），在很大程度上減小了計算量。

2.3.3 關鍵技術總結

1.高吞吐 & 擴展性關鍵設計

• 去計算熱點：組織多級散列數據流，逐級降維。
• 降計算量：前置子計算結果複用，分佈式多路歸併。
• 降網絡IO，磁盤IO：優化 PB 序列化算法，自管理 MQ 批量。
• 去存儲熱點：消除 HBase Rowkey 熱點。
• 無鎖處理：自研線程分桶的流批處理模型，全局無鎖。
• 全環節水平擴展：計算、傳輸、存儲均水平擴展。

2.系統高可靠、低運維、數據準確性高於5個9關鍵設計

• 無狀態化 + 快速自愈：節點無狀態化，宕機秒級感知自愈。
• 異常實時感知：異常節點經過心跳摘除，異常數據遷移回溯。
• 故障隔離容災：各維度獨立隔離故障範圍；多機房容災。
• 逐級降維過程當中數據不失真，精確的 TP 計算模式。

3.提高實時性關鍵設計

• 流式拓撲模型，分佈式子計算結果複用，計算量逐級遞減。
• 無鎖處理：自研線程分桶的流批處理模型，全局無鎖。
• 異常實時監測自愈：計算節點異常時迅速 Rebalance，及時自愈。
• 秒級計算流獨立，內存存儲。

3、優化效果

1. 目前日均處理數據量超萬億，系統可支撐日10萬億+量級並具有良好的擴展能力；秒峯值可處理5億+數據；單服務日吞吐上限提高1000倍+，單服務能夠支撐5000億數據計算。
2. 最大時延從4小時+下降到2min-，秒級指標時延 TP99 達到 6s；平均時延從4.7分+下降到1.5分-，秒級指標平均時延6s。
3. 上線後集羣未發生雪崩，同時宕機1/3實例2秒內自動化自愈。
4. 支持多維度的準實時精確 TP 計算，最高支持到 TP 6個9；支持全部服務全部維度統計。
5. 千餘節點集羣運維投入從周20小時+下降至10分-。

4、總結

本文提供了一種日均超萬億規模下多維度精確 TP 計算的準實時數據計算引擎方案，適用於在超大規模數字化治理體系建設中，解決擴展性、實時性、精確性、穩定性、運維成本等問題。美團基礎研發平臺歡迎業界同行一塊兒交流、探討。

5、做者簡介

繼東，業祥，成達，張昀，均來自基礎架構服務治理團隊，研發工程師。

招聘信息

美團基礎架構團隊誠招高級、資深技術專家，Base 北京、上海。咱們致力於建設美團全公司統一的高併發高性能分佈式基礎架構平臺，涵蓋數據庫、分佈式監控、服務治理、高性能通訊、消息中間件、基礎存儲、容器化、集羣調度等基礎架構主要的技術領域。歡迎有興趣的同窗投送簡歷到 tech@meituan.com（郵件標題註明：美團基礎架構團隊）。

閱讀更多技術文章，請掃碼關注微信公衆號-美團技術團隊！