簡介：?本文重點(diǎn)介紹Hologres如何落地阿里巴巴飛豬實(shí)時數(shù)倉場景，并助力飛豬雙11實(shí)時數(shù)據(jù)大屏3秒起跳，全程0故障。

摘要：剛剛結(jié)束的2020天貓雙11中，MaxCompute交互式分析（下稱Hologres）+實(shí)時計(jì)算Flink搭建的云原生實(shí)時數(shù)倉首次在核心數(shù)據(jù)場景落地，為大數(shù)據(jù)平臺創(chuàng)下一項(xiàng)新紀(jì)錄。借此之際，我們將陸續(xù)推出云原生實(shí)時數(shù)倉雙11實(shí)戰(zhàn)系列內(nèi)容，本文重點(diǎn)介紹Hologres如何落地阿里巴巴飛豬實(shí)時數(shù)倉場景，并助力飛豬雙11實(shí)時數(shù)據(jù)大屏3秒起跳，全程0故障。

今年雙十一較以往最大的變化就是活動的整體節(jié)奏從原來“單節(jié)”調(diào)整為今年的“雙節(jié)”，自然地形成兩波流量高峰，大屏和營銷數(shù)據(jù)的統(tǒng)計(jì)周期變長，指標(biāo)維度變得更多，同時集團(tuán)GMV媒體大屏首次直接復(fù)用飛豬大屏鏈路數(shù)據(jù)，所以如何保障集團(tuán)GMV媒體大屏、飛豬數(shù)據(jù)大屏以及雙十一整體數(shù)據(jù)的實(shí)時、準(zhǔn)確、穩(wěn)定是一個比較大的挑戰(zhàn)。

本次雙十一飛豬實(shí)時大屏零點(diǎn)3秒起跳，全程0故障，順利護(hù)航阿里巴巴集團(tuán)媒體大屏，做到了指標(biāo)精確、服務(wù)穩(wěn)定、反饋實(shí)時。
而這一切都離不開大屏背后實(shí)時數(shù)據(jù)全鏈路的技術(shù)升級和保障。飛豬實(shí)時數(shù)據(jù)整體架構(gòu)如下圖所示：

下面將會介紹，為了實(shí)現(xiàn)快、準(zhǔn)、穩(wěn)的雙11實(shí)時數(shù)據(jù)大屏，業(yè)務(wù)針對實(shí)時數(shù)據(jù)全鏈路做了哪些升級改進(jìn)和優(yōu)化。

一、公共層加固，抵御洪峰流量

抵御雙十一流量洪峰，首先發(fā)力的是實(shí)時數(shù)據(jù)公共層。經(jīng)過近兩年的迭代完善，多端、多源的實(shí)時數(shù)據(jù)公共層已經(jīng)實(shí)現(xiàn)了日志、交易、營銷互動、服務(wù)域的全域覆蓋，作業(yè)吞吐和資源效率也在不斷的提升，本次雙十一為了平穩(wěn)通過流量雙峰，對其進(jìn)行了多輪的全鏈路的壓測和進(jìn)一步的夯實(shí)加固：

1）維表遷移，分散熱點(diǎn)依賴

維表是實(shí)時公共層的核心邏輯和物理依賴，熱點(diǎn)維表在大促時可能就是服務(wù)的風(fēng)險(xiǎn)點(diǎn)和瓶頸。飛豬商品表是各類實(shí)時作業(yè)依賴最多的Hbase維表，其中包括大促時流量暴漲的飛豬淘寶端流量公共層作業(yè)。去年通過對淘系PV流量提取的深度邏輯優(yōu)化，將該維表的日常QPS由幾十w降低到了幾w，但隨著后續(xù)點(diǎn)擊公共層以及其他業(yè)務(wù)作業(yè)的不斷新增依賴，日常QPS很快升到了5w+，大促壓測時一路飆升到十多w，且維表所在的Hbase集群比較老舊且為公共集群，大促穩(wěn)定性風(fēng)險(xiǎn)較大。所以將飛豬商品表及其他大流量公共層依賴維表都遷移到性能更佳的lindorm集群，將其他非核心的應(yīng)用層維表繼續(xù)保留原有habse集群，分散大促洪峰時對維表的壓力。

2）作業(yè)隔離，防止資源擠壓

實(shí)時作業(yè)的資源消耗也符合二八原理，小部分的作業(yè)消耗了大部分的計(jì)算資源。飛豬淘系的曝光作業(yè)雙十一大促時至少需要1000+CU保障資源，PV公共層任務(wù)需要600CU，整個流量公共層9個作業(yè)至少需要集群一半以上的資源來進(jìn)行保障。為防止洪峰襲來是單隊(duì)列內(nèi)的多個大作業(yè)資源超用（大流量時作業(yè)消耗會超出配置資源）時發(fā)生擠壓，影響吞吐，將大作業(yè)分散不同資源隊(duì)列。同樣對于各個類目的交易公共層任務(wù)也會分散在各個資源隊(duì)列，防止單一集群突發(fā)極端異常，導(dǎo)致指標(biāo)數(shù)據(jù)跌0。

3）雙十一性能表現(xiàn)

雙十一期間，實(shí)時公共層順利抵御淘系源頭較日常交易流量250倍和日志流量3倍，整體流量公共層最高約幾千萬條/秒的洪峰沖擊，淘系交易公共層任務(wù)無任何時延，流量公共層分鐘級時延并很快消退。

二、架構(gòu)升級，提效開發(fā)

雙十一大促的核心三個階段預(yù)售、預(yù)熱、正式，正式階段最重要的事情就是付尾款。本次雙十一業(yè)務(wù)側(cè)比較大的變化就是付尾款由原來的一天變成了三天，導(dǎo)致去年的關(guān)于尾款的營銷數(shù)據(jù)都無法復(fù)用。除了要保留之前大盤、類目、天、小時等多維度尾款支付相關(guān)的指標(biāo)，還需要新增商品、商家粒度的尾款，同時因?yàn)槲部钪芷谧冮L，為了業(yè)務(wù)更高效的催尾款，臨時可能需要新增更多維度的數(shù)據(jù)（尾款的最后一天就接到了需要拉取未支付尾款訂單明細(xì)的需求）。所以為了應(yīng)對本次雙十一尾款數(shù)據(jù)指標(biāo)長周期、多維度、易變化的挑戰(zhàn)，將大屏和營銷數(shù)據(jù)的數(shù)據(jù)架構(gòu)由預(yù)計(jì)算模式升級為預(yù)計(jì)算+批流一體的即席查詢混合模式，整體的開發(fā)效率至少提升1倍以上，且可以方便的適應(yīng)需求變更。

1）新的營銷數(shù)據(jù)架構(gòu)：

• 即席查詢部分：Hologres+Flink流批一體的數(shù)據(jù)架構(gòu)，使用了Hologres的分區(qū)表和即時查詢能力。將公共層的實(shí)時明細(xì)數(shù)據(jù)寫入當(dāng)日分區(qū)，離線側(cè)公共層明細(xì)數(shù)據(jù)由MaxCompute直接導(dǎo)入覆蓋Hologres次日覆蓋分區(qū)（對于準(zhǔn)確性和穩(wěn)定性非嚴(yán)苛的場景，可以選擇都去掉離線merge的步驟），同時寫入時注意配置主鍵覆蓋，防止實(shí)時任務(wù)異常時，可以回刷。各位維度的指標(biāo)計(jì)算，直接在Hologres中通過sql聚合，即時返回查詢結(jié)果，非常方便的適應(yīng)統(tǒng)計(jì)指標(biāo)的需求變更。
• 預(yù)計(jì)算部分：保留了之前比較成熟的Flink+Hbase+Onservice的計(jì)算、存儲和服務(wù)架構(gòu)。主要通過Flink實(shí)時聚合指標(biāo)，并寫入Hbase，onservice做查詢服務(wù)和鏈路切換。高可用和穩(wěn)定性場景，構(gòu)建主備鏈路，可能還會配合離線指標(biāo)數(shù)據(jù)回流，修復(fù)實(shí)時鏈路可能出現(xiàn)的異常和誤差。

2）簡單高效的指標(biāo)計(jì)算

由Hologress搭建的即席查詢服務(wù)，除了架構(gòu)簡單高效，指標(biāo)計(jì)算更是簡單到令人發(fā)指，極大的解放了實(shí)時指標(biāo)數(shù)據(jù)的開發(fā)效率。
對于尾款支付部分，有一個很常規(guī)，但如果通過Flink SQL來實(shí)現(xiàn)就會比較雞肋或者代價較大的指標(biāo)，就是從零點(diǎn)到各小時累計(jì)尾款支付金額或支付率。flink的group by本質(zhì)是分組聚合，可以很方便對小時數(shù)據(jù)分組聚合，但是很難對從0-2點(diǎn)，0-3點(diǎn)，0-4點(diǎn)這類累計(jì)數(shù)據(jù)構(gòu)建分組來進(jìn)行計(jì)算，只能構(gòu)建0點(diǎn)到當(dāng)前小時max(hour)的數(shù)據(jù)分組做聚合。帶來的問題就是，一旦數(shù)據(jù)出錯需要回刷，只會更新最后一個小時的數(shù)據(jù)，中間的小時累計(jì)情況都無法更新。
而對于通過Hologres的即時查詢的引擎來說，只需要對小時聚合之后再來一個窗口函數(shù)，一個統(tǒng)計(jì)sql搞定，極大的提升了開發(fā)效率。示例如下：

select stat_date,stat_hour,cnt,gmv --小時數(shù)據(jù) ,sum(cnt) over(partition by stat_date order by stat_hour asc) as acc_cnt --小時累計(jì)數(shù)據(jù) ,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 gmvfrom dwd_trip_xxxx_pay_riwhere stat_date in('20201101','20201102')group by stat_date,stat_hour ) a ;

三、鏈路和任務(wù)優(yōu)化，保障穩(wěn)定

1）主備雙鏈3備份

阿里巴巴集團(tuán)GMV媒體大屏一直由集團(tuán)DT團(tuán)隊(duì)自主把控，今年雙十一的集團(tuán)大屏，為了保證口徑的一致和完整性，首次直接復(fù)用飛豬實(shí)時鏈路數(shù)據(jù)，所以對大屏指標(biāo)計(jì)算和鏈路的穩(wěn)定性和時效提出了更高的要求。
為了保證系統(tǒng)高可用，各個類目的交易從源頭數(shù)據(jù)庫的DRC同步到交易明細(xì)公共層分別構(gòu)建張北、南通集群主備雙鏈路，對于應(yīng)用層的GMV統(tǒng)計(jì)任務(wù)和Hbase結(jié)果存儲在雙鏈的基礎(chǔ)上又增加上海集群的備份。整體的鏈路架構(gòu)如下：

同時，配合全鏈路的實(shí)時任務(wù)異常監(jiān)控和報(bào)警，出現(xiàn)異常時可以做到鏈路秒級切換，系統(tǒng)SLA達(dá)到99.99%以上。

2）零點(diǎn)3s起跳優(yōu)化

為了保證零點(diǎn)3s起跳，對任務(wù)的全鏈路數(shù)據(jù)處理細(xì)節(jié)優(yōu)化。

• 源頭部分優(yōu)化了DRC同步后binlog的TT寫入，將源TT的多queue縮減為單queue，減少數(shù)據(jù)間隔時延。早期的開發(fā)沒有正確評估各類目交易數(shù)據(jù)流量情況，而將TT的queue數(shù)設(shè)置過大，導(dǎo)致單queue內(nèi)流量很小，TT采集時默認(rèn)的cache size和頻次，導(dǎo)致數(shù)據(jù)數(shù)據(jù)的間隔時延很大，從而放大了整體鏈路的時延。TT多queue縮容后，數(shù)據(jù)間隔時延基本下降至秒級以內(nèi)。
• 中間部分優(yōu)化各類目的交易公共層的處理邏輯，消減邏輯處理時延。初版的TTP交易(國際機(jī)票、火車票等)公共層，為了更多維的復(fù)用完全模仿了離線公共層的處理，將復(fù)雜且時延較大的航段信息關(guān)聯(lián)到一起，導(dǎo)致整個任務(wù)的處理時延達(dá)十幾秒。為了精確平衡時延和復(fù)用性，將舊有的多流join后統(tǒng)一輸出，改為多級join輸出，將gmv的處理時延降低到3s以內(nèi)。整體流程如下：
  
• 任務(wù)節(jié)點(diǎn)部分，調(diào)整參數(shù)配置，降低緩沖和IO處理時延。公共層和GMV統(tǒng)計(jì)部分，調(diào)整miniBatch的allowLatency、cache size，TT輸出的flush interval，Hbase輸出的flushsize等等

3）TopN優(yōu)化

TopN一直實(shí)時營銷分析常見的統(tǒng)計(jì)場景，因?yàn)槠浔旧砭褪菬狳c(diǎn)統(tǒng)計(jì)，所以比較容易出現(xiàn)數(shù)據(jù)傾斜、性能和穩(wěn)定性問題。雙十一預(yù)售開始后，會場、商家、商品的曝光流量的TopN作業(yè)就開始陸續(xù)的出現(xiàn)背壓，作業(yè)checkpoint超時失敗，時延巨大且易failover，統(tǒng)計(jì)數(shù)據(jù)基本不可用狀態(tài)。初期判斷為流量上漲，作業(yè)吞吐不夠，調(diào)大資源和并發(fā)基本無任何效果，背壓仍集中在rank的節(jié)點(diǎn)而資源充足。仔細(xì)排查發(fā)現(xiàn)rank節(jié)點(diǎn)執(zhí)行算法蛻化為性能較差的RetractRank算法，之前group by后再row_number()倒排后取topN的邏輯，無法自動優(yōu)化成UnaryUpdateRank算法，性能急降（原因?yàn)閁naryUpdateRank算子有準(zhǔn)確性風(fēng)險(xiǎn)在內(nèi)部Flink3.7.3版本被下線）。多次調(diào)整和測試之后，確定無法通過配置優(yōu)化問題，最終通過多重邏輯優(yōu)化進(jìn)行化解。

• 將會場分類的曝光、商家商品的任務(wù)進(jìn)行邏輯拆分為兩個任務(wù)，防止商品或商家邏輯rank節(jié)點(diǎn)數(shù)據(jù)傾斜，導(dǎo)致整體數(shù)據(jù)出不來。
• 先做了一級聚合計(jì)算UV，減少TOP排序數(shù)據(jù)數(shù)據(jù)量，再做二級聚合優(yōu)化為UpdateFastRank算法，最終checkpoint秒級，回溯聚合一天曝光數(shù)據(jù)只需要10分鐘。
• 當(dāng)然還有一種策略是做二級TopN，先

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

?

數(shù)據(jù)大屏一直是實(shí)時場景高要求的代表，每次雙十一業(yè)務(wù)帶來的考驗(yàn)和挑戰(zhàn)，都會對整個實(shí)時數(shù)據(jù)體系和鏈路帶來新的突破。同時，飛豬的實(shí)時數(shù)據(jù)不僅僅只是止點(diǎn)亮媒體大屏，提效營銷分析和會場運(yùn)營，由實(shí)時公共層和特征層、實(shí)時營銷分析、實(shí)時標(biāo)簽和RTUS服務(wù)構(gòu)成的實(shí)時數(shù)據(jù)體系，正在全方位、多維度地附能搜索、推薦、營銷、觸達(dá)和用戶運(yùn)營等核心業(yè)務(wù)。

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

總結(jié)

以上是生活随笔為你收集整理的Hologres助力飞猪双11实时数据大屏秒级响应的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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