《數據與計算新范式：京東數據湖架革新之路》.pdf

《《數據與計算新范式：京東數據湖架革新之路》.pdf》由會員分享，可在線閱讀，更多相關《《數據與計算新范式：京東數據湖架革新之路》.pdf（26頁珍藏版）》請在三個皮匠報告上搜索。

1、數據與計算新范式：京東數據湖架構新之旅2025.03.29 北京快元中張越京東零售資深技術專家數據湖核定位與特性2.京東Hudi核研特性3.業務落地與實踐1.背景介紹數 倉 視 角站在數據平臺及數倉發展的視角，上述挑戰已成為該領域技術架構演進的核心驅動力，即如何以較低成本獲取強實時性、高質量的數據，進而推動數據平臺及數倉架構不斷向流批融合、湖倉一體方向發展，這種技術收斂的架構逐漸成為大數據技術發展的重要趨勢。主 要 矛 盾互聯網行業的不斷演進與業務的持續拓展，如何獲取高質量的數據逐漸成為核心挑戰之一。這種挑戰體現在業務數據規模膨脹對于數據實時性、數據口徑一致性、數據高效生產及獲取的訴求愈發強烈

2、，而這與傳統大數據平臺離線、實時架構下數據口徑不一致、實時數據占比低、兩套鏈路存儲計算及研發維護成本高的矛盾日益凸顯。京 東 內 部作為技術演進的關鍵成果，數據湖正在各大技術廠商中得到廣泛實施。在京東集團內部，數據湖技術也在迅速演進，展現出積極的增長勢頭，為業務數據的實時化轉型提供了強有力的支持。數據湖的演進數 倉 視 角數 據 湖 演 進2021年Databricks發表題為Lakehouse:A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics的論文，文章首次給出Lakeh

3、ouse的定義。經過近兩年的快速發展，目前數倉架構在企業中的演進已邁入第三階段，即湖倉一體階段。提 升 效 率Lakehouse一份存儲、一套數據口徑，為下游提供流、批兩種查詢方式，流批一體架構的優化，提升數據開發、運維和交付效率降 低 成 本通過Lakehouse技術，實現行級別更新和端到端增量改造，極大減少數據更新成本和全鏈路計算壓力，降低計算和存儲成本數據湖的定位數 據 湖 演 進在湖倉一體架構中，最關鍵的組成部分是數據湖表協議，它介于計算引擎和存儲引擎之間，通過開放存儲格式向上屏蔽底層文件存儲細節，提供“表”的概念，并提供ACID事務保障、快照管理、行級更新、流批讀寫、湖表文件元數據等

4、核心特性。同時結合各種計算、OLAP引擎向下讀寫數據。數 據 湖 演 進HUDI=HadoopUpsertsanDIncremental具備傳統數據庫的核心能力：行級別Upserts、Deletes以及可插拔的主鍵索引Index的能力 原子性、事務性、自動回滾的等能力具備傳統數倉的核心能力：適配Parquet、ORC等數據格式，適合海量數據多維分析場景 具備計算存儲分離的特點，有更好的擴展性與資源使用率增量處理的能力：Hudi能夠提供流讀、流寫的功能，從而構建端到端流式、分鐘級、準實時增量模型數據湖核特性京東Hudi核研特性1.數據湖定位與核特性3.業務落地與實踐2.湖表多模存儲 數據湖結構的

5、局限性數據時效性目前以Hudi、Paimon為代表的數據湖技術已經具備端到端分鐘級增量處理能力，由于數據湖存儲基于分布式文件系統，其分鐘級延遲幾乎是極限。但是許多業務場景，如搜索推薦、廣告歸因和異常檢測，都要求秒級實時響應。元數據割裂基于Hudi能夠構建分鐘級數據延遲的準實時鏈路，但與當前秒級時延的純流鏈路存在元數據割裂的問題，無法滿足基于業務時間溯源與探查等需求。擴展性有限Hudi目前依托于底層文件系統，在其上構建統一的元數據視圖，提供包括原子性、索引能力以及行級別更新等特性，但仍然是“一表一存儲”的設計，即表與底層物理存儲一 一對應。這樣的設計容易受到單個物理集群性能上限限制，且無法很好的

6、與大數據生態(HBase、Kafka、Redis)相結合。數據湖技術能夠構建端到端分鐘級時延、流批融合的數據鏈路，但仍然具備一定的局限性：湖表多模存儲 整體架構數 據 湖 演 進湖表多模存儲設計的核心邏輯是結合Hudi自身元數據，打破“一表一存儲”的設計，構建統一的IO抽象層與Hudi邏輯表視圖能力，實現數據湖表跨模態存儲，即“一表多存儲”。對外暴露邏輯表，實現對查詢、寫入端的透明；在不同存儲介質間，擴展Hudi表服務能力，即通過Clustering/Compaction實現跨集群湖表文件布局優化?？刹灏未鎯橘|統一 IO 抽象層邏 輯 表 視 圖湖表多模存儲 湖表數據緩沖層數據可見性與數據時

7、效數據寫入緩沖層并commit后即對下游可見，無論后續“搬運工作”何時開始與結束都不影響數據可見性與時效數 據 流 轉 過 程湖表數據緩沖層，即為湖表多模存儲的一個具體的落地場景，將湖表物理存儲劃分為以高性能HDFS為基礎的數據緩沖層和以共享HDFS為基礎的數據持久層一 致 性 語 義復用了湖表自身的Compaction和Clustering表服務能力，來實現緩沖層到持久層的數據搬運工作，該行為同樣遵循湖表的commit機制與MVCC快照隔離設計，因此湖表開啟數據緩沖層后，同樣具有原子性、事務性保障以及Exactly Once語義熱數據先寫到數據緩沖層，后續再通過Clustering/Comp

8、action等表服務“搬運”至數據持久層，滿足性能、穩定性訴求湖表多模存儲 湖表數據緩沖層普通湖表讀寫流程湖表數據緩沖層讀寫流程 下圖展示普通Hudi表與開啟緩沖層后的Hudi表讀寫流程之間的對比。在未開啟緩沖層之前，計算引擎直接寫入數據到共享HDFS并commit；計算引擎查詢Hudi表直接從共享HDFS中讀取數據。開啟數據緩沖層后，計算引擎先將熱數據寫入到高性能HDFS中后并commit；引擎直接查詢邏輯視圖，緩沖層與持久層數據均響應查詢需求。通過Clustering或Compaction服務，完成數據搬運及對湖表文件的整理。湖表多模存儲 湖表數據緩沖層基于京東線上環境真實流量曝光數據進行

9、壓測，關注平均吞吐量(條數/分鐘)、Flink作業CP時長及失敗重啟次數。結論：開啟緩沖層后，Hudi寫入性能提升2倍，CP時長減少70%，Hudi寫入任務穩定性提升98%數據湖Black Hole框架為探索Hudi IO性能的極限，我們設計并實現Blackhole性能壓測方案，思路如下：拆解Hudi IO過程為數據加工、組織IO流、數據IO三個階段，通過對比各階段組合的性能數據，去判定Hudi在COW表和MOR表模式下的性能天花板和瓶頸，并以此輔助分析后續優化的技術方向。數據加工：數據序列化/反序列化、元數據字段填充、索引查找 組織IO流：并發模型、Parquet Row Group組織與壓

10、縮等 數據IO：調用外部存儲的SDK構建輸出流針對不同階段，接入“Blackhole”，并壓測其性能天花板IO性能優化 進制流拷ClusteringHudi表主要采用Parquet格式，計算引擎在Clustering過程中數據會經歷“列轉行再轉列”的過程，在這個過程中數據沒有發生變化（不考慮排序），只是從源文件復制到目標文件，但過程卻涉及到壓縮/解壓縮、編解碼、行列互轉、計算引擎行格式與Hudi行格式的互轉等計算邏輯，存在比較大的計算浪費，耗時也比較長。IO性能優化 進制流拷Clustering優化思路：提供HoodieParquetRewriter能力，在Clustering合并小文件的過程

11、中，省略繁瑣的行列數據轉換與壓縮過程，直接按照RowGroup、ColumnChunk進行二進制拷貝到目標文件，最終再重寫Footer。支持Schema演進，Hudi支持Schema演進，包括增加字段、放大數值類型等，而數據開發過程經常出現Parquet文件Schema不一致的情況。為保證合并后文件Schema與表Schema一致，HoodieParquetRewriter會獲取表最新的Schema作為輸出文件的Schema，并依次與輸入文件的Schema進行對比，如果文件Schema中存在缺失字段，則在二進制流拷貝過程中對缺失的字段填充空值。支持Hudi自定義元信息合并，在HoodiePar

12、quetRewriter中會記錄每個輸入文件的Footer 中Hudi元數據元信息，并在完成數據二進制拷貝后分別計算出對應的最新元信息，并寫入到Parquet文件中。hoodie_min_record_key、hoodie_max_record_key、org.apche.hudi.bloomfilter、hoodie_bloom_filter_type_codeIO性能優化 進制流拷Clustering配置相同參數，分別以默認策略與二進制流拷貝策略對100GB數據進行Clustering，二進制流拷貝執行策略相較于默認執行策略，執行時長縮短93%，計算量減少95%默認策略：耗時18分鐘，Ta

13、skTime 28.7小時二進制流拷貝策略：耗時1.2分鐘，TaskTime 1.3小時京東數據湖態全景在持續改進和提升數據湖核心能力的基礎上，逐步構建起一個完善的數據湖生態系統。這個生態系統覆蓋數據接入、管理和分析等全生命周期，如下圖所示：集成入湖對接集成平臺DataBus，支持多種數據類型、多種接入方式將其他外部系統的數據快速導入到數據湖中。湖表管理對接數據管理平臺DMS、數據星圖DataOS，提供對湖表的統一管理，包括創建、獲取及修改、刪除等操作，將湖表管理的入口統一收斂。數 據 開 發基于實時計算平臺JRC、開發中心Easy Studio加工數據湖表中的數據，引擎涉及Flink、Hiv

14、e、Spark，滿足用戶流、批加工湖表數據的需求。京東數據湖態全景數據質量支持對數據湖表中的數據進行質量監控及掃描，從完整性、唯一性、有效性和準確性等多個維度配置監控規則并進行校驗。數據查詢支持使用多種查詢引擎（Spark、Hive、Presto、Doris）對數據湖表中的數據進行查詢和檢索，提供靈活的數據訪問手段。湖 表 切 換在完成數據湖表中數據的處理加工，且數據質量滿足業務要求后，下游業務可以從原先Hive表切換到當前湖表，確保數據的連續性和一致性。業務落地與實踐2.京東Hudi核研特性1.數據湖核定位與特性3.京東流量資產數據湖升級 歷史痛點模型割裂不同類的用戶交互行為模型，如曝光、點

15、擊、瀏覽、訂單等，又按照埋點上報端來劃分為主站APP、M、PC、WEIXIN及各垂站APP等，再考慮實時和離線，同一類的交互模型將衍生出10余張表或流模型，共40+模型，相互割裂難以維護。架 構 負 擔 重原流量數倉采用典型的Lambda架構，具有全量流量的離線加工鏈路以及部分白名單的實時數據加工鏈路兩套。長期以來存在離線、實時數據對不齊，多種計算組件和架構范式導致的成本負擔高等問題時效性不完備流量全量數據T+1時效，且SLA壓力大流量資產，作為京東體量最大，應用范圍最廣的數據資產之一，在京東搜推廣等場景一直有較為廣泛的應用，但傳統的流量資產存在以下幾個痛點京東流量資產數據湖升級 湖倉架構近5

16、年京東零售數倉最大規模的一次升級，實現流量資產流批融合，基于一份流量數據、統一口徑，同時滿足下游實時、離線分析與加工訴求。新架構圖如下京東流量資產數據湖升級挑戰與解決案2024PerformanceStabilityData SkewScalability穩定性挑戰：京東某些HDFS集群繁忙度較高，流寫會出現timeout重試甚至異常重啟。解決方案：自研湖表多模存儲能力，流量數據先寫高性能、強穩定緩沖層，以保障流任務穩定性。擴展性挑戰：隨著流量數據量的持續提升以及大促場景下的驟增，受Flink機房資源限制，單個Flink集群擴容出現瓶頸，此時需要將任務拆分多個，并發Append同一張流量湖表解

17、決方案：解決元數據沖突、JM與TM通信沖突、以及Hive元數據同步的沖突，實現輕量級的無鎖并發Append，解決擴展性問題數據傾斜與小文件挑戰：業務分區傾斜嚴重，最大分區與最小分區數據量相差730萬倍，需解決數據傾斜和隨之帶來的小文件問題。解決方案：在Flink流寫Hudi的核心拓撲鏈路上，新增一個自定義partitioner接口，通過業務數據分布特點，定義分區策略。性能挑戰：京東某些HDFS集群繁忙度較高，過保機器較多，Flink流寫會出現timeout重試甚至異常重啟，導致寫入性能均值吞吐受限，且擴資源效果不明顯。解決方案：自研湖表多模存儲能力，流量數據先寫高性能緩沖層，再通過Cluste

18、ring服務搬運至持久層，保證事務性、時效性的同時，極大提升寫入性能，且吞吐能夠橫向擴展。京東流量資產數據湖升級 收益成本節降在流量數據增長60%的前提下，共計節省 2,047萬元/年數據時效與SLA 數據新鮮度由天級別提升至15min T+1 GDM層流量數據全部就緒時間從02:40提前到00:40，提前2小時大促表現 大促期間，面對流量洪峰總量同比增長 79.7%，均值達 4.5億條/min，首次實現流量數據大促全時段無延遲 大促期間，新模型SLA穩定，相比舊模型，T+1 GDM層流量數據全部就緒時間，提前5小時交易更新場景數據湖升級 架構2024業務背景交易表特征在于歷史存量大，日變化量相對較小，且大部分的更新隨機發生在較新的訂單上，而對舊訂單有著長尾分布的特性。以交易某表為例，歷史全量上千億條，日變化量不足1%。離線數倉加工時，為了計算訂單的最新狀態，需要基于歷史全量訂單與當日增量進行開窗、關聯等操作，并進行全量刷寫，整體計算成本高、時效性差，目前離線時效為T+2交易更新場景數據湖升級 收益離線計算賬單 成本節省 79.3%數據時效：從 T+2 優化到 每天05:20 出數(依賴上游5:00 產出的數據)，實際執行時長從10小時縮短到20分鐘，全數據鏈路滿足業務當天看數的切實訴求。Thanks！2025.03.29 北京快元中