2021年11月23日至12月3日，中國資訊通訊研究院（以下簡稱“中國信通院”）對第13批分散式分析型資料庫共計27款產品進行了大資料產品能力評測。阿里雲即時數倉Hologres（原阿里雲互動式分析）在報表任務、互動式查詢、壓力測試、穩定性等方面通過了中國信通院分散式分析型資料庫效能評測（大規模），並以8192個節點重新整理了透過該評測現有參評的規模記錄。
在本次評測中，Hologres是目前透過中國信通院大資料產品分散式分析型資料庫大規模效能評測的規模最大的MPP資料倉庫產品。透過該評測，證明了阿里雲實時數倉Hologres能夠作為資料倉庫和大資料平臺的基礎設施，可以滿足使用者建設大規模資料倉庫和資料平臺的需求，具備支撐關鍵行業核心業務資料平臺的能力。
在Hologres例項的雲原生排程和運維體系建設上，團隊也聯合阿里云云原生等團隊，解決了在超大規模叢集；在運維能力建設上，團隊透過自動化、智慧化的運維體系建設，解決了例項部署和穩定性保障的問題。
一 超大規模部署面臨的挑戰
隨著網際網路的發展，資料量出現了指數型的增長，單機的資料庫已經不能滿足業務的需求。特別是在分析領域，一個查詢就可能需要處理很大一部分甚至全量資料，海量資料帶來的壓力變得尤為迫切。同時，隨著企業數字化轉型程序的加速，資料的時效性變得越來越重要，如何利用資料更好的賦能業務成為企業數字化轉型的關鍵。
大資料即時數倉場景相比資料庫的規模往往是成倍增加：資料量增加（TB級、PB級甚至是EB級）、資料處理的複雜度更高、效能要更快、服務和分析要同時滿足等等。
而使用過開源OLAP系統的使用者，尤其是透過開源OLAP自建叢集的使用者，都有一些比較深刻的體會，就是部署和運維困難，包括ClickHouse、Druid等，都面臨瞭如下難題：
-
如何滿足叢集的快速交付和彈性伸縮 -
如何定義服務的可用性指標和SLA體系
-
儲存計算一體，機型選擇和容量規劃困難 -
監控能力弱，故障恢復慢，自愈能力缺失
同時，隨著規模的增加，規模優勢和高效能吞吐下的壓力，即時數倉的部署和運維難度呈指數級增加，系統面臨了諸多排程、部署和運維上的各種挑戰：
-
如何解決排程能力滿足在單叢集萬臺規模下服務例項的秒級拉起和彈性伸縮能力的要求；
-
如何解決大規模叢集自身的容量規劃、穩定性保障、機器自愈，提升相關的運維效率；
-
如何實現例項和叢集的監控時效和準確性的雙重要求，包括怎麼在分鐘內完成問題發現和分鐘級的問題解決
得益於阿里雲強大的雲原生基礎服務研發能力，即時數倉Hologres透過優秀的架構設計和阿里雲大資料智慧運維中臺的能力等多個核心能力的建設，解決這些挑戰，為使用者提供了一個性能強大、擴充套件能力優秀、高可靠、免運維的即時數倉產品。
本文將會從超大規模部署與運維體系建設出發，分析超大規模即時數倉面臨的挑戰和針對性的設計及解決方案，實現在高負載高吞吐的同時支援高效能，並做到生產級別的高可用。
二 基於雲原生的大規模排程架構設計
隨著雲技術的興起，原來越多的系統剛開始利用Kubernetes作為容器應用叢集化管理系統，為容器化應用提供了自動化的資源排程，容器部署，動態擴容、滾動升級、負載均衡，服務發現等功能。
Hologres在設計架構之初就提前做了最佳化，採用雲原生容器化部署的方式，基於Kubernetes作為資源排程系統，滿足了即時數倉場景上的超大規模節點和排程能力。Hologres依賴的雲原生叢集可以支援超過1萬臺伺服器，單例項可以達到8192個節點甚至更大的規模。
1 Kubernetes萬臺排程
Kubernetes官方公佈叢集最大規模為5000臺，而在阿里雲場景下，為了滿足業務規模需求、資源利用率提升等要求，雲原生叢集規模要達萬臺。眾所周知Kubernetes是中心節點式服務，強依賴ETCD與kube-apiserver，該塊是效能瓶頸的所在，突破萬臺規模需要對相關元件做深度最佳化。同時要解決單點Failover速度問題，提升雲原生叢集的可用率。
透過壓測，模擬在萬臺node和百萬pod下的壓力，發現了比較嚴重的響應延遲問題，包括：
-
etcd大量的讀寫延遲，並且產生了拒絕服務的情形，同時因其空間的限制也無法承載 Kubernetes 儲存大量的物件； -
API Server 查詢延遲非常高，併發查詢請求可能導致後端 etcd oom； -
Controller 處理延時高，異常恢復時間久，當發生異常重啟時，服務的恢復時間需要幾分鐘； -
Scheduler 延遲高、吞吐低，無法適應業務日常運維的需求，更無法支援大促態的極端場景
為了突破k8s叢集規模的瓶頸，相關團隊做了詳細調研，找到了造成處理瓶頸的原因：
-
發現效能瓶頸在kubelet，每10s上報一次自身全量資訊作為心跳同步給k8s，該資料量小則幾KB大則10KB+，當節點到達5000時，會對kube-apiserver和ETCD造成寫壓力。 -
etcd 推薦的儲存能力只有2G，而萬臺規模下k8s叢集的物件儲存要求遠遠超過這個要求，同時要求效能不能下降； -
用於支援叢集高可用能力的多API Server部署中，會出現負載不均衡的情況，影響整體吞吐能力； -
原生的scheduler 效能較差，能力弱，無法滿足針對混部、大促等場景下的能力。
針對該情況，做了如下最佳化，從而達到萬臺規模排程：
-
etcd設計新的記憶體空閒頁管理演算法，大幅最佳化etcd效能； -
透過落地 Kubernetes 輕量級心跳、改進 HA 叢集下多個 API Server 節點的負載均衡，解決了APIServer的效能瓶頸； -
透過熱備的方式大幅縮短了 controller/scheduler 在主備切換時的服務中斷時間，提高了整個叢集的可用性； -
透過支援等價類處理以及隨機鬆弛演算法的引入，提升了Scheduler的排程效能
三 Hologres運維體系建設
1 Hologres運維體系總覽
針對OLAP體系碰到的問題和痛點，以及在超大規模部署壓力下的運維挑戰，同時依託阿里雲大資料運維中臺，我們設計了Hologres的運維體系，解決資源和叢集交付等自動化問題、叢集和例項級別的即時可觀測性問題和智慧化的自愈體系，提升Hologres的SLA到生產可用級別。
2 叢集自動化交付
Hologres 是完全基於雲原生的方式設計和實現的，透過儲存計算分離的方式，解耦了計算資源和儲存資源；其中計算節點的部署透過K8s叢集進行部署和拉起。透過自研的運維管理系統ABM，在叢集交付上，我們對叢集進行抽象設計，分離出資源叢集和業務叢集的概念；資源叢集的交付，ABM和底層平臺進行打通，進行資源叢集的建立和容量維持；在業務叢集上，ABM提供基於K8s 概念的部署模板，將管控等節點在資源叢集上快速拉起，完成交付。
3 可觀測性體系
系統的可觀測效能幫助業務更好的管理叢集水位和問題排查等，從而提升企業級管控能力。在可觀測性上，不僅需要透出更加簡單易懂的監控指標，還需要有成熟的日誌採集系統，從而實現更簡單的運維，只需要為業務問題負責。基於阿里雲的監控產品和Hologres的可觀測性需求，我們設計了Hologres的即時監控能力。
Metric監控體系
為了支援詳細的系統能力觀察、效能監控、快速的問題定位和debug，Hologres 支援了非常豐富的Metric監控體系，這也對整個Metric鏈路的採集、儲存和查詢提出了非常高的要求。在監控鏈路上，Hologres 選擇了阿里巴巴自研的Emon平臺，除了支援億級Metric每秒的寫入，Emon還支援自動downsample、聚合最佳化等能力；同時在後端我們透過即時鏈路，可以把核心Metric吐到雲監控，方便使用者自助的對例項進行監控觀察和問題定位。
日誌採集和監控
在日誌採集上，Hologres採用了成熟的雲產品SLS，可以支援中心式的日誌排查和過濾 ；同時考慮到Hologres的日誌量也非常龐大，在採集上採用了分模組和分級的機制，在控制成本的同時，能很好的解決問題排查和審計的需要。同時，SLS也提供了基於關鍵字等方式的監控方案，可以對關鍵錯誤進行告警，以方便及時處理問題。
基於元倉的可用性監控
在Metric和日誌的採集及告警上，更多的是體現某一個模組上的問題，上面的手段還無法完整的回答某一個例項的可用性。基於此，我們構建了一個Hologres運維數倉，透過多維度的事件、狀態進行綜合判斷例項是否工作正常。
在元倉中會收集和維護多維度資料，包括例項的meta資料、Hologres中各模組的可用性判斷標準、例項各模組的狀態、事件中心，包括運維事件、客戶事件、系統事件等；在進行例項可用性判斷的同時，元倉還提供了用於例項診斷、例項巡檢等各種資料。當前元倉的能力已經產品化釋出為慢Query日誌，使用者可以透過慢query日誌，進行自助化問題診斷和調優。
4 智慧運維提升產品SLA
在可觀測性完善的基礎上，為了提升問題定位的速度和縮短例項恢復時間，即提升Hologres的MTTR，基於阿里雲大資料運維中臺提供的基礎能力和智慧運維方案，我們構建了完整的Hologres SLA管理體系和故障診斷及自愈體系。
1 SLA體系
基於Hologres運維元倉的資料和例項可用性定義，我們建立了Hologres例項級別可用性的管理系統，例項可用性資料會進入ABM的SLI資料庫，SLI根據資料和條件觸發例項可用性監控，在監控發出的同時，會觸發例項的診斷，系統根據診斷結果，判斷是否進行自愈，如果是已知可以自動恢復情況，會觸發自愈，進行故障的自動恢復；如果是未知情況，會觸發生成人工工單，工單系統會由人跟進完成，並逐步形成自愈的action。
2 智慧巡檢
智慧巡檢解決的是叢集或者例項的一些隱性和不緊急的問題，避免一些小問題的日積月累引發質變影響線上的穩定性；除了一些比較清晰定義的巡檢項，智慧巡檢還引入了聚類演算法等，對系統指標進行分析，這也會幫助我們發現一些叢集中的離散節點，進行及時處理，避免問題節點導致影響整個例項的可用性。
3 智慧診斷和自愈
智慧診斷既依賴運維元倉的資料，同時還會依賴診斷相關的演算法支援，包括日誌聚類、根因分析等，進行錯誤日誌的聚類，對聚類結果進行打標。在ABM提供的演算法和工程能力支援下，例項診斷已經在幫助業務進行問題的快速定位，提升問題解決的效率，縮短了例項的MTTR。
四 Hologres產品級運維能力
除了上面介紹的Hologres服務本身的運維穩定性保障。在Hologres 產品側，透過多種方式提升系統的穩定性：
1、高可用架構
採用高可用架構設計，穩定支撐阿里集團歷年雙11等大促流量峰值，經歷大規模生產考驗，包括
-
儲存計算分離架構提升系統擴充套件靈活性
-
多形態replication解決資料讀寫分離，主要包括多副本提高吞吐、單例項資源組隔離、多例項共享儲存高可用
-
排程系統提升節點failover快速恢復能力
2、多元化的系統可觀性指標
除了Hologres本身架構的設計，同時也為使用者提供多元化的觀測指標，即時監控叢集狀態和事後覆盤，無需複雜操作，只需為業務負責：
-
多維度監控指標：CPU、記憶體、連線數、IO等監控指標即時查詢，即時預警；
-
慢query日誌：發生的慢Query或失敗Query透過時間、plan、cpu消耗等各項指標進行診斷、分析和採取最佳化措施，提高自助診斷能力；
-
執行計劃視覺化：透過多種視覺化展現的方式，對Query進行執行分析、執行分析，詳細運算元解讀，並進行最佳化建議引導，避免盲目調優，降低效能調優門檻，快速達到效能調優的目的。
五 總結
透過對大規模排程下面臨的排程效能瓶頸的分析和針對性的最佳化，Hologres 可以完成8192節點甚至更大規模的例項交付和擴縮容。同時基於雲原生的Hologres智慧運維體系建設，解決了大規模叢集和例項下面臨的運維效率和穩定性提升問題，使得Hologres在阿里巴巴內部核心場景歷經多年雙11生產考驗，在高負載高吞吐的同時實現高效能，實現生產級別的高可用，更好的支撐業務，為企業的數字化轉型提供了良好的支援。
阿里雲即時數倉Hologres：
https://www.aliyun.com/product/bigdata/hologram?spm=a2cbu.13822726.0.0.56711a9cIKkCzv
Redis入門到精通（進階篇）
本課程從Redis入門開始，面向不同層次的學習者設計課程，既可以帶領初學者入門，同時也為已經入門的開發者提供了多個企業級解決方案，並結合當下較為集中的快取問題進行深入剖析，並給出對應的企業級解決方案。
關鍵詞
節點
系統
數倉
阿里雲
即時數倉
