本文首發(fā)于泊浮目的語(yǔ)雀:https://www.yuque.com/17sing

0.背景：Dataflow之前

在Dataflow相關(guān)的論文發(fā)表前，大家都往往認(rèn)為需要兩套API來(lái)實(shí)現(xiàn)流計(jì)算和批計(jì)算，典型的實(shí)現(xiàn)便是Lambda架構(gòu)。

由于早期的流處理框架并不支持Exactly Once，導(dǎo)致流處理的數(shù)據(jù)并不精準(zhǔn)。在這個(gè)基礎(chǔ)上，一旦數(shù)據(jù)出現(xiàn)問(wèn)題，則要導(dǎo)致大量的數(shù)據(jù)重放——這是因?yàn)槭录怯袝r(shí)序要求的。因此，Lambda往往會(huì)通過(guò)流處理框架獲取不是特別精準(zhǔn)的結(jié)果，同時(shí)也會(huì)定時(shí)運(yùn)行批處理程序，來(lái)獲取更精準(zhǔn)的結(jié)果——當(dāng)更精準(zhǔn)的結(jié)果出來(lái)時(shí)，我們就不需要前者了。

但這也帶來(lái)的新的問(wèn)題，所有的視圖都需要流、批處理層各做一次，代碼也要寫(xiě)兩套，這帶來(lái)了數(shù)據(jù)口徑不同?？梢哉f(shuō)是在計(jì)算機(jī)資源以及人力資源上至少加了兩倍的開(kāi)銷。

Kappa提出了將所有數(shù)據(jù)落到Kafka上，將存儲(chǔ)模型與計(jì)算模型統(tǒng)一，但犧牲了時(shí)間——當(dāng)數(shù)據(jù)量大時(shí)，回溯計(jì)算的壓力巨大。

直到The dataflow model: a practical approach to balancing correctness, latency, and cost in massive-scale, unbounded, out-of-order data processing發(fā)表后，流與批有望在編程模型上統(tǒng)一， 上述相關(guān)的問(wèn)題得以緩解。

1. Flink的實(shí)現(xiàn)

Flink比起其他的流處理框架，更優(yōu)在兩點(diǎn)：

1. 遵循Dataflow模型，在編程模型上統(tǒng)一流批一體
2. 改進(jìn)Chandy-Lamport算法，以更低的代價(jià)保證精準(zhǔn)一次的實(shí)現(xiàn)

1.1 編程模型統(tǒng)一的背后

編程模型的統(tǒng)一具體體現(xiàn)在Flink SQL以及DataStream上。我們可以用相同的SQL or 幾乎相同的代碼跑流與批的任務(wù)。尤其是SQL，比起DataStream在聲明式上更甚。因此用戶在使用它們時(shí)，僅僅需要描述自己想要什么，而不是自己要做什么。具體做什么的事，F(xiàn)link框架會(huì)幫你搞定。

在Flink框架上，目前主要解決了以下問(wèn)題：

• IO模型：批處理會(huì)更加關(guān)注吞吐，因此是pull模型；而流處理更加關(guān)注實(shí)時(shí)性，因此是push模型?；谶@個(gè)條件，Source算子需要同時(shí)支持兩種模型來(lái)適應(yīng)不同的計(jì)算模式。詳細(xì)見(jiàn) FLIP-27: Refactor Source Interface。
• 調(diào)度策略：批處理的算子并不需要同時(shí)在線，前一批的算子完成后再調(diào)度后一批算子即可——由于計(jì)算資源往往比存儲(chǔ)資源昂貴，這是一個(gè)很不錯(cuò)的優(yōu)化方案。當(dāng)然在資源充足的情況下，追求性能也可以不考慮這種策略；但流處理的作業(yè)需要作業(yè)啟動(dòng)時(shí)就全部被調(diào)度。因此，StreamGraph需要同時(shí)支持這兩種模式——即LazyScheduling和EagerScheduling。
• 批流的銜接：假如我們要分析近30天的數(shù)據(jù)，大多數(shù)情況下都是29天的離線數(shù)據(jù)加上最近一天的實(shí)時(shí)數(shù)據(jù)，如何保證銜接時(shí)數(shù)據(jù)不多也不少，其實(shí)是個(gè)麻煩的事情，在不少工程實(shí)踐中會(huì)用一些比較hacks的方法。好在Flink1.4中引入了 Hybrid Source來(lái)簡(jiǎn)化這件事—— FLIP-150: Introduce Hybrid Source。

1.2 Checkpoint不是銀彈

Checkpoint是Flink框架中重要的容錯(cuò)機(jī)制，它的一個(gè)前提要求是數(shù)據(jù)源可重復(fù)讀。在數(shù)倉(cāng)場(chǎng)景下，雖然絕大多數(shù)情況下數(shù)據(jù)都不會(huì)發(fā)生變化——但也會(huì)有冷數(shù)據(jù)處理機(jī)制以及一些merge發(fā)生。這將對(duì)數(shù)據(jù)可重讀造成一定的挑戰(zhàn)。另外，在筆者負(fù)責(zé)的產(chǎn)品QMatrix中，對(duì)數(shù)據(jù)庫(kù)做全量遷移時(shí)也會(huì)遇到類似的挑戰(zhàn)：T1時(shí)刻讀到的全量數(shù)據(jù)為集合1，而T2時(shí)刻讀到的全量數(shù)據(jù)則為集合2。而MVVC也只能維持在一個(gè)session中。

上面描述的是在數(shù)據(jù)源要考慮的容錯(cuò)條件。在數(shù)據(jù)已經(jīng)全部流入任務(wù)時(shí)，容錯(cuò)機(jī)制也需要重新考慮——盡量避免重復(fù)讀取數(shù)據(jù)源以及上游任務(wù)的重算。因此社區(qū)引入了可插拔的Shuffle Service來(lái)提供Shuffle數(shù)據(jù)的持久用以支持細(xì)粒度的容錯(cuò)恢復(fù)——FLIP-31: Pluggable Shuffle Service。

2. 剩下的問(wèn)題：數(shù)據(jù)來(lái)源不統(tǒng)一

上述流批銜接的前提是數(shù)據(jù)源被分為了流數(shù)據(jù)源和批數(shù)據(jù)源。那么口徑便是不統(tǒng)一的，這會(huì)帶來(lái)一些對(duì)接成本。

目前流行的方案會(huì)采用數(shù)據(jù)湖（如IceBerg、Hudi、DeltaLake）來(lái)做流批數(shù)據(jù)的統(tǒng)一，并且由于大多數(shù)據(jù)湖都支持Time Travel，離線數(shù)據(jù)的可重復(fù)讀問(wèn)題也順帶解決。

另外，Pravega這種以流批一體存儲(chǔ)為設(shè)計(jì)目標(biāo)的軟件可能也是解決方案之一。

3. 小結(jié)

在本文中，筆者和大家一起了解了流批一體的來(lái)源，以及Flink社區(qū)在流批一體中做出的努力。此外，我們也看到了有些問(wèn)題并不是Flink這個(gè)框架可以解決的，需要整個(gè)大數(shù)據(jù)生態(tài)來(lái)一起演進(jìn)，走向流批一體。

在文章的最后，感謝余空同學(xué)的交流與指導(dǎo)，我們一起寫(xiě)出了這篇文章。