Apache Flink狀態管理和容錯機制介紹

1、有狀態的流數據處理

一、什麼是有狀態的計算

計算任務的結果不只僅依賴於輸入，還依賴於它的當前狀態，其實大多數的計算都是有狀態的計算。

好比wordcount,給一些word,其計算它的count,這是一個很常見的業務場景。count作爲輸出，在計算的過程當中要不斷的把輸入累加到count上去，那麼count就是一個state。

二、傳統的流計算系統缺乏對於程序狀態的有效支持

• 狀態數據的存儲和訪問；
• 狀態數據的備份和恢復；
• 狀態數據的劃分和動態擴容。

在傳統的批處理中，數據是劃分爲塊分片去完成的，而後每個Task去處理一個分片。當分片執行完成後，把輸出聚合起來就是最終的結果。在這個過程中，對於state的需求仍是比較小的。

對於流計算而言，對State有很是高的要求，由於在流系統中輸入是一個無限制的流，會運行很長一段時間，甚至運行幾天或者幾個月都不會停機。在這個過程中，就須要將狀態數據很好的管理起來。很不幸的是，在傳統的流計算系統中，對狀態管理支持並非很完善。好比storm,沒有任何程序狀態的支持，一種可選的方案是storm+hbase這樣的方式去實現，把這狀態數據存放在Hbase中，計算的時候再次從Hbase讀取狀態數據，作更新在寫入進去。這樣就會有以下幾個問題

• 流計算系統的任務和Hbase的數據存儲有可能不在同一臺機器上，致使性能會不好。這樣常常會作遠端的訪問，走網絡和存儲；
• 備份和恢復是比較困難，由於Hbase是沒有回滾的，要作到Exactly onces 很困難。在分佈式環境下，若是程序出現故障，只能重啓Storm，那麼Hbase的數據也就沒法回滾到以前的狀態。
  好比廣告計費的這種場景，Storm+Hbase是是行不通的，出現的問題是錢可能就會多算，解決以上的辦法是Storm+mysql，經過mysql的回滾解決一致性的問題。可是架構會變得很是複雜。性能也會不好，要commit確保數據的一致性。
• 對於storm而言狀態數據的劃分和動態擴容也是很是難作。
  一個很嚴重的問題是全部用戶都會在strom上重複的作這些工做，好比搜索，廣告都要在作一遍，由此限制了部門的業務發展。

三、Flink豐富的狀態訪問和高效的容錯機制

Flink在最先設計的時候就意識到了這個問題，並提供了豐富的狀態訪問和容錯機制。以下圖所示：

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

Flink而且提供了豐富的狀態訪問和高效的容錯機制

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

2、Flink中的狀態管理

按照數據的劃分和擴張方式，Flink中大體分爲2類：

• Keyed States
• Operator States

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

一、Keyed States

Keyed States的使用

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

Flink也提供了Keyed States多種數據結構類型

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

Keyed States的動態擴容

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

二、Operator State

Operator States的使用

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

Operator States的數據結構不像Keyed States豐富，如今只支持List

Operator States多種擴展方式

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

Operator States的動態擴展是很是靈活的，現提供了3種擴展，下面分別介紹：

• ListState:併發度在改變的時候，會將併發上的每一個List都取出，而後把這些List合併到一個新的List,而後根據元素的個數在均勻分配給新的Task;
• UnionListState:相比於ListState更加靈活，把劃分的方式交給用戶去作，當改變併發的時候，會將原來的List拼接起來。而後不作劃分，直接交給用戶；
• BroadcastState:如大表和小表作Join時，小表能夠直接廣播給大表的分區，在每一個併發上的數據都是徹底一致的。作的更新也相同，當改變併發的時候，把這些數據COPY到新的Task便可

以上是Flink Operator States提供的3種擴展方式，用戶能夠根據本身的需求作選擇。

使用Checkpoint提升程序的可靠性

用戶能夠根據的程序裏面的配置將checkpoint打開，給定一個時間間隔後，框架會按照時間間隔給程序的狀態進行備份。當發生故障時，Flink會將全部Task的狀態一塊兒恢復到Checkpoint的狀態。從哪一個位置開始從新執行。
Flink也提供了多種正確性的保障，包括：

• AT LEAST ONCE;
• Exactly once;

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

備份爲保存在State中的程序狀態數據
Flink也提供了一套機制，容許把這些狀態放到內存當中。作Checkpoint的時候，由Flink去完成恢復。

從已中止做業的運行狀態中恢復
當組件升級的時候，須要中止當前做業。這個時候須要從以前中止的做業當中恢復，Flink提供了2種機制恢復做業:

• Savepoint:是一種特殊的checkpoint，只不過不像checkpoint按期的從系統中去觸發的，它是用戶經過命令觸發，存儲格式和checkpoint
  也是不相同的，會將數據按照一個標準的格式存儲，無論配置什麼樣，Flink都會從這個checkpoint恢復，是用來作版本升級一個很是好的工具；
• External Checkpoint：對已有checkpoint的一種擴展，就是說作完一次內部的一次Checkpoint後，還會在用戶給定的一個目錄中，多存儲一份checkpoint的數據；

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

3、狀態管理和容錯機制實現

下面介紹一下狀態管理和容錯機制實現方式，Flink提供了3種不一樣的StateBackend,

• MemoryStateBackend
• FsStateBackend
• RockDBStateBackend

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

用戶能夠根據本身的需求選擇，若是數據量較小，能夠存放到MemoryStateBackend和FsStateBackend中，若是數據量較大，能夠放到RockDB中。

下面介紹HeapKeyedStateBackend和RockDBKeyedStateBackend

第一，HeapKeyedStateBackend

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

第二，RockDBKeyedStateBackend

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

Checkpoint的執行流程
Checkpoint的執行流程是按照Chandy-Lamport算法實現的。

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

Checkpoint Barrier的對齊

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

全量Checkpoint
全量Checkpoint會在每一個節點作備份數據時，只須要將數據都便利一遍，而後寫到外部存儲中，這種狀況會影響備份性能。在此基礎上作了優化。

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

RockDB的增量Checkpoint

RockDB的數據會更新到內存，當內存滿時，會寫入到磁盤中。增量的機制會將新產生的文件COPY持久化中，而以前產生的文件就不須要COPY到持久化中去了。經過這種方式減小COPY的數據量，並提升性能。

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

4、阿里相關工做介紹

Flink在阿里的成長路線
阿里是從2015年開始調研Flink,2015年10月啓動Blink項目，並完善Flink在大規模生產下的一些優化和改進。2016年雙11採用了Blink系統，爲搜索，推薦，廣告業務提供服務。2017年5月Blink已成爲阿里的實時計算引擎。

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

阿里在狀態管理和容錯相關的工做

若是想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共賬號：iteblog_hadoop

正在作的工做，基於State重構Window方面的一些優化，阿里也正在將功能作完善。後續將包括asynchronous Checkpoint的功能完善，並和社區進一步溝通和合做。幫助Flink社區完善相關方面的工做。

5、本文 PPT 下載

本文的 PPT 能夠到 《Flink China社區線下 Meetup·北京站 PPT 資料分享》 裏面進行下載。