Hologres助力飛豬雙11實時數據大屏秒級響應

簡介： 本文重點介紹Hologres如何落地阿里巴巴飛豬實時數倉場景，並助力飛豬雙11實時數據大屏3秒起跳，全程0故障。

摘要：剛剛結束的2020天貓雙11中，MaxCompute交互式分析（下稱Hologres）+實時計算Flink搭建的雲原生實時數倉首次在覈心數據場景落地，爲大數據平臺創下一項新紀錄。藉此之際，咱們將陸續推出雲原生實時數倉雙11實戰系列內容，本文重點介紹Hologres如何落地阿里巴巴飛豬實時數倉場景，並助力飛豬雙11實時數據大屏3秒起跳，全程0故障。

今年雙十一較以往最大的變化就是活動的總體節奏從原來「單節」調整爲今年的「雙節」，天然地造成兩波流量高峯，大屏和營銷數據的統計週期變長，指標維度變得更多，同時集團GMV媒體大屏首次直接複用飛豬大屏鏈路數據，因此如何保障集團GMV媒體大屏、飛豬數據大屏以及雙十一總體數據的實時、準確、穩定是一個比較大的挑戰。

本次雙十一飛豬實時大屏零點3秒起跳，全程0故障，順利護航阿里巴巴集團媒體大屏，作到了指標精確、服務穩定、反饋實時。
而這一切都離不開大屏背後實時數據全鏈路的技術升級和保障。飛豬實時數據總體架構以下圖所示：

下面將會介紹，爲了實現快、準、穩的雙11實時數據大屏，業務針對實時數據全鏈路作了哪些升級改進和優化。

1、公共層加固，抵禦洪峯流量

抵禦雙十一流量洪峯，首先發力的是實時數據公共層。通過近兩年的迭代完善，多端、多源的實時數據公共層已經實現了日誌、交易、營銷互動、服務域的全域覆蓋，做業吞吐和資源效率也在不斷的提高，本次雙十一爲了平穩經過流量雙峯，對其進行了多輪的全鏈路的壓測和進一步的夯實加固：

1）維表遷移，分散熱點依賴

維表是實時公共層的核心邏輯和物理依賴，熱點維表在大促時可能就是服務的風險點和瓶頸。飛豬商品表是各種實時做業依賴最多的Hbase維表，其中包括大促時流量暴漲的飛豬淘寶端流量公共層做業。去年經過對淘系PV流量提取的深度邏輯優化，將該維表的平常QPS由幾十w下降到了幾w，但隨着後續點擊公共層以及其餘業務做業的不斷新增依賴，平常QPS很快升到了5w+，大促壓測時一路飆升到十多w，且維表所在的Hbase集羣比較老舊且爲公共集羣，大促穩定性風險較大。因此將飛豬商品表及其餘大流量公共層依賴維表都遷移到性能更佳的lindorm集羣，將其餘非核心的應用層維表繼續保留原有habse集羣，分散大促洪峯時對維表的壓力。

2）做業隔離，防止資源擠壓

實時做業的資源消耗也符合二八原理，小部分的做業消耗了大部分的計算資源。飛豬淘系的曝光做業雙十一大促時至少須要1000+CU保障資源，PV公共層任務須要600CU，整個流量公共層9個做業至少須要集羣一半以上的資源來進行保障。爲防止洪峯襲來是單隊列內的多個大做業資源超用（大流量時做業消耗會超出配置資源）時發生擠壓，影響吞吐，將大做業分散不一樣資源隊列。一樣對於各個類目的交易公共層任務也會分散在各個資源隊列，防止單一集羣突發極端異常，致使指標數據跌0。

3）雙十一性能表現

雙十一期間，實時公共層順利抵禦淘系源頭較平常交易流量250倍和日誌流量3倍，總體流量公共層最高約幾千萬條/秒的洪峯衝擊，淘系交易公共層任務無任什麼時候延，流量公共層分鐘級時延並很快消退。

2、架構升級，提效開發

雙十一大促的核心三個階段預售、預熱、正式，正式階段最重要的事情就是付尾款。本次雙十一業務側比較大的變化就是付尾款由原來的一天變成了三天，致使去年的關於尾款的營銷數據都沒法複用。除了要保留以前大盤、類目、天、小時等多維度尾款支付相關的指標，還須要新增商品、商家粒度的尾款，同時由於尾款週期變長，爲了業務更高效的催尾款，臨時可能須要新增更多維度的數據（尾款的最後一天就接到了須要拉取未支付尾款訂單明細的需求）。因此爲了應對本次雙十一尾款數據指標長週期、多維度、易變化的挑戰，將大屏和營銷數據的數據架構由預計算模式升級爲預計算+批流一體的即席查詢混合模式，總體的開發效率至少提高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 ;

3、鏈路和任務優化，保障穩定

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之內。總體流程以下：
  
• 任務節點部分，調整參數配置，下降緩衝和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，先
• 原文連接
  本文爲阿里雲原創內容，未經容許不得轉載。

數據大屏一直是實時場景高要求的表明，每次雙十一業務帶來的考驗和挑戰，都會對整個實時數據體系和鏈路帶來新的突破。同時，飛豬的實時數據不只僅只是止點亮媒體大屏，提效營銷分析和會場運營，由實時公共層和特徵層、實時營銷分析、實時標籤和RTUS服務構成的實時數據體系，正在全方位、多維度地附能搜索、推薦、營銷、觸達和用戶運營等核心業務。

做者簡介：王偉（花名炎辰），阿里巴巴飛豬技術部高級數據工程師 。