概要：剛剛結束的2020天貓雙11中，MaxCompute交互式分析（下稱Hologres）+實時計算Flink搭建的雲原生實時數倉首次在核心數據場景落地，為大數據平臺創下一項新紀錄。藉此之際，我們將陸續推出雲原生實時數倉雙11實戰系列內容，本篇將重點介紹Hologres在阿里巴巴網絡監控部門成功替換Druid的最佳實踐，並助力雙11實時網絡監控大盤毫秒級響應。
3...
2...
1...
00:00:00 。購物車，結算，提交訂單，付款
00:01:00...。滴，您的支付寶消費xxx萬元。
億萬人同時參與的千億級項目，破記錄的峰值58萬筆/秒，剁手黨們在整個交易過程中如絲般順滑，好像參加了一個假的雙11，而這一切的背後都離不開阿里巴巴網絡能力的強大支持。隨著技術的發展，尤其是近年來雲和電商業務的愈發興盛，基礎網絡也變得越來越龐大和複雜，如何保障這張膨脹網絡的穩定性，提供雲上用戶暢通無阻的購物體驗，對網絡系統建設者和運維者說更是極大的考驗。
理論上來說，故障不可避免，但是如果能夠做到快速發現，定位，修復甚至預防故障，縮短故障時長，即可讓用戶輕微或無感是穩定性追求的終極目標。2015年的微軟提出了pingmesh，成為業界事實的解決方案，但是由於天生的某些缺陷性，導致故障發現時間過長。阿里巴巴網絡研發事業部從2017年就開始研發站在世界前沿的探測系統AliPing，AliPing實時系統的出現將阿里故障發現帶入了秒級響應，數據採集到處理到大盤呈現最快時間延遲在數秒之間，告警+故障定位分鐘級，7*24全天候監控著整個阿里的網絡狀況。
AliPling的核心架構圖如下：
在整個系統中，監控大盤作為故障發現的核心元素，承擔著實時呈現網絡狀況的重任，每一條曲線的起起伏伏，就有可能代表用戶的業務在受損， 如何快速實時展示網絡狀態，並預警/發現網絡故障，幫助用戶迅速止血，這對於監控團隊的監控大盤也是重大的考驗。對於監控人員使用的監控大盤來說，困難有多個：
1）數據時效性要求高：需要實時的將處理完的結構化數據（告警，監控）7*24小時的呈現在使用者（GOC, 各個或者監控人員面前，以便及時地發現處理全阿里+螞蟻的網絡故障。
2）數據源複雜：網絡數據源眾多，業務場景眾多，有一分鐘數百G的流量監控數據，也有一分鐘幾十K的IDC網絡數據，如何將這些不同種類，不同數據量的業務數據，納入監控體系發現異常，對整體端到端監控大盤來說也是一種考驗。
3）數據指標維度多：對於監控人員來說，需要監控的數據指標維度特別多，可以看作是一個複雜的OLAP查詢系統，如何根據自身業務場景從大盤中實時查詢所需的業務數據，這對於處理後端數據的OLAP框架也是一個重大挑戰。
技術選型
對於監控大盤來說，用戶的組合查詢條件具有不可預知性，其結構化數據沒有辦法提前算好，只通過OLAP(聯機分析處理)技術，實時對基礎數據分析組合，並將結果呈現給用戶。Aliping大盤實際就是OLAP技術體現，將不同維度的故障數據（機房、區域、DSW、ASW、PSW、部門、應用等等）通過大盤形式展現在用戶面前。
2017年在AliPing系統實施的時候，我們對比了多項OLAP數據庫， 其中選擇比較有代表性的進行了對比：
1）HIVE
底層基於HDFS存儲，將SQL語句分解為MapReduce任務進行查詢。其優點是學習成本低，可以通過類SQL語句快速實現簡單的MapReduce統計，不必開發專門的MapReduce應用，十分適合數據倉庫的統計分析。但是由於底層是HDFS分佈式文件系統的限制性，不能進行常見的CUD(對錶記錄操作)操作，同時Hive需要從已有的數據庫或日誌進行同步最終入到HDFS文件系統中，當前要做到增量實時同步都相當困難。最重要的是：查詢速度慢，無法滿足監控大盤秒級相應需求。
2）Kylin
傳統OLAP根據數據存儲方式的不同分為ROLAP（relational olap）以及MOLAP（multi-dimension olap）。ROLAP 以關係模型的方式存儲用作多為分析用的數據，優點在於存儲體積小，查詢方式靈活，然而缺點也顯而易見，每次查詢都需要對數據進行聚合計算，為了改善短板，ROLAP使用了列存、並行查詢、查詢優化、位圖索引等技術。Kylin中數據立方的思想就是以空間換時間，通過定義一系列的緯度，對每個緯度的組合進行預先計算並存儲。有N個緯度，就會有2的N次種組合。所以最好控制好緯度的數量，因為存儲量會隨著緯度的增加爆炸式的增長，產生災難性後果。這個對於龐大的網絡數據和不可確定性維度組合，是不可以接受的。
3）ClickHouse
這個是由俄羅斯yandex公司開發的，專門為在線數據分析而設計。根據官方提供的文檔來看，ClickHouse 日處理記錄數"十億級"（沒測過）。其機制採用列式存儲，數據壓縮，支持分片，支持索引，並且會將一個計算任務拆分分佈在不同分片上並行執行，計算完成後會將結果彙總，支持SQL和聯表查詢但是支持不夠好，支持實時更新，自動多副本同步。總體來說，ClickHouse還算不錯，但是由於不夠成熟，官方支持度不夠，bug也多多，最重要的是集團內也沒看到人用，只能放棄。
4）Druid
是一種能對歷史和實時數據提供亞秒級別的查詢的數據存儲系統。Druid 支持低延時的數據攝取，靈活的數據探索分析，高性能的數據聚合，簡便的水平擴展。適用於數據量大，可擴展能力要求高的分析型查詢系統。其機制將熱點和實時數據存儲在實時節點（Realtime Node）內存中，將歷史數據存儲在歷史節點（history node）的硬盤中，實時+偽實時的結構，保證查詢基本都在毫秒級。高速攝入，快速查詢正是滿足了我們的需求，同時還有通用計算引擎團隊的有力支持，在早期我們選擇了druid作為了我們監控大盤的OLAP支持系統。
新OLAP網絡監控系統
隨著業務的複雜化，業務進一步增多，Druid使用過程中也暴露出一系列問題：
1）數據量攝入的瓶頸， 集團上雲，流量的引入，使我們數據量激增，數據寫入出現了數次大故障
2）由於業務複雜多變，我們需要增加維度數據，Druid增加相對來說過程比較複雜
3）Druid的查詢方式不友好，有一套自己的查詢語言，對於SQL支持太差，浪費大量時間學習
4）不支持高併發，對於大促來說簡直是災難。有兩年雙十一，我們只能上線踢用戶保證監控大盤可用。
隨著暴露出的問題越來越多，我們也在尋找一款既能替代Druid解決當前問題，又能滿足實時OLAP多維分析場景需求的產品。
也是在集團內其他部門沉澱的最佳實踐中知道Hologres，並且瞭解到Hologres支持行存模式下的高併發點查和列存模式下的實時OLAP多維分析，覺得這一點很貼合我們網絡監控系統的要求，於是就抱著試試的心態先去測試體驗Hologres。通過全鏈路的測試和大量的場景數據驗證，能滿足我們場景需求，於是就決定上線Hologres至正式生產中。
改造後的新OLAP監控系統如下圖所示，整體的數據流程大致如下：
- Kafka實時採集網絡相關的監控指標數據，並寫入Flink中輕度彙總加工
- Flink將初步加工完成的基礎粒度的實時數據實時寫入Hologres中，由Hologres提供統一的存儲
- Hologres直接實時對接監控大屏，大屏實時展示多種監控指標的變化情況，不符合預期的數據實時報警，相應的業務人員立即排查問題並解決。
業務價值
今年也是Hologres第一年參與AIS網絡故障監控的雙11作戰，作為新秀交出了令我們比較滿意的答卷。整體來說對於業務的價值主要表現如下：
1）TB級數據毫秒級響應
對於實時監控來說，時間就是生命線，越快發現故障就能越快止血，如何根據用戶輸入的複雜組合條件，在TB級數據中，僅僅以秒級甚至是毫秒級的響應篩選出符合要求的數據（OLAP），這對很多系統來說都是很大的挑戰，而實戰證明，合理的利用Hologres索引功能，並通過資源的合理分配等，在OLAP實時性上完美的滿足了監控業務的需要。
2）支持高併發
雙11的監控大屏往往需要查詢查詢歷史數據，並根據歷史數據做報警預測，以往的系統最多隻能支撐不到數十用戶的查詢（數10天數據），而Hologres能支撐數百用戶的大規模並行查詢並且依舊沒有達到上限，在今年雙11的0點時，面對數百倍的平時數據量衝擊，監控曲線依舊平滑如舊，毫無滯澀之感。
3）寫入性能高
對於之前數十萬/秒，數百萬/秒的寫入能力，Druid的表現不是很好容易出現湧塞現象，而Hologres可以輕鬆做到，這也就輕鬆解決了我們的實時寫入瓶頸問題。
4）學習成本低
Hologres兼容Postgres，全SQL支持，非常方便新用戶上手，無需再花費時間和精力去研究語法。同時Hologres對於BI工具的兼容性很好，無需做改造就能對接監控大屏，節約大量時間。
對每一個天貓雙11剁手人來說，每一次的絲滑般購物體驗都離不開阿里網絡能力的支撐，而監控大盤就是阿里網絡狀況的眼睛。Hologres作為大盤的核心環節，給大盤持續賦能。但是，作為一個新生兒，HOLO仍然有一些不太成熟的地方，在透明升級、穩定性等環節上依存在提升空間。我們也願意同Hologres一起成長，期待明年雙11 Hologres更優秀的表現。
作者簡介：唐儻，隸屬網絡研發事業部網絡，現從事網絡穩定性開發研究工作，前北郵研究生導師，擁有數個網絡和算法相關專利。