在當今以數據為核心的商業環境中，企業正面臨著海量數據的處理和分析挑戰。為克服傳統數據倉庫在處理速度、靈活性和成本效率方面的局限，小紅書數據倉庫團隊引入如 Apache Iceberg 等數據湖技術，將其與數倉架構相結合，以釋放數據湖在查詢性能、實時數據處理和成本效益方面的潛力。

小紅書數據倉庫團隊通過一系列創新實踐，如 UBT 鏈路優化查詢效率、渠道歸因數據架構改造、漢姆拉比數據鏈路優化以及直播準實時鏈路提升等，證明了數倉與數據湖技術的結合能帶來顯著的業務價值：不僅提升用戶體驗，還實現了計算和存儲資源的大幅度節約，同時確保了數據的高質量和一致性。

未來，團隊計劃繼續利用數據湖技術構建準實時的數據新架構，以滿足企業對數據時效性的多樣化需求。

一、背景

過去十多年，Hive/Spark on HDFS 作為離線數據倉庫的事實標準，在實踐中得到了廣泛應用。然而，隨著業務對數據時效性和查詢性能要求的提升，Hive 的傳統架構開始顯現出其局限性。具體表現在：

• 數據變更成本高昂：即使僅變更一條記錄，也需要重新刷新整個分區的數據；
• 數據產出時效性差：分區數據通常需要 T+1 日期才能完成；
• 數據查詢性能緩慢：查詢相關數據通常需要掃描目錄中的所有文件，大表查詢耗時且效率低下；
• 資源利用率不足：所有天級調度任務的資源消耗全部集中在調度期間，容易導致多任務搶占資源，影響資源使用效率。

這些性能問題嚴重制約了數據倉庫在支持業務決策中的作用。為了應對這些挑戰，我們積極探索新方向，力求在滿足業務日益多樣化的需求下，總結出一些通用化、低成本的數倉架構新方案以解決上述問題。本文詳細記錄了我們在數倉架構和數據湖技術結合方面的深入探索和實踐，期待對您有幫助，歡迎結合自己興趣和相關業務自主選擇閱讀。

二、數據湖技術優勢

數據湖技術近年來在數據管理領域引起了廣泛關注，其優勢在于提供了一種靈活且高效的數據存儲和處理方式。一方面，在 Apache Iceberg、Apache Hudi 等知名開源項目的推動下，社區氣氛十分活躍；另一方面，處于鏈路上下游的數倉軟件和數據分析引擎，也開始積極擁抱開放的數據湖格式，如 Doris 系的開源數倉和 Starrocks 引擎，它們能夠查詢 Iceberg 數據，進一步證明了數據湖技術的實用性和前瞻性。

不同于原有的 Hive 數倉架構，Iceberg 依托于其文件級數據追蹤的技術架構，展現出以下顯著優勢：

• 查詢性能提升：Iceberg 支持異步數據重組(如 Zorder)，結合動態列全局排序和索引機制，大幅減少查詢時的文件讀取量，顯著提升查詢效率和 shuffle 性能。
• 增量讀寫能力：小紅書自研的 Iceberg 適配了 Spark 引擎，支持 update、merge into、delete 等語義，能夠對指定文件進行刪除和更新操作。相較于 Hive 的分區目錄完全重刷，可將更新成本降低至文件粒度。
• 流批一體架構：Iceberg 基于增量讀寫機制，通過適配 Flink 等實時引擎的讀寫，形成了“MQ + Flink + Iceberg”的流批一體架構。對于近實時的需求，這種架構既可以提升數據產出的時效性，也可以省去維護 Lambda 架構所需的人力和資源成本。
• 成本效應顯著：Iceberg 底層采用 Parquet 文件格式，其列存儲格式和索引排序機制通過提升重復字段的壓縮效率，進而節約了存儲成本。

三、UBT鏈路優化查詢效率

UBT 日志（User Behavior Tracking），全稱用戶行為追蹤日志，詳細記錄了用戶在特定平臺、應用或網站上行為軌跡，如頁面訪問、圖片曝光、按鈕點擊等。作為流量數據的核心組成部分，UBT 也是小紅書數據倉庫中數據量最大、查詢頻次最多的數據表之一。隨著小紅書用戶基數的快速增長和使用時長的增加，流量數據規模不斷膨脹，導致 UBT 日志查詢效率低下，用戶體驗受損。用戶在進行日志查詢時，常常面臨長時間的等待，甚至在數據量過大時無法完成查詢，這些問題嚴重制約了數據驅動決策的效率和效果。

3.1 歷史方案回顧

在處理 UBT 日志數據時，我們曾采用一種樸素的方法：將數據從主表抽取到多個分流表中，以便下游業務方能夠針對特定需求進行查詢。這種方法在業務邏輯相對簡單時，能夠有效減少查詢的數據量，提高查詢效率。

然而，隨著業務復雜度的增加，這種方法暴露出一系列問題：

• 成本與復雜性增加：隨著業務規則的多樣化，分流表的數量迅速增長，導致計算和存儲成本不斷攀升，且難以管理。
• 數據一致性挑戰：對分流規則的任何變更都需回刷大量歷史數據，這不僅耗時耗力，還可能引入數據不一致的風險。
• 數據冗余與維護困難：個性化的分流規則缺乏通用性和排他性，數據在不同規則間重復存儲，增加了維護的難度。

這種基于自定義規則的分流策略，在面對日益增長的數據量時，不僅資源消耗巨大，而且難以維護，嚴重影響了數據的實時性和查詢效率。在某些情況下，缺乏分流表支持的原日志查詢變得異常困難。

3.2 查詢性能優化

在流量數據分析中，點位(埋點)作為描述用戶特定行為的關鍵標識，也是業務數倉數據加工的基礎粒度。面對小紅書線上近萬個點位的龐大數據量，我們實施了一系列查詢性能優化策略，以提升數據處理效率。

我們認識到，通過點位限制幫助用戶縮小數據范圍，加速后續的業務邏輯處理，可有效提升查詢性能。然而，傳統的分區策略在面對龐大的點位數量時顯得力不從心，Hive Metastore 難以承受巨大的分區規模。因此，我們的目標轉變為如何能購針對特定點位的數據進行快速定位并篩選，實現數據范圍的精確縮小。

從這一視角出發，數據湖為我們提供了新的視角和解決方案。我們采用了全局排序的方法，將相同點位的數據集中存儲，而將不同點位的數據分散存儲在不同的文件中。這種策略不僅提升了文件過濾的效率，還通過引入 Iceberg 技術，將點位的 min-max 信息存儲在 meta 文件中。這樣，在任務規劃階段，查詢引擎就能利用這些信息進行文件過濾，顯著減少了實際查詢過程中需要處理的文件數量，從而實現了查詢性能的大幅提升。

性能優化方案如下：

• 全局排序：按照點位 ID 進行全局排序，實現了自定義的數據抽樣和分區劃分的邏輯，并且為大點位劃分更多分區，解決了大小點位數據傾斜問題，從而提高單個點位的計算效率。另外，為解決隨機采樣可能存在誤差的問題，我們借助 Spark Sql 的自動查詢優化（AQE）功能作為兜底，并開發了 bypass hash 函數，以便在 Spark 中實現自定義分區，根據數據生成的 partition_id 來劃分分區。
• 分區排序與去重：若日志數據存在重復的情況，按照傳統思路，需要先去重然后再排序來優化查詢，這會帶來兩次 shuffle，顯著增加計算成本。為了解決這一問題，我們基于全局排序采取了一種創新的方法：在數據按點位 ID 排序的同時，直接在排序過程中識別并過濾掉重復的數據。
• Iceberg 視圖生成：為了確保與現有 Hive 生態系統的兼容性，我們在 Hive 表上建立了外部 Iceberg 表級視圖。這一視圖通過掃描數據文件并提交文件 metric 信息，使得下游系統能夠基于 Iceberg 的 MinMax 提升查詢性能，并且能直接讀取視圖進行數據消費，簡化了數據訪問流程。

通過這些優化，UBT Iceberg 表的查詢性能得到了顯著提升，用戶在查詢特定點位數據時的時長縮短了約 80～90%，極大地提高了數據處理的效率和用戶體驗。

3.3 新分流方案

上述性能優化提升了用戶對點位的查詢效率。點位是用戶使用日志的基礎粒度，我們開始進一步考慮以點位為基礎，構建一套新的分流體系，旨在替代原有的分流表體系。新體系的設計遵循了三個核心原則：確保分流查詢性能滿足用戶需求、最小化存儲和計算開銷、以及限制分流表的數量以避免無序增長。基于這些原則，我們設計了以下新分流方案：

• 分流轉換功能：新方案實現了在 Spark 執行計劃層，自動將對分流表的查詢轉換為對 Iceberg 表中特定點位集合的查詢，從而提高了查詢效率。
• 業務場景導向：新分流體系以通過構建實際業務場景作為準入標準，每個業務場景對應一個分流表，同時通過上線流量產品注冊收攏分流表的創建，這樣既明確了分流的業務含義，也杜絕了分流數量的無限制上漲。
• 視圖封裝：在分流轉化函數外層，我們封裝了分流表視圖，這使得下游業務方無需感知內部優化，簡化了數據訪問流程。

新分流表不再直接存儲數據，也無需任務調度，從而避免了計算和存儲資源的消耗。更新分流表時，只需調整點位集合，無需回刷歷史數據。得益于之前的查詢性能優化，新分流方案在滿足業務需求的同時，也保持了高效的查詢性能。

相較于舊方案，新分流方案每天可節省數十萬 GB/Hour 的計算資源和幾百 TB 的存儲資源，同時任務產出時效提升了約 30 分鐘，查詢性能得到了數十倍的提升。這一改進不僅提升了數據處理效率，也為未來的數據分析和業務決策提供了更堅實的基礎。

四、渠道歸因數據架構改造

渠道歸因作為分析用戶行為路徑、埋點歸因的關鍵工具，對于社區、電商和直播等業務的流量分析至關重要。它不僅支持流量來源和轉化分析，還有助于深入理解用戶路徑。作為數據倉庫的基礎服務，渠道歸因要求具備高實效性、準確性和穩定性。

在早期的渠道歸因實踐中，我們使用 Flink 處理 UBT 日志數據，為每條數據附加用戶從打開 App 到當前頁面的完整跳轉路徑，并直接寫入云存儲。由于小紅書的 Flink 集群部署在公有云，而離線數據和處理引擎位于 A 云，我們通過 Discp 操作將數據從公有云遷移到 A 云。這種架構導致時效性差，因為跨云同步和分區任務在離線側完成，且每天需要占用額外的存儲資源，增加了成本。

為了解決這些問題，我們對渠道歸因數據架構進行了徹底改造。我們移除了原有的離線 Discp 任務和 Spark 分流，轉而采用 Flink 與 Iceberg 的結合，實現了在實時數據寫入過程中的自動分流。這一改造不僅優化了任務處理的負載均衡，還確保了分區數據文件數量的可控性，從而保障了離線數據產出的時效性和查詢效率。通過這些改進，離線數據的產出時效提升了 90%，從而盡早釋放離線集群資源，保障了其他離線作業的穩定性。同時，實時渠道產出的數據現在也能支持交易、直播、廣告等實時業務場景，為企業提供更快速、更靈活的數據分析能力。

Iceberg 的實時讀寫能力使其成為流批一體的理想存儲解決方案。然而，由于實時鏈路和離線鏈路位于不同的云平臺，我們不得不在兩個云上分別備份數據。為了解決這一問題，我們設計了兩條獨立的數據處理鏈路：實時業務消費實時分流任務的數據，而離線側則消費 Iceberg 數據。在新架構中，渠道歸因數據首先寫入 Kafka，然后分為實時分流作業和實時入湖作業。實時入湖作業按業務分區，將數據寫入 Iceberg。Iceberg 收集各分區的最新統計信息，并根據這些信息重新分配業務分區的并發處理，確保整體處理均衡。離線側通過定期輪詢 Iceberg 的元信息，監聽當前處理的數據時間，觸發下游的小時級或天級任務調度。這一改造顯著提升了數據處理的靈活性和效率。

五、漢姆拉比反爬數據鏈路優化

小紅書的反爬蟲日志，由于接入了整個公司的反爬場景（ Scenarioid ），導致整體數據量龐大。它作為反爬蟲日志的核心，其龐大的數據量在生產過程中消耗了大量計算和存儲資源。特別是，不同云之間的跨云文件傳輸過程，每天傳輸數百 TB 數據，占據了 20% 的帶寬資源，尤其是在業務高峰期時，對跨云傳輸服務造成巨大的負載壓力，從而嚴重影響跨云傳輸服務的穩定性。

解決該問題的核心難點在于，在大數據量及有限時間內的條件下，如何有效降低跨云傳輸的文件大小。為了有效降低跨云傳輸的數據量，我們結合數據湖團隊的流批一體工具鏈，對漢姆拉比數據鏈路進行了優化，采取以下策略：

• 數據同步策略調整：不再直接同步公有云上的 Agent-smith 日志，而是通過 Kafka2Iceberg 任務，將漢姆拉比 Kafka 數據同步到公有云上的 Iceberg 表，Iceberg 底層基于 Parquet 文件格式，其列存儲格式和索引排序機制可以提升重復字段的壓縮效率，因此最終跨云同步的對象變成了經過壓縮的 Iceberg 表，從而極大提升了同步效率。
• 數據壓縮與批量處理：在 Kafka 中，我們針對場景（ Scenarioid ）字段進行 shuffle，并通過每 5 分鐘 checkpoint 機制批量導入數據到Iceberg 表，同時在導入過程中對文件進行 Parquet 壓縮。這種 shuffle 和 壓縮的結合顯著提高了數據的壓縮率。

優化后成果顯著，新鏈路的數據到崗時間比老鏈路提前了約 85 分鐘，專線帶寬節省了 83%，存儲空間也減少了 83%。這些改進不僅提高了數據處理效率，還為公司節省了寶貴的資源，確保了數據鏈路的高效運行。

六、直播準實時鏈路改造

為了提升直播業務的數據處理能力，我們基于數據湖技術對直播實時鏈路進行了全面改造，實現了流批一體的數據處理架構。這一架構不僅在交易實時數倉領域得到了成功應用，還顯著提升了直播間入口曝光和點擊行為事實明細表的數據處理效率。

如下圖所示，直播入口曝光點擊流量經分流后進入直播處理鏈路，此時會寫入數據湖，作為歷史數據回溯使用，而 Kafka 鏈路則基于 Flink 任務加工生成實時離線一致的 DWD 層，同步入湖和 Kafka，滿足實時、近實時、離線的直播下游使用需求。

通過采用 Flink 與 AWS Iceberg 的結合，以及多個用戶自定義函數（UDF），我們成功地將原有的 UBT 鏈路切換至新的架構。這一轉變不僅還原了大部分字段，還確保了數據校驗的一致性。目前，新鏈路已穩定運行，顯示出以下顯著優勢：

• 流批一體：實時和離線邏輯的統一，確保了數據的一致性。字段解析和邏輯處理集中在實時處理中，避免一點改動涉及多張表的問題。
• 統一數據源：實時和離線分析使用相同的數據源，進一步保障了實時與離線指標的一致性。
• 維護成本降低：公共層的人力維護成本大幅減少，迭代和開發工作現在只需單一人員完成。

此外，數據湖技術還顯著提升了直播數倉的實時開發效率和數據質量。例如，AWS Iceberg 支持離線任務調度，實現流批一體，而相對便宜的 COS Iceberg 提供了成本效益更高的數據入湖存儲，適用于日常的數據校驗、Kafka 即時查詢和 Case 排查等需求。

COS Iceberg 的引入解決了 Kafka 數據存儲時間短和即時查詢不便的問題，使得實時開發更加便捷。實時寫入任務，如 Starrocks、Redkv、ES 等，都會同時寫入 COS Iceberg，便于問題排查和數據校驗。Iceberg 中存儲的分區、Offset等元信息，對于排查字段狀態、亂序等問題尤為有用。

數據湖技術的 upsert 能力為數倉架構帶來了顯著的升級。對于日志表等 Append 類型表，實現流批一體相對容易，但對于需要更新操作的 Upsert 表，數據湖必須具備相應的能力。為此，數據湖團隊早期開發并上線了 Iceberg v10 表，該表支持 upsert 功能。如下圖所示，在這一架構下，數倉團隊已成功應用于域內和域外訂單表，通過 Package_id 和 Sku_id 的聯合主鍵進行更新，使得表既可以作為增量表，也可以作為全量表使用。此外，基于 As Of Time 的時間切片查詢功能，全量表僅需存儲一份數據，這不僅方便了實時離線數據的對齊和歷史狀態查詢，還彌補了離線鏈路數據歸檔后狀態回溯更新成本高的問題。

展望未來，數據湖團隊將繼續開發和迭代 Apache Paimon，數倉也將采用 Paimon 來構建支持 upsert 場景的流批一體架構，進一步提升數據處理的靈活性和效率。這將為實時分析和歷史數據管理提供更加強大和靈活的工具，確保數據湖技術在數倉架構中的全面應用和持續優化。

七、收益

結合數倉與數據湖技術的相關實踐，從落地效果上看，我們已經在三個關鍵領域實現了顯著的收益

• 產出時效：通過準實時鏈路的改造，我們顯著提升了數據處理的時效性。ODS 和 DWD 層的數據時效提升了 50%。同時 0-2 點為資源空閑時間段，提前產出能夠留給下游任務更多的空間，提升空閑時間段的資源利用率。
• 成本收益：主要分為存儲成本收益、計算資源成本收益和人力成本收益。例如，“漢姆拉比數據鏈路”優化后，新鏈路節省了 83% 的存儲空間。在計算資源方面，" UBT 鏈路優化查詢效率提升"項目每天節省了數十萬 GB/Hour 的計算資源和幾百 TB 的存儲資源。人力成本方面，流批一體架構的實現減少了公共層的維護和開發工作，如"直播準實時鏈路提升"項目，現在僅需一人即可完成迭代和開發。
• 數據質量：通過 "MQ + Flink + Iceberg" 的流批一體架構，我們確保了實時和離線數據的一致性，有效解決了數據不一致的問題，從而提升了數據質量。這在"渠道歸因數據鏈路架構"和"直播準實時鏈路提升項目"中得到了驗證。

八、未來規劃

數據湖技術為數倉提供了一種高效、低成本且響應迅速的解決方案，有效滿足了公司對數據時效性日益增長的需求。

展望未來，我們計劃在數據引擎團隊的支持下，利用數據湖技術大規模構建，低成本的次實時數據解決方案。這些方案將針對那些不需要極快速響應的業務場景，旨在成為實時分析的首選。通過這種方式，實現開發效率和資源成本的雙重優化。

此外，我們還將探索“數據湖 + OLAP 引擎”的組合策略，以構建新的業務交付標準。這種策略將結合數據湖的靈活性和 OLAP 引擎的高性能，為數倉提供更強大的數據處理能力，支持更復雜的分析需求，提高數據迭代的效率，同時保持成本效益。我們致力于通過這些創新推動數倉技術的持續進步，為公司的數據分析和決策提供更堅實的支持。誠摯邀請您的加入，一起探索數倉和數據湖技術的無限可能。

九、作者簡介

• 馬爾科(吳浩亮) 
  小紅書數據解決方案專家，現負責小紅書用戶增長、搜推、基礎流量、電商、直播等多個業務領域數倉建設。
• 孫武(施裕豪)  
  小紅書數據倉庫工程師，畢業于東南大學，現負責用戶行為分析產品和社區&流量數據建設。
• 黃猿(吳筱琦)
  小紅書數據倉庫工程師，畢業于南京大學，現負責渠道歸因和數據任務性能優化。
• 沈默(王有凱)
  小紅書數據倉庫工程師，畢業于北京郵電大學，現負責流量實時&離線數據倉庫基礎層建設。
• 撿子(薛夏磊)
  小紅書數據倉庫工程師，畢業于復旦大學，現負責交易&直播實時數據建設。