字節(jié)跳動基于數(shù)據(jù)湖技術(shù)的近實(shí)時場景實(shí)踐
導(dǎo)讀：本講嘉賓是來自抖音電商實(shí)時數(shù)倉團(tuán)隊的大數(shù)據(jù)工程師馬汶園，分享主題為基于數(shù)據(jù)湖技術(shù)的近實(shí)時場景實(shí)踐。
主要包括以下幾部分內(nèi)容：
數(shù)據(jù)湖技術(shù)的特性
近實(shí)時技術(shù)的架構(gòu)
電商數(shù)倉實(shí)踐
未來的挑戰(zhàn)與規(guī)劃
01
1. 數(shù)據(jù)湖概念
從數(shù)據(jù)研發(fā)與應(yīng)用的角度，數(shù)據(jù)湖技術(shù)具有以下特點(diǎn)：
首先，數(shù)據(jù)湖可存儲海量、低加工的原始數(shù)據(jù)。在數(shù)據(jù)湖中開發(fā)成本較低，可以支持靈活的構(gòu)建，構(gòu)建出來的數(shù)據(jù)的復(fù)用性也比較強(qiáng)。
其次，在存儲方面，成本比較低廉，且容量可擴(kuò)展性強(qiáng)。
與傳統(tǒng)數(shù)倉建模使用的schema on write 模式相比，數(shù)據(jù)湖采用了一種 schema on read 的模式，即不會事先對它的 schema 做過多的定義，而是在使用的時候才去決定 schema，從而支持上游更豐富、更靈活的應(yīng)用。
2. 字節(jié)數(shù)據(jù)湖
Apache Hudi有下面非常重要的特性：
Hudi不僅僅是數(shù)據(jù)湖的一種存儲格式（Table Format），而是提供了Streaming 流式原語的、具備數(shù)據(jù)庫、 數(shù)據(jù)倉庫核心功能（高效upsert/deletes、索引、壓縮優(yōu)化）的數(shù)據(jù)湖平臺。
Hudi 支持各類計算、查詢引擎（Flink、Spark、Presto、Hive），底層存儲兼容各類文件系統(tǒng) （HDFS、Amazon S3、GCS、OSS）
Hudi 使用 Timeline Service機(jī)制對數(shù)據(jù)版本進(jìn)行管理，實(shí)現(xiàn)了數(shù)據(jù)近實(shí)時增量讀、寫。
Hudi 支持 Merge on Read / Copy on Write 兩種表類型，以及Read Optimized / Real Time 兩種Query模式，用戶可以在海量的低加工的數(shù)據(jù)之上，根據(jù)實(shí)際需求，在 “數(shù)據(jù)可見實(shí)時性“和 “數(shù)據(jù)查詢實(shí)時性” 上做出靈活的選擇。（其中，Read Optimized Query 是面向數(shù)據(jù)可見實(shí)時性需求的；Real Time Query 是面向數(shù)據(jù)查詢實(shí)時性 需求的）
業(yè)界目前有多套開源的數(shù)據(jù)湖的實(shí)現(xiàn)方案，字節(jié)數(shù)據(jù)湖是字節(jié)跳動基于 Apache Hudi 深度定制，適用于商用生產(chǎn)的數(shù)據(jù)湖存儲方案，其特性如下：
字節(jié)數(shù)據(jù)湖為打通實(shí)時計算與離線計算，及實(shí)時數(shù)據(jù)、離線數(shù)據(jù)共通復(fù)用提供了橋梁。Hudi的開源實(shí)現(xiàn)支持多種引擎，在字節(jié)跳動的實(shí)現(xiàn)中，集成了Flink、Spark、Presto，同時支持streaming和batch計算。
字節(jié)數(shù)據(jù)湖擁有良好的元數(shù)據(jù)管理能力，并在此之上實(shí)現(xiàn)了索引。使用行、列存儲并用的存儲格式，為高性能讀寫提供堅實(shí)的基礎(chǔ)。
字節(jié)數(shù)據(jù)湖新增了多源拼接功能，對于需要融合多種數(shù)據(jù)源或者構(gòu)建集市型數(shù)據(jù)集的場景，多源拼接功能簡化了數(shù)據(jù)操作，使數(shù)據(jù)集的構(gòu)建更加簡便。
字節(jié)數(shù)據(jù)湖支持 read optimize 和 real time兩種 query 模式。同時提供 upsert（主鍵更新）、append（非主鍵更新）兩種數(shù)據(jù)更新能力，應(yīng)用擴(kuò)展性強(qiáng)，對用戶使用友好。
02
近實(shí)時技術(shù)架構(gòu)
1. 近實(shí)時場景特點(diǎn)
近實(shí)時場景在一般分為兩種類型，第一類是面向分析型的需求，第二類是面向運(yùn)維型的需求。
面向分析型的需求，主要用戶為分析師、運(yùn)營人員或決策層，其特點(diǎn)是需求量大，并且要求數(shù)據(jù)研發(fā)快速響應(yīng)。從數(shù)據(jù)內(nèi)容來講，分析型需求旺，需要從多視角、多維度進(jìn)行分析，實(shí)驗性質(zhì)比較強(qiáng)，需要在底層加工的時候進(jìn)行跨數(shù)據(jù)域的關(guān)聯(lián)。不嵌入到具體的產(chǎn)品功能或者業(yè)務(wù)流程中，所以對延遲和質(zhì)量 SLA 的容忍度較高。
面向運(yùn)維型的需求，主要用戶是數(shù)據(jù)研發(fā)人員和數(shù)據(jù)運(yùn)維人員。這類場景需要成本低廉、操作便捷的存儲來提高研發(fā)和運(yùn)維的效率。
總結(jié)以上兩類場景的共同點(diǎn)為：均需以“較高人效、較低存儲成本“的解決方案進(jìn)行支持。
2. 數(shù)據(jù)湖技術(shù)的適用性
數(shù)據(jù)湖為什么適用于近實(shí)時場景，其原因可以總結(jié)為三點(diǎn)：
（1）復(fù)用流批的結(jié)果
對于流式計算來說，可以利用批式計算的結(jié)果解決歷史累積結(jié)果、數(shù)據(jù)冷啟動、數(shù)據(jù)回溯等問題。
對于批計算來說，通過將次日凌晨大數(shù)據(jù)量的批式計算，轉(zhuǎn)換為復(fù)用用流計算當(dāng)日更新增量的結(jié)果， 從而提高離線數(shù)據(jù)的產(chǎn)出時效性 。降低數(shù)據(jù)基線破線的風(fēng)險。
通過復(fù)用批流計算的結(jié)果，也可以提高開發(fā)的人效。
（2）統(tǒng)一存儲
字節(jié)數(shù)據(jù)湖采用HDFS作為底層存儲層，通過將ods、dwd這類偏上游的數(shù)倉層次的數(shù)據(jù)入湖，并將加工dws、app層的計算放在湖內(nèi)， 從而把實(shí)時計算的“中間數(shù)據(jù)”、“結(jié)果數(shù)據(jù)”都落入數(shù)據(jù)湖中，實(shí)現(xiàn)了與基于hive存儲的離線數(shù)據(jù) 在 存儲上的統(tǒng)一。
（3）簡化計算鏈路
利用了數(shù)據(jù)湖多元拼接的功能，減少join操作，解決多數(shù)據(jù)源的融合問題，簡化數(shù)據(jù)鏈路。也可以通過將離線維表導(dǎo)入到近實(shí)時計算中，復(fù)用離線計算的結(jié)果，從而簡化鏈路。
3. 近實(shí)時架構(gòu)方案
我們探索的近實(shí)時架構(gòu)時，并沒有選擇業(yè)界比較流行的批流一體方案，而是在流式計算和批式計算中間尋求優(yōu)勢互補(bǔ)的中間態(tài)。雖然當(dāng)前業(yè)界在計算引擎層面做到了流批一體，但是，在實(shí)際的數(shù)據(jù)生產(chǎn)加工過程中，在數(shù)據(jù)質(zhì)量、數(shù)據(jù)運(yùn)維、血緣管理、開發(fā)套件等方面，實(shí)時計算、離線計算客觀上存在著較大差異。
因此，我們采取的策略是設(shè)計一種近實(shí)時的計算架構(gòu)，在保留離線計算數(shù)據(jù)的豐富度和復(fù)雜度的同時，又兼顧實(shí)時計算的時效性高的特點(diǎn)，將兩者進(jìn)行優(yōu)勢互補(bǔ)。這種近實(shí)時的方案，能滿足剛才提到的分析型、運(yùn)維型的業(yè)務(wù)需求。
另一方面，針對數(shù)據(jù)產(chǎn)品里要求秒級跳變的數(shù)據(jù)大屏、或者是嵌入到業(yè)務(wù)流程中的，對數(shù)據(jù)精準(zhǔn)性要求高的事務(wù)型處理需求，則不適合近實(shí)時架構(gòu)。
4. 近實(shí)時架構(gòu)方案演進(jìn)
下面這張圖展示的是數(shù)倉研發(fā)人員較為熟悉的離線和實(shí)時數(shù)倉的架構(gòu)：從業(yè)務(wù)系統(tǒng)中抽取數(shù)據(jù)，ODS 層到 App 層逐層加工。離線和實(shí)時數(shù)倉的數(shù)據(jù)交互主要發(fā)生在DIM維表，對于緩慢變化的屬性信息，會加工離線的數(shù)據(jù)，導(dǎo)入到實(shí)時的 Redis 或 HBase 存儲，然后復(fù)用到實(shí)時計算中。
下圖是基于Hudi構(gòu)建的湖倉架構(gòu)，該架構(gòu)強(qiáng)調(diào)實(shí)時、離線數(shù)據(jù)的復(fù)用性（從圖中虛線可以看出）。數(shù)據(jù)湖近實(shí)時同步的數(shù)據(jù)，可以通過增量的方式同步到離線數(shù)倉的 ODS 層，提升同步效率。而數(shù)據(jù)湖中的DWD和DWS層，也可以復(fù)用離線數(shù)倉中建設(shè)的維表，因為本身都是基于HDFS存儲，免去了數(shù)據(jù)同步和加工的成本。此外，對于新型的業(yè)務(wù)或者是數(shù)據(jù)源，也可以將數(shù)據(jù)從業(yè)務(wù)系統(tǒng)導(dǎo)入湖中，再按照ODS到DMS分層開發(fā)。
傳統(tǒng)離線數(shù)倉中的 DWD 層通常不面向應(yīng)用，這點(diǎn)和基于數(shù)據(jù)湖的架構(gòu)是有所區(qū)別的。數(shù)據(jù)湖的思想是 schema-on-read，希望盡量把更多原始的信息開放給用戶，不進(jìn)行過度的加工，從圖中大家也可以看到，數(shù)據(jù)湖中的DWD 層是面向 Presto 查詢，提供給用戶構(gòu)建數(shù)據(jù)看板或分析報表，也可以經(jīng)過更深度的加工后提供給用戶。
03
電商數(shù)倉實(shí)踐
接下來介紹一下抖音電商實(shí)時數(shù)倉團(tuán)隊在各類業(yè)務(wù)具體場景的實(shí)踐案例。
1. 分析型場景實(shí)踐
（1）營銷大促
對于618、雙11等購物節(jié)日，平臺需要提前進(jìn)行大促招商和資源提報，業(yè)務(wù)有當(dāng)日分析和當(dāng)日決策的需求。營銷大促場景的特點(diǎn)是數(shù)據(jù)本身變更頻率不高（小時級），但是需要支持一段周期（5-15天） 至今的累積值統(tǒng)計 。之前的純離線方案，是每小時對 T – 1的數(shù)據(jù)進(jìn)行全量計算，下游使用Presto 分析。這種方案的缺點(diǎn)是數(shù)據(jù)的時效性差，且往往小時級任務(wù)難以保證一小時內(nèi)產(chǎn)出數(shù)據(jù)結(jié)果。
另一種純實(shí)時的方案是將數(shù)據(jù)源導(dǎo)入到 Flink，由 Flink 進(jìn)行長周期大狀態(tài)的計算（15 天的所有信息都維護(hù)在作業(yè)的狀態(tài)內(nèi)）。這種方案的優(yōu)點(diǎn)是實(shí)效性好。但是，任務(wù)穩(wěn)定性難以保障，此外，還需要將數(shù)據(jù)結(jié)導(dǎo)入到實(shí)時OLAP數(shù)據(jù)庫中（如clickhouse），存儲成本較高。
對于這類場景，近實(shí)時架構(gòu)提出的解決方案是：將實(shí)時的數(shù)據(jù)流入湖，利用 Spark 進(jìn)行小時級的調(diào)度，合并離線 T - 1 周期內(nèi)的全量數(shù)據(jù)和T增量數(shù)據(jù)，將結(jié)果存儲到數(shù)據(jù)湖中，通過Presto供實(shí)時分析決策使用。通過在湖內(nèi)合并實(shí)時和離線數(shù)據(jù)，既解決了純實(shí)時方案中大狀態(tài)穩(wěn)定性的問題，又解決了純離線方案時效性低的問題。同時，這種方案充分復(fù)用了已有數(shù)據(jù)，開發(fā)和操作成本相對低廉。
（2）流量診斷
流量診斷這類場景是對推薦系統(tǒng)召回的各階段流量進(jìn)行實(shí)時監(jiān)控分析，從而為推薦系統(tǒng)提供策略優(yōu)化建議。同時，也能夠改善商家的流量獲取、為運(yùn)營同學(xué)排查 case 提效。
流量數(shù)據(jù)和其他業(yè)務(wù)數(shù)據(jù)相比，本身的數(shù)據(jù)量級非常大，且屬于單條事件型數(shù)據(jù)，數(shù)據(jù)沒有業(yè)務(wù)主鍵。需求上，通常需要觀察時間窗口內(nèi)的趨勢性指標(biāo)。
針對這類場景，數(shù)據(jù)湖方案就體現(xiàn)出了其處理海量數(shù)據(jù)的適用性。在解決方案中，是將流量數(shù)據(jù)增量入湖，以append的方式寫入non_index類型的湖表，定時15分鐘調(diào)度進(jìn)行窗口匯總計算，通過 Presto 支持近實(shí)時分析診斷。對于更復(fù)雜的計算或者離線的業(yè)務(wù)需求，也可以定時同步到Hive表，在滿足了近實(shí)時分析的同時，也實(shí)現(xiàn)了離線的復(fù)用。
（3）物流監(jiān)控
物流監(jiān)控的業(yè)務(wù)需求是串聯(lián)物流鏈路中的關(guān)鍵性業(yè)務(wù)節(jié)點(diǎn)，比如包裹的發(fā)貨、攬收、簽收，為運(yùn)營同學(xué)提供物流單的全景圖，幫助商家實(shí)現(xiàn)物流的實(shí)時監(jiān)控。
物流監(jiān)控場景最大的特點(diǎn)是，物流履約的過程中，涉及的業(yè)務(wù)系統(tǒng)多，數(shù)據(jù)源多，且沒有統(tǒng)一的業(yè)務(wù)主鍵。從另一方面來講，由于物流本身的業(yè)務(wù)鏈路比較長，對于數(shù)據(jù)的觀測的時效性不高，可延緩至分鐘級。
對于多業(yè)務(wù)系統(tǒng)多數(shù)據(jù)源關(guān)聯(lián)問題，一種傳統(tǒng)的實(shí)現(xiàn)方式是做多源 join 的操作，但是join 操作需要 Flink 維護(hù)大狀態(tài)，其次是計算復(fù)雜度也比較高。為了解決該問題，我們利用字節(jié)數(shù)據(jù)湖多源拼接功能：在業(yè)務(wù)系統(tǒng)上、下游的兩兩數(shù)據(jù)源共用主鍵情況下，每個數(shù)據(jù)源各自更新其業(yè)務(wù)字段到中間結(jié)果湖表中，再將多個中間結(jié)果表做拼接，從而實(shí)現(xiàn)了多業(yè)務(wù)系統(tǒng)數(shù)據(jù)源的串聯(lián)。由此利用了湖表的特性代替了計算中的join操作，簡化stateful計算。下圖所示的具體例子可供參考。
（4） 風(fēng)險治理
風(fēng)險治理是電商交易業(yè)務(wù)中不可或缺的環(huán)節(jié)。風(fēng)險治理通過會話、舉報、評論、交易等多業(yè)務(wù)視角去近實(shí)時地分析，預(yù)判出商家的欺詐行為，或者識別黑灰產(chǎn)業(yè)、資金資損的風(fēng)險事件。這類需求的特點(diǎn)是：對于實(shí)時性要求不高（業(yè)務(wù)變化15 分鐘可見），但是需要支持靈活的自主查詢，來滿足下游報表、看板，數(shù)據(jù)集等多樣的需求。
其次，風(fēng)險治理需要關(guān)聯(lián)多個數(shù)據(jù)域，進(jìn)行整體的風(fēng)險排查。比如推斷疑似黑灰產(chǎn)商家，需要查驗資質(zhì)信息、舉報信息或者交易的信息。在分析的過程中，需要關(guān)聯(lián)很多離線維表來獲取商家的資質(zhì)、等級、評分等信息，再做最終的預(yù)判。這類需求特點(diǎn)和近實(shí)時分析所支持的場景是相吻合的。因此，可采用基于數(shù)據(jù)湖的解決方案，利用數(shù)據(jù)湖的海量低加工的數(shù)據(jù)處理特性，將多數(shù)據(jù)源實(shí)時增量入庫，避免過多的 join 或者是匯總計算，同時又把離線的表去做復(fù)用。整體直接面向查詢引擎，由用戶去決定在查詢分析時候的 schema ，也就是轉(zhuǎn)化為 schema on read 的模式。
2. 運(yùn)維型場景實(shí)踐
該類場景面向的用戶主要是：數(shù)據(jù)研發(fā)人員、數(shù)據(jù)運(yùn)維人員。
（1）數(shù)據(jù)產(chǎn)品異動監(jiān)控
指標(biāo)異動監(jiān)控是數(shù)據(jù)生產(chǎn)中非常重要的環(huán)節(jié)，通過在數(shù)據(jù)內(nèi)容層面提前感知問題，有助于問題的快速定位和解決，保障數(shù)據(jù)產(chǎn)出的SLA。在實(shí)踐中，如果僅僅監(jiān)控計算組件：比如監(jiān)控 Flink、Spark 等組件metrics 、Kafka 的lag、數(shù)據(jù)庫性能，并不能有效的保障數(shù)據(jù)產(chǎn)品的SLA。對于實(shí)時計算鏈路來說，由于兜底邏輯，或者源數(shù)據(jù)臟數(shù)據(jù)等原因，即使計算鏈路上的組件沒有問題，最后呈現(xiàn)給用戶的指標(biāo)仍有可能不符合預(yù)期。為了更好的查詢和分析中間結(jié)果，需要將消息隊列和存儲組件中的的數(shù)據(jù)落盤，以往的方式是：離線小時表的形式同步到Hive中，又或者是落盤到成本較高的OLAP數(shù)據(jù)庫中。但是當(dāng)前，可以通過將中間結(jié)果近實(shí)時增量同步至數(shù)據(jù)湖，在湖中支持多種類型的分析監(jiān)控，比如說多數(shù)據(jù)源對照，全局異常檢測，大型商家或關(guān)鍵 KOL達(dá)人的實(shí)體抽測等等。從而實(shí)現(xiàn)了操作簡便、成本低廉的對數(shù)據(jù)內(nèi)容的運(yùn)維。
（2）實(shí)時消息落盤檢測
下圖是大家比較熟悉的實(shí)時數(shù)據(jù)鏈路，和離線鏈路最大的不同之處在于中間的計算結(jié)果都是基于消息隊列存儲，不支持?jǐn)?shù)據(jù)的全局觀測和整體數(shù)據(jù)校驗。
通過CDC將消息隊列里的數(shù)據(jù)落盤到數(shù)據(jù)湖中，實(shí)現(xiàn)中間數(shù)據(jù)的全面可見、可測，對于提高數(shù)據(jù)研發(fā)同學(xué)的效率和數(shù)據(jù)質(zhì)量有很大幫助。
04
未來挑戰(zhàn)與規(guī)劃
隨著在抖音電商場景的落地，數(shù)據(jù)湖技術(shù)在近實(shí)時場景支持業(yè)務(wù)的可行性得到了驗證。最后從數(shù)據(jù)研發(fā)的角度，講一下數(shù)據(jù)湖未來的挑戰(zhàn)和規(guī)劃。
為了今后接入更多、更大數(shù)據(jù)量的業(yè)務(wù)，對數(shù)據(jù)湖性能提出了更高的要求。對于實(shí)時數(shù)倉來說，主要是數(shù)據(jù)可見性提升和數(shù)據(jù)查詢RT的提升。
和 Flink、Spark 更深度集成，例如在 failover 階段提供更強(qiáng)的穩(wěn)定性保障。
在良好的讀寫性能、穩(wěn)定性保障的基礎(chǔ)上，由近實(shí)時分析型應(yīng)用轉(zhuǎn)向近實(shí)時產(chǎn)品型應(yīng)用。
今天的分享就到這里，謝謝大家。
