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

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

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

一、背景

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

數(shù)據(jù)變更成本高昂：即使僅變更一條記錄，也需要重新刷新整個分區(qū)的數(shù)據(jù)；

數(shù)據(jù)產(chǎn)出時效性差：分區(qū)數(shù)據(jù)通常需要 T+1 日期才能完成；

數(shù)據(jù)查詢性能緩慢：查詢相關(guān)數(shù)據(jù)通常需要掃描目錄中的所有文件，大表查詢耗時且效率低下；

資源利用率不足：所有天級調(diào)度任務(wù)的資源消耗全部集中在調(diào)度期間，容易導(dǎo)致多任務(wù)搶占資源，影響資源使用效率。

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

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

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

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

查詢性能提升：Iceberg 支持異步數(shù)據(jù)重組(如 Zorder)，結(jié)合動態(tài)列全局排序和索引機(jī)制，大幅減少查詢時的文件讀取量，顯著提升查詢效率和 shuffle 性能。

增量讀寫能力：小紅書自研的 Iceberg 適配了 Spark 引擎，支持 update、merge into、delete 等語義，能夠?qū)χ付ㄎ募M(jìn)行刪除和更新操作。相較于 Hive 的分區(qū)目錄完全重刷，可將更新成本降低至文件粒度。

流批一體架構(gòu)：Iceberg 基于增量讀寫機(jī)制，通過適配 Flink 等實時引擎的讀寫，形成了“MQ + Flink + Iceberg”的流批一體架構(gòu)。對于近實時的需求，這種架構(gòu)既可以提升數(shù)據(jù)產(chǎn)出的時效性，也可以省去維護(hù) Lambda 架構(gòu)所需的人力和資源成本。

成本效應(yīng)顯著：Iceberg 底層采用 Parquet 文件格式，其列存儲格式和索引排序機(jī)制通過提升重復(fù)字段的壓縮效率，進(jìn)而節(jié)約了存儲成本。

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

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

3.1 歷史方案回顧

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

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

成本與復(fù)雜性增加：隨著業(yè)務(wù)規(guī)則的多樣化，分流表的數(shù)量迅速增長，導(dǎo)致計算和存儲成本不斷攀升，且難以管理。

數(shù)據(jù)一致性挑戰(zhàn)：對分流規(guī)則的任何變更都需回刷大量歷史數(shù)據(jù)，這不僅耗時耗力，還可能引入數(shù)據(jù)不一致的風(fēng)險。

數(shù)據(jù)冗余與維護(hù)困難：個性化的分流規(guī)則缺乏通用性和排他性，數(shù)據(jù)在不同規(guī)則間重復(fù)存儲，增加了維護(hù)的難度。

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

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

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

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

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

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

全局排序：按照點位 ID 進(jìn)行全局排序，實現(xiàn)了自定義的數(shù)據(jù)抽樣和分區(qū)劃分的邏輯，并且為大點位劃分更多分區(qū)，解決了大小點位數(shù)據(jù)傾斜問題，從而提高單個點位的計算效率。另外，為解決隨機(jī)采樣可能存在誤差的問題，我們借助 Spark Sql 的自動查詢優(yōu)化（AQE）功能作為兜底，并開發(fā)了 bypass hash 函數(shù)，以便在 Spark 中實現(xiàn)自定義分區(qū)，根據(jù)數(shù)據(jù)生成的 partition_id 來劃分分區(qū)。

分區(qū)排序與去重：若日志數(shù)據(jù)存在重復(fù)的情況，按照傳統(tǒng)思路，需要先去重然后再排序來優(yōu)化查詢，這會帶來兩次 shuffle，顯著增加計算成本。為了解決這一問題，我們基于全局排序采取了一種創(chuàng)新的方法：在數(shù)據(jù)按點位 ID 排序的同時，直接在排序過程中識別并過濾掉重復(fù)的數(shù)據(jù)。

Iceberg 視圖生成：為了確保與現(xiàn)有 Hive 生態(tài)系統(tǒng)的兼容性，我們在 Hive 表上建立了外部 Iceberg 表級視圖。這一視圖通過掃描數(shù)據(jù)文件并提交文件 metric 信息，使得下游系統(tǒng)能夠基于 Iceberg 的 MinMax 提升查詢性能，并且能直接讀取視圖進(jìn)行數(shù)據(jù)消費，簡化了數(shù)據(jù)訪問流程。

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

3.3 新分流方案

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

分流轉(zhuǎn)換功能：新方案實現(xiàn)了在 Spark 執(zhí)行計劃層，自動將對分流表的查詢轉(zhuǎn)換為對 Iceberg 表中特定點位集合的查詢，從而提高了查詢效率。

業(yè)務(wù)場景導(dǎo)向：新分流體系以通過構(gòu)建實際業(yè)務(wù)場景作為準(zhǔn)入標(biāo)準(zhǔn)，每個業(yè)務(wù)場景對應(yīng)一個分流表，同時通過上線流量產(chǎn)品注冊收攏分流表的創(chuàng)建，這樣既明確了分流的業(yè)務(wù)含義，也杜絕了分流數(shù)量的無限制上漲。

視圖封裝：在分流轉(zhuǎn)化函數(shù)外層，我們封裝了分流表視圖，這使得下游業(yè)務(wù)方無需感知內(nèi)部優(yōu)化，簡化了數(shù)據(jù)訪問流程。

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

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

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

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

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

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

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

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

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

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

數(shù)據(jù)同步策略調(diào)整：不再直接同步公有云上的 Agent-smith 日志，而是通過 Kafka2Iceberg 任務(wù)，將漢姆拉比 Kafka 數(shù)據(jù)同步到公有云上的 Iceberg 表，Iceberg 底層基于 Parquet 文件格式，其列存儲格式和索引排序機(jī)制可以提升重復(fù)字段的壓縮效率，因此最終跨云同步的對象變成了經(jīng)過壓縮的 Iceberg 表，從而極大提升了同步效率。

數(shù)據(jù)壓縮與批量處理：在 Kafka 中，我們針對場景（ Scenarioid ）字段進(jìn)行 shuffle，并通過每 5 分鐘 checkpoint 機(jī)制批量導(dǎo)入數(shù)據(jù)到Iceberg 表，同時在導(dǎo)入過程中對文件進(jìn)行 Parquet 壓縮。這種 shuffle 和 壓縮的結(jié)合顯著提高了數(shù)據(jù)的壓縮率。

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

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

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

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

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

流批一體：實時和離線邏輯的統(tǒng)一，確保了數(shù)據(jù)的一致性。字段解析和邏輯處理集中在實時處理中，避免一點改動涉及多張表的問題。

統(tǒng)一數(shù)據(jù)源：實時和離線分析使用相同的數(shù)據(jù)源，進(jìn)一步保障了實時與離線指標(biāo)的一致性。

維護(hù)成本降低：公共層的人力維護(hù)成本大幅減少，迭代和開發(fā)工作現(xiàn)在只需單一人員完成。

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

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

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

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

七、收益

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

產(chǎn)出時效：通過準(zhǔn)實時鏈路的改造，我們顯著提升了數(shù)據(jù)處理的時效性。ODS 和 DWD 層的數(shù)據(jù)時效提升了 50%。同時 0-2 點為資源空閑時間段，提前產(chǎn)出能夠留給下游任務(wù)更多的空間，提升空閑時間段的資源利用率。

成本收益：主要分為存儲成本收益、計算資源成本收益和人力成本收益。例如，“漢姆拉比數(shù)據(jù)鏈路”優(yōu)化后，新鏈路節(jié)省了 83% 的存儲空間。在計算資源方面，" UBT 鏈路優(yōu)化查詢效率提升"項目每天節(jié)省了數(shù)十萬 GB/Hour 的計算資源和幾百 TB 的存儲資源。人力成本方面，流批一體架構(gòu)的實現(xiàn)減少了公共層的維護(hù)和開發(fā)工作，如"直播準(zhǔn)實時鏈路提升"項目，現(xiàn)在僅需一人即可完成迭代和開發(fā)。

數(shù)據(jù)質(zhì)量：通過 "MQ + Flink + Iceberg" 的流批一體架構(gòu)，我們確保了實時和離線數(shù)據(jù)的一致性，有效解決了數(shù)據(jù)不一致的問題，從而提升了數(shù)據(jù)質(zhì)量。這在"渠道歸因數(shù)據(jù)鏈路架構(gòu)"和"直播準(zhǔn)實時鏈路提升項目"中得到了驗證。

八、未來規(guī)劃

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

展望未來，我們計劃在數(shù)據(jù)引擎團(tuán)隊的支持下，利用數(shù)據(jù)湖技術(shù)大規(guī)模構(gòu)建，低成本的次實時數(shù)據(jù)解決方案。這些方案將針對那些不需要極快速響應(yīng)的業(yè)務(wù)場景，旨在成為實時分析的首選。通過這種方式，實現(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ù)迭代的效率，同時保持成本效益。我們致力于通過這些創(chuàng)新推動數(shù)倉技術(shù)的持續(xù)進(jìn)步，為公司的數(shù)據(jù)分析和決策提供更堅實的支持。誠摯邀請您的加入，一起探索數(shù)倉和數(shù)據(jù)湖技術(shù)的無限可能。