2024峰會-京東零售數據湖應用與實踐.pdf

《2024峰會-京東零售數據湖應用與實踐.pdf》由會員分享，可在線閱讀，更多相關《2024峰會-京東零售數據湖應用與實踐.pdf（20頁珍藏版）》請在三個皮匠報告上搜索。

1、DataFunSummitDataFunSummit#20242024京東零售數據湖應用與實踐京東零售數據湖應用與實踐陳洪健-京東-大數據架構師背景和痛點背景和痛點迭代和優化迭代和優化效果和收益效果和收益未來展望和規劃未來展望和規劃目錄目錄 CONTENTCONTENTDataFunSummitDataFunSummit#202420240101背景和痛點背景和痛點數據實時性和完整性矛盾在線分析和在線訓練場景需要數據具備實時性（T+0）和一定的歷史數據。但當前數倉采用Lambda架構，實時數據和歷史數據分別存儲在不同介質中，使得在需要同時具備實時性和完整性的數據應用場景下，用戶需要分別對接不同

2、的系統，使用不同的API實現需求，并且需要接受口徑差異問題，這樣的設計低效且不友好。架構維護成本高1、當前的埋點日志入倉采用自運維的Plumber任務，對物理機資源有強依賴，日常需求達到百臺，大促期間更需數百臺。但集團正處于減少物理機資源階段，可能無法滿足未來擴容需求。2、當前實時數據通過秒級數據實現，整體計算和存儲資源較高，對于低優先級或對時效無強要求的場景，存在資源浪費的情況。3、離線鏈路冗長，T+1批處理時數據量級波動大，導致任務時效性受影響。波動時GDM資產完成時間可能超過4:00，可能引發雪崩，任務集中搶占資源，導致大量任務延遲時效性問題。狀態數據的更新和存儲問題 在當前的傳統數據倉

3、庫架構中，數據狀態的更新是一種重量級操作，它的操作方式是將分區內全部數據重寫，即使其中的大部分數據沒有發生變化。這不僅浪費了大量的計算資源，也降低了系統的效率。另外，為了能快速查詢到歷史時刻的數據快照，我們每天或每小時都要存儲全量數據，這同樣消耗了大量的存儲資源。典型案例：商品價格表-小時粒度（目前只包含10%活躍商品）商品全量表-天粒度：每天數據量數千億，以每天數億的速度增長DataFunSummitDataFunSummit#202420240202迭代和優化迭代和優化技術方案1.流量涉及的生產庫寫實時Topic；2.將處理的離線MR作業改為流處理的Flink作業，提升數據時效；3.將數據

4、通過Flink作業寫入Hudi表；4.對數據進行邏輯加工和不同表的JOIN，生成GDM/RDDM 對外開放模型表；多流合并存儲模型存儲模型:分區表+MOR+Bucket 性能性能提升提升:降低list操作頻次、Bucket2GB 非分區表-分區表 限定保留版本數200(版本數*平均提交周期)，定時clean、Archive 異步Compaction操作 降低成本降低成本 多表資源復用(資源成本)可視化和自動建表(人力成本)數據一致性數據一致性:數據保序:表主鍵Hash分組傳輸 數據完整性:心跳機制和業務的時間窗去判斷數據的完整性，Precombine可持續性可持續性 健壯性(數據積壓、任務異常

5、、數據時延等)元數據更新，業務變更帶來的分析庫結構變更 穩定性(資源隔離、上游集中刷數、定時跑批)外鍵關聯每10min一批次，執行以下a)sku增量數據關聯維表(spu)全量數據b)spu增量數據關聯sku fdm全量數據c)union后寫入m03表關聯復雜降低策略關聯復雜降低策略:維度建模、分層存儲、臨時表 過載控制過載控制:記錄級限流，資源配置模型 開發方式開發方式:FlinkSQL+SparkSQL 能力增強能力增強:Hudi維度表的能力，維表lookup MOR表增量讀優化，優先讀取 Log 文件 Spark與Flink混寫一致性優化(索引、數據格式等)狀態后端表TTL設定，表級別 T

6、TL.持續穩定持續穩定:異?；謴?、監控告警增強(數據積壓、限流、checkpoint失敗、處理流量等)查詢優化1.數據緩存（1）Hudi 元數據緩存（2）Block級文件緩存：通過將外部存儲系統的原始數據按照一定策略切分成多個 block 后，緩存至 StarRocks 的本地 BE 節點，從而避免重復的遠端數據拉取開銷，實現熱點數據查詢分析性能的進一步提升。2.異步物化視圖物化視圖是特殊的物理表，能夠存儲基于基表的預計算結果。當對基表執行復雜查詢時，StarRocks 可以自動復用物化視圖中的預計算結果，實現查詢透明加速、湖倉加速和數據建模等業務需求。本地存儲加速本地存儲加速：物化視圖可以利

7、用 StarRocks 的本地存儲加速優勢，如索引、分區分桶和 Colocate Group，從而相較直接從數據湖查詢數據具有更好的查詢性能。無需維護加載任務無需維護加載任務：物化視圖通過自動刷新任務透明地更新數據，無需維護導入任務。此外，基于 Hive、Iceberg 和 Paimon Catalog 的物化視圖可以檢測數據更改并在分區級別執行增量刷新。智能查詢改寫智能查詢改寫：查詢可以被透明改寫至物化視圖，無需修改應用使用的查詢語句即可加速查詢。HUDIDataFunSummitDataFunSummit#202420240303效果和收益效果和收益時效提升實現離線數據的近線時效，增量式的

8、數據處理鏈路可以最大化提高數據產出的時效性，將T+1的數據縮短至T+0，可以顯著提高業務側觀測和監控數據效果的效率。流量離線gdm層計算完成時間由3:00-4:00提升至00:00-00:20，實現計算削峰，解決時效問題提升作業效率降低構建大寬表的資源成本，將數據修改原子化（刷數、刷崗），提升效率。當前BC每月例行刷數，需要刷adm層-app層-在線存儲層（ck）至少三層，涉及交易、用戶、財務主題，約數十任務，每個任務都需重新處理數千E左右數據，但是BC維度變化影響數據量不足5%，其中有95%的不變數據在浪費資源，后續可做到只修改變化數據刷崗設計解解決決方方案案APPADMDIMCK、Dori

9、sreloadBI報表GDMADMAPPStarRocksBI報表FDMBDM降低存儲數據由快照改為增量存儲，降低存儲代價，同時支持回看有狀態的歷史快照。當前全量商品數千億，為了能回看歷史每天全量存儲，一年共消耗約數PB，使用Time travel+Savepoint能力，一年減少存儲90%統一口徑和API流批一體的計算鏈路，統一計算引擎，天然做到數據口徑一致，較Lambda架構降低50%的維護和對接成本，對外做到離近線一套查詢Api，業務方無須異構取數，有效提高算法側迭代、AB效率。GDMADMAPP可視化大屏BI報表戰報Clickhouse1TopicRDDMAPPClickhouse2查詢分層使數倉具備索引能力，降低模型使用的開銷，提升查詢效率，同時可以直接對接主流引擎（Trino、Clickhouse、StarRocks等）實現查詢分層GDMADMAPPStarRocks、Trino可視化大屏BI報表戰報Clickhousedt分區DataFunSummitDataFunSummit#202420240404未來展望和規劃未來展望和規劃推進項 1）容災措施（機房宕機、任務重啟、數據修復等）；2）與批任務的資源隔離，彈性伸縮能力，優化資源消耗；3）Hudi流式寫入帶來的小文件問題；4）數據免疫系統建設 5）提升Hudi表的自管理能力，降低維護成本感謝觀看感謝觀看謝謝觀看