flink雜記

flink的特色：能同時知足高性能、高吞吐、低延時，相比較於storm和spark streaming，storm的吞吐量不如flink，而spark streaming的延時比較高，由於spark streaming進行流式計算的原理就是微批操做，就是要積累必定的時間，雖然能夠儘可能下降這個時間粒度，可是延時指標仍是會比flink要高

• 同時支持高吞吐、低延時、高性能
  
• 支持事件時間概念（event time）
  
• 支持有狀態計算（狀態就是中間計算結果，每次計算新的數據進入到流式系統中都是基於中間狀態結果進行計算，不須要利用原始數據從新計算，這樣提高了計算效率）
  
• 支持高度靈活的窗口計算
  
• 基於輕量級分佈式快照實現的容錯（利用checkpoint實現高度容錯的狀態管理）
  
• 基於jvm實現獨立的內存管理
  
• save points（保存點）

flink的基本架構
客戶端：客戶端經過創建akka鏈接提交任務給JobManager，而且經過JobManager獲取任務狀態和執行狀況。
JobManager：至關於Master，負責任務管理和資源管理，JobManager接受到客戶端提交的任務之後，會根據TaskManager的Task Slot狀況進行任務的分配，而且經過Actor system和TaskManager進行通訊，獲取任務的執行狀態返回給客戶端；同時在任務執行的過程當中會觸發Checkpoints操做，TaskManager收到checkpoint指令後完成checkpoint操做，全部的checkpoint協調過程都是在JobManager中完成的。
TaskManager：至關於Slave，負責任務的執行和任務在每一個節點上的資源申請和管理。

有界數據集：有明確時間範圍的起始和結束，用於批計算
無界數據集：會一直產生的數據，沒有明確時間範圍的起始和結束，用於流處理
spark streaming對有界數據集進行批處理，對無界數據集進行微批處理從而實現流計算；實際上有界數據集合無界數據集是能夠相互轉化的，利用這個思想，flink利用統一的流處理模式處理不一樣類型的數據集

flink的開放API

• SQL API
• Table API：在DataSet和DataStream的基礎上多了一層Schema信息，將 數據集註冊成表
  
• DataSet/DataStream API
  
• Stateful Stream Processing API：最底層的API，能夠操做狀態、時間等底層數據

flink程序的主要步驟

• 設定執行環境
  
• 建立和加載數據集
  
• 對數據集指定轉換操做邏輯
  
• 指定計算結果輸出位置
  
• 觸發程序執行

flink的編程模型採用DataFlow模型，主要須要實現三種DataStream API：Data Source/Transformation/Data Sink

flink內部常見數據重分區策略

• Random Partitioning：經過隨機的方式將數據分配在下游算子的每一個分區中，分區相對均衡，可是會破壞原有數據的分區結構
  
• Roundrobin Partitioning：經過循環的方式對數據集中的數據進行重分區，數據會全局性的經過網絡介質傳輸到其餘節點完成數據的從新平衡，儘量的保證每一個分區的數據平衡，當數據集發生數據傾斜的時候使用這種策略是比較有效的優化方法
  
• Rescaling Partitioning：僅僅針對上下游繼承的算子進行重平衡，具體的分區要根據上下游算子的並行度決定

常見的幾種經過建立Class實現Function接口

• MapFunction[T, O]須要指定輸入輸出的流數據類型
  
• FilterFunction[T]
  
• ReduceFunction[T]
  
• 還能夠經過實現RichFunction接口，用於比較高級的數據處理場景，接口中有open, close, getRuntimeContext, setRuntimeContext等方法來獲取狀態，緩存等系統內部數據.

WaterMark
watermark學習

window計算

• flink會根據上游數據集是否爲KeyedStream類型，進行不一樣的window計算，若是是，則根據key在不一樣的task實例中並行分別計算，若是不是，則用windowAll()方法，將全部數據路由到一個task鍾計算，獲得全局統計結果（很容易反壓致使延遲）

Tumbling Windows：根據固定時間進行切分，窗口連續不重疊，適用於按照固定大小和週期統計某一指標
Sliding Windows：在Tumbling Windows的基礎上增長了滑動時間，當滑動時間和窗口大小相等，則兩種窗口等價，適用於根據設定頻率計算指定窗口大小的統計指標，例如每隔30s統計最近10min的活躍用戶
Session Windows：將某段時間內活躍度較高的數據聚合成一個窗口，不須要固定窗口大小和滑動時間，只須要定義session gap，表示多長時間沒有活躍數據則觸發window，若數據一直不間斷進入窗口，有可能致使窗口始終不觸發的狀況，適用於非連續性數據處理或週期性產生數據的場景
Global Windows：沒有起始時間和結束時間，須要自定義觸發器來觸發，還須要指定數據清理機制，不然數據將一直留在內存中，最終致使內存溢出

• 經常使用Window Function：
  • ReduceFunction/AggregateFunction：基於中間狀態計算的增量聚合函數，性能較高
    
  • ProcessWindowsFunction：基於窗口所有數據計算的聚合函數，能夠利用窗口狀態數據和元數據進行更復雜的計算

多流合併須要保證輸入的stream要構建在相同的Window上，並使用相同的key做爲關聯條件，且每一個stream中都要有key與key能關聯纔會有輸出結果

狀態管理

Keyed State事先按照key對數據進行了分區，而Operator State只和並行的算子實例綁定
狀態管理的兩種形式：Managed State由Flink Runtime控制和管理狀態數據，並將狀態數據存儲到內存以及經過外部接口持久化到Checkpoints中，任務異常能夠經過狀態數據恢復任務；而Raw State是由算子本身管理數據結構，觸發Checkpoint過程當中，只是將數據序列化到Checkpoints中，恢復任務時再反序列化回來，相比較之下，Managed State能更好的支持狀態數據的重平衡以及更加完善的內存管理

• 狀態管理器
  • MemoryStateBackend：基於內存的狀態管理器，將狀態數據所有存儲在JVM堆內存中，具備快速高效的特色，可是有內存容量的限制；聚合類算子的狀態會存儲在JobManager的內存中，所以聚合類算子比較多的應用會對JobManager形成較大壓力，在建立MemoryStateBackend時最好指定狀態初始化內存大小，這種方式比較適用於測試環境，用於本地的測試和驗證
    
  • FsStateBackend：基於文件系統的狀態管理器，將狀態數據存儲在文件系統中，能夠採用同步/異步的方式同步數據，最大的好處就是相對比較穩定，能最大程度保證數據的安全性，不會由於外部故障致使任務沒法恢復，適用於狀態數據很是大的場景
    
  • RocksDBStateBackend：flink中內置的第三方狀態管理器，採用異步的方式進行狀態數據的同步，狀態數據首先寫入RocksDB，而後異步寫入文件系統，對於熱點數據存儲在RocksDB，長時間才更新的數據則寫入磁盤進行存儲，而體量比較小的數據則直接存儲在JobManager的內存中，所以性能比FsStateBackend高，也適用於狀態數據很是大的場景.

批處理DataSet API
利用廣播變量和分佈式緩存進行數據的共享，讓每臺計算節點都能在本地獲取數據文件，進而提高分佈式計算環境下數據處理的效率：實現RichFunction接口，經過實現open()方法調用getRuntimeContext()方法獲取廣播變量或分佈式緩存.

flink部署模式

1. local模式：適用於本地開發和測試環境，佔用的資源較少，部署簡單，只須要部署JDK和flink便可達到功能開發和測試的目的。只須要一臺主機便可。
2. standalone cluster：能夠在測試環境功能驗證完畢到版本發佈的時候使用，進行性能驗證。搭建須要ssh、jdk和flink。至少須要3臺主機，一個master兩個worker節點。使用自帶的資源管理器
3. YARN：flink使用YARN進行調度。有兩種模式，一是yarn session model，這種模式flink會向yarn申請足夠多的資源，並在yarn上啓動長時間運行的flink session集羣，用戶將任務提交到flink session集羣上運行，從而再也不與yarn進行交互，讓flink應用在相同的集羣環境上運行，屏蔽底層不一樣的運行環境；另外一種是single job model，每一個flink任務單獨向yarn提交一個application，而且有獨立的JobManager和TaskManager，任務結束對應組件的資源也會被釋放
4. kubernetes：更加方便進行管理和運維 HA模式： 如今主流的方式有standalone cluster HA 和YARN cluster HA方式，適用於在生產上部署。 standalone cluster HA利用zookeeper完成JobManager leader的選舉，多個JobManager只有一個處於工做模式，其餘處於standby模式 YARN cluster HA經過重啓的方式保證JobManager高可用