作者 | 梅醬
來源 | 阿裡技術公衆号
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功能做具體介紹。
基于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。
實體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：
- 單執行個體多副本：一個執行個體内采用Shard級多副本機制，可用來實作跨程序高可用，讀寫分離，同時因為副本可動态增加，能輕松支援高并發的讀。
- 多執行個體讀寫分離：不同的執行個體之間共享一份存儲，實作計算跨機房高可用，通常用于讀寫分離場景，并支援高并發的讀場景
- 多執行個體容災：多個執行個體之間不共享存儲，實作計算和存儲服務的跨機房高可用，支援讀寫分離，讀的高并發，版本的熱更新和存儲系統的遷移等功能
- 單執行個體多副本
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底層技術原理揭秘系列，從高性能存儲引擎到高效率查詢引擎，高吞吐寫入到高QPS查詢等，全方位解讀Hologres。
參考連結：
1、2020年VLDB的論文《Alibaba Hologres: A cloud-Native Service for Hybrid Serving/Analytical Processing》：
http://www.vldb.org/pvldb/vol13/p3272-jiang.pdf2、Hologres揭秘：首次公開！阿裡巴巴雲原生實時數倉核心技術揭秘：
https://developer.aliyun.com/article/7791183、Hologres揭秘：首次揭秘雲原生Hologres存儲引擎：
https://developer.aliyun.com/article/779284?4、Hologres揭秘：Hologres高效率分布式查詢引擎：
https://developer.aliyun.com/article/784506?5、Hologres揭秘：高性能原生加速MaxCompute核心原理：
https://developer.aliyun.com/article/784755?6、Hologers揭秘：優化COPY，批量導入性能提升5倍+：
https://developer.aliyun.com/article/785001?7、Hologres揭秘：如何支援超高QPS線上服務（點查）場景：
https://developer.aliyun.com/article/785647?做智能世界的乘風者，講述“我與阿裡雲IoT”的故事
這一年，#阿裡雲IoT# 的千萬開發者的作品，盛開在江河湖泊田間園區商場小區，讓萬物智聯成為現實。這一年，#阿裡雲乘風者計劃#給了每一位技術達人盡情揮灑書寫，洞見思想火花的舞台。記錄這個美好而偉大的過程吧，”我與阿裡雲IoT”，期待聽到你的故事，有獎征文。
點選這裡，檢視活動詳情！