簡介：本文將會介紹今年是如何在去年基礎上進行實時數倉高可用架構升級，并成功大規模落地雙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，直接服務數十個在線服務場景，數百個核心分析業務，有效降低了構建實時數倉主備鏈路的人力以及機器成本，減輕了核心業務對于讀取穩定的壓力，完美經受住各大促核心場景的檢驗，實現生產高可用。

原文鏈接

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

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的CCO x Hologres：实时数仓高可用架构再次升级，双11大规模落地的全部內容，希望文章能夠幫你解決所遇到的問題。

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