[[435826]]

1.前言

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

2.背景

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

批任務：常用 Hive、Spark。

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

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

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

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

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

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

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

博主認為，目前最重要的一個原因就是數(shù)據(jù)亂序導致的數(shù)據(jù)質量問題。

在實時領域最常用和常見的場景有以下兩種：

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

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

當然還有其他場景，這里就不一一列舉了。

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

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

分鐘/小時累計指標

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

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

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

6.總結

本文主要介紹了以下三部分內容：

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