一、數據湖在快手的應用歷程

1. 業務面臨的問題與挑戰

（1）數倉規模的持續膨脹

快手業務發展迅速，對數據精細化運營的要求越來越高。隨之而來，數倉的數據模型持續快速增長。這帶來了兩個主要問題：

其一，計算和存儲成本也隨之線性增長。在當前降本增效的大背景下，持續的成本增長與團隊的目標戰略相悖。

其二，龐大的數據模型給治理和運維帶來了挑戰。多套數據模型迭代節奏不一致，容易導致數據一致性的質量問題，運維成本越來越高。

（2）協作效率有待提升

快手是一家多元化的業務公司，不可避免地會涉及到跨部門的數據協作。以計算ROI 為例，就需要匯總收入和支出兩部分數據，而這些數據掌握在不同的業務部門手中。跨部門協作時，主要會遇到兩個問題：

其一，時間的匹配。由于不同部門的業務側重點不一樣，在排期上難免會有差異，影響協作效率。

其二，數據異動追蹤不夠敏捷。當數據發生異動時，由于聯動上下游多方排查時數據連環依賴加工，造成牽連廣泛、排查周期較長。

（3）實時與離線數據差異

對數據時效性要求高的場景，比如活動效果監控、策略快速驗證等，存在實時和離線數據誤差的問題。如，實時數據顯示當天目標達成或未達成，但次日離線數據結果相反，這就會影響到業務決策的及時性和準確性。

對于數倉規模為什么會持續擴漲，接下來基于真實的案例做分析。從需求交付的視角，最細粒度的目標是基于[公共模型 3]同時交付核心日報、增長錢效、增長日報 3 個需求；這樣看起來最合理的數倉模型只需要 1 個模型即可；但，實際為什么不行。我個人認為原因有二，其一：面向數據應用的視角，時效 SLA 是繞不開的話題，因為用到多個數據來源，將結果整合到一起，數據的時效 SLA = 最晚的數據源就緒時間 + 任務執行時間，那么為了滿足數據時效 SLA 的訴求，會建設[公共模型 1&2&3]；其二：如果將大量的業務過程的指標和緯度整合到一個模型，當前的計算引擎(Hive、Spark)的執行時長過長&優化難度較大；從而進一步帶來時效 SLA 的保障壓力。

那么有沒有辦法實現純面向領域模型、業務過程、數據建模理論，滿足計算性能要求，滿足時效 SLA 要求的解決方案。經過思考，我們需要一個引擎，它支持對數倉模型的更新寫。

2. 架構演進：從 Hive 到 Hudi 的技術變革之路

經過調研，數據湖技術支持對數倉模型的更新寫。市面上有多個引擎該如何選擇？主要的評判標準有三：第一，引擎的功能豐富度，功能越豐富，就可以適配更多的業務場景，適用性更強；第二，與快手現有大數據架構和技術棧的契合度，契合度越高，引入新引擎的投入越小、時間越短，解決問題的效率越高；第三，引擎的自動化程度，自動化程度越高帶來的運維成本越低。

綜合對比后，Hudi 憑借其豐富的功能、與現有架構的良好適配性，以及相對較低的運維成本，成為快手大數據團隊的首選。

選定引擎后，對數倉架構的規劃藍圖是：按照業務實體整體設計大寬表，實現跨領域的打通(增長、商業化、電商)，跨業務的并行協作；單領域(增長)的多業務過程的團隊內并行協作；業務間&團隊內實施的同學關注于實體粒度下實現。依據 SLA 的訴求將模型拆成合理的子任務，通過更新的方式補充模型數據內容。

下邊我們基于問題看下如何應用。

3. 快手 Hudi 數據庫應用推廣歷程

我們依賴引擎的更新能力，可以從純數倉架構最理想模型的視角設計數倉模型。比如，我們將[數據統計]的所有指標和緯度 + 實體 ID 整合，建設跨主題的明細表，具體方案：

（1）基于時效SLA 的訴求，將子任務拆成 4、5、6、7 點執行的 4 個任。

（2）不用時間點執行的子任務，更新數據內容到跨主題的明細表。

（3）上層應用基于時效 SLA 抽取部分字段計算滿足業務訴求。

綜上，可以滿足數據架構的合理性、數據時效 SLA 的訴求、不同數據域(團隊)的協作。

對比傳統的一次性更新的模型，子任務邏輯更簡單、數量更小，因此任務的計算&執行效率更高，進一步提升了數據的 SLA 時效。

針對上述的建設過程，經過真實業務驗證取得了一些成效。

4. 快手Hudi 應用實踐初見成效

（1）從數倉模型視角：引擎更新能力的支持，可以將我們過往散落的模型中的業務過程做有效的整合。能更聚焦和詳細的通過數據描述業務；同時在數據的查找、使用、應用(計算)效率上有顯著提升。

（2）從數倉規模視角：去掉了因時效 SLA 帶來的非必要中間模型，因計算能力不足拆分的優化模型；數據規模有顯著下降；規模的下降帶來運維壓力的減輕、存儲、計算成本的下降。

（3）從數倉增量視角：除必要的新實體，絕大部分工作體現在對實體資產的迭代；使得公共數據的完備度持續完善，復用度持續提升；從而間接提升研發效率。

從結果來看，數據湖技術在生產、應用、效率、成本上是有收益的，那實際的推廣策略是什么，如何評估新引擎推廣的 ROI？

推廣策略、生態建設。

在推廣策略上分為幾個階段。

（1）功能&場景的覆蓋驗證

要推廣一款新的基礎組件，要找準切入點。我們重點聚焦在當前 Hive 和 Spark 生態無法有效解決的"老大難"問題：活動的分鐘級時效問題、狀態演變的全量回刷場景、DAU 點擊的時效優化場景。通過解決“老大難"問題，從業務的視角可以驗證引擎可以解決過往的不可能，體現其增量價值。

（2）論證點到面的普適性

在增長業務驗證其 100% 支持業務的可能性，從歷史任務的改造遷移、增量任務的直接應用，結果如上數據。通過整個業務方向的論證，可以認為：引擎在解決業務問題上具有普遍適用性。

（3）工具鏈生態建設、提升研發效率

技術落地的關鍵在于復用。快手內部擁很多業務部門，要做到全面普及，必須標準化使用范式，沉淀出一整套工具鏈。同時，我們在不斷地實踐中探索總結出了一些技術最佳實踐，以 ShowCase 的形式推廣到各個業務部門，實現了經驗的快速復制。

（4）廣泛應用

在引擎技術的可能性基礎上，加上工具生態的效率加持；公司各個團隊根據自己的業務場景和業務痛點進行針對性的應用與優化；目前已經得到廣泛的應用。

二、數據湖在快手的應用案例

1. 業務賦能：Hudi 在快手的典型場景

（1）CDC 數據同步

在數據同步方面，Hudi 展現出了不錯的效果。通過將小時或者天的定時觸發同步，迭代成實時的數據同步；這種數據同步模式，為許多實時性要求高的業務提供了有力保障。業務方不必再受限于夜間批處理的時間窗口，而是可以隨時消費到最新的數據，極大地提升了數據應用的靈活性。在時效上收益明顯，比如，一些核心的場景有60~90 分鐘的提升。

（2）批流結合業務加速

在某些場景下，僅有批處理還不夠，還需要實時的流式計算能力。Hudi 通過無縫集成批處理引擎和流處理引擎，很好地滿足了這一訴求。比如，除夕的紅包雨，需要在兩輪紅包雨之間完成下一輪 Push 推送的計算，使用歷史的小時計算需要 4~5 個小時的時間，但使用 Hudi 可以在上一輪紅包雨期間完成參與用戶的更新標記。Hudi 從技術上滿足了業務的場景訴求。在活動期間高頻應用，拿到了顯著的結果收益。

（3）架構升級數倉優化

基于寬表數據建設，將歷史基于時效&計算優化的 71 個模型，設計整合為基于設備&用戶為實體的 3 個模型，同時基于 SLA 的訴求拆分不同的子任務，最終在模型規模、計算成本、存儲成本都拿到不錯的收益。

基于引擎的更新能力，對數倉模型的設計思路和實現方式也有根本上的改變；比如，在計算 N 留存的設計，從過完多次重復的笛卡爾積計算轉為簡單更新計算，在時效和成本上取得顯著收益。

2. 快手 Hudi 應用實踐的一些思考

（1）需求引領，技術驅動

企業級服務的推廣切忌閉門造車，一定要深入了解一線的業務需求，找準痛點，才能真正發揮技術的驅動作用。快手的例子充分說明，Hudi 之所以能夠在較短時間內取得驕人的成績，正是得益于其直指業務痛點的能力。從這個意義上說，Hudi 在快手的成功首先應歸功于需求的精準引領。

（2）制度先行，奠定規范基礎

Hudi 在快手的推廣之所以能夠做到體系化，與其完善的配套制度是分不開的。通過建立統一的數據分層規范，快手為 Hudi 構建了一個蓬勃發展的良好生態。同時，將 Hudi 的最佳實踐以制度的形式固化下來，又為后續的推廣應用掃清了障礙。這為我們提供了一個很好的借鑒：任何新技術的引入都要考慮與現有的制度規范相配套，二者相輔相成，才能創造奇跡。

（3）打破壁壘，集體智慧方顯威力

Hudi 在快手的成功應用離不開各方的通力協作。從最初由基礎架構團隊主導，到后來獲得越來越多BU 的青睞和使用，我們越來越意識到要打破部門壁壘，讓集體智慧發揮出最大的威力。正如開源界流行的 "Given enough eyeballs，all bugs are shallow" 法則，新技術能否真正落地，關鍵在于能否調動起全員的積極性，在實踐中不斷打磨，集眾人之所長，補己之所短。

總而言之，快手在 Hudi 的引入和推廣過程中積累了豐富的經驗，也收獲了不菲的回報。其成功的要義在于需求引領、制度先行、破除壁壘，我們期待 Hudi 在快手能夠為業務創新和增長提供源源不斷的動力。也希望我們的實踐能給業界帶來一些啟示，為同行提供一些可資借鑒的范式。技術的進步永無止境，讓我們攜手共進，共創美好未來!

三、Q&A

Q：新的 Hudi 架構后，查詢速度優化可以從哪些方面來考慮？

A：對 Hudi 的查詢有兩種模式，第一種是在生產完成數據更新后即可以讀，第二種是數據需要 merge 之后才能使用，這種情況下需要等待 merge 之后再讀取數據。從生產讀的話，可以基于 Hudi 無增量來消費上游的變更數據，通過變更數據加上增量計算減少開銷提高性能。分析查詢的話，可以加上二級索引來快速進行查詢。