簡介：本篇將重點介紹Hologres在阿里巴巴網絡監控部門成功替換Druid的最佳實踐，并助力雙11實時網絡監控大盤毫秒級響應。

概要：剛剛結束的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更優秀的表現。

作者簡介：唐儻，隸屬網絡研發事業部網絡，現從事網絡穩定性開發研究工作，前北郵研究生導師，擁有數個網絡和算法相關專利。

原文鏈接：https://developer.aliyun.com/article/778707?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的揭秘双11丝滑般剁手之路背后的网络监控技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。