[[435826]]

1.前言

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

2.背景

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

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

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

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

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

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

是對(duì)于阿里列舉的問題的一個(gè)抽象。因?yàn)槿绻軌驈?fù)用的話，下圖中的三個(gè)問題也就不存在了!

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

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

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

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

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

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

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

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

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

分鐘/小時(shí)累計(jì)指標(biāo)

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

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

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

6.總結(jié)

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

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