[[435826]]

1.前言

本文主要是分享目前博主理解的流批一體產(chǎn)生的背景，想解決的問題，以及后續(xù)可能實現(xiàn)的思路，并以幾個案例進行介紹。拋磚引玉，讓大家不止停留在做流批一體這件事，而是能更深入思考背后的原因。

2.背景

在介紹流批一體之前，首先看看目前流和批領(lǐng)域常用的引擎：

批任務(wù)：常用 Hive、Spark。

流任務(wù)：常用 Flink。Spark Streaming 與 Storm 使用率目前在流式場景會小于 Flink。

3.什么問題導(dǎo)致產(chǎn)生了流批一體的概念呢?

一個前提：在生產(chǎn)場景中，當(dāng)同一個口徑的指標(biāo)分別用流任務(wù)產(chǎn)出了實時數(shù)據(jù)，用批任務(wù)產(chǎn)出了離線數(shù)據(jù)，才會去考慮是否需要做流批一體。如果一個指標(biāo)只需要產(chǎn)出離線，何談流批一體呢?

一個角度：博主認(rèn)為，流批一體更應(yīng)該站在流的角度思考，去將流任務(wù)產(chǎn)出的結(jié)果在批領(lǐng)域(或者以批數(shù)據(jù)的形式)進行復(fù)用，而不僅僅是在引擎?zhèn)让妫珹PI 接口層面的統(tǒng)一。這點思考與下圖阿里(From FFA 2020)所說的問題的觀點類似，博主理解實時復(fù)用在離線領(lǐng)域 可能

是對于阿里列舉的問題的一個抽象。因為如果能夠復(fù)用的話，下圖中的三個問題也就不存在了!

解決的問題：在上述前提和思考角度的基礎(chǔ)上，博主認(rèn)為，流批一體目前需要解決的最重要的就是解決流任務(wù)產(chǎn)出數(shù)據(jù)的質(zhì)量問題，這也是流數(shù)據(jù)能在批場景復(fù)用的前提。用過 Flink 做實時數(shù)據(jù)開發(fā)的同學(xué)應(yīng)該都碰到過 Flink 產(chǎn)出數(shù)據(jù)的時候，總會由于一些異常(比如使用了窗口可能會導(dǎo)致丟數(shù))導(dǎo)致和離線 Hive、Spark 產(chǎn)出的數(shù)據(jù)有一些微小的差別，這樣就沒法做到實時數(shù)據(jù)在離線領(lǐng)域的復(fù)用。博主理解，流批一體的重點就是要解決這個問題，其他的在資源節(jié)約、人效提高方面的優(yōu)勢都是基于此的附加價值。

4.那么導(dǎo)致流任務(wù)產(chǎn)生數(shù)據(jù)質(zhì)量問題的原因是什么，有哪些常見場景?

博主認(rèn)為，目前最重要的一個原因就是數(shù)據(jù)亂序?qū)е碌臄?shù)據(jù)質(zhì)量問題。

在實時領(lǐng)域最常用和常見的場景有以下兩種：

第一種是 Flink 任務(wù)開窗口的場景。舉例，一個開了 TUMBLE WINDOW 的 Flink 任務(wù)，遇到嚴(yán)重的數(shù)據(jù)亂序的情況(用戶配置的最大亂序、允許延遲等參數(shù)都解決不了)，那么任務(wù)就會把數(shù)據(jù)給丟掉，這種場景下就會導(dǎo)致實時數(shù)據(jù)與離線數(shù)據(jù)產(chǎn)生差異。

第二種是實時維表關(guān)聯(lián)的場景。如果事實表的數(shù)據(jù)先到，就有關(guān)聯(lián)不到維表中的數(shù)據(jù)。從而產(chǎn)生與離線的差異。

當(dāng)然還有其他場景，這里就不一一列舉了。

5.想要解決上述數(shù)據(jù)質(zhì)量問題，可行的思路有哪些?

理想化的思路：以 TUMBLE WINDOW 為例， TUMBLE WINDOW 的初衷就是為了產(chǎn)出不變的結(jié)果(即 append 流)，因此遇到延遲很大的數(shù)據(jù)才無法處理，那么我們可以將 TUMBLE WINDOW 使用 GROUP AGG(retract 流、或者叫做 CDC 模式)替換去計算。當(dāng)有遲到的數(shù)據(jù)時，GROUP AGG 會正常的處理及將上次的結(jié)果給撤回，將重新計算的新結(jié)果下發(fā)下去。但是這種方式存在的問題是如果我們想用 CDC 的模式去運行任務(wù)，我們需要全鏈路都是以 CDC 的模式去運行，包括計算引擎、消息隊列、OLAP 引擎等，而且還要保障 Exactly-once。(但是說到 CDC 是不是想到了數(shù)據(jù)湖?這可能也是后續(xù)的一個發(fā)展方向)。再以阿里(From FFA 2020)提到的一個分鐘\小時累計指標(biāo)舉例，我們看看阿里是怎么做的。實際阿里就是使用 GROUP AGG 做的計算(但是對于后續(xù)的鏈路不知道是否是使用 CDC 的方式運行的)。

分鐘/小時累計指標(biāo)

阿里的思路(From FFA 2020)：如下圖阿里所示，場景一是如果流批一體輸入源不同，需要批任務(wù)調(diào)度訂正結(jié)果，場景二是如果流批結(jié)果相同，就不跑批任務(wù)了。第一種情況沒有啥可說的;但是如果是第二種情況，這里簡單分析下：我們知道驗證流批結(jié)果相同的前提是，跑了批任務(wù)產(chǎn)出了結(jié)果主動去和流任務(wù)的結(jié)果去做對比，但是在場景二中實際是批任務(wù)并沒有運行!!!所以這里能想到的就是需要在事前、事中、事后做很多的監(jiān)控來保障流任務(wù)產(chǎn)出的整體流程沒有任何問題，從而保障能達到和預(yù)期批任務(wù)產(chǎn)出的結(jié)果相同。

新老研發(fā)模式對比

總結(jié)：上述的第一種思路相對比較理想化，基本是站在流任務(wù)產(chǎn)出的數(shù)據(jù)可以以批的模式進行復(fù)用角度去思考的，撇開了批任務(wù)執(zhí)行這一個過程。第二種阿里 FFA 2020 的思路相比來說對于鏈路軟硬件條件沒那么高，博主認(rèn)為是更具可行性的。

6.總結(jié)

本文主要介紹了以下三部分內(nèi)容：

• 流批一體的誕生是為了解決同一個指標(biāo)在離線、實時任務(wù)產(chǎn)出數(shù)據(jù)差異問題(數(shù)據(jù)質(zhì)量)
• 導(dǎo)致數(shù)據(jù)差異的根本原因就是數(shù)據(jù)亂序 
• 如果想解決這個問題，理想化就是全鏈路 CDC，更具操作性的思路可以參考阿里 FFA 2020