簡介：本文將會介紹今年是如何在去年基礎(chǔ)上進(jìn)行實(shí)時數(shù)倉高可用架構(gòu)升級，并成功大規(guī)模落地雙11。

作者 | 梅醬
來源 | 阿里技術(shù)公眾號

一 2021年雙11總結(jié)

2021年阿里巴巴雙11期間，由CCO+Hologres構(gòu)建的高可用實(shí)時數(shù)倉經(jīng)過2年的迭代，支撐了阿里集團(tuán)內(nèi)部從智能到人工，從應(yīng)用到數(shù)據(jù)產(chǎn)品，從B/C到內(nèi)部運(yùn)營等數(shù)10個核心應(yīng)用場景，并在雙11實(shí)時大屏、實(shí)時監(jiān)控大盤等多個應(yīng)用場景全面啟動新一代高可用及災(zāi)備方案，在Hologres主集群寫入峰值達(dá)450萬+每秒的情況下，還能真正做到數(shù)據(jù)“0”延遲，服務(wù)“0”延遲。

相比2020年，今年通過優(yōu)化實(shí)時寫入鏈路，在Binlog消費(fèi)和維表Join流量翻倍的情況下，同等資源下Hologres Binlog讀取峰值達(dá)1700萬+每秒，整體水位平穩(wěn)保持正常高吞吐。同時今年首次在大促核心場景上線新一代高可用及災(zāi)備方案，取消去年使用的雙實(shí)例+雙鏈路的高成本方式，極大降低人力開發(fā)、壓測以及運(yùn)維成本，降低無效雙鏈路任務(wù)上百個，減少人力投入50%，節(jié)約上千cu計(jì)算資源。

下面將會介紹今年是如何在去年基礎(chǔ)上進(jìn)行實(shí)時數(shù)倉高可用架構(gòu)升級，并成功大規(guī)模落地雙11。

去年精彩回顧：Hologres是如何完美支撐雙11智能客服實(shí)時數(shù)倉的？

二 客戶簡介

CCO是Chief Customer Officer的縮寫，也是阿里巴巴集團(tuán)客戶體驗(yàn)事業(yè)部的簡稱。在阿里巴巴經(jīng)濟(jì)體內(nèi)，CCO是“客戶第一”價值觀落地的組織保障，是整個經(jīng)濟(jì)體客戶體驗(yàn)的神經(jīng)網(wǎng)絡(luò)，也是觸達(dá)消費(fèi)者和商家的最前線。“成為新商業(yè)的服務(wù)生態(tài)搖籃”，“讓體驗(yàn)成為商業(yè)的核心競爭力”是我們的愿景。憑借著為消費(fèi)者、商家和經(jīng)濟(jì)體提供專業(yè)服務(wù)的小二，為平臺不斷挖掘存量客戶價值的體驗(yàn)運(yùn)營專家，為業(yè)務(wù)發(fā)展提供底層支撐的數(shù)據(jù)、產(chǎn)品和技術(shù)人才，我們成為了互聯(lián)網(wǎng)行業(yè)獨(dú)一無二的數(shù)字化服務(wù)體驗(yàn)團(tuán)隊(duì) —— 一支有愛有擔(dān)當(dāng)，富有創(chuàng)造力的“阿里柔軍”。

三 業(yè)務(wù)挑戰(zhàn)

CCO通過與Hologres高度共建，構(gòu)建了集實(shí)時化、自助化、系統(tǒng)化于一體的用戶體驗(yàn)實(shí)時數(shù)倉，完美助力2020年雙11場景，支持上千+服務(wù)大屏，削峰30%，節(jié)約成本近30%。

但是在2021年，任務(wù)規(guī)模也相比2020年增長1.5倍，實(shí)時數(shù)據(jù)膨脹2倍以上，如何有效管理數(shù)據(jù)和資源成為了越來越關(guān)鍵的問題，同時2021年大促期間將會面臨更加高并發(fā)高吞吐的流量，如何保障實(shí)時數(shù)倉的高可用，以及保持穩(wěn)定性和成本的平衡，是今年構(gòu)建實(shí)時數(shù)倉的核心挑戰(zhàn)。

2020年雙11，為了應(yīng)對大促的流量洪峰，在高可用方面，我們花費(fèi)1個月，投入巨大人力成本，來構(gòu)建雙鏈路+雙實(shí)例的高可用方案，以下為去年雙11的實(shí)時數(shù)倉架構(gòu)。這個架構(gòu)雖然支撐了去年雙11等各種大促流量洪峰，但是在今年更為復(fù)雜的環(huán)境和外部更多挑戰(zhàn)的情況下，也存在著一定的痛點(diǎn)，主要有以下幾個：

• 浪費(fèi)資源：數(shù)據(jù)同時寫入多個實(shí)例，滿足主備要求，既浪費(fèi)了計(jì)算資源，也浪費(fèi)了存儲資源，同時也額外增加了業(yè)務(wù)的開發(fā)成本和運(yùn)維成本。
• 無法高效保證主備鏈路數(shù)據(jù)一致性：在數(shù)據(jù)雙寫時，當(dāng)某個實(shí)例因?yàn)橐驗(yàn)榉N種原因出現(xiàn)延遲時，無法與另外一個實(shí)例保持完整的數(shù)據(jù)一致性，無法做到真正的高可靠。
• 運(yùn)維復(fù)雜：雙鏈路意味著需要采用兩套架構(gòu)，雖然搭建邏輯以及開發(fā)邏輯都一致，但是當(dāng)對主鏈路進(jìn)行運(yùn)維發(fā)布（如升降配，bug fixed等）或者邏輯修改時，牽一發(fā)而動全身，還需要同時維護(hù)備鏈路，操作比較復(fù)雜，運(yùn)維鏈路長。

為了解決2020年遺留的問題，2021年雙11對實(shí)時數(shù)倉進(jìn)行升級，采用新一代高可用及災(zāi)備方案，在對單鏈路進(jìn)行充分的壓測評估以及長應(yīng)急預(yù)案外，實(shí)例內(nèi)使用多副本+共享存儲的方式，除了在出現(xiàn)未知問題時可以快速切換副本來提高業(yè)務(wù)的可用性外，還極大的降低了構(gòu)建雙鏈路的成本。同時在面對大促和日常流量時，可以快速縮容，提高架構(gòu)的整體靈活性，在成本和效率上相比去年更加的平衡，實(shí)現(xiàn)生成高可用，成功大規(guī)模落地雙11。

下面將會具體介紹今年的高可用及災(zāi)備方案。

四 業(yè)務(wù)方案

整體數(shù)據(jù)鏈路同2020年保持一致：數(shù)據(jù)源數(shù)據(jù)通過Flink ETL處理后實(shí)時寫入Hologres，行存表用于在線服務(wù)場景，列存表用于復(fù)雜多維分析場景，再由Hologres通過通過不同的場景直接對接上層應(yīng)用。

在去年方案的基礎(chǔ)上，對架構(gòu)進(jìn)行升級，對Hologres服務(wù)和分析場景進(jìn)行集群隔離以及高可用部署，組成當(dāng)下實(shí)時數(shù)倉3.0架構(gòu)。

注：部分不核心業(yè)務(wù)由于歷史原因暫時無法下線，所以由Hologres同步至某DB引擎提供服務(wù)。

升級1：多種隔離方式滿足生產(chǎn)高可用

在高可用部分，今年的方案升級主要如下：
1）服務(wù)和分析集群隔離
采用行存和列存兩個實(shí)例集群，有效隔離行存服務(wù)和列存分析場景下對于QPS/RT不同要求的能力。

• 行存集群承載核心實(shí)時數(shù)據(jù)，主要承擔(dān)與Flink高頻的交互（數(shù)據(jù)寫入、Binlog消費(fèi)、維表關(guān)聯(lián)），同時提供比如數(shù)據(jù)特征、用戶畫像等在線點(diǎn)查服務(wù)，實(shí)現(xiàn)在線推薦。
• 列存集群主要用于復(fù)雜多維分析，由Flink實(shí)時寫入，應(yīng)用于實(shí)時數(shù)據(jù)大屏、實(shí)時監(jiān)控等一系列核心場景

2）分析場景讀寫分離高可用和災(zāi)備
對于大促期間高保的列存分析核心場景，啟用多實(shí)例共享存儲讀寫分離高可用和非共享存儲災(zāi)備的能力建設(shè)。

• 讀寫分離高可用：多個實(shí)例共享存儲，主實(shí)例具備完整能力，數(shù)據(jù)可讀可寫，權(quán)限、系統(tǒng)參數(shù)可配置，而子實(shí)例處于只讀狀態(tài)，所有的變更都通過主實(shí)例完成，實(shí)例之間共享一份數(shù)據(jù)存儲，實(shí)例間數(shù)據(jù)異步實(shí)時同步。這個方案實(shí)現(xiàn)了完整的讀寫分離功能，保障不同業(yè)務(wù)場景的SLA，在高吞吐的數(shù)據(jù)寫入和復(fù)雜的架構(gòu)作業(yè)、OLAP、AdHoc查詢、線上服務(wù)等場景中，負(fù)載之間物理上完全隔離，不會因?qū)懭氘a(chǎn)生查詢的抖動。同時當(dāng)某個子實(shí)例出現(xiàn)問題時，可以在其余子實(shí)例間緊急切換，也不會帶來數(shù)據(jù)一致性的問題。
• 災(zāi)備：在多機(jī)房部署多個實(shí)例，實(shí)例間不共享存儲，數(shù)據(jù)通過實(shí)例間進(jìn)行實(shí)時同步，數(shù)據(jù)冗余在多個文件系統(tǒng)，在集群出現(xiàn)問題時，可做緊急切換。

日增量數(shù)據(jù)在數(shù)十TB的規(guī)模下，無論是共享存儲的讀寫分離高可用還是非共享存儲的災(zāi)備模式，同機(jī)房/跨機(jī)房實(shí)時數(shù)據(jù)同步延遲都低于10ms，完全滿足我們對于大促高保場景的數(shù)據(jù)時效性要求。

升級2：實(shí)時鏈路優(yōu)化提高吞吐

對于核心場景，在大促流量洪峰下查詢需要保持高性能，寫入也同樣需要保持高吞吐，才能不影響業(yè)務(wù)的下一步?jīng)Q策，例如每年雙11交易峰值，對寫入和Binlog消費(fèi)的壓力都比較大，因此實(shí)時鏈路的優(yōu)化與保障需要格外處理。今年針對大流量場景的任務(wù)調(diào)優(yōu)，在實(shí)時鏈路上我們針對并發(fā)、攢批、connector等都做了相應(yīng)的優(yōu)化，保證了高吞吐寫入，降級寫入延遲，滿足不同業(yè)務(wù)系統(tǒng)的需求。

• 優(yōu)化寫入connector的帶寬策略，避開VIP帶寬由5GB/s到20GB/s的限制。
• 大流量的行存表擴(kuò)容shard數(shù)，比如交易表，提高寫入并發(fā)能力。
• 大流量的任務(wù)選擇合適的并發(fā)，比如交易表我們采用的參數(shù)是Binglog并發(fā)：512、sink并發(fā)：512、batch size：512、buffer size：20000、ingore delete：true。
• 合適的攢批能力：選擇更加合適的connector的攢批以及server端的攢批，交易場景的輸入流量和輸出流量的峰值差距能夠達(dá)到30%，一定程度上具備削峰填谷的效果。

為什么要采用這樣的方案，有比較強(qiáng)的場景原因也有比較客觀原因造成的方案折中：

• 由于歷史原因，不同的應(yīng)用系統(tǒng)可能會依賴不同的數(shù)據(jù)服務(wù)引擎，比如某些KV引擎暫時未改造下線，為了保證數(shù)據(jù)一致性，我們通過消費(fèi)Hologres Binlog，將某些實(shí)時數(shù)據(jù)向其它KV引擎做實(shí)時同步，既保證了數(shù)據(jù)一致性，也可以滿足不同應(yīng)用系統(tǒng)的需求。
• 對于交易流量，大促峰值往往高于日常非常多，為了保證峰值吞吐性能，所有引擎按照峰值擴(kuò)容，會有極大的資源浪費(fèi)，通過數(shù)倉中轉(zhuǎn)的流量需要具備一定的“消峰填谷”的能力，來保證目標(biāo)引擎不必過度擴(kuò)容。

五 總結(jié)

由CCO+Hologres構(gòu)建的高可用實(shí)時數(shù)倉經(jīng)過2年的迭代，由最初的傳統(tǒng)數(shù)倉逐漸升級到2021年的高可用實(shí)時數(shù)倉：2020年年雙11大促首次采用以Hologres為核心實(shí)時數(shù)倉方案，統(tǒng)一了實(shí)時核心數(shù)據(jù)與部分離線數(shù)據(jù)的存儲。再到2021年通過對實(shí)時數(shù)倉進(jìn)行高可用架構(gòu)升級，由鏈路雙寫順利升級為讀寫分離高可用以及災(zāi)備架構(gòu)，并在雙11以及雙12等核心場景規(guī)模應(yīng)用。實(shí)時任務(wù)規(guī)模由去年的幾百+增加至上千+，寫入壓力增加至1700萬+每秒，數(shù)據(jù)規(guī)模高達(dá)幾百TB，直接服務(wù)數(shù)十個在線服務(wù)場景，數(shù)百個核心分析業(yè)務(wù)，有效降低了構(gòu)建實(shí)時數(shù)倉主備鏈路的人力以及機(jī)器成本，減輕了核心業(yè)務(wù)對于讀取穩(wěn)定的壓力，完美經(jīng)受住各大促核心場景的檢驗(yàn)，實(shí)現(xiàn)生產(chǎn)高可用。

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。