流式計算分為無狀態和有狀態兩種情況。無狀態計算觀察每個獨立的事件，Storm就是無狀態的計算框架，每一條訊息來了以後和前後都沒有關係，一條是一條。比如我們接收電力系統感測器的資料，當電壓超過240v就報警，這就是無狀態的資料。但是如果我們需要同時判斷多個電壓，比如三相電路，我們判斷三相電都高於某個值，那麼就需要將狀態儲存，計算。因為這三條記錄是分別傳送過來的。

Storm需要自己實現有狀態的計算，比如藉助於自定義的記憶體變數或者redis等系統，保證低延遲的情況下自己去判斷實現有狀態的計算，但是Flink就不需要這樣，而且作為新一代的流處理系統，Flink非常重視。

一致性

其實就是訊息傳遞的正確性。在流處理中，一致性分為 3 個級別。

• at-most-once：最多一次，可能會丟失。

• at-least-once：最少一次，可能會重複，而計算的時候可能就會多次運算影響結果。

• exactly-once：恰好保證一次，這樣得到的結果是最準確的。

最先保證 exactly-once 的系統（Storm Trident 和 Spark Streaming），但是在效能和表現力這兩個方面付出了很大的代價。為了保證 exactly-once，這些系統無法單獨地對每條記錄運用應用邏輯，而是同時處理多條（一批）記錄，保證對每一批的處理要麼全部成功，要麼全部失敗。這就導致在得到結果前， 必須等待一批記錄處理結束。因此，使用者經常不得不使用兩個流處理框架 （一個用來保證 exactly-once，另一個用來對每個元素做低延遲處理），結果使基礎設施更加複雜。

但是，Flink解決了這種問題。

檢查點機制

檢查點是 Flink 最有價值的創新之一，因為它使 Flink 可以保 證 exactly-once，並且不需要犧牲效能。

Flink 檢查點的核心作用是確保狀態正確，即使遇到程式中斷，也要正確。 記住這一基本點之後，我們用一個例子來看檢查點是如何執行的。Flink 為 使用者提供了用來定義狀態的工具。例如，以下這個 Scala 程式按照輸入記錄 的第一個欄位（一個字串）進行分組並維護第二個欄位的計數狀態。

val stream: DataStream[(String, Int)] = ... 
 
val counts: DataStream[(String, Int)] = stream   
.keyBy(record => record._1)   
.mapWithState((in: (String, Int), count: Option[Int]) =>     
  count match {       
  	case Some(c) => ( (in._1, c + in._2), Some(c + in._2) )       
  	case None => ( (in._1, in._2), Some(in._2) )     
})

 

該程式有兩個運算元：keyBy 運算元用來將記錄按照第一個元素（一個字串） 進行分組，根據該 key 將資料進行重新分割槽，然後將記錄再發送給下一個運算元：有狀態的 map 運算元（mapWithState）。 map 運算元在接收到每個元素後， 將輸入記錄的第二個欄位的資料加到現有總數中，再將更新過的元素髮射出去。

輸入流中的 6 條記錄被檢查點屏障 （checkpoint barrier）隔開，所有的 map 運算元狀態均為0（計數還未開始）。 所有 key 為 a 的記錄將被頂層的 map 運算元處理，所有 key 為 b 的記錄將被中間層的 map 運算元處理，所有 key 為 c 的記錄則將被底層的 map 運算元處理。

如果輸入流來自訊息傳輸系統Kafka，這個相互隔離的位置就是偏移量。

檢查點屏障像普通記錄一樣在運算元之間流動。當 map 運算元處理完前 3 條記錄 並收到檢查點屏障時，它們會將狀態以非同步的方式寫入穩定儲存.

當沒有出現故障時，Flink 檢查點的開銷極小，檢查點操作的速度由穩定儲存的可用頻寬決定。

如果檢查點操作失敗，Flink 會丟棄該檢查點並繼續正常執行，因為之後的 某一個檢查點可能會成功。

在這種情況下，Flink 會重新拓撲（可能會獲取新的執行資源），將輸入流 倒回到上一個檢查點，然後恢復狀態值並從該處開始繼續計算。

Flink 將輸入流倒回到上一個檢查點屏障的位置，同時恢復 map 運算元的狀態值。 然後，Flink 從此處開始重新處理。這樣做保證了在記錄被處理之後，map 運算元的狀 態值與沒有發生故障時的一致.

Flink 檢查點演算法的正式名稱是非同步屏障快照（asynchronous barrier snapshotting）。

儲存點

狀態版本控制

檢查點由 Flink 自動生成，用來在故障發生時重新處理記錄，從而修正狀 態。Flink 使用者還可以通過另一個特性有意識地管理狀態版本，這個特性叫作儲存點（savepoint）。

儲存點與檢查點的工作方式完全相同，只不過它由使用者通過 Flink 命令列工 具或者 Web 控制檯手動觸發，而不由 Flink 自動觸發，使用者可以從儲存點重啟作業，而不用從頭開始。對儲存點的另一種理解是，它在明確的時間點儲存應用程式狀態的版本。

在圖中，v.0 是某應用程式的一個正在執行的版本。我們分別在 t1 時刻和 t2 時刻觸發了儲存點。因此，可以在任何時候返回到這兩個時間點，並且重 啟程式。更重要的是，可以從儲存點啟動被修改過的程式版本。舉例來說， 可以修改應用程式的程式碼（假設稱新版本為 v.1），然後從t1 時刻開始執行 改動過的程式碼。

使用儲存點更新Flink 應用程式的版本。新版本可以從舊版本生成的一個 儲存點處開始執行.

端到端的一致性

在該應用程式架構中，有狀態的Flink 應用程式消費來自訊息佇列的資料， 然後將資料寫入輸出系統，以供查詢。

輸入資料來自Kafka，在將狀態內容傳送到輸出儲存系統的過程中，如何保證 exactly-once 呢？這 叫作端到端的一致性。本質上有兩種實現方法，用哪一種方法則取決於輸 出儲存系統的型別，以及應用程式的需求。

(1) 第一種方法是在 sink 環節緩衝所有輸出，並在 sink 收到檢查點記錄時， 將輸出“原子提交”到儲存系統。這種方法保證輸出儲存系統中只存在 有一致性保障的結果，並且不會出現重複的資料。從本質上說，輸出存 儲系統會參與 Flink 的檢查點操作。要做到這一點，輸出儲存系統需要 具備“原子提交”的能力。

(2) 第二種方法是急切地將資料寫入輸出儲存系統，同時牢記這些資料可能 是“髒”的，而且需要在發生故障時重新處理。如果發生故障，就需要將 輸出、輸入和 Flink 作業全部回滾，從而將“髒”資料覆蓋，並將已經寫 入輸出的“髒”資料刪除。注意，在很多情況下，其實並沒有發生刪除 操作。例如，如果新記錄只是覆蓋舊紀錄（而不是新增到輸出中），那麼 “髒”資料只在檢查點之間短暫存在，並且最終會被修正過的新資料覆蓋。

根據輸出儲存系統的型別，Flink 及與之對應的聯結器可以一起保證端到端 的一致性，並且支援多種隔離級別。

更多Flink相關文章：

Streaming-大資料的未來

實時計算大資料處理的基石-Google Dataflow

資料架構的未來——淺談流處理架構

穿梭時空的實時計算框架——Flink對時間的處理

Flink快速入門--安裝與示例執行

大資料實時處理的王者-Flink

更多實時計算,Flink,Kafka等相關技術博文，歡迎關注實時流式計算：

相關推薦