—— 圖片來自 《國家地理中文網》——
往期推薦：
Flink在資源管理上可以分為兩層：叢集資源和自身資源。叢集資源支援主流的資源管理系統，如yarn、mesos、k8s等，也支援獨立啟動的standalone叢集。自身資源涉及到每個子task的資源使用，由Flink自身維護。
1 叢集架構剖析
Flink的執行主要由 客戶端、一個JobManager（後文簡稱JM）和 一個以上的TaskManager（簡稱TM或Worker）組成。
客戶端
客戶端主要用於提交任務到叢集，在Session或Per Job模式中，客戶端程式還要負責解析使用者程式碼，生成JobGraph；在Application模式中，直接提交使用者jar和執行引數即可。客戶端一般支援兩種模式：detached模式，客戶端提交後自動退出。attached模式，客戶端提交後阻塞等待任務執行完畢再退出。
JobManager
JM負責決定應用何時排程task，在task執行結束或失敗時如何處理，協調檢查點、故障恢復。該程式主要由下面幾個部分組成：
1 ResourceManager，負責資源的申請和釋放、管理slot（Flink叢集中最細粒度的資源管理單元）。Flink實現了多種RM的實現方案以適配多種資源管理框架，如yarn、mesos、k8s或standalone。在standalone模式下，RM只能分配slot，而不能啟動新的TM。注意：這裡所說的RM跟Yarn的RM不是一個東西，這裡的RM是JM中的一個獨立的服務。
2 Dispatcher，提供Flink提交任務的rest介面，為每個提交的任務啟動新的JobMaster，為所有的任務提供web ui，查詢任務執行狀態。
3 JobMaster，負責管理執行單個JobGraph，多個任務可以同時在一個叢集中啟動，每個都有自己的JobMaster。注意這裡的JobMaster和JobManager的區別。
TaskManager
TM也叫做worker，用於執行資料流圖中的任務，快取並交換資料。叢集至少有一個TM，TM中最小的資源管理單元是Slot，每個Slot可以執行一個Task，因此TM中slot的數量就代表同時可以執行任務的數量。
2 Slot與資源管理
每個TM是一個獨立的JVM程式，內部基於獨立的執行緒執行一個或多個任務。TM為了控制每個任務的執行資源，使用task slot來進行管理。每個task slot代表TM中的一部分固定的資源，比如一個TM有3個slot，每個slot將會得到TM的1/3記憶體資源。不同任務之間不會進行資源的搶佔，注意GPU目前沒有進行隔離，目前slot只能劃分記憶體資源。
比如下面的資料流圖，在擴充套件成並行流圖後，同一的task可能分拆成多個任務並行在叢集中執行。操作鏈可以把多個不同的任務進行合併，從而支援在一個執行緒中先後執行多個任務，無需頻繁釋放申請執行緒。同時操作鏈還可以統一快取資料，增加資料處理吞吐量，降低處理延遲。
在Flink中，想要不同子任務合併需要滿足幾個條件：下游節點的入邊是1（保證不存在資料的shuffle）；子任務的上下游不為空；連線策略總是ALWAYS；分割槽型別為ForwardPartitioner；並行度一致；當前Flink開啟Chain特性。
在叢集中的執行圖可能如下：
Flink也支援slot的共享，即把不同任務根據任務的依賴關係分配到同一個Slot中。這樣帶來幾個好處：方便統計當前任務所需的最大資源配置（某個子任務的最大並行度）；避免Slot的過多申請與釋放，提升Slot的使用效率。
通過Slot共享，就有可能某個Slot中包含完整的任務執行鏈路。
3 應用執行
一個Flink應用就是使用者編寫的main函式，其中可能包含一個或多個Flink的任務。這些任務可以在本地執行，也可以在遠端叢集啟動，叢集既可以長期執行，也支援獨立啟動。下面是目前支援的任務提交方案：
Session叢集
生命週期：叢集事先建立並長期執行，客戶端提交任務時與該叢集連線。即使所有任務都執行完畢，叢集仍會保持執行，除非手動停止。因此叢集的生命週期與任務無關。
資源隔離：TM的slot由RM申請，當上面的任務執行完畢會自動進行釋放。由於多個任務會共享相同的叢集，因此任務間會存在競爭，比如網路頻寬等。如果某個TM掛掉，上面的所有任務都會失敗。
其他方面：擁有提前建立的叢集，可以避免每次使用的時候過多考慮叢集問題。比較適合那些執行時間很短，對啟動時間有比較高的要求的場景，比如互動式查詢分析。
Per Job叢集
生命週期：為每個提交的任務單獨建立一個叢集，客戶端在提交任務時，直接與ClusterManager溝通申請建立JM並在內部執行提交的任務。TM則根據任務執行需要的資源延遲申請。一旦任務執行完畢，叢集將會被回收。
資源隔離：任務如果出現致命問題，僅會影響自己的任務。
其他方面：由於RM需要申請和等待資源，因此啟動時間會稍長，適合單個比較大、長時間執行、需要保證長期的穩定性、不在乎啟動時間的任務。
Application叢集
生命週期：與Per Job類似，只是main()方法執行在叢集中。任務的提交程式很簡單，不需要啟動或連線叢集，而是直接把應用程式打包到資源管理系統中並啟動對應的EntryPoint，在EntryPoint中呼叫使用者程式的main()方法，解析生成JobGraph，然後啟動執行。叢集的生命週期與應用相同。
資源隔離：RM和Dispatcher是應用級別。