一、數(shù)據(jù)湖在快手的應用歷程

1. 業(yè)務(wù)面臨的問題與挑戰(zhàn)

（1）數(shù)倉規(guī)模的持續(xù)膨脹

快手業(yè)務(wù)發(fā)展迅速，對數(shù)據(jù)精細化運營的要求越來越高。隨之而來，數(shù)倉的數(shù)據(jù)模型持續(xù)快速增長。這帶來了兩個主要問題：

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

其二，龐大的數(shù)據(jù)模型給治理和運維帶來了挑戰(zhàn)。多套數(shù)據(jù)模型迭代節(jié)奏不一致，容易導致數(shù)據(jù)一致性的質(zhì)量問題，運維成本越來越高。

（2）協(xié)作效率有待提升

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

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

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

（3）實時與離線數(shù)據(jù)差異

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

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

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

2. 架構(gòu)演進：從 Hive 到 Hudi 的技術(shù)變革之路

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

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

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

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

3. 快手 Hudi 數(shù)據(jù)庫應用推廣歷程

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

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

（2）不用時間點執(zhí)行的子任務(wù)，更新數(shù)據(jù)內(nèi)容到跨主題的明細表。

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

綜上，可以滿足數(shù)據(jù)架構(gòu)的合理性、數(shù)據(jù)時效 SLA 的訴求、不同數(shù)據(jù)域(團隊)的協(xié)作。

對比傳統(tǒng)的一次性更新的模型，子任務(wù)邏輯更簡單、數(shù)量更小，因此任務(wù)的計算&執(zhí)行效率更高，進一步提升了數(shù)據(jù)的 SLA 時效。

針對上述的建設(shè)過程，經(jīng)過真實業(yè)務(wù)驗證取得了一些成效。

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

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

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

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

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

推廣策略、生態(tài)建設(shè)。

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

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

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

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

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

（3）工具鏈生態(tài)建設(shè)、提升研發(fā)效率

技術(shù)落地的關(guān)鍵在于復用?？焓謨?nèi)部擁很多業(yè)務(wù)部門，要做到全面普及，必須標準化使用范式，沉淀出一整套工具鏈。同時，我們在不斷地實踐中探索總結(jié)出了一些技術(shù)最佳實踐，以 ShowCase 的形式推廣到各個業(yè)務(wù)部門，實現(xiàn)了經(jīng)驗的快速復制。

（4）廣泛應用

在引擎技術(shù)的可能性基礎(chǔ)上，加上工具生態(tài)的效率加持；公司各個團隊根據(jù)自己的業(yè)務(wù)場景和業(yè)務(wù)痛點進行針對性的應用與優(yōu)化；目前已經(jīng)得到廣泛的應用。

二、數(shù)據(jù)湖在快手的應用案例

1. 業(yè)務(wù)賦能：Hudi 在快手的典型場景

（1）CDC 數(shù)據(jù)同步

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

（2）批流結(jié)合業(yè)務(wù)加速

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

（3）架構(gòu)升級數(shù)倉優(yōu)化

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

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

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

（1）需求引領(lǐng)，技術(shù)驅(qū)動

企業(yè)級服務(wù)的推廣切忌閉門造車，一定要深入了解一線的業(yè)務(wù)需求，找準痛點，才能真正發(fā)揮技術(shù)的驅(qū)動作用?？焓值睦映浞终f明，Hudi 之所以能夠在較短時間內(nèi)取得驕人的成績，正是得益于其直指業(yè)務(wù)痛點的能力。從這個意義上說，Hudi 在快手的成功首先應歸功于需求的精準引領(lǐng)。

（2）制度先行，奠定規(guī)范基礎(chǔ)

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

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

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

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

三、Q&A

Q：新的 Hudi 架構(gòu)后，查詢速度優(yōu)化可以從哪些方面來考慮？

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