概要：剛剛結束的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直接實時對接監控大屏，大屏實時展示多種監控名額的變化情況，不符合預期的資料實時報警，相應的業務人員立即排查問題并解決。
揭秘雙11絲滑般剁手之路背後的網絡監控技術
業務價值
今年也是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更優秀的表現。
作者簡介：唐傥，隸屬網絡研發事業部網絡，現從事網絡穩定性開發研究工作，前北郵研究所學生導師，擁有數個網絡和算法相關專利。