Apache Flink論文簡讀

轉載自：https://blog.csdn.net/lpstudy/article/details/83661945

Flink不同於Spark的batch processing，它着眼於data streaming processing。它的輸入可被看做一條無窮的stream，將函數應用到stream上，再輸出。Flink底層是流式處理，延遲更小，但是在某些時候batch processing可能更有效，因此Flink在上層也基於流式處理構建了batch處理，它通過記錄流式處理的start point，以及維護流式運行過程中的state來實現一個窗口的batch處理。

batch處理與流式處理的異同

1. batch看到是一個dataset，它可認為是一堆無序的records集合，然后將算法應用到dataset上面。Spark采用的內存型的RDD，然后將其划分成一個個的小的batch，Schedule這些batch到不同的機器上執行。Spark的batch處理過程可看做一個有向無環圖，在多輪iteration的過程中，會不斷的schedule job，會有一定的處理時延。
2. 流式處理看到的是一條具有無限輸入的記錄流，與batch不同的是，它的輸入有序，並有時間戳的概念。Flink在這個數據流上應用算法處理數據，延遲很低；在有batch需求的場景下，可通過設置流處理起始點，並記錄處理狀態，更新狀態，來實現batch處理。此外，Flink有一個專門設計的API來支持static datasets，它使用專門的數據結構和算法，往往更高效。

Flink基礎軟件棧架構

1. 軟件棧

   如上面圖1所示，Flink Core底層是流處理引擎，然后在上層抽象出Batch processing和Stream
   Processing，再上層構建幾種常用的應用：表格，圖，機器學習，復雜事件處理等

2. 流處理模型

   客戶端接收程序代碼，轉換成data-flow graph，然后提交給Job Manager。Job Manager將job分發給Task manager並跟蹤狀態和執行結果，發生失敗的failover等等。

上層的任何代碼都最終會被編譯成data-flow graph，然后交給Flink的Core層來統一處理。

Flink底層數據流圖

數據流圖是上層各種API的底層抽象，被Core層所執行，它主要包括兩種結構實體：有狀態的Operators以及Data Streams。當前層的Operator接收上一層的Operator的輸出作為輸入，並將運算結果以流的形式傳遞到下一層的Operator，Data Stream是連接兩個Operator的通道。

基本結構

如上圖所示，OP1這個運算符接收SRC1的輸出，並將運算結果傳遞到下一層的Operator SNK1。這三個Operator由兩個data stream進行連接，分別是IS1和IS3。這兩個數據流有所不同，IS1是一種暫時性的中間結果，這意味着我們不需要將其序列化到非易失性存儲實體中（內存中暫存即可），這就為Pipeline的處理提供了可能，SRC1和OP1可以並行運行，上層處理一個record之后，可以直接傳遞到下層繼續處理，組成一個pipeline的模式；而IS3是需要將流序列化到非易失性存儲的數據流，這種意味着OP1必須首先將輸出序列化到磁盤中，SNK1才能啟動執行，這樣兩邊的Operator就不能並行運行，同時還有額外的磁盤I/O的開銷，這種流叫作blocking data stream。blocking data stream要求生產者必須生產一定量的數據之后，才能用於下層的消費，它會先將積累的records存儲到內存中，如果內存不夠，那就序列化到磁盤中。

數據交換的時延和吞吐

兩個Operator通過交換buffer的方式來交換數據，buffer在兩種情況下傳遞到下層的消費者：(a) buffer滿了, (b) 超時了。 如果超時時間比較短或者buffer比較小，那么延遲會很低，但是這樣的話吞吐量會下降，通過調整超時時間或者buffer的大小，可以調整throughout和latency的tradeoff。

控制事件與records的融合

值得注意的是，Flink在records中間可以自由的插入Control Event，operator在收到相應的event進行相應的處理，這使得控制事件可以與現有的流直接融合，舉例如下三種控制事件：

1. checkpoint barriers

   這種控制事件用於Fault tolerance。在流中插入checkpoint事件，會促使流將當前的狀態保存下來，當發生故障后，可以直接使用上一次的checkpoint來恢復。

2. watermarks

   這種控制事件標識records的處理狀態。我們知道records有兩種時間概念：event-time和processing-time，在延遲很大時，這兩個指標可能相差很大。為了控制差異，可以插入watermarks，並綁定一個時間屬性t，例如如果operator如果收到了一個event-time為t的watermarks，意味着所有event-time小於t的records全都進入了operator中。這種機制在window records處理特別有效，例如5s一個windows，在5s結束之后插入一個watermark，來指示operator處理這個完整的windows。

3. iteration barriers

   這個專門的barrier是用於像機器學習這種需要多輪iteration的場景。傳統的Spark在iteration中，必須通過schedule a new job，這無疑會浪費大量的系統。很多場景下，迭代過程應該是一個自循環的過程：接收外部輸入，內部多輪迭代，傳遞到下層輸出。

下圖是一個簡單的迭代處理框架，operator內部包含了核心的處理邏輯。

Flink上層分析框架

有狀態的流處理

很多上層應用需要狀態管理，例如session處理，圖處理，機器學習（例如一顆訓練好的決策樹）等。Flink提供了接口來bind operator和相應的狀態，另外用戶還可以指定這些狀態在后端存儲，以用於故障恢復。

流窗口

這種主要用於時間段內分析，很多分析操作需要對窗口獲取一些統計信息。Flink使用windows的assigned（用於record分配到哪個窗口）， trigger（用於指定窗口啥時候執行），retain（用於指定窗口多少內容保留到下一次）。下面是一個代碼的例子，它定義了一個全局window，每1000次觸發一次窗口執行，並且每次保留100個records，用於下次的窗口。

stream
.window(GlobalWindow.create())
.trigger(Count.of(1000))
.evict(Count.of(100))

---

• [1] Apache Flink™: Stream and Batch Processing in a Single Engine