摘要：剛剛結束的2020天貓雙11中，MaxCompute互動式分析（Hologres）+實時計算Flink搭建的雲原生實時數倉首次在核心資料場景落地，為大資料平台創下一項新紀錄。借此之際，我們将陸續推出雲原生實時數倉雙11實戰系列内容，本文重點介紹Hologres如何落地阿裡巴巴飛豬實時數倉場景，并助力飛豬雙11實時資料大屏3秒起跳，全程0故障。
今年雙十一較以往最大的變化就是活動的整體節奏從原來“單節”調整為今年的“雙節”，自然地形成兩波流量高峰，大屏和營銷資料的統計周期變長，名額次元變得更多，同時集團GMV媒體大屏首次直接複用飛豬大屏鍊路資料，是以如何保障集團GMV媒體大屏、飛豬資料大屏以及雙十一整體資料的實時、準确、穩定是一個比較大的挑戰。
本次雙十一飛豬實時大屏零點3秒起跳，全程0故障，順利護航阿裡巴巴集團媒體大屏，做到了名額精确、服務穩定、回報實時。
而這一切都離不開大屏背後實時資料全鍊路的技術更新和保障。飛豬實時資料整體架構如下圖所示：
一、公共層加強，抵禦洪峰流量
抵禦雙十一流量洪峰，首先發力的是實時資料公共層。經過近兩年的疊代完善，多端、多源的實時資料公共層已經實作了日志、交易、營銷互動、服務域的全域覆寫，作業吞吐和資源效率也在不斷的提升，本次雙十一為了平穩通過流量雙峰，對其進行了多輪的全鍊路的壓測和進一步的夯實加強：
1）維表遷移，分散熱點依賴
維表是實時公共層的核心邏輯和實體依賴，熱點維表在大促時可能就是服務的風險點和瓶頸。飛豬商品表是各類實時作業依賴最多的Hbase維表，其中包括大促時流量暴漲的飛豬淘寶端流量公共層作業。去年通過對淘系PV流量提取的深度邏輯優化，将該維表的日常QPS由幾十w降低到了幾w，但随着後續點選公共層以及其他業務作業的不斷新增依賴，日常QPS很快升到了5w+，大促壓測時一路飙升到十多w，且維表所在的Hbase叢集比較老舊且為公共叢集，大促穩定性風險較大。是以将飛豬商品表及其他大流量公共層依賴維表都遷移到性能更佳的lindorm叢集，将其他非核心的應用層維表繼續保留原有habse叢集，分散大促洪峰時對維表的壓力。
2）作業隔離，防止資源擠壓
實時作業的資源消耗也符合二八原理，小部分的作業消耗了大部分的計算資源。飛豬淘系的曝光作業雙十一大促時至少需要1000+CU保障資源，PV公共層任務需要600CU，整個流量公共層9個作業至少需要叢集一半以上的資源來進行保障。為防止洪峰襲來是單隊列内的多個大作業資源超用（大流量時作業消耗會超出配置資源）時發生擠壓，影響吞吐，将大作業分散不同資源隊列。同樣對于各個類目的交易公共層任務也會分散在各個資源隊列，防止單一叢集突發極端異常，導緻名額資料跌0。
3）雙十一性能表現
雙十一期間，實時公共層順利抵禦淘系源頭較日常交易流量250倍和日志流量3倍，整體流量公共層最高約幾千萬條/秒的洪峰沖擊，淘系交易公共層任務無任何時延，流量公共層分鐘級時延并很快消退。
二、架構更新，提效開發
雙十一大促的核心三個階段預售、預熱、正式，正式階段最重要的事情就是付尾款。本次雙十一業務側比較大的變化就是付尾款由原來的一天變成了三天，導緻去年的關于尾款的營銷資料都無法複用。除了要保留之前大盤、類目、天、小時等多元度尾款支付相關的名額，還需要新增商品、商家粒度的尾款，同時因為尾款周期變長，為了業務更高效的催尾款，臨時可能需要新增更多元度的資料（尾款的最後一天就接到了需要拉取未支付尾款訂單明細的需求）。是以為了應對本次雙十一尾款資料名額長周期、多元度、易變化的挑戰，将大屏和營銷資料的資料架構由預計算模式更新為預計算+批流一體的即席查詢混合模式，整體的開發效率至少提升1倍以上，且可以友善的适應需求變更。
1）新的營銷資料架構：
- 即席查詢部分：Hologres+Flink流批一體的資料架構，使用了Hologres的分區表和即時查詢能力。将公共層的實時明細資料寫入當日分區，離線側公共層明細資料由MaxCompute直接導入覆寫Hologres次日覆寫分區（對于準确性和穩定性非嚴苛的場景，可以選擇都去掉離線merge的步驟），同時寫入時注意配置主鍵覆寫，防止實時任務異常時，可以回刷。各位次元的名額計算，直接在Hologres中通過sql聚合，即時傳回查詢結果，非常友善的适應統計名額的需求變更。
- 預計算部分：保留了之前比較成熟的Flink+Hbase+Onservice的計算、存儲和服務架構。主要通過Flink實時聚合名額，并寫入Hbase，onservice做查詢服務和鍊路切換。高可用和穩定性場景，建構主備鍊路，可能還會配合離線名額資料回流，修複實時鍊路可能出現的異常和誤差。
2）簡單高效的名額計算
由Hologress搭建的即席查詢服務，除了架構簡單高效，名額計算更是簡單到令人發指，極大的解放了實時名額資料的開發效率。
對于尾款支付部分，有一個很正常，但如果通過Flink SQL來實作就會比較雞肋或者代價較大的名額，就是從零點到各小時累計尾款支付金額或支付率。flink的group by本質是分組聚合，可以很友善對小時資料分組聚合，但是很難對從0-2點，0-3點，0-4點這類累計資料建構分組來進行計算，隻能建構0點到目前小時max(hour)的資料分組做聚合。帶來的問題就是，一旦資料出錯需要回刷，隻會更新最後一個小時的資料，中間的小時累計情況都無法更新。
而對于通過Hologres的即時查詢的引擎來說，隻需要對小時聚合之後再來一個視窗函數，一個統計sql搞定，極大的提升了開發效率。示例如下：
select stat_date,stat_hour,cnt,gmv --小時資料
,sum(cnt) over(partition by stat_date order by stat_hour asc) as acc_cnt --小時累計資料
,sum(gmv) over(partition by stat_date order by stat_hour asc) as acc_gmv
from(
select stat_date,stat_hour,count(*) cnt,sum(gmv) as gmv
from
dwd_trip_xxxx_pay_ri
where stat_date in('20201101','20201102')
group by stat_date,stat_hour
) a ; 三、鍊路和任務優化，保障穩定
1）主備雙鍊3備份
阿裡巴巴集團GMV媒體大屏一直由集團DT團隊自主把控，今年雙十一的集團大屏，為了保證口徑的一緻和完整性，首次直接複用飛豬實時鍊路資料，是以對大屏名額計算和鍊路的穩定性和時效提出了更高的要求。
為了保證系統高可用，各個類目的交易從源頭資料庫的DRC同步到交易明細公共層分别建構張北、南通叢集主備雙鍊路，對于應用層的GMV統計任務和Hbase結果存儲在雙鍊的基礎上又增加上海叢集的備份。整體的鍊路架構如下：
同時，配合全鍊路的實時任務異常監控和報警，出現異常時可以做到鍊路秒級切換，系統SLA達到99.99%以上。
2）零點3s起跳優化
為了保證零點3s起跳，對任務的全鍊路資料處理細節優化。
- 源頭部分優化了DRC同步後binlog的TT寫入，将源TT的多queue縮減為單queue，減少資料間隔時延。早期的開發沒有正确評估各類目交易資料流量情況，而将TT的queue數設定過大，導緻單queue内流量很小，TT采集時預設的cache size和頻次，導緻資料資料的間隔時延很大，進而放大了整體鍊路的時延。TT多queue縮容後，資料間隔時延基本下降至秒級以内。
- 中間部分優化各類目的交易公共層的處理邏輯，消減邏輯處理時延。初版的TTP交易(國際機票、火車票等)公共層，為了更多元的複用完全模仿了離線公共層的處理，将複雜且時延較大的航段資訊關聯到一起，導緻整個任務的處理時延達十幾秒。為了精确平衡時延和複用性，将舊有的多流join後統一輸出，改為多級join輸出，将gmv的處理時延降低到3s以内。整體流程如下：
Hologres助力飛豬雙11實時資料大屏秒級響應 - 任務節點部分，調整參數配置，降低緩沖和IO處理時延。公共層和GMV統計部分，調整miniBatch的allowLatency、cache size，TT輸出的flush interval，Hbase輸出的flushsize等等
3）TopN優化
TopN一直實時營銷分析常見的統計場景，因為其本身就是熱點統計，是以比較容易出現資料傾斜、性能和穩定性問題。雙十一預售開始後，會場、商家、商品的曝光流量的TopN作業就開始陸續的出現背壓，作業checkpoint逾時失敗，時延巨大且易failover，統計資料基本不可用狀态。初期判斷為流量上漲，作業吞吐不夠，調大資源和并發基本無任何效果，背壓仍集中在rank的節點而資源充足。仔細排查發現rank節點執行算法蛻化為性能較差的RetractRank算法，之前group by後再row_number()倒排後取topN的邏輯，無法自動優化成UnaryUpdateRank算法，性能急降（原因為UnaryUpdateRank算子有準确性風險在内部Flink3.7.3版本被下線）。多次調整和測試之後，确定無法通過配置優化問題，最終通過多重邏輯優化進行化解。
- 将會場分類的曝光、商家商品的任務進行邏輯拆分為兩個任務，防止商品或商家邏輯rank節點資料傾斜，導緻整體資料出不來。
- 先做了一級聚合計算UV，減少TOP排序資料資料量，再做二級聚合優化為UpdateFastRank算法，最終checkpoint秒級，回溯聚合一天曝光資料隻需要10分鐘。
- 當然還有一種政策是做二級TopN，先對商品或商家的id進行hash分組取top，再做整體top
實時資料不止點亮大屏
資料大屏一直是實時場景高要求的代表，每次雙十一業務帶來的考驗和挑戰，都會對整個實時資料體系和鍊路帶來新的突破。同時，飛豬的實時資料不僅僅隻是止點亮媒體大屏，提效營銷分析和會場營運，由實時公共層和特征層、實時營銷分析、實時标簽和RTUS服務構成的實時資料體系，正在全方位、多元度地附能搜尋、推薦、營銷、觸達和使用者營運等核心業務。
作者簡介：王偉（花名炎辰），阿裡巴巴飛豬技術部進階資料工程師 。