《基于Apache Flink的流處理》讀書筆記

前段時間詳細地閱讀了 《Apache Flink的流處理》 這本書,作者是 Fabian Hueske&Vasiliki Kalavri,國內崔星燦翻譯的,這本書非常詳細、全面得介紹了Flink流處理,并且以氣象數據的例子講解其中的使用,我把其中一些比較重要的句子做了比較 , 并且分享給大家 。有一些我不是很理解,需要以后慢慢去消化,我就不做詳細的展開 。
一、傳統的數據處理框架1.1事務型處理企業在日常業務運營過程中會用到各類基于web的應用,通常是業務系統 , 比如訂單、客戶系統等等        通常一個應用對于1個或多個數據庫,應用通過執行遠程數據庫系統的事務來讀取或更新狀態
1.2分析型處理存儲于不同事務類型數據系統中的數據,可以為企業提供業務運營相關的分析見解,通常是將數據從業務系統的數據庫中復制到數倉,然后再進行分析和查詢 。這個過程稱為ETL 。
二、Flink和Spark的區別2.1共同點高吞吐、在壓力下保持正確
2.2不同點:1.本質上,Spark是微批處理,而Flink是流處理         2.Flink低延遲         3.Flink支持時間語義,可通過WaterMark來處理亂序數據,如果Spark要處理亂序數據只能通過RDD排序來實現         4.Flink支持狀態編程 , 使用方式更加靈活         5.Flink提供精確一次的狀態一致性保障
2.3本質區別:本質上是流與微批的區別
2.4 數據模型:Spark采用RDD模型,Spark Streaming的DStream實際上也就是一組小批數據的RDD的集合        Flink基本數據是流,以及事件Event序列
2.5運行架構:Spark是批計算,將DAG劃分成不同的stage,一個完成后才可以計算下一個        Flink是標準的流執行模式 , 一個事件在處理后可以直接發往下一個節點
三、Flink流處理基礎3.1DataFlow圖描述了數據在不同操作之間流動 。        通常表現為有向圖,頂點表現為算子,表示計算,邊表示數據的依賴關系
3.2StreamGraph根據用戶通過StreamAPI編寫的代碼生成的最初的圖 , 由2部分構成:         1.StreamNode,代表算子,表示計算         2.StreamEdge:連接兩個StreamNode的邊,表示數據的依賴關系
3.3JobGraphStreamGraph經過優化后生成了JobGraph , 提交給JobManager的數據結構,由以下3個構成:         1.JobVertex:經過優化后符合條件的多個StreamNode可能串聯在一起生成1個JobVertex         2.JobEdge:連接JobVertex,代表了JobGraph的依賴關系 。         3.IntermediateDataSet:經過JobVertex節點處理的數據輸出
3.4ExecutionGraphJobGraph的并行版本 , 由JobManager生成,調度底層的核心數據結構
3.5物理執行圖JobManager根據ExecutionGraph對Job進行調度,在TaskManager上部署后形成的圖 , 并不是一個數據結構
四、算子狀態4.1本地變量單個算子同一并行度子任務可以訪問,其余都不行
4.2算子狀態(Operator State)算子狀態的作用范圍限定為算子任務        由同一個算子同一并行的子任務所處理的所有數據都可以訪問到相同的狀態        狀態對于同一子任務而言是共享的        算子狀態不能由相同或不同算子的另一個子任務訪問主要有3種:        ListState:將狀態表示為一組數據的列表        Union List State:也是ListState,區別在從savepoint或者checkpoint啟動時如何恢復        BroadCast State:廣播狀態
4.3鍵控狀態(Keyed State)鍵控狀態是根據輸入數據流中定義的鍵(key)來維護和訪問的        key相同的數據所能訪問的狀態        KeyedState只能在鍵控流中使用主要有4種:        ValueState:將狀態表示為單個的值        ListState:將狀態表示為一組數據的列表        MapState:將狀態表示為一組 Key-Value 對        ReducingState:將狀態表示為一個用于聚合操作的列表

推薦閱讀