簡介：本文將會從阿里巴巴雙11場景出發，分析實時數倉面臨的高可用挑戰以及針對性設計。

2021年阿里巴巴雙11完美落下為帷幕，對消費者來說是一場購物盛宴，對背后的業務支撐技術人來說，更是一場年度大考。在這場大考中，一站式實時數倉Hologres以每秒11.2億條的高速寫入，和每秒1.1億次的查詢峰值（包含點查和OLAP查詢），交出了滿意的答卷，穩定高效地支撐了阿里巴巴雙11核心應用場景。

這是一站式實時數倉Hologres誕生的第5年，也是支撐阿里巴巴雙11核心場景的第4年。這也證明實時數倉技術已經開始從幕后走到臺前，支撐起更多的在線生產系統，并在性能、穩定性、高可用性等方面經受住了嚴苛的考驗。

本文將會從阿里巴巴雙11場景出發，分析實時數倉面臨的高可用挑戰以及針對性設計。

可用性、成本、復雜度的綜合挑戰

傳統上，實時數倉（數據倉庫）是一個非生產系統，主要面向內部客戶，支撐實時大屏、實時報表等場景。用戶對它的穩定性、可用性的要求相較于訂單、購物車這樣的生產系統要弱很多，只要能繼續使用，即使實時數倉短暫不可用或者有明顯波動，影響也不是很大。

而隨著實時數倉開始對外提供服務，業務對系統的可用性、穩定性都提出了更高更嚴苛的要求。特別是如果提供的是to C的服務，那要求就更高了。

舉幾個Hologres被用在阿里生產系統中的例子：

阿里的CCO（Customer Chief Officer）通過阿里小蜜來向C端消費者提供查詢服務。

阿里媽媽為廣告主（B端）提供廣告圈選服務。

達摩院無人車包裹配送服務。

...

這些系統的最大特點是他們都是生產系統，如果系統不穩定或者不可用，那么影響會非常大。

具體到雙11這樣的極端場景，在流量洪峰下要做好生產高服務質量、達到高可用對任何系統都是一件極具挑戰的事。傳統分布式系統是通過副本和隔離機制來實現可用性和一致性，而要實現生產可用的高可用也需要面臨一定的取舍和挑戰：

• 面向流量洪峰時的可擴展能力
• 系統因意外或者故障宕機時的快速恢復能力
• 主備切換時的數據一致性問題
• 保證高性能的同時資源隔離能力
• 多副本隔離帶來的資源成本問題
• .......

通過本文，我們將會介紹，一站式實時數倉Hologers的高可用架構設計和實踐，從而達到低成本、可擴展、高可用的生產服務能力。

Hologres高可用架構設計

1. ? 計算存儲分離架構提高系統擴展靈活性

實時數倉技術不管是面向分析型場景還是服務型場景，所處理的數據量級、場景復雜度都遠比傳統數據庫要高，尤其是互聯網、電商等行業，活動促銷多，大促和日常所處理的流量完全不一樣，這就非常考驗系統的資源水平擴展能力。

在傳統的分布式系統中，常用的存儲計算架構有如下三種：

Shared Disk/Storage （共享存儲）：有一個分布式的存儲集群，每個計算節點像訪問單機數據一樣訪問這個共享存儲上的數據；這種架構的存儲層可以比較方便的擴展，但是計算節點需要引入分布式協調機制保證數據同步和一致性，因此計算節點的可擴展性有一個上限。

Shared Nothing：每個計算節點自己掛載存儲，一個節點只能處理一個分片的數據，節點之間可以通信，最終有一個匯總節點把數據進行匯總。這種架構能比較方便的擴展，但是它的缺點是節點failover需要等待數據加載完成之后才能提供服務；并且存儲和計算需要同時擴容，不夠靈活。擴容后，有漫長的數據rebalance過程。

Storage Disaggregation（存儲計算分離架構）：存儲和Shared Storage類似，有一個分布式的共享存儲集群，計算層處理數據的模式和Shared Nothing類似，數據是分片的，每個shard只處理自己所在分片的數據，每個計算節點還可以有本地緩存。

這種存儲計算分離的架構好處在于：

• 一致性處理簡單：計算層只需要保證同一時刻只有一個計算節點寫入同一分片的數據。
• 擴展性更靈活：計算和存儲可以分開擴展，計算不夠擴計算節點，存儲不夠擴存儲節點。這樣在大促等場景上會非常靈活。計算資源不夠了，馬上擴容計算就好了，不需要像Shared Nothing那樣做耗時耗力的數據rebalance；也不會出現Shared Nothing那樣，出現單機的存儲容量瓶頸。
• 計算節點故障恢復快：計算節點發生failover之后，數據可以按需從分布式的共享存儲異步拉取。因此，failover的速度非常快。

在架構上，Hologres采用的是第3種存儲計算分離架構，Hologres的存儲使用的是阿里自研的Pangu分布式文件系統（類似HDFS）。用戶可以根據業務需求進行彈性擴縮容，輕松應對在線系統不同的流量峰值。

2.多形態Replication解決數據讀寫分離

Replication（復制）是實現高可用的必備技術，通過不同形態的Replication設計，快速將數據在節點間、集群間進行復制，實現隔離和SLA保障。

Hologers同時支持了邏輯Replication和物理Replication，下面將會針對Hologres的Replication功能做具體介紹。

1）基于Binlog的邏輯Replication

類似于傳統數據庫MySQL中的Binlog概念，在Hologres中，Binlog用來記錄數據庫中表數據的修改記錄，比如Insert/Delete/Update的操作，主要應用場景包括：

數據實時復制、同步場景，典型的場景就是把一張Hologres的行存表復制成一張列存表，行存支持點查點寫，列存支持多維分析型需求，同步的邏輯通常由Flink支撐。這個是Hologres在V1.1版本之前的一種典型用法。在Hologres 1.1中支持了行列共存表后，可以一張表滿足行存和列存兩種需求。

實現事件的全鏈路驅動，通過Flink消費Hologres Binlog，實現事件驅動的加工開發，完成ODS向DWD，DWD向DWS等的全實時加工作業。

在Hologres中，邏輯Replication依賴Binlog實現，發生變更的表作為Publication發布變更事件，加工邏輯處理后寫入Subscription側。用戶可以訂閱一個表的Binlog轉成Record，寫入到另外一張表里，實現邏輯上的復制功能。這種做法可以天然做到不同Workload的隔離，但是它有兩個問題：它是一個最終一致性的模型，很難做到強一致；另一個是它消耗了兩份資源，使用兩份存儲，并且寫入鏈路的資源也得有兩份。

因此Hologres也實現了物理Replication。

2）物理Replication

在Hologres中，物理Replication是基于WAL log的復制，我們可以把存儲引擎看成是狀態機，WAL log是這個狀態機的輸入。當我們要對某個Shard做Replication的時候，我們會起一個Follower Shard讀取當前最新的WAL log進行回放（replay），同時Leader Shard又有新的WAL產生，Follower Shard會從Leader Shard訂閱最新的WAL，不斷的回放，從而達到和Leader Shard一致的狀態。如果需要保證Follower Shard上的可見性，我們可以在讀請求中加一個強一致的選項，問一下Follower Shard和Leader Shard之間WAL log的回放差距，等補齊差距后再返回查詢結果。

Follower Shard回放WAL log的過程中，對WAL log中指向的數據文件可以進行復制。也可以只進行引用，其中復制的方式稱為非共享存儲模式，引用的方式稱為共享存儲模式。

基于此，Hologres實現了3種形態的物理Replication：

1.單實例多副本：一個實例內采用Shard級多副本機制，可用來實現跨進程高可用，讀寫分離，同時因為副本可動態增加，能輕松支持高并發的讀。

2.多實例讀寫分離：不同的實例之間共享一份存儲，實現計算跨機房高可用，通常用于讀寫分離場景，并支持高并發的讀場景

3.多實例容災：多個實例之間不共享存儲，實現計算和存儲服務的跨機房高可用，支持讀寫分離，讀的高并發，版本的熱升級和存儲系統的遷移等功能

• 單實例多副本

Hologres數據分片單元是Shard，Shard可以有多個副本，但是存儲只有一份。平時，查詢流量可以被各個副本均攤，從而實現高QPS。當某一個副本failover以后，流量可以快速被導到其他副本。并且Shard的故障恢復非常輕量，只需回放部分WAL，沒有數據的復制。基于單實例內多副本機制，可以很方便的實現計算的可擴展性，并快速解決物理機單機failover問題。

應用場景：

單實例內的查詢高可用：當一個Shard所在Worker發生故障時，可以通過前端階段的重試操作，將請求重定向到副本Shard所在Worker，從而應用異常無感知。

通過負載均攤，實現更高吞吐：同一份數據由多個Shard共同對外提供服務，不同的查詢路由到不同的Shard所在節點，從而實現負載在多個Shard間的均衡，QPS可以顯著提升，對于每次查詢只訪問確定Shard的場景（例如點查場景）提升明顯。

機器故障快速Failover：從Hologres V1.1版本開始，采用全新恢復機制，Shard恢復速度在一分鐘以內，可用性進一步增強。

• 多實例讀寫分離

和單實例內多副本的Replication相比，跨實例的Replication實現了Meta的物理復制。

Hologres 在V1.1版本，支持了共享存儲的多實例部署方案。在該方案中，主實例具備完整能力，數據可讀可寫，權限、系統參數可配置，而子實例處于只讀狀態，所有的變更都通過主實例完成，實例之間共享一份數據存儲，實例間數據異步實時同步。

應用場景：

1.讀寫分離：這個方案實現了完整的讀寫分離功能，保障不同業務場景的SLA，在高吞吐的數據寫入和復雜的架構作業、OLAP、AdHoc查詢、線上服務等場景中，負載之間物理上完全隔離，不會因寫入產生查詢的抖動。

2.多類型負載細粒度資源分配：一個主實例可以配置多個只讀從實例，實例之間可以根據業務情況配置不同規格，例如使用256Core作為寫入和加工實例，512Core作為OLAP只讀實例，128Core作為在線Serving實例，32Core作為開發測試實例。

• 多實例跨城容災

多實例非共享存儲的Replication，可以理解為傳統意義上的災備功能，支持容災，異地多活，并實現讀寫分離和讀的高并發，同樣也可以基于多個實例實現讀的高可用。除此之外，還可以進行版本熱升級，存儲系統遷移。

應用場景：

災備：在不同的Region，部署有不同的存儲集群（Pangu），數據在同步后會分別保存在不同的存儲集群上，當發生某個Region不可用時，異地備份的實例可以繼續對外提供服務。

集群遷移：機房的容量空間總是有限，經常會發生因為不可控原因，需要將實例從某個機房遷移到其他機房，甚至從某個Region遷移到其他Region，用戶希望遷移過程盡可能是對業務無感的。因此可以通過Replication機制，實現實例狀態在集群間的遷移。

熱升級：熱升級過程中，需要業務服務能力不中斷，屬于高速公路上換發動機的需求，因此需要系統具備某種類似“滾動”升級的能力。通過Replication機制，可以先克隆出一個實例，在新的實例上完成軟件版本的升級，再將相關的網絡路由等配置接入到新的實例，從而完成無需停機的熱升級。

3.調度系統提高節點failover快速恢復能力

分布式環境failover是不可避免的，當failover發生時，需要高效的檢測，快速的恢復，這就是調度的范疇。

一個Hologres實例有多個HoloWorker，當某一個HoloWorker發生意外、宕機、failover時，通過Hologres的調度系統，可以快速檢測到節點異常，并將異常節點的Service如Frontend、Coordinator、Shard快速調度到另外一個健康的HoloWorker，同時SLB將會將流量導流到新的健康Frontend上。

調度分為計算單元的調度和流量的調度：

1）計算單元的調度

計算單元的調度分為Pod的調度、Pod內子進程調度以及Actor的調度

• Pod的調度利用了K8S的能力，Hologres中被K8S調度的單元是HoloWorker；
• Pod內子進程調度以及Actor的調度是Hologres分布式調度模塊HoloFlow提供的能力。

Hologres中兩種類型的計算單元需要被調度，一類是以子進程模式提供Service，例如Frontend；另一類是以Actor模式提供的Service，例如某一個分片的數據服務Shard。HoloFlow提供了這兩類服務的健康檢測以及調度的能力。

2）流量的調度

流量的調度又分為外部流量和內部流量的調度。

• 外部流量即入口流量，這部分調度是SLB提供的能力，Hologres會定時監測Frontend的健康狀態，一旦某個Frontend不健康了，流量就會從SLB上摘除。
• 內部流量Hologres提供了內部的健康檢測和服務發現機制，例如StoreMaster提供了Shard的健康檢測和服務發現機制，一旦某個Shard不健康，Coordinator就會把流量導到這個Shard健康的Replica上。

通過Hologres的調度系統，實現了節點故障、Failover的快速檢測以及自動調度恢復能力，滿足業務的穩定性需求，提高系統可用性。

4.多層次隔離輕松應對不同業務SLA

隨著實時數倉在生產系統越來越廣泛的應用，不同的業務也有著不同的SLA訴求，比如雙11時，老板和運營對交易數據的查詢需求比較高，物流端又希望物流訂單能實時高效刷新，開發又希望數據能快速寫入，不要影響后面的數據查詢和分析....

具體到Hologres，一個實例支持不同的Workload，包括點查點寫，批量導入，交互式分析等。那么不同Workload的SLA需要被保障，例如批量導入不能影響交互式分析的延時，交互式分析的請求不能影響實時寫入的實效性等；Hologres也支持多租戶同時使用，不同租戶之間也不能相互影響；

以上描述的場景都是隔離的范疇，相對來說隔離級別越高，成本越大，資源利用率越低。在進程內部實現低成本可用的隔離是一個很有技術挑戰的事情。

Hologres實現了多個層次的隔離手段。如下圖是上面介紹的Replication（復制）和隔離的關系，復制本質上是在不同的機器/容器中服務同一份數據（或其復本），所以本質上是一種物理隔離。在物理隔離外，Hologres還支持資源組隔離、調度組和（SchedulingGroup）隔離，用戶可以在成本和SLA上做tradeoff，滿足不同用戶對隔離的需求。

1）物理機和容器隔離

在物理機和容器隔離上，Hologers是通過k8s來部署，利用k8s的Node Selector/Affinity以及Taints/Tolerations等功能，可以比較方便的實現實例和實例間容器的隔離。對于一些對SLA要求非常高的客戶，我們還可以對機器單獨打標，只允許某一個實例的容器調度到打標的機器上，從而實現機器級別的隔離，防止其他實例的干擾。

2）資源組隔離

在Hologres中，多租戶的隔離需求是通過資源組來實現的。Hologres的資源組隔離本質上是線程級別的隔離。實例內的Worker可以按照CPU、內存、IO劃分為不同的資源組。不同的用戶加入到不同的資源組，限制每個用戶使用的資源上限，以保證用戶之間的作業互不影響。

例如資源組（1）有50%的資源，資源組（2）有30%的資源，資源組（3）有20%的資源。我們把用戶A綁定的資源組（一）上，用戶B綁定在資源組（2）上，用戶C和D綁定到資源組（3）上。這樣用戶A,B.C發起的請求就會分別調度到不同的資源組。

通過資源組的隔離，實現實例內的資源隔離。這種隔離的優點是能夠在一個實例內實現不同用戶的隔離，保證用戶間的作業不相互影響。這種隔離是一種軟隔離，在隔離效果上是不如基于replication的物理隔離的。所以資源組隔離更適合不同用戶的OLAP查詢隔離等場景，而基于replication的物理隔離更適合線上服務。

3）SchedulingGroup隔離

通常來說，2）中的線程級別隔離模型會有如下問題：

• 在操作系統層面：線程切換是一個不小的開銷。為了把因為等待IO而空閑的CPU利用起來，需要把很多CPU浪費在線程切換上。測試發現，嚴重的時候線程切換能浪費掉一半以上的CPU；
• 線程的數目很難掌握：不同的query、不同的數據、不同的cache命中率，被IO阻塞的可能性差異會非常大，以至于需要的線程數差別非常大。這種情況下，使用固定線程數目的線程池是很難受的。線程多了會引起多余的切換，加劇切換的開銷；線程少了則可能沒法把空閑的CPU都利用起來。而相比于線程切換，線程的創建和銷毀會帶來更大的開銷，所以想要通過動態創建線程來保持恰當的線程數，這也是不太可能的；

理想的方案是能有一種輕量級的調度單元，功能類似于線程，但是創建/銷毀和調度/切換的開銷要小得多。這樣的話：

• 我們可以根據業務邏輯的需要，創建足夠多的“線程”去并發使用CPU，而不必擔心切換的開銷大、或者CPU用不滿；
• 當需要業務邏輯需要使用CPU時，直接根據并發度的需要去創建N個這樣的“線程”，用完即銷毀。這樣就能使業務邏輯靈活控制任務的并行度，不必受制于底層框架；

根據上面的設計理念，Hologres在自研調度系統HOS中，通過一個輕量級調度單元EC來實現。

SchedulingGroup隔離利用了HOS EC調度的能力，同一個Query有多個EC執行，這些EC可以被歸類到一個SchedulingGroup，不同的SchedulingGroup可以用公平的策略瓜分時間片。

SchedulingGroup隔離保證了當系統中同時跑一個大Query（分析型）和一個小Query（點查）的時候，小Query不至于因為搶不到CPU被大Query block住。SchedulingGroup隔離本質上是協程級別的隔離，是Hologres的核心競爭力之一。

Hologres高可用在雙11的落地實踐

Hologers的高可用技術今年也穩定支持了阿里巴巴雙11的核心業務場景，下面來做一一介紹。

1）業務雙聯路+讀寫實例分離（DT團隊實踐）

DT大淘系數據是阿里巴巴集團典型的數據中臺，負責天貓、淘寶、聚劃算等業務大促及日常行業看數需求，通過天貓/淘寶營銷活動分析產品，支持決策層和小二在大促期間進行數據分析及決策。

隨著業務增長和產品的不斷迭代，數據團隊也面臨更復雜的分析需求，技術團隊在保障數據實時性、準確性的同時，還要面臨更高壓力的寫入，在保障整體數據鏈路的穩定性和整體產品的高可用上面臨更嚴格的考驗。

在高可用場景上，今年DT引入了Hologres的讀寫分離能力，并結合全鏈路的主備雙鏈路，在降低單庫出問題概率的同時構建異地主備容災，建立產品核心指標的“復活甲”，通過秒級切換的高可用容災方案，高吞吐寫入和靈活查詢互不干擾，分析查詢QPS增長80%的同時，查詢抖動明顯減少，讓業務擁有底氣和信心去應對隨時可能出現的不可控風險，為整個產品和業務決策分析提供穩定支持，

2）雙鏈路容災+讀寫分離（CCO團隊實踐）

CCO是阿里巴巴集團的客戶體驗事業部，支持的場景包括服務資源調度、實時數據監控等。“客戶第一”價值觀落地的組織保障，是整個經濟體客戶體驗的神經網絡，也是觸達消費者和商家的最前線。

隨著業務的發展，以及行業的整體業務趨勢，以及相應商家和消費者們更加實時和穩定的服務請求。去年是業務上做了雙鏈路寫入和存儲冗余來保證高可用。今年雙11使用了Hologres原生的 只讀實例 和 容災 高可用方案下掉了業務的雙鏈路，省去備用數據鏈路上實時任務開發維護、數據比對的人力投入，減少鏈路切換時的數據不一致等，整體開發人力成本減少200人日，環比去年降低50%以上；減少了100+用于實時重保的備份鏈路作業，減少實時計算資源2000CU。

總結

在過去一年，Hologres引入了多副本、資源隔離、讀寫分離等多種能力，并在今年阿里巴巴核心應用場景中得到了很好的應用，實現了生產高可用。

隨著實時數倉技術被生產系統的廣泛使用，業務對高可用的要求也越來也嚴苛。我們希望通過分享Hologres的高可用設計原理和應用實踐，與行業互通有無，共同為社會的高度發展添磚加瓦。

Hologres是阿里云自研的一站式實時數倉，這個云原生系統融合了實時服務和分析大數據的場景，全面兼容PostgreSQL協議并與大數據生態無縫打通，能用同一套數據架構同時支持實時寫入實時查詢以及實時離線聯邦分析。它的出現簡化了業務的架構，為業務提供實時決策的能力，讓大數據發揮出更大的商業價值。從阿里集團誕生到云上商業化，隨著業務的發展和技術的演進，Hologres也在持續不斷優化核心技術競爭力，為了讓大家更加了解Hologres，我們計劃持續推出Hologres底層技術原理揭秘系列，從高性能存儲引擎到高效率查詢引擎，高吞吐寫入到高QPS查詢等，全方位解讀Hologres，請大家持續關注！

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的技术分享：从双11看实时数仓Hologres高可用设计与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

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