在大資料處理領域，批處理任務和流處理任務一般被認為是兩種不同的任務，乙個大資料框架一般會被設計為只能處理其中一種任務
*例如storm只支援流處理任務，而mapreduce、spark只支援批處理任務。spark streaming是採用了一種micro-batch的架構，即把輸入的資料流且分為細粒度的batch，並為每乙個batch資料提交乙個批處理的spark任務，所以spark streaming本質上還是基於spark批處理系統對流式資料進行處理，和storm等完全流式的資料處理方式完全不同。
* flink通過靈活的執行引擎，能夠同時支援批處理任務和流處理任務
在執行引擎這一層，流處理系統與批處理系統最大的不同在於節點間的資料傳輸方式。
而對於乙個批處理系統，其節點間資料傳輸的標準模型是：當一條資料被處理完成後，序列化到快取中，並不會立刻通過網路傳輸到下乙個節點，當快取寫滿，就持久化到本地硬碟上，當所有資料都被處理完成後，才開始將處理後的資料通過網路傳輸到下乙個節點。
這兩種資料傳輸模式是兩個極端，對應的是流處理系統對低延遲的要求和批處理系統對高吞吐量的要求。
flink的執行引擎採用了一種十分靈活的方式，同時支援了這兩種資料傳輸模型。
flink以固定的快取塊為單位進行網路資料傳輸，使用者可以通過設定快取塊超時值指定快取塊的傳輸時機。如果快取塊的超時值為0，則flink的資料傳輸方式類似上文所提到流處理系統的標準模型，此時系統可以獲得最低的處理延遲。
如果快取塊的超時值為無限大，則flink的資料傳輸方式類似上文所提到批處理系統的標準模型，此時系統可以獲得最高的吞吐量。
同時快取塊的超時值也可以設定為0到無限大之間的任意值。快取塊的超時閾值越小，則flink流處理執行引擎的資料處理延遲越低，但吞吐量也會降低，反之亦然。通過調整快取塊的超時閾值，使用者可根據需求靈活的權衡系統延遲和吞吐量。
flink學習 flink架構
flink結構 graph 2個併發度 source為1個併發度 的sockettextstreamwordcount四層執行圖的演變過程 jobgraph streamgraph經過優化後生成了 jobgraph，提交給 jobmanager 的資料結構。executiongraph jobman...
Flink原理與實現 詳解Flink中的狀態管理
上面flink原理與實現的文章中，有引用word count的例子，但是都沒有包含狀態管理。也就是說，如果乙個task在處理過程中掛掉了，那麼它在記憶體中的狀態都會丟失，所有的資料都需要重新計算。從容錯和訊息處理的語義上 at least once,exactly once flink引入了stat...
Flink原理與實現 理解Flink中的計算資源
本文所討論的計算資源是指用來執行 task 的資源，是乙個邏輯概念。本文會介紹 flink 計算資源相關的一些核心概念，如 slot slotsharinggroup colocationgroup chain等。並會著重討論 flink 如何對計算資源進行管理和隔離，如何將計算資源利用率最大化等等...