于汝國-京東流量資產基于湖倉架構的落地實踐(1).pdf

《于汝國-京東流量資產基于湖倉架構的落地實踐(1).pdf》由會員分享，可在線閱讀，更多相關《于汝國-京東流量資產基于湖倉架構的落地實踐(1).pdf（16頁珍藏版）》請在三個皮匠報告上搜索。

1、京東零售-集團數據計算平臺于汝國/技術專家京東流量資產基于湖倉架構的落地實京東流量資產基于湖倉架構的落地實踐踐背景與痛點01挑戰與優化02收益與表現03總結與展望04目 錄01 背景與痛點Lambda架構湖倉一體架構離線與實時異構 鏈路冗余，成本較高 數據口徑不一致數據重復問題離線T+1數據時效，SLA壓力較大統一數據口徑，減少存儲成本基于Hudi事務能力，實現EOS（Exactly-Once Semantics）Flink+Hudi為下游提供分鐘級數據02 挑戰與優化多模IO能力挑戰：挑戰：某些HDFS集群在熱點時段繁忙度較高。此時Flink流寫Hudi會出現timeout重試甚至異常重啟，

2、導致寫入性能均值吞吐受限，且擴Flink資源對性能提升效果不明顯解決方案：解決方案：自研湖表多模IO能力，將湖表物理存儲劃分為緩沖層和持久層，流量數據先寫高性能緩沖層，極大提升寫入性能與任務穩定性，且吞吐能夠橫向擴展可 插 拔 存 儲 介 質統一 IO 抽象層落地場景邏輯表視圖02 挑戰與優化多模IO能力數 據 可 見 性與 數 據 時 效數據寫入緩沖層并commit后即對下游可見，無論后續“搬運工作”何時開始與結束都不影響數據可見性與時效數 據 流 轉 過 程熱數據先寫到數據緩沖層，后續再通過Clustering/Compaction等表服務“搬運”至數據持久層，滿足性能、穩定性訴求一 致

3、性 語 義復用了湖表Compaction和Clustering表服務能力，來實現緩沖層到持久層的數據搬運工作，該行為同樣遵循湖表的commit機制與MVCC快照隔離設計，因此湖表開啟數據緩沖層后，同樣具有原子性、事務性保障以及EOS語義 02 挑戰與優化多模IO能力普通湖表讀寫流程湖表數據緩沖層讀寫流程02 挑戰與優化多模IO能力湖表數據緩沖層 讀 寫 流 程開啟湖表緩沖層Flink任務入湖速率監控:開啟湖表緩沖層后，入湖任務寫入均值速率和穩定性有所改善 未開啟湖表緩沖層相同資源 開啟緩沖層后：更快、更穩定 Hudi寫入吞吐提升100%CP時長減少95%穩定性提升97%02 挑戰與優化湖表動態

4、分區策略挑戰：挑戰：業務分區傾斜嚴重，最大分區與最小分區數據量相差730萬倍，需解決數據傾斜導致的寫入性能和小文件問題解決方案：解決方案：在Flink流寫Hudi的核心拓撲鏈路上，新增自定義Partitioner策略，根據湖表數據特征來路由數據，從而緩解數據傾斜，控制文件數量File File numnum =表分區數*Sink并行度eg：表分區數54，Sink并行度2000，一次commit產生文件數至少為10.8w個02 挑戰與優化湖表動態分區策略優化：優化：根據各個分區的大小來設計動態分區策略，數據量較大的分區(如S、P)，單獨路由到特定的subtask集合，集合的大小根據該分區對應的數

5、據量大小確定，S分區占據了近一半的數據，因此它的subtask集合占據了Sink算子并行度的一半，而其他非常小的分區則三兩成隊路由到單獨的subtask（盡量減少單個subtask寫分區數量，減少寫入句柄切換）。效果：效果：按此方式優化后，一次commit寫入的文件約為6000+，減少了94%，寫入性能提升了1倍多。02 挑戰與優化多寫并發Append挑戰：挑戰：隨著流量數據量的持續提升以及大促場景下的驟增，受Flink機房資源限制，且單個Flink集群即使擴容后性能也會出現瓶頸，如何提升實時入湖任務的寫入性能成為一大挑戰解決方案解決方案：將入湖任務拆分成多個，通過擴展湖的多寫能力并發Appe

6、nd同一張流量湖表檢查點元數據沖突Hive元數據沖突任務任務1 1 分區S、分區P任務任務2 2 非分區S、分區P02 挑戰與優化反序列化優化挑戰：挑戰：新架構仍舊以JSON為數據格式，但是比舊架構多了120+字段，行級的反序列化成本很高，尤其數據量級增大之后，往往成為整個任務的性能瓶頸解決方案：解決方案：將source讀取消息后的反序列化操作拆解到單獨的算子中，通過擴并行度提升任務性能 解析Headers過濾不需要的業務域數據，而非通過Deser整個消息后來過濾優化優化1 1：將Deser操作從Source算子中抽出來，Source算子只負責從Topic拉取字節級的消息數據，通過注冊一個專門

7、JsonDeser的Lookup Table來執行Deser操作，該Lookup算子并行度可按性能要求調整02 挑戰與優化反序列化優化SELECT value,proc_timeFROM source_diWHERE(CAST(headersa AS VARCHAR)=jd_main_app)and(CAST(headersb AS VARCHAR)in(S,P)union all SELECT value,proc_timeFROM source_inner_diWHERE(CAST(headersa AS VARCHAR)=jd_main_app)and(CAST(headersb AS

8、VARCHAR)in(S,P)優化優化2 2：受限于Flink單任務瓶頸，采用拆任務方式來提高入湖性能，但拆分需要根據消息所屬業務域來進行，為避免拆分后的任務仍需要序列化整體數據，我們將消息業務域字段寫入Topic消息Headers中，拆分后的任務只需要解析Headers來過濾掉不需要的業務域數據，而非通過Deser整個消息后來過濾02 挑戰與優化流轉批處理挑戰：挑戰：在處理實時湖表時，需要一種機制來感知湖表的業務時間水位線，并判斷何時 T-1 的數據已準備就緒，以便正確啟動下游的離線加工任務解決方案：解決方案：通過流量湖表的流轉批機制來實現這一目標03 收益與表現58.3%基于社區Clust

9、ering能力，實現分區級30min數據全局排序與合并，提升數據壓縮率，存儲成本節降58.3%在流量數據增長60%的前提下，共計節省 2,000+萬元/年存儲節降2 小時 數據新鮮度由天級別提升至15min T+1 GDM層流量數據全部就緒時間日常從02:40提前到00:40，提前2小時SLA與時效提升平穩無延遲 流量洪峰總量同比增長79.7%，均值達4.5億條/min，首次實現流量數據大促全時段無延遲 新架構SLA穩定，相比原架構，T+1 GDM層流量數據全部就緒時間，從06:03提前至00:54，提前5小時雙11大促04 總結與展望流量資產在湖倉一體架構的轉型落地，解決流量資產在原Lamb

10、da架構下離在線數據對不齊，計算及存儲架構范式不統一等問題，流批數據同源同模型，并額外提供了近實時增量數據，提升用戶接入體驗和效率，拓寬業務使用場景。生產大規模流讀流量數據資產的下游業務主要以批讀方式為主，目前還未在生產環境中大規模驗證過流讀，主要考慮的點包括：流讀數據穩定性、處理性能以及數據完整性等。目前在流讀方面滿足生產可用的級別做了一些完善，包括支持更細粒度（inputsplit）的限速、靈活的數據下發策略、多寫場景下流讀、豐富的metric指標等。數據湖秒級時延數據在入湖時，先寫入數據文件和元數據，提交事務成功后數據才可見，因為涉及到與文件系統的交互，整體寫入較慢，因而一般為分鐘級提交。未來可以擴充數據湖分層存儲的能力，將數據寫入到Kafka、HBase、Redis等高速存儲中，在湖表的元數據中記錄高速存儲的位點、key等元信息。在讀取時將持久存儲與高速存儲的內容聯合到一起，從而使Hudi實現秒級別時延。演講人：于汝國 技術專家感謝大家觀看