—— 圖片來自 《國家地理中文網》——
往期推薦：
Flink深入淺出：部署模式
Flink深入淺出：記憶體模型
Flink深入淺出：JDBC Source從理論到實戰
Flink深入淺出：Sql Gateway原始碼分析
Flink深入淺出：JDBC Connector原始碼分析
什么是Flink 之 架構篇
什么是Flink 之 應用篇
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是應用級別，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/170832.html
標籤：大數據