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

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

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

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

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

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

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

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

1. 阿里的CCO（Customer Chief Officer）通過阿里小蜜來向C端消費者提供查詢服務。
2. 阿里媽媽為廣告主（B端）提供廣告圈選服務。
3. 達摩院無人車包裹配送服務。

...

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

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

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

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

Hologres高可用架構設計

1. 計算儲存分離架構提高系統擴充套件靈活性

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

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

1. Shared Disk/Storage （共享儲存）：有一個分散式的儲存叢集，每個計算節點像訪問單機資料一樣訪問這個共享儲存上的資料；這種架構的儲存層可以比較方便的擴充套件，但是計算節點需要引入分散式協調機制保證資料同步和一致性，因此計算節點的可擴充套件性有一個上限。
2. Shared Nothing：每個計算節點自己掛載儲存，一個節點只能處理一個分片的資料，節點之間可以通訊，最終有一個彙總節點把資料進行彙總。這種架構能比較方便的擴充套件，但是它的缺點是節點failover需要等待資料載入完成之後才能提供服務；並且儲存和計算需要同時擴容，不夠靈活。擴容後，有漫長的資料rebalance過程。
3. 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的操作，主要應用場景包括：

1. 資料實時複製、同步場景，典型的場景就是把一張Hologres的行存表複製成一張列存表，行存支援點查點寫，列存支援多維分析型需求，同步的邏輯通常由Flink支撐。這個是Hologres在V1.1版本之前的一種典型用法。在Hologres 1.1中支援了行列共存表後，可以一張表滿足行存和列存兩種需求。
2. 實現事件的全鏈路驅動，通過Flink消費Hologres Binlog，實現事件驅動的加工開發，完成ODS向DWD，DWD向DWS等的全實時加工作業。

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

​

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問題。

應用場景：

1. 單例項內的查詢高可用：當一個Shard所在Worker發生故障時，可以通過前端階段的重試操作，將請求重定向到副本Shard所在Worker，從而應用異常無感知。
2. 通過負載均攤，實現更高吞吐：同一份資料由多個Shard共同對外提供服務，不同的查詢路由到不同的Shard所在節點，從而實現負載在多個Shard間的均衡，QPS可以顯著提升，對於每次查詢只訪問確定Shard的場景（例如點查場景）提升明顯。
3. 機器故障快速Failover：從Hologres V1.1版本開始，採用全新恢復機制，Shard恢復速度在一分鐘以內，可用性進一步增強。

​

• 多例項讀寫分離

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

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

應用場景：

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

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

​

• 多例項跨城容災

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

應用場景：

1. 災備：在不同的Region，部署有不同的儲存叢集（Pangu），資料在同步後會分別儲存在不同的儲存叢集上，當發生某個Region不可用時，異地備份的例項可以繼續對外提供服務。
2. 叢集遷移：機房的容量空間總是有限，經常會發生因為不可控原因，需要將例項從某個機房遷移到其他機房，甚至從某個Region遷移到其他Region，使用者希望遷移過程儘可能是對業務無感的。因此可以通過Replication機制，實現例項狀態在叢集間的遷移。
3. 熱升級：熱升級過程中，需要業務服務能力不中斷，屬於高速公路上換髮動機的需求，因此需要系統具備某種類似“滾動”升級的能力。通過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的物理隔離更適合線上服務。

​

通常來說，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，請大家持續關注！

原文連結
本文為阿里雲原創內容，未經允許不得轉載。

​