在當(dāng)今以數(shù)據(jù)為核心的商業(yè)環(huán)境中，企業(yè)正面臨著海量數(shù)據(jù)的處理和分析挑戰(zhàn)。為克服傳統(tǒng)數(shù)據(jù)倉庫在處理速度、靈活性和成本效率方面的局限，小紅書數(shù)據(jù)倉庫團(tuán)隊(duì)引入如 Apache Iceberg 等數(shù)據(jù)湖技術(shù)，將其與數(shù)倉架構(gòu)相結(jié)合，以釋放數(shù)據(jù)湖在查詢性能、實(shí)時(shí)數(shù)據(jù)處理和成本效益方面的潛力。

小紅書數(shù)據(jù)倉庫團(tuán)隊(duì)通過一系列創(chuàng)新實(shí)踐，如 UBT 鏈路優(yōu)化查詢效率、渠道歸因數(shù)據(jù)架構(gòu)改造、漢姆拉比數(shù)據(jù)鏈路優(yōu)化以及直播準(zhǔn)實(shí)時(shí)鏈路提升等，證明了數(shù)倉與數(shù)據(jù)湖技術(shù)的結(jié)合能帶來顯著的業(yè)務(wù)價(jià)值：不僅提升用戶體驗(yàn)，還實(shí)現(xiàn)了計(jì)算和存儲(chǔ)資源的大幅度節(jié)約，同時(shí)確保了數(shù)據(jù)的高質(zhì)量和一致性。

未來，團(tuán)隊(duì)計(jì)劃繼續(xù)利用數(shù)據(jù)湖技術(shù)構(gòu)建準(zhǔn)實(shí)時(shí)的數(shù)據(jù)新架構(gòu)，以滿足企業(yè)對(duì)數(shù)據(jù)時(shí)效性的多樣化需求。

一、背景

過去十多年，Hive/Spark on HDFS 作為離線數(shù)據(jù)倉庫的事實(shí)標(biāo)準(zhǔn)，在實(shí)踐中得到了廣泛應(yīng)用。然而，隨著業(yè)務(wù)對(duì)數(shù)據(jù)時(shí)效性和查詢性能要求的提升，Hive 的傳統(tǒng)架構(gòu)開始顯現(xiàn)出其局限性。具體表現(xiàn)在：

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

這些性能問題嚴(yán)重制約了數(shù)據(jù)倉庫在支持業(yè)務(wù)決策中的作用。為了應(yīng)對(duì)這些挑戰(zhàn)，我們積極探索新方向，力求在滿足業(yè)務(wù)日益多樣化的需求下，總結(jié)出一些通用化、低成本的數(shù)倉架構(gòu)新方案以解決上述問題。本文詳細(xì)記錄了我們?cè)跀?shù)倉架構(gòu)和數(shù)據(jù)湖技術(shù)結(jié)合方面的深入探索和實(shí)踐，期待對(duì)您有幫助，歡迎結(jié)合自己興趣和相關(guān)業(yè)務(wù)自主選擇閱讀。

二、數(shù)據(jù)湖技術(shù)優(yōu)勢(shì)

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

不同于原有的 Hive 數(shù)倉架構(gòu)，Iceberg 依托于其文件級(jí)數(shù)據(jù)追蹤的技術(shù)架構(gòu)，展現(xiàn)出以下顯著優(yōu)勢(shì)：

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

三、UBT鏈路優(yōu)化查詢效率

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

3.1 歷史方案回顧

在處理 UBT 日志數(shù)據(jù)時(shí)，我們?cè)捎靡环N樸素的方法：將數(shù)據(jù)從主表抽取到多個(gè)分流表中，以便下游業(yè)務(wù)方能夠針對(duì)特定需求進(jìn)行查詢。這種方法在業(yè)務(wù)邏輯相對(duì)簡單時(shí)，能夠有效減少查詢的數(shù)據(jù)量，提高查詢效率。

然而，隨著業(yè)務(wù)復(fù)雜度的增加，這種方法暴露出一系列問題：

• 成本與復(fù)雜性增加：隨著業(yè)務(wù)規(guī)則的多樣化，分流表的數(shù)量迅速增長，導(dǎo)致計(jì)算和存儲(chǔ)成本不斷攀升，且難以管理。
• 數(shù)據(jù)一致性挑戰(zhàn)：對(duì)分流規(guī)則的任何變更都需回刷大量歷史數(shù)據(jù)，這不僅耗時(shí)耗力，還可能引入數(shù)據(jù)不一致的風(fēng)險(xiǎn)。
• 數(shù)據(jù)冗余與維護(hù)困難：個(gè)性化的分流規(guī)則缺乏通用性和排他性，數(shù)據(jù)在不同規(guī)則間重復(fù)存儲(chǔ)，增加了維護(hù)的難度。

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

3.2 查詢性能優(yōu)化

在流量數(shù)據(jù)分析中，點(diǎn)位(埋點(diǎn))作為描述用戶特定行為的關(guān)鍵標(biāo)識(shí)，也是業(yè)務(wù)數(shù)倉數(shù)據(jù)加工的基礎(chǔ)粒度。面對(duì)小紅書線上近萬個(gè)點(diǎn)位的龐大數(shù)據(jù)量，我們實(shí)施了一系列查詢性能優(yōu)化策略，以提升數(shù)據(jù)處理效率。

我們認(rèn)識(shí)到，通過點(diǎn)位限制幫助用戶縮小數(shù)據(jù)范圍，加速后續(xù)的業(yè)務(wù)邏輯處理，可有效提升查詢性能。然而，傳統(tǒng)的分區(qū)策略在面對(duì)龐大的點(diǎn)位數(shù)量時(shí)顯得力不從心，Hive Metastore 難以承受巨大的分區(qū)規(guī)模。因此，我們的目標(biāo)轉(zhuǎn)變?yōu)?strong>如何能購針對(duì)特定點(diǎn)位的數(shù)據(jù)進(jìn)行快速定位并篩選，實(shí)現(xiàn)數(shù)據(jù)范圍的精確縮小。

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

性能優(yōu)化方案如下：

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

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

3.3 新分流方案

上述性能優(yōu)化提升了用戶對(duì)點(diǎn)位的查詢效率。點(diǎn)位是用戶使用日志的基礎(chǔ)粒度，我們開始進(jìn)一步考慮以點(diǎn)位為基礎(chǔ)，構(gòu)建一套新的分流體系，旨在替代原有的分流表體系。新體系的設(shè)計(jì)遵循了三個(gè)核心原則：確保分流查詢性能滿足用戶需求、最小化存儲(chǔ)和計(jì)算開銷、以及限制分流表的數(shù)量以避免無序增長?；谶@些原則，我們?cè)O(shè)計(jì)了以下新分流方案：

• 分流轉(zhuǎn)換功能：新方案實(shí)現(xiàn)了在 Spark 執(zhí)行計(jì)劃層，自動(dòng)將對(duì)分流表的查詢轉(zhuǎn)換為對(duì) Iceberg 表中特定點(diǎn)位集合的查詢，從而提高了查詢效率。
• 業(yè)務(wù)場景導(dǎo)向：新分流體系以通過構(gòu)建實(shí)際業(yè)務(wù)場景作為準(zhǔn)入標(biāo)準(zhǔn)，每個(gè)業(yè)務(wù)場景對(duì)應(yīng)一個(gè)分流表，同時(shí)通過上線流量產(chǎn)品注冊(cè)收攏分流表的創(chuàng)建，這樣既明確了分流的業(yè)務(wù)含義，也杜絕了分流數(shù)量的無限制上漲。
• 視圖封裝：在分流轉(zhuǎn)化函數(shù)外層，我們封裝了分流表視圖，這使得下游業(yè)務(wù)方無需感知內(nèi)部優(yōu)化，簡化了數(shù)據(jù)訪問流程。

新分流表不再直接存儲(chǔ)數(shù)據(jù)，也無需任務(wù)調(diào)度，從而避免了計(jì)算和存儲(chǔ)資源的消耗。更新分流表時(shí)，只需調(diào)整點(diǎn)位集合，無需回刷歷史數(shù)據(jù)。得益于之前的查詢性能優(yōu)化，新分流方案在滿足業(yè)務(wù)需求的同時(shí)，也保持了高效的查詢性能。

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

四、渠道歸因數(shù)據(jù)架構(gòu)改造

渠道歸因作為分析用戶行為路徑、埋點(diǎn)歸因的關(guān)鍵工具，對(duì)于社區(qū)、電商和直播等業(yè)務(wù)的流量分析至關(guān)重要。它不僅支持流量來源和轉(zhuǎn)化分析，還有助于深入理解用戶路徑。作為數(shù)據(jù)倉庫的基礎(chǔ)服務(wù)，渠道歸因要求具備高實(shí)效性、準(zhǔn)確性和穩(wěn)定性。

在早期的渠道歸因?qū)嵺`中，我們使用 Flink 處理 UBT 日志數(shù)據(jù)，為每條數(shù)據(jù)附加用戶從打開 App 到當(dāng)前頁面的完整跳轉(zhuǎn)路徑，并直接寫入云存儲(chǔ)。由于小紅書的 Flink 集群部署在公有云，而離線數(shù)據(jù)和處理引擎位于 A 云，我們通過 Discp 操作將數(shù)據(jù)從公有云遷移到 A 云。這種架構(gòu)導(dǎo)致時(shí)效性差，因?yàn)榭缭仆胶头謪^(qū)任務(wù)在離線側(cè)完成，且每天需要占用額外的存儲(chǔ)資源，增加了成本。

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

Iceberg 的實(shí)時(shí)讀寫能力使其成為流批一體的理想存儲(chǔ)解決方案。然而，由于實(shí)時(shí)鏈路和離線鏈路位于不同的云平臺(tái)，我們不得不在兩個(gè)云上分別備份數(shù)據(jù)。為了解決這一問題，我們?cè)O(shè)計(jì)了兩條獨(dú)立的數(shù)據(jù)處理鏈路：實(shí)時(shí)業(yè)務(wù)消費(fèi)實(shí)時(shí)分流任務(wù)的數(shù)據(jù)，而離線側(cè)則消費(fèi) Iceberg 數(shù)據(jù)。在新架構(gòu)中，渠道歸因數(shù)據(jù)首先寫入 Kafka，然后分為實(shí)時(shí)分流作業(yè)和實(shí)時(shí)入湖作業(yè)。實(shí)時(shí)入湖作業(yè)按業(yè)務(wù)分區(qū)，將數(shù)據(jù)寫入 Iceberg。Iceberg 收集各分區(qū)的最新統(tǒng)計(jì)信息，并根據(jù)這些信息重新分配業(yè)務(wù)分區(qū)的并發(fā)處理，確保整體處理均衡。離線側(cè)通過定期輪詢 Iceberg 的元信息，監(jiān)聽當(dāng)前處理的數(shù)據(jù)時(shí)間，觸發(fā)下游的小時(shí)級(jí)或天級(jí)任務(wù)調(diào)度。這一改造顯著提升了數(shù)據(jù)處理的靈活性和效率。

五、漢姆拉比反爬數(shù)據(jù)鏈路優(yōu)化

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

解決該問題的核心難點(diǎn)在于，在大數(shù)據(jù)量及有限時(shí)間內(nèi)的條件下，如何有效降低跨云傳輸?shù)奈募笮?。為了有效降低跨云傳輸?shù)臄?shù)據(jù)量，我們結(jié)合數(shù)據(jù)湖團(tuán)隊(duì)的流批一體工具鏈，對(duì)漢姆拉比數(shù)據(jù)鏈路進(jìn)行了優(yōu)化，采取以下策略：

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

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

六、直播準(zhǔn)實(shí)時(shí)鏈路改造

為了提升直播業(yè)務(wù)的數(shù)據(jù)處理能力，我們基于數(shù)據(jù)湖技術(shù)對(duì)直播實(shí)時(shí)鏈路進(jìn)行了全面改造，實(shí)現(xiàn)了流批一體的數(shù)據(jù)處理架構(gòu)。這一架構(gòu)不僅在交易實(shí)時(shí)數(shù)倉領(lǐng)域得到了成功應(yīng)用，還顯著提升了直播間入口曝光和點(diǎn)擊行為事實(shí)明細(xì)表的數(shù)據(jù)處理效率。

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

通過采用 Flink 與 AWS Iceberg 的結(jié)合，以及多個(gè)用戶自定義函數(shù)（UDF），我們成功地將原有的 UBT 鏈路切換至新的架構(gòu)。這一轉(zhuǎn)變不僅還原了大部分字段，還確保了數(shù)據(jù)校驗(yàn)的一致性。目前，新鏈路已穩(wěn)定運(yùn)行，顯示出以下顯著優(yōu)勢(shì)：

• 流批一體：實(shí)時(shí)和離線邏輯的統(tǒng)一，確保了數(shù)據(jù)的一致性。字段解析和邏輯處理集中在實(shí)時(shí)處理中，避免一點(diǎn)改動(dòng)涉及多張表的問題。
• 統(tǒng)一數(shù)據(jù)源：實(shí)時(shí)和離線分析使用相同的數(shù)據(jù)源，進(jìn)一步保障了實(shí)時(shí)與離線指標(biāo)的一致性。
• 維護(hù)成本降低：公共層的人力維護(hù)成本大幅減少，迭代和開發(fā)工作現(xiàn)在只需單一人員完成。

此外，數(shù)據(jù)湖技術(shù)還顯著提升了直播數(shù)倉的實(shí)時(shí)開發(fā)效率和數(shù)據(jù)質(zhì)量。例如，AWS Iceberg 支持離線任務(wù)調(diào)度，實(shí)現(xiàn)流批一體，而相對(duì)便宜的 COS Iceberg 提供了成本效益更高的數(shù)據(jù)入湖存儲(chǔ)，適用于日常的數(shù)據(jù)校驗(yàn)、Kafka 即時(shí)查詢和 Case 排查等需求。

COS Iceberg 的引入解決了 Kafka 數(shù)據(jù)存儲(chǔ)時(shí)間短和即時(shí)查詢不便的問題，使得實(shí)時(shí)開發(fā)更加便捷。實(shí)時(shí)寫入任務(wù)，如 Starrocks、Redkv、ES 等，都會(huì)同時(shí)寫入 COS Iceberg，便于問題排查和數(shù)據(jù)校驗(yàn)。Iceberg 中存儲(chǔ)的分區(qū)、Offset等元信息，對(duì)于排查字段狀態(tài)、亂序等問題尤為有用。

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

展望未來，數(shù)據(jù)湖團(tuán)隊(duì)將繼續(xù)開發(fā)和迭代 Apache Paimon，數(shù)倉也將采用 Paimon 來構(gòu)建支持 upsert 場景的流批一體架構(gòu)，進(jìn)一步提升數(shù)據(jù)處理的靈活性和效率。這將為實(shí)時(shí)分析和歷史數(shù)據(jù)管理提供更加強(qiáng)大和靈活的工具，確保數(shù)據(jù)湖技術(shù)在數(shù)倉架構(gòu)中的全面應(yīng)用和持續(xù)優(yōu)化。

七、收益

結(jié)合數(shù)倉與數(shù)據(jù)湖技術(shù)的相關(guān)實(shí)踐，從落地效果上看，我們已經(jīng)在三個(gè)關(guān)鍵領(lǐng)域?qū)崿F(xiàn)了顯著的收益

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

八、未來規(guī)劃

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

展望未來，我們計(jì)劃在數(shù)據(jù)引擎團(tuán)隊(duì)的支持下，利用數(shù)據(jù)湖技術(shù)大規(guī)模構(gòu)建，低成本的次實(shí)時(shí)數(shù)據(jù)解決方案。這些方案將針對(duì)那些不需要極快速響應(yīng)的業(yè)務(wù)場景，旨在成為實(shí)時(shí)分析的首選。通過這種方式，實(shí)現(xiàn)開發(fā)效率和資源成本的雙重優(yōu)化。

此外，我們還將探索“數(shù)據(jù)湖 + OLAP 引擎”的組合策略，以構(gòu)建新的業(yè)務(wù)交付標(biāo)準(zhǔn)。這種策略將結(jié)合數(shù)據(jù)湖的靈活性和 OLAP 引擎的高性能，為數(shù)倉提供更強(qiáng)大的數(shù)據(jù)處理能力，支持更復(fù)雜的分析需求，提高數(shù)據(jù)迭代的效率，同時(shí)保持成本效益。我們致力于通過這些創(chuàng)新推動(dòng)數(shù)倉技術(shù)的持續(xù)進(jìn)步，為公司的數(shù)據(jù)分析和決策提供更堅(jiān)實(shí)的支持。誠摯邀請(qǐng)您的加入，一起探索數(shù)倉和數(shù)據(jù)湖技術(shù)的無限可能。

九、作者簡介

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