2021年11月23日至12月3日，中國信息通信研究院(以下簡稱“中國信通院”)對第13批分布式分析型數(shù)據(jù)庫共計27款產(chǎn)品進(jìn)行了大數(shù)據(jù)產(chǎn)品能力評測。阿里云實時數(shù)倉Hologres(原阿里云交互式分析)在報表任務(wù)、交互式查詢、壓力測試、穩(wěn)定性等方面通過了中國信通院分布式分析型數(shù)據(jù)庫性能評測(大規(guī)模)，并以8192個節(jié)點(diǎn)刷新了通過該評測現(xiàn)有參評的規(guī)模記錄。

在本次評測中，Hologres是目前通過中國信通院大數(shù)據(jù)產(chǎn)品分布式分析型數(shù)據(jù)庫大規(guī)模性能評測的規(guī)模最大的MPP數(shù)據(jù)倉庫產(chǎn)品。通過該評測，證明了阿里云實時數(shù)倉Hologres能夠作為數(shù)據(jù)倉庫和大數(shù)據(jù)平臺的基礎(chǔ)設(shè)施，可以滿足用戶建設(shè)大規(guī)模數(shù)據(jù)倉庫和數(shù)據(jù)平臺的需求，具備支撐關(guān)鍵行業(yè)核心業(yè)務(wù)數(shù)據(jù)平臺的能力。

在Hologres實例的云原生調(diào)度和運(yùn)維體系建設(shè)上，團(tuán)隊也聯(lián)合阿里云云原生等團(tuán)隊，解決了在超大規(guī)模集群;在運(yùn)維能力建設(shè)上，團(tuán)隊通過自動化、智能化的運(yùn)維體系建設(shè)，解決了實例部署和穩(wěn)定性保障的問題。

一 超大規(guī)模部署面臨的挑戰(zhàn)

隨著互聯(lián)網(wǎng)的發(fā)展，數(shù)據(jù)量出現(xiàn)了指數(shù)型的增長，單機(jī)的數(shù)據(jù)庫已經(jīng)不能滿足業(yè)務(wù)的需求。特別是在分析領(lǐng)域，一個查詢就可能需要處理很大一部分甚至全量數(shù)據(jù)，海量數(shù)據(jù)帶來的壓力變得尤為迫切。同時，隨著企業(yè)數(shù)字化轉(zhuǎn)型進(jìn)程的加速，數(shù)據(jù)的時效性變得越來越重要，如何利用數(shù)據(jù)更好的賦能業(yè)務(wù)成為企業(yè)數(shù)字化轉(zhuǎn)型的關(guān)鍵。

大數(shù)據(jù)實時數(shù)倉場景相比數(shù)據(jù)庫的規(guī)模往往是成倍增加：數(shù)據(jù)量增加(TB級、PB級甚至是EB級)、數(shù)據(jù)處理的復(fù)雜度更高、性能要更快、服務(wù)和分析要同時滿足等等。

而使用過開源OLAP系統(tǒng)的用戶，尤其是通過開源OLAP自建集群的用戶，都有一些比較深刻的體會，就是部署和運(yùn)維困難，包括ClickHouse、Druid等，都面臨了如下難題：

• 如何滿足集群的快速交付和彈性伸縮
• 如何定義服務(wù)的可用性指標(biāo)和SLA體系
• 存儲計算一體，機(jī)型選擇和容量規(guī)劃困難
• 監(jiān)控能力弱，故障恢復(fù)慢，自愈能力缺失

同時，隨著規(guī)模的增加，規(guī)模優(yōu)勢和高性能吞吐下的壓力，實時數(shù)倉的部署和運(yùn)維難度呈指數(shù)級增加，系統(tǒng)面臨了諸多調(diào)度、部署和運(yùn)維上的各種挑戰(zhàn)：

• 如何解決調(diào)度能力滿足在單集群萬臺規(guī)模下服務(wù)實例的秒級拉起和彈性伸縮能力的要求;
• 如何解決大規(guī)模集群自身的容量規(guī)劃、穩(wěn)定性保障、機(jī)器自愈，提升相關(guān)的運(yùn)維效率;
• 如何實現(xiàn)實例和集群的監(jiān)控時效和準(zhǔn)確性的雙重要求，包括怎么在分鐘內(nèi)完成問題發(fā)現(xiàn)和分鐘級的問題解決

得益于阿里云強(qiáng)大的云原生基礎(chǔ)服務(wù)研發(fā)能力，實時數(shù)倉Hologres通過優(yōu)秀的架構(gòu)設(shè)計和阿里云大數(shù)據(jù)智能運(yùn)維中臺的能力等多個核心能力的建設(shè)，解決這些挑戰(zhàn)，為用戶提供了一個性能強(qiáng)大、擴(kuò)展能力優(yōu)秀、高可靠、免運(yùn)維的實時數(shù)倉產(chǎn)品。

本文將會從超大規(guī)模部署與運(yùn)維體系建設(shè)出發(fā)，分析超大規(guī)模實時數(shù)倉面臨的挑戰(zhàn)和針對性的設(shè)計及解決方案，實現(xiàn)在高負(fù)載高吞吐的同時支持高性能，并做到生產(chǎn)級別的高可用。

二 基于云原生的大規(guī)模調(diào)度架構(gòu)設(shè)計

隨著云技術(shù)的興起，原來越多的系統(tǒng)剛開始利用Kubernetes作為容器應(yīng)用集群化管理系統(tǒng)，為容器化應(yīng)用提供了自動化的資源調(diào)度，容器部署，動態(tài)擴(kuò)容、滾動升級、負(fù)載均衡，服務(wù)發(fā)現(xiàn)等功能。

Hologres在設(shè)計架構(gòu)之初就提前做了優(yōu)化，采用云原生容器化部署的方式，基于Kubernetes作為資源調(diào)度系統(tǒng)，滿足了實時數(shù)倉場景上的超大規(guī)模節(jié)點(diǎn)和調(diào)度能力。Hologres依賴的云原生集群可以支持超過1萬臺服務(wù)器，單實例可以達(dá)到8192個節(jié)點(diǎn)甚至更大的規(guī)模。

1 Kubernetes萬臺調(diào)度

Kubernetes官方公布集群最大規(guī)模為5000臺，而在阿里云場景下，為了滿足業(yè)務(wù)規(guī)模需求、資源利用率提升等要求，云原生集群規(guī)模要達(dá)萬臺。眾所周知Kubernetes是中心節(jié)點(diǎn)式服務(wù)，強(qiáng)依賴ETCD與kube-apiserver，該塊是性能瓶頸的所在，突破萬臺規(guī)模需要對相關(guān)組件做深度優(yōu)化。同時要解決單點(diǎn)Failover速度問題，提升云原生集群的可用率。

通過壓測，模擬在萬臺node和百萬pod下的壓力，發(fā)現(xiàn)了比較嚴(yán)重的響應(yīng)延遲問題，包括：

• etcd大量的讀寫延遲，并且產(chǎn)生了拒絕服務(wù)的情形，同時因其空間的限制也無法承載 Kubernetes 存儲大量的對象;
• API Server 查詢延遲非常高，并發(fā)查詢請求可能導(dǎo)致后端 etcd oom;
• Controller 處理延時高，異?；謴?fù)時間久，當(dāng)發(fā)生異常重啟時，服務(wù)的恢復(fù)時間需要幾分鐘;
• Scheduler 延遲高、吞吐低，無法適應(yīng)業(yè)務(wù)日常運(yùn)維的需求，更無法支持大促態(tài)的極端場景

為了突破k8s集群規(guī)模的瓶頸，相關(guān)團(tuán)隊做了詳細(xì)調(diào)研，找到了造成處理瓶頸的原因：

• 發(fā)現(xiàn)性能瓶頸在kubelet，每10s上報一次自身全量信息作為心跳同步給k8s，該數(shù)據(jù)量小則幾KB大則10KB+，當(dāng)節(jié)點(diǎn)到達(dá)5000時，會對kube-apiserver和ETCD造成寫壓力。
• etcd 推薦的存儲能力只有2G，而萬臺規(guī)模下k8s集群的對象存儲要求遠(yuǎn)遠(yuǎn)超過這個要求，同時要求性能不能下降;
• 用于支持集群高可用能力的多API Server部署中，會出現(xiàn)負(fù)載不均衡的情況，影響整體吞吐能力;
• 原生的scheduler 性能較差，能力弱，無法滿足針對混部、大促等場景下的能力。

針對該情況，做了如下優(yōu)化，從而達(dá)到萬臺規(guī)模調(diào)度：

• etcd設(shè)計新的內(nèi)存空閑頁管理算法，大幅優(yōu)化etcd性能;
• 通過落地 Kubernetes 輕量級心跳、改進(jìn) HA 集群下多個 API Server 節(jié)點(diǎn)的負(fù)載均衡，解決了APIServer的性能瓶頸;
• 通過熱備的方式大幅縮短了 controller/scheduler 在主備切換時的服務(wù)中斷時間，提高了整個集群的可用性;
• 通過支持等價類處理以及隨機(jī)松弛算法的引入，提升了Scheduler的調(diào)度性能

三 Hologres運(yùn)維體系建設(shè)

1 Hologres運(yùn)維體系總覽

針對OLAP體系碰到的問題和痛點(diǎn)，以及在超大規(guī)模部署壓力下的運(yùn)維挑戰(zhàn)，同時依托阿里云大數(shù)據(jù)運(yùn)維中臺，我們設(shè)計了Hologres的運(yùn)維體系，解決資源和集群交付等自動化問題、集群和實例級別的實時可觀測性問題和智能化的自愈體系，提升Hologres的SLA到生產(chǎn)可用級別。

2 集群自動化交付

Hologres 是完全基于云原生的方式設(shè)計和實現(xiàn)的，通過存儲計算分離的方式，解耦了計算資源和存儲資源;其中計算節(jié)點(diǎn)的部署通過K8s集群進(jìn)行部署和拉起。通過自研的運(yùn)維管理系統(tǒng)ABM，在集群交付上，我們對集群進(jìn)行抽象設(shè)計，分離出資源集群和業(yè)務(wù)集群的概念;資源集群的交付，ABM和底層平臺進(jìn)行打通，進(jìn)行資源集群的創(chuàng)建和容量維持;在業(yè)務(wù)集群上，ABM提供基于K8s 概念的部署模板，將管控等節(jié)點(diǎn)在資源集群上快速拉起，完成交付。

3 可觀測性體系

系統(tǒng)的可觀測性能幫助業(yè)務(wù)更好的管理集群水位和問題排查等，從而提升企業(yè)級管控能力。在可觀測性上，不僅需要透出更加簡單易懂的監(jiān)控指標(biāo)，還需要有成熟的日志采集系統(tǒng)，從而實現(xiàn)更簡單的運(yùn)維，只需要為業(yè)務(wù)問題負(fù)責(zé)。基于阿里云的監(jiān)控產(chǎn)品和Hologres的可觀測性需求，我們設(shè)計了Hologres的實時監(jiān)控能力。

Metric監(jiān)控體系

為了支持詳細(xì)的系統(tǒng)能力觀察、性能監(jiān)控、快速的問題定位和debug，Hologres 支持了非常豐富的Metric監(jiān)控體系，這也對整個Metric鏈路的采集、存儲和查詢提出了非常高的要求。在監(jiān)控鏈路上，Hologres 選擇了阿里巴巴自研的Emon平臺，除了支持億級Metric每秒的寫入，Emon還支持自動downsample、聚合優(yōu)化等能力;同時在后端我們通過實時鏈路，可以把核心Metric吐到云監(jiān)控，方便用戶自助的對實例進(jìn)行監(jiān)控觀察和問題定位。

日志采集和監(jiān)控

在日志采集上，Hologres采用了成熟的云產(chǎn)品SLS，可以支持中心式的日志排查和過濾 ;同時考慮到Hologres的日志量也非常龐大，在采集上采用了分模塊和分級的機(jī)制，在控制成本的同時，能很好的解決問題排查和審計的需要。同時，SLS也提供了基于關(guān)鍵字等方式的監(jiān)控方案，可以對關(guān)鍵錯誤進(jìn)行告警，以方便及時處理問題。

基于元倉的可用性監(jiān)控

在Metric和日志的采集及告警上，更多的是體現(xiàn)某一個模塊上的問題，上面的手段還無法完整的回答某一個實例的可用性。基于此，我們構(gòu)建了一個Hologres運(yùn)維數(shù)倉，通過多維度的事件、狀態(tài)進(jìn)行綜合判斷實例是否工作正常。在元倉中會收集和維護(hù)多維度數(shù)據(jù)，包括實例的meta數(shù)據(jù)、Hologres中各模塊的可用性判斷標(biāo)準(zhǔn)、實例各模塊的狀態(tài)、事件中心，包括運(yùn)維事件、客戶事件、系統(tǒng)事件等;在進(jìn)行實例可用性判斷的同時，元倉還提供了用于實例診斷、實例巡檢等各種數(shù)據(jù)。當(dāng)前元倉的能力已經(jīng)產(chǎn)品化發(fā)布為慢Query日志，用戶可以通過慢query日志，進(jìn)行自助化問題診斷和調(diào)優(yōu)。

4 智能運(yùn)維提升產(chǎn)品SLA

在可觀測性完善的基礎(chǔ)上，為了提升問題定位的速度和縮短實例恢復(fù)時間，即提升Hologres的MTTR，基于阿里云大數(shù)據(jù)運(yùn)維中臺提供的基礎(chǔ)能力和智能運(yùn)維方案，我們構(gòu)建了完整的Hologres SLA管理體系和故障診斷及自愈體系。

SLA體系

基于Hologres運(yùn)維元倉的數(shù)據(jù)和實例可用性定義，我們建立了Hologres實例級別可用性的管理系統(tǒng)，實例可用性數(shù)據(jù)會進(jìn)入ABM的SLI數(shù)據(jù)庫，SLI根據(jù)數(shù)據(jù)和條件觸發(fā)實例可用性監(jiān)控，在監(jiān)控發(fā)出的同時，會觸發(fā)實例的診斷，系統(tǒng)根據(jù)診斷結(jié)果，判斷是否進(jìn)行自愈，如果是已知可以自動恢復(fù)情況，會觸發(fā)自愈，進(jìn)行故障的自動恢復(fù);如果是未知情況，會觸發(fā)生成人工工單，工單系統(tǒng)會由人跟進(jìn)完成，并逐步形成自愈的action。

智能巡檢

智能巡檢解決的是集群或者實例的一些隱性和不緊急的問題，避免一些小問題的日積月累引發(fā)質(zhì)變影響線上的穩(wěn)定性;除了一些比較清晰定義的巡檢項，智能巡檢還引入了聚類算法等，對系統(tǒng)指標(biāo)進(jìn)行分析，這也會幫助我們發(fā)現(xiàn)一些集群中的離散節(jié)點(diǎn)，進(jìn)行及時處理，避免問題節(jié)點(diǎn)導(dǎo)致影響整個實例的可用性。

智能診斷和自愈

智能診斷既依賴運(yùn)維元倉的數(shù)據(jù)，同時還會依賴診斷相關(guān)的算法支持，包括日志聚類、根因分析等，進(jìn)行錯誤日志的聚類，對聚類結(jié)果進(jìn)行打標(biāo)。在ABM提供的算法和工程能力支持下，實例診斷已經(jīng)在幫助業(yè)務(wù)進(jìn)行問題的快速定位，提升問題解決的效率，縮短了實例的MTTR。

四 Hologres產(chǎn)品級運(yùn)維能力

除了上面介紹的Hologres服務(wù)本身的運(yùn)維穩(wěn)定性保障。在Hologres 產(chǎn)品側(cè)，通過多種方式提升系統(tǒng)的穩(wěn)定性：

1、高可用架構(gòu)

采用高可用架構(gòu)設(shè)計，穩(wěn)定支撐阿里集團(tuán)歷年雙11等大促流量峰值，經(jīng)歷大規(guī)模生產(chǎn)考驗，包括

存儲計算分離架構(gòu)提升系統(tǒng)擴(kuò)展靈活性

多形態(tài)replication解決數(shù)據(jù)讀寫分離，主要包括多副本提高吞吐、單實例資源組隔離、多實例共享存儲高可用

調(diào)度系統(tǒng)提升節(jié)點(diǎn)failover快速恢復(fù)能力

2、多元化的系統(tǒng)可觀性指標(biāo)

除了Hologres本身架構(gòu)的設(shè)計，同時也為用戶提供多元化的觀測指標(biāo)，實時監(jiān)控集群狀態(tài)和事后復(fù)盤，無需復(fù)雜操作，只需為業(yè)務(wù)負(fù)責(zé)：

多維度監(jiān)控指標(biāo)：CPU、內(nèi)存、連接數(shù)、IO等監(jiān)控指標(biāo)實時查詢，實時預(yù)警;

慢query日志：發(fā)生的慢Query或失敗Query通過時間、plan、cpu消耗等各項指標(biāo)進(jìn)行診斷、分析和采取優(yōu)化措施，提高自助診斷能力;

執(zhí)行計劃可視化：通過多種可視化展現(xiàn)的方式，對Query進(jìn)行運(yùn)行分析、執(zhí)行分析，詳細(xì)算子解讀，并進(jìn)行優(yōu)化建議引導(dǎo)，避免盲目調(diào)優(yōu)，降低性能調(diào)優(yōu)門檻，快速達(dá)到性能調(diào)優(yōu)的目的。

五 總結(jié)

通過對大規(guī)模調(diào)度下面臨的調(diào)度性能瓶頸的分析和針對性的優(yōu)化，Hologres 可以完成8192節(jié)點(diǎn)甚至更大規(guī)模的實例交付和擴(kuò)縮容。同時基于云原生的Hologres智能運(yùn)維體系建設(shè)，解決了大規(guī)模集群和實例下面臨的運(yùn)維效率和穩(wěn)定性提升問題，使得Hologres在阿里巴巴內(nèi)部核心場景歷經(jīng)多年雙11生產(chǎn)考驗，在高負(fù)載高吞吐的同時實現(xiàn)高性能，實現(xiàn)生產(chǎn)級別的高可用，更好的支撐業(yè)務(wù)，為企業(yè)的數(shù)字化轉(zhuǎn)型提供了良好的支持。

阿里云實時數(shù)倉Hologres：

https://www.aliyun.com/product/bigdata/hologram?spm=a2cbu.13822726.0.0.56711a9cIKkCzv