計算任務的結果不只僅依賴於輸入,還依賴於它的當前狀態,其實大多數的計算都是有狀態的計算。html
好比wordcount,給一些word,其計算它的count,這是一個很常見的業務場景。count作爲輸出,在計算的過程當中要不斷的把輸入累加到count上去,那麼count就是一個state。mysql
在傳統的批處理中,數據是劃分爲塊分片去完成的,而後每個Task去處理一個分片。當分片執行完成後,把輸出聚合起來就是最終的結果。在這個過程中,對於state的需求仍是比較小的。算法
對於流計算而言,對State有很是高的要求,由於在流系統中輸入是一個無限制的流,會運行很長一段時間,甚至運行幾天或者幾個月都不會停機。在這個過程中,就須要將狀態數據很好的管理起來。很不幸的是,在傳統的流計算系統中,對狀態管理支持並非很完善。好比storm,沒有任何程序狀態的支持,一種可選的方案是storm+hbase這樣的方式去實現,把這狀態數據存放在Hbase中,計算的時候再次從Hbase讀取狀態數據,作更新在寫入進去。這樣就會有以下幾個問題sql
Flink在最先設計的時候就意識到了這個問題,並提供了豐富的狀態訪問和容錯機制。以下圖所示:微信
若是想及時瞭解Spark、Hadoop或者Hbase相關的文章,歡迎關注微信公共賬號:iteblog_hadoop網絡
Flink而且提供了豐富的狀態訪問和高效的容錯機制數據結構
若是想及時瞭解Spark、Hadoop或者Hbase相關的文章,歡迎關注微信公共賬號:iteblog_hadoop架構
按照數據的劃分和擴張方式,Flink中大體分爲2類:併發
若是想及時瞭解Spark、Hadoop或者Hbase相關的文章,歡迎關注微信公共賬號:iteblog_hadoop框架
Keyed States的使用
若是想及時瞭解Spark、Hadoop或者Hbase相關的文章,歡迎關注微信公共賬號:iteblog_hadoop
Flink也提供了Keyed States多種數據結構類型
若是想及時瞭解Spark、Hadoop或者Hbase相關的文章,歡迎關注微信公共賬號:iteblog_hadoop
Keyed States的動態擴容
若是想及時瞭解Spark、Hadoop或者Hbase相關的文章,歡迎關注微信公共賬號:iteblog_hadoop
Operator States的使用
若是想及時瞭解Spark、Hadoop或者Hbase相關的文章,歡迎關注微信公共賬號:iteblog_hadoop
Operator States的數據結構不像Keyed States豐富,如今只支持List
Operator States多種擴展方式
若是想及時瞭解Spark、Hadoop或者Hbase相關的文章,歡迎關注微信公共賬號:iteblog_hadoop
Operator States的動態擴展是很是靈活的,現提供了3種擴展,下面分別介紹:
以上是Flink Operator States提供的3種擴展方式,用戶能夠根據本身的需求作選擇。
使用Checkpoint提升程序的可靠性
用戶能夠根據的程序裏面的配置將checkpoint打開,給定一個時間間隔後,框架會按照時間間隔給程序的狀態進行備份。當發生故障時,Flink會將全部Task的狀態一塊兒恢復到Checkpoint的狀態。從哪一個位置開始從新執行。
Flink也提供了多種正確性的保障,包括:
若是想及時瞭解Spark、Hadoop或者Hbase相關的文章,歡迎關注微信公共賬號:iteblog_hadoop
備份爲保存在State中的程序狀態數據
Flink也提供了一套機制,容許把這些狀態放到內存當中。作Checkpoint的時候,由Flink去完成恢復。
從已中止做業的運行狀態中恢復
當組件升級的時候,須要中止當前做業。這個時候須要從以前中止的做業當中恢復,Flink提供了2種機制恢復做業:
若是想及時瞭解Spark、Hadoop或者Hbase相關的文章,歡迎關注微信公共賬號:iteblog_hadoop
下面介紹一下狀態管理和容錯機制實現方式,Flink提供了3種不一樣的StateBackend,
若是想及時瞭解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
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社區完善相關方面的工做。
本文的 PPT 能夠到 《Flink China社區線下 Meetup·北京站 PPT 資料分享》 裏面進行下載。