Flink深入淺出: 資源管理(v1.11)
—— 圖片來自 《國家地理中文網》——
往期推薦：
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是應用級別。
