?在當今數字化商業浪潮中，數據無疑是企業的核心資產，而流量數據更是電商巨頭京東業務運轉的關鍵驅動力。它廣泛應用于搜索推薦、廣告投放等多個核心業務場景，直接影響著用戶體驗和商業效益。但隨著業務規模的不斷膨脹，傳統架構在處理流量數據時逐漸力不從心，升級架構迫在眉睫。本文將深入剖析京東流量資產架構從 Lambda 架構邁向湖倉一體架構的變革之旅，包括面臨的挑戰、創新的解決方案、顯著的收益以及未來的發展方向。

今天的介紹會圍繞下面四點展開：

1.?背景與痛點

2.?挑戰與優化

3.?收益與表現

4.?總結與展望

---

01背景與痛點

京東早期采用?Lambda?架構，在處理流量數據時，構建了離線和實時兩條獨立的處理鏈路。在實時鏈路中，數據經埋點采集服務裁剪解析后，進入消息隊列，再由?Flink?實時加工處理，供下游業務實時使用；離線鏈路則將全量數據存儲到對象存儲，后續通過?Hive?加工，為下游業務提供離線數據分析支持。

這種架構雖然能提供不同時效的數據服務，但弊端明顯。計算資源方面，兩條鏈路獨立運轉，導致計算資源雙倍消耗，開發和維護成本也隨之翻倍。存儲和計算架構異構，使得實時流數據和離線表數據常常無法對齊，存在數據差距，下游用戶在使用數據時，需要花費大量時間和精力排查解決數據不一致問題，使用體驗較差。

此外，為優化離線鏈路時效，采用小時級加工替代?T+1?批處理，卻引入了數據冗余存儲和多次拷貝的問題，進一步增加了存儲和計算成本。而且，流量數倉?GDM?層?T+1?數據時效在日常通常為凌晨兩點，面對復雜的內部業務場景，下游計算處理時間緊張，數據的?SLA（數據可用性保證）難以保障，在大促或流量高峰期，問題更加突出，嚴重影響業務決策的及時性和準確性。

為解決?Lambda?架構的痛點，京東引入湖倉一體架構。湖倉架構具有諸多特性，如支持數據更新、存儲分離，能處理結構化和非結構化等多種數據類型。在流量資產場景中，其端到端的分鐘級能力、支持事務保障數據讀寫一致性、MVCC（多版本并發控制）提供輕量級時間旅行能力以及數據重新布局降低存儲和查詢成本等特性，發揮了關鍵作用。

在新架構下，數據經埋點采集服務進入消息隊列，由?Flink?實時加工后實時寫入湖表。湖表數據既能滿足下游業務分鐘級時延的實時需求，也可供下游業務通過批讀方式進行離線處理。新架構將兩條鏈路收斂為一條，統一了數據口徑，減少了存儲成本。基于?Hudi?的事務能力，實現了數據處理的?EOS（Exactly-Once Semantics，精確一次語義），確保數據處理的準確性和完整性。Flink?與?Hudi?的技術組合，為下游業務提供了近實時的精準數據，有力地支持了業務的高效運營。

02挑戰與優化

1.?多模?IO?能力優化：突破寫入性能瓶頸

在?Flink?實時寫入?Hudi?的過程中，某些?HDFS?集群在熱點時段繁忙度高，導致?Flink?寫入任務頻繁出現?timeout?重試，甚至作業失敗重啟，嚴重限制了寫入性能。單純擴充?Flink?資源，對性能提升效果不佳。

京東自研多模?IO?能力，將湖表物理存儲劃分為緩沖層和持久層。創新性地設計統一的?IO?抽象層和?Hudi?邏輯表視圖，底層存儲可插拔集成多種介質，如?HDFS、OSS、Kafka、HBase、Redis?等。熱數據先寫入以高性能?HDFS?為基礎的緩沖層，后續通過?Hudi?的?Clustering、Compaction?表服務將數據搬運到共享?HDFS?持久層。

開啟數據緩沖層后，Flink?實時入湖任務的寫入均值速率和穩定性顯著提升。對比測試顯示，寫入吞吐提升?104%，checkpoint?平均完成時間減少?95%，作業異常失敗次數大幅降低，穩定性提升?97%，有效解決了寫入性能和任務穩定性問題。

2.?湖表動態分區策略：應對數據傾斜難題

業務分區數據傾斜嚴重，最大分區與最小分區數據量相差達?730?萬倍。若直接寫入湖表，會產生大量小文件，給?HDFS?存儲和后續處理帶來巨大壓力，同時單個?subtask?寫多個分區文件，頻繁切換文件柄也會消耗大量性能。

京東在?Flink?流寫?Hudi?的核心拓撲鏈路上，新增自定義?Partitioner?策略。根據分區大小設計動態分區方案，數據量大的分區（如?S?分區）單獨路由到特定的?subtask?集合，集合大小依據分區數據量確定；小分區則三兩成組路由到其他單獨的?subtask。優化后，一次?commit?寫入文件數從約?10.8?萬個減少到?6000?多個，減少了?94%，寫入性能提升一倍多，有效緩解了數據傾斜和小文件問題。

3.?多寫并發?Append：突破流量增長瓶頸

隨著流量數據量持續增長，尤其是大促期間數據量驟增，Flink?機房資源有限，單個?Flink?集群即使擴容也會出現性能瓶頸。

京東將入湖任務拆分，利用湖的多寫能力并發?Append?同一張流量湖表。例如，將數據量大的?S、P?分區拆分成一個任務，非?S、P?分區拆分成另一個任務。在拆分過程中，解決了檢查點元數據沖突和?Hive?元數據同步沖突等問題。通過在每個任務的檢查點元數據目錄維護各自元數據信息，確保任務失敗時可回滾恢復；每個作業維護自己的?last_commit_time?標識，避免分區缺失問題，實現了輕量級并發?Append，提升了實時入湖任務的寫入性能。

4.?反序列化優化：降低行級反序列化成本

新架構采用?JSON?數據格式，且比舊架構多了?120?多個字段，行級反序列化成本高，成為任務性能瓶頸。

京東采取兩項優化措施。一是將反序列化操作從?source?算子中抽離，source?算子僅負責從?Kafka?拉取字節級消息數據，通過注冊專門的反序列化?lookup table?執行反序列化操作，并擴展該算子并行度提升讀取性能。二是在拆分任務時，將消息業務域字段寫入?Kafka?消息?header?中，拆分后的任務只需解析?header?過濾數據，避免反序列化整條消息，有效降低了反序列化開銷。

5.?流轉批處理：精準調度離線任務

在處理實時湖表時，需要一種機制感知湖表業務時間水位線，判斷?T-1?數據是否準備就緒，以啟動下游離線加工任務。

京東通過流量湖表的流轉批機制實現這一目標。改造?Flink Hudi writer，使其將業務時間寫入元數據，流轉批服務定期掃描湖表元數據中的業務水位線。當所有分區水位線最小值超過?T?日零點，且對應的?Clustering?表服務合并完成時，表明?T-1?數據準備就緒，下游離線任務即可調度運行，確保了離線任務調度的準確性和及時性。

03顯著成效：湖倉架構升級的收益

1.?數據時效性飛躍

湖倉一體架構升級后，數據時效性從?T+1?提升到?15?分鐘，SLA?從凌晨兩點半提前到零點半。數據量越大，SLA?提升越明顯，為下游業務提供了更充裕的處理時間，極大地提高了業務響應速度和決策效率。

2.?存儲成本降低

基于社區?Clustering?能力，實現分區級?30?分鐘數據全局排序與合并，提升了數據壓縮率，存儲數據量從每天?120TB?優化到?50TB，存儲成本降低?58.3%。在流量數據增長?60%?的情況下，每年節省兩千多萬元，有效節約了企業運營成本。

3.?大促表現卓越

在去年雙?11?大促期間，面對流量洪峰，最大流量曝光模型總量同比增長?80%，均值達每分鐘?4.5?億。新架構首次實現流量數據全時間段平穩運行且無延遲，SLA?更加穩定，T+1 GDM?層流量數據全部就緒時間從?6?點?03?分提前到 0?點?54?分，提前了?5?個小時，有力保障了大促期間業務的穩定高效運行。

04 未來展望：持續創新的方向

1.?探索生產環境大規模流讀

目前，流量數據資產下游業務主要以批讀方式為主，流讀在生產環境中尚未大規模驗證。未來，京東將重點關注流讀數據的穩定性、處理性能和數據完整性。當前已在流讀方面進行了部分完善，如支持更細粒度的限速、靈活的數據分發策略、多寫場景下的流讀功能，并豐富了?metric?指標用于監控，后續將進一步探索和優化，推動流讀在生產環境中的大規模應用。

2.?追求?Hudi?秒級實時處理

數據入湖時，寫入速度較慢，通常為分鐘級提交。京東計劃擴展湖表多模?IO?能力，將數據寫入?Kafka、HBase、Redis?等高速存儲中，并在湖表元數據記錄高速存儲的位點和?key?等元信息。讀取時，將持久存儲與高速存儲內容聯合，實現?Hudi?的秒級時延，進一步提升數據處理的實時性。

京東流量資產湖倉一體架構的升級實踐，成功解決了傳統架構的諸多問題，取得了顯著的成效。未來，京東將繼續在流讀和實時處理等方面深入探索創新，不斷挖掘流量數據的價值，為業務發展注入強大動力，也為行業數據架構的發展提供了寶貴的借鑒經驗。