關注公眾號：大數(shù)據(jù)技術派，回復“資料”，領取1000G資料。
本文首發(fā)于我的個人博客：Flink 是如何統(tǒng)一批流引擎的

2015 年，F(xiàn)link 的作者就寫了 Apache Flink: Stream and Batch Processing in a Single Engine 這篇論文。本文以這篇論文為引導，詳細講講 Flink 內部是如何設計并實現(xiàn)批流一體的架構。

前言

通常我們在 Flink 中說批流一體指的是這四個方向，其中 Runtime 便是 Flink 運行時的實現(xiàn)。

數(shù)據(jù)交換模型

Flink 對于流作業(yè)和批作業(yè)有一個統(tǒng)一的執(zhí)行模型。

Flink 中每個 Task 的輸出會以 IntermediateResult 做封裝，內部并沒有對流和批兩種作業(yè)做一個明確的劃分，只是通過不同類型的 IntermediateResult 來表達 PIPELINED 和 BLOCKING 這兩大類數(shù)據(jù)交換模型。

在了解數(shù)據(jù)交換模型之前，我們來看下為什么 Flink 對作業(yè)類型不作區(qū)分，這樣的好處是什么？

如上圖所示，假如我們有一個工作需要將批式作業(yè)執(zhí)行結果作為流式作業(yè)的啟動輸入，那怎么辦？這個作業(yè)是算批作業(yè)還是流作業(yè)？

很顯然，以我們的常識是無法定義的，而現(xiàn)有的工業(yè)界的辦法也是如此，將這個作業(yè)拆分為兩個作業(yè)，先跑批式作業(yè)，再跑流式作業(yè)，這樣當然可以，但是人工運維的成本也是足夠大的：

  1. 需要一個外界存儲來管理批作業(yè)的輸出數(shù)據(jù)。
  2. 需要一個支持批流作業(yè)依賴的調度系統(tǒng)。

如果期望實現(xiàn)這樣一個作業(yè)，那么首先執(zhí)行這個作業(yè)的計算引擎的作業(yè)屬性就不能對批作業(yè)和流作業(yè)進行強綁定。那么 Flink 能否實現(xiàn)這樣的需求呢？我們先來看看數(shù)據(jù)交換的具體細節(jié)，最后再來一起看看這個作業(yè)的可行性。

我們以 PIPELINED 數(shù)據(jù)交換模型為例，看看是如何設計的：

PIPELINED 模式下，RecordWriter 將數(shù)據(jù)放入到 Buffer 中，根據(jù) Key 的路由規(guī)則發(fā)送給對應的 Partition，Partition 將自己的數(shù)據(jù)封裝到 Reader 中放入隊列，讓 Netty Server 從隊列中讀取數(shù)據(jù)，發(fā)送給下游。

我們將數(shù)據(jù)交換模式改為 BLOCKING，會發(fā)現(xiàn)這個設計也是同樣可行的。Partition 將數(shù)據(jù)寫入到文件，而 Reader 中維護著文件的句柄，上游任務結束后調度下游任務，而下游任務通過 Netty Client 的 Partition Request 喚醒對應的 Partition 和 Reader，將數(shù)據(jù)拉到下游。

調度模型

有 LAZY 和 EAGER 兩種調度模型，默認情況下流作業(yè)使用 EAGER，批作業(yè)使用 LAZY。

EAGER

這個很好理解，因為流式作業(yè)是 All or Nothing 的設計，要么所有 Task 都 Run 起來，要么就不跑。

LAZY

LAZY 模式就是先調度上游，等待上游產生數(shù)據(jù)或結束后再調度下游。有些類似 Spark 中的 Stage 執(zhí)行模式。

Region Scheduling

可以看到，不管是 EAGER 還是 LAZY 都沒有辦法執(zhí)行我們剛才提出的批流混合的任務，于是社區(qū)提出了 Region Scheduling 來統(tǒng)一批流作業(yè)的調度，我們先看一下如何定義 Region：

以 Join 算子為例，我們都知道如果 Join 算子的兩個輸入都是海量數(shù)據(jù)的話，那么我們是需要等兩個輸入的數(shù)據(jù)都完全準備好才能進行 Join 操作的，所以 Join 兩條輸入的邊對應的數(shù)據(jù)交換模式對應的應該是 BLOCKING 模式，我們可以根據(jù) BLOCKING 的邊將作業(yè)劃分為多個子 Region，如上圖虛線所示。

如果實現(xiàn)了 Region Scheduling 之后，我們在上面提到的批流混合的作業(yè)就可以將深色部分流式作業(yè)劃為一個 Region，淺色部分批式作業(yè)再劃分為多個 Region，而淺色部分是深色部分 Region 的輸入，所以根據(jù) Region Scheduling 的原則會優(yōu)先調度最前面的 Region。

總結

上面提到了數(shù)據(jù)交換模型和調度模型，簡單來講其實就兩句話：

1 實現(xiàn)了用 PIPELINED 模型去跑批式作業(yè)

用 PIPELINED 模型跑流式作業(yè)和用 BLOCKING 模型跑批式作業(yè)都是沒有什么新奇的。這里提到用 PIPELINED 模式跑批作業(yè)，主要是針對實時分析的場景，以 Spark 為例，在大部分出現(xiàn) Shuffle 或是聚合的場景下都會出現(xiàn)落盤的行為，并且調度順序是一個一個 Stage 進行調度，極大地降低了數(shù)據(jù)處理的實時性，而使用 PIPELINED 模式會對性能有一定提升。

可能有人會問類似 Join 的算子如何使用 PIPELINED 數(shù)據(jù)交換模型實現(xiàn)不落盤的操作？事實上 Flink 也會落盤，只不過不是在 Join 的兩個輸入端落盤，而是將兩個輸入端的數(shù)據(jù)傳輸?shù)?Join 算子上，內存撐不住時再進行落盤，海量數(shù)據(jù)下和 Spark 的行為并沒有本質區(qū)別，但是在數(shù)據(jù)量中等，內存可容納的情況下會帶來很大的收益。

2 集成了一部分調度系統(tǒng)的功能

根據(jù) Region 來調度作業(yè)時，Region 內部跑的具體是流作業(yè)還是批作業(yè)，F(xiàn)link 自身是不關心的，更關心的 Region 之間的依賴關系，一定程度上，利用這種調度模型我們可以將過去需要拆分為多個作業(yè)的執(zhí)行模式放到一個作業(yè)中來執(zhí)行，比如上面提到的批流混合的作業(yè)。