Flink（二）
一、統一的批處理與流處理系統
在大數據處理領域，批處理任務與流處理任務一般被認為是兩種不同的任務，一個大數據項目一般會被設計為只能處理其中一種任務，例如Apache Storm、Apache Smaza只支持流處理任務，而Aapche MapReduce、Apache Tez、Apache Spark只支持批處理任務。
Spark Streaming是Apache Spark之上支持流處理任務的子系統，看似一個特例，實則不然——Spark Streaming采用了一種micro-batch的架構，即把輸入的數據流切分成細粒度的batch，並為每一個batch數據提交一個批處理的Spark任務，所以Spark Streaming本質上還是基於Spark批處理系統對流式數據進行處理，和Apache Storm、Apache Smaza等完全流式的數據處理方式完全不同。通過其靈活的執行引擎，Flink能夠同時支持批處理任務與流處理任務。
在執行引擎這一層，流處理系統與批處理系統最大不同在於節點間的數據傳輸方式。
對於一個流處理系統，其節點間數據傳輸的標准模型是：當一條數據被處理完成后，序列化到緩存中，然后立刻通過網絡傳輸到下一個節點，由下一個節點繼續處理。
而對於一個批處理系統，其節點間數據傳輸的標准模型是：當一條數據被處理完成后，序列化到緩存中，並不會立刻通過網絡傳輸到下一個節點，當緩存寫滿，就持久化到本地硬盤上，當所有數據都被處理完成后，才開始將處理后的數據通過網絡傳輸到下一個節點。
這兩種數據傳輸模式是兩個極端，對應的是流處理系統對低延遲的要求和批處理系統對高吞吐量的要求。
Flink的執行引擎采用了一種十分靈活的方式，同時支持了這兩種數據傳輸模型。Flink以固定的緩存塊為單位進行網絡數據傳輸，用戶可以通過緩存塊超時值指定緩存塊的傳輸時機。如果緩存塊的超時值為0，則Flink的數據傳輸方式類似上文所提到流處理系統的標准模型，此時系統可以獲得最低的處理延遲。如果緩存塊的超時值為無限大，則Flink的數據傳輸方式類似上文所提到批處理系統的標准模型，此時系統可以獲得最高的吞吐量。
同時緩存塊的超時值也可以設置為0到無限大之間的任意值。
緩存塊的超時閾值越小，則Flink流處理執行引擎的數據處理延遲越低，但吞吐量也會降低，
反之亦然。通過調整緩存塊的超時閾值，用戶可根據需求靈活地權衡系統延遲和吞吐量。
二、架構
當Flink集群啟動后，會首先啟動一個JobManager和一個或者多個TaskManager。 由Client提交任務給JobManager，JobManager會調度任務到各個taskManager去執行，
TaskManager會將心跳和統計信息匯報給JobManager。
TaskManager之間以流的形式進行數據的傳輸。
JobManager 主要負責調度Job並協調Task，從client接收jar，生成優化后的執行計划，執行Task。
每個slot能啟動一個Task。task為線程。
-------講義-------
要了解一個系統，一般都是從架構開始。
我們關心的問題是：系統部署成功后各個節點都啟動了哪些服務，各個服務之間又是怎么交互和協調的。
下方是 Flink 集群啟動后架構圖：
當 Flink 集群啟動后，首先會啟動一個 JobManger 和一個或多個的 TaskManager。由 Client 提交任務給 JobManager，JobManager 再調度任務到各個 TaskManager 去執行，然后 TaskManager 將心跳和統計信息匯報給 JobManager。TaskManager 之間以流的形式進行數據的傳輸。上述三者均為獨立的 JVM 進程。
Client 為提交 Job 的客戶端，可以是運行在任何機器上（與 JobManager 環境連通即可）。提交 Job 后，Client 可以結束進程（Streaming的任務），也可以不結束並等待結果返回。
JobManager 主要負責調度 Job 並協調 Task 做 checkpoint，職責上很像 Storm 的 Nimbus。從 Client 處接收到 Job 和 JAR 包等資源后，會生成優化后的執行計划，並以 Task 的單元調度到各個 TaskManager 去執行。
TaskManager 在啟動的時候就設置好了槽位數（Slot），每個 slot 能啟動一個 Task，Task 為線程。從 JobManager 處接收需要部署的 Task，部署啟動后，與自己的上游建立 Netty 連接，接收數據並處理。
可以看到 Flink 的任務調度是多線程模型，並且不同Job/Task混合在一個 TaskManager 進程中。雖然這種方式可以有效提高 CPU 利用率，但是個人不太喜歡這種設計，因為不僅缺乏資源隔離機制，同時也不方便調試。類似 Storm 的進程模型，一個JVM 中只跑該 Job 的 Tasks 實際應用中更為合理。
flink編程模型：
