簡介：本文將會介紹今年是如何在去年基礎上進行實時數倉高可用架構升級，併成功大規模落地雙11。
作者 | 梅醬
來源 | 阿里技術公眾號
一 2021年雙11總結
2021年阿里巴巴雙11期間，由CCO+Hologres構建的高可用實時數倉經過2年的迭代，支撐了阿里集團內部從智慧到人工，從應用到資料產品，從B/C到內部運營等數10個核心應用場景，並在雙11實時大屏、實時監控大盤等多個應用場景全面啟動新一代高可用及災備方案，在Hologres主叢集寫入峰值達450萬+每秒的情況下，還能真正做到資料“0”延遲，服務“0”延遲。
相比2020年，今年透過最佳化實時寫入鏈路，在Binlog消費和維表Join流量翻倍的情況下，同等資源下Hologres Binlog讀取峰值達1700萬+每秒，整體水位平穩保持正常高吞吐。同時今年首次在大促核心場景上線新一代高可用及災備方案，取消去年使用的雙例項+雙鏈路的高成本方式，極大降低人力開發、壓測以及運維成本，降低無效雙鏈路任務上百個，減少人力投入50%，節約上千cu計算資源。
下面將會介紹今年是如何在去年基礎上進行實時數倉高可用架構升級，併成功大規模落地雙11。
去年精彩回顧：Hologres是如何完美支撐雙11智慧客服實時數倉的？
二 客戶簡介
CCO是Chief Customer Officer的縮寫，也是阿里巴巴集團客戶體驗事業部的簡稱。在阿里巴巴經濟體內，CCO是“客戶第一”價值觀落地的組織保障，是整個經濟體客戶體驗的神經網路，也是觸達消費者和商家的最前線。“成為新商業的服務生態搖籃”，“讓體驗成為商業的核心競爭力”是我們的願景。憑藉著為消費者、商家和經濟體提供專業服務的小二，為平臺不斷挖掘存量客戶價值的體驗運營專家，為業務發展提供底層支撐的資料、產品和技術人才，我們成為了網際網路行業獨一無二的數字化服務體驗團隊 —— 一支有愛有擔當，富有創造力的“阿里柔軍”。
三 業務挑戰
CCO透過與Hologres高度共建，構建了集實時化、自助化、系統化於一體的使用者體驗實時數倉，完美助力2020年雙11場景，支援上千+服務大屏，削峰30%，節約成本近30%。
但是在2021年，任務規模也相比2020年增長1.5倍，實時資料膨脹2倍以上，如何有效管理資料和資源成為了越來越關鍵的問題，同時2021年大促期間將會面臨更加高併發高吞吐的流量，如何保障實時數倉的高可用，以及保持穩定性和成本的平衡，是今年構建實時數倉的核心挑戰。
2020年雙11，為了應對大促的流量洪峰，在高可用方面，我們花費1個月，投入巨大人力成本，來構建雙鏈路+雙例項的高可用方案，以下為去年雙11的實時數倉架構。這個架構雖然支撐了去年雙11等各種大促流量洪峰，但是在今年更為複雜的環境和外部更多挑戰的情況下，也存在著一定的痛點，主要有以下幾個：
- 浪費資源：資料同時寫入多個例項，滿足主備要求，既浪費了計算資源，也浪費了儲存資源，同時也額外增加了業務的開發成本和運維成本。
- 無法高效保證主備鏈路資料一致性：在資料雙寫時，當某個例項因為因為種種原因出現延遲時，無法與另外一個例項保持完整的資料一致性，無法做到真正的高可靠。
- 運維複雜：雙鏈路意味著需要採用兩套架構，雖然搭建邏輯以及開發邏輯都一致，但是當對主鏈路進行運維釋出（如升降配，bug fixed等）或者邏輯修改時，牽一髮而動全身，還需要同時維護備鏈路，操作比較複雜，運維鏈路長。
為了解決2020年遺留的問題，2021年雙11對實時數倉進行升級，採用新一代高可用及災備方案，在對單鏈路進行充分的壓測評估以及長應急預案外，例項內使用多副本+共享儲存的方式，除了在出現未知問題時可以快速切換副本來提高業務的可用性外，還極大的降低了構建雙鏈路的成本。同時在面對大促和日常流量時，可以快速縮容，提高架構的整體靈活性，在成本和效率上相比去年更加的平衡，實現生成高可用，成功大規模落地雙11。
下面將會具體介紹今年的高可用及災備方案。
四 業務方案
整體資料鏈路同2020年保持一致：資料來源資料透過Flink ETL處理後實時寫入Hologres，行存表用於線上服務場景，列存表用於複雜多維分析場景，再由Hologres透過透過不同的場景直接對接上層應用。
在去年方案的基礎上，對架構進行升級，對Hologres服務和分析場景進行叢集隔離以及高可用部署，組成當下實時數倉3.0架構。
注：部分不核心業務由於歷史原因暫時無法下線，所以由Hologres同步至某DB引擎提供服務。
升級1：多種隔離方式滿足生產高可用
在高可用部分，今年的方案升級主要如下：
1）服務和分析叢集隔離
採用行存和列存兩個例項叢集，有效隔離行存服務和列存分析場景下對於QPS/RT不同要求的能力。
- 行存叢集承載核心實時資料，主要承擔與Flink高頻的互動（資料寫入、Binlog消費、維表關聯），同時提供比如資料特徵、使用者畫像等線上點查服務，實現線上推薦。
- 列存叢集主要用於複雜多維分析，由Flink實時寫入，應用於實時資料大屏、實時監控等一系列核心場景
2）分析場景讀寫分離高可用和災備
對於大促期間高保的列存分析核心場景，啟用多例項共享儲存讀寫分離高可用和非共享儲存災備的能力建設。
- 讀寫分離高可用：多個例項共享儲存，主例項具備完整能力，資料可讀可寫，許可權、系統引數可配置，而子例項處於只讀狀態，所有的變更都透過主例項完成，例項之間共享一份資料儲存，例項間資料非同步實時同步。這個方案實現了完整的讀寫分離功能，保障不同業務場景的SLA，在高吞吐的資料寫入和複雜的架構作業、OLAP、AdHoc查詢、線上服務等場景中，負載之間物理上完全隔離，不會因寫入產生查詢的抖動。同時當某個子例項出現問題時，可以在其餘子例項間緊急切換，也不會帶來資料一致性的問題。
- 災備：在多機房部署多個例項，例項間不共享儲存，資料透過例項間進行實時同步，資料冗餘在多個檔案系統，在叢集出現問題時，可做緊急切換。
日增量資料在數十TB的規模下，無論是共享儲存的讀寫分離高可用還是非共享儲存的災備模式，同機房/跨機房實時資料同步延遲都低於10ms，完全滿足我們對於大促高保場景的資料時效性要求。
升級2：實時鏈路最佳化提高吞吐
對於核心場景，在大促流量洪峰下查詢需要保持高效能，寫入也同樣需要保持高吞吐，才能不影響業務的下一步決策，例如每年雙11交易峰值，對寫入和Binlog消費的壓力都比較大，因此實時鏈路的最佳化與保障需要格外處理。今年針對大流量場景的任務調優，在實時鏈路上我們針對併發、攢批、connector等都做了相應的最佳化，保證了高吞吐寫入，降級寫入延遲，滿足不同業務系統的需求。
- 最佳化寫入connector的頻寬策略，避開VIP頻寬由5GB/s到20GB/s的限制。
- 大流量的行存表擴容shard數，比如交易表，提高寫入併發能力。
- 大流量的任務選擇合適的併發，比如交易表我們採用的引數是Binglog併發：512、sink併發：512、batch size：512、buffer size：20000、ingore delete：true。
- 合適的攢批能力：選擇更加合適的connector的攢批以及server端的攢批，交易場景的輸入流量和輸出流量的峰值差距能夠達到30%，一定程度上具備削峰填谷的效果。
為什麼要採用這樣的方案，有比較強的場景原因也有比較客觀原因造成的方案折中：
- 由於歷史原因，不同的應用系統可能會依賴不同的資料服務引擎，比如某些KV引擎暫時未改造下線，為了保證資料一致性，我們透過消費Hologres Binlog，將某些實時資料向其它KV引擎做實時同步，既保證了資料一致性，也可以滿足不同應用系統的需求。
- 對於交易流量，大促峰值往往高於日常非常多，為了保證峰值吞吐效能，所有引擎按照峰值擴容，會有極大的資源浪費，透過數倉中轉的流量需要具備一定的“消峰填谷”的能力，來保證目標引擎不必過度擴容。
五 總結
由CCO+Hologres構建的高可用實時數倉經過2年的迭代，由最初的傳統數倉逐漸升級到2021年的高可用實時數倉：2020年年雙11大促首次採用以Hologres為核心實時數倉方案，統一了實時核心資料與部分離線資料的儲存。再到2021年透過對實時數倉進行高可用架構升級，由鏈路雙寫順利升級為讀寫分離高可用以及災備架構，並在雙11以及雙12等核心場景規模應用。實時任務規模由去年的幾百+增加至上千+，寫入壓力增加至1700萬+每秒，資料規模高達幾百TB，直接服務數十個線上服務場景，數百個核心分析業務，有效降低了構建實時數倉主備鏈路的人力以及機器成本，減輕了核心業務對於讀取穩定的壓力，完美經受住各大促核心場景的檢驗，實現生產高可用。
原文連結
本文為阿里雲原創內容，未經允許不得轉載。