小紅書如何實現數倉效率與成本的雙重最佳化

　　在當今以資料為核心的商業環境中，企業正面臨著海量資料的處理和分析挑戰。為克服傳統資料倉儲在處理速度、靈活性和成本效率方面的侷限，小紅書資料倉儲團隊引入如 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 日誌（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 引擎的高效能，為數倉提供更強大的資料處理能力，支援更復雜的分析需求，提高資料迭代的效率，同時保持成本效益。我們致力於透過這些創新推動數倉技術的持續進步，為公司的資料分析和決策提供更堅實的支援。誠摯邀請您的加入，一起探索數倉和資料湖技術的無限可能。