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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 Kubernetes萬臺(tái)調(diào)度

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

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

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

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

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

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

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

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

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

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

2 集群自動(dòng)化交付

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

3 可觀測(cè)性體系

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

Metric監(jiān)控體系

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

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

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

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

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

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

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

SLA體系

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

智能巡檢

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

智能診斷和自愈

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

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

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

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

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

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

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

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

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

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

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

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

執(zhí)行計(jì)劃可視化：通過多種可視化展現(xiàn)的方式，對(duì)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é)

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

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

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