web
用戶經過 DataStream API、DataSet API、SQL 和 Table API 編寫 Flink 任務,它會生成一個JobGraph。JobGraph 是由 source、map()、keyBy()/window()/apply() 和 Sink 等算子組成的。當 JobGraph 提交給 Flink 集羣后,可以以 Local、Standalone、Yarn 和 Kubernetes 四種模式運行。網絡
JobManager的功能主要有:多線程
將 JobGraph 轉換成 Execution Graph,最終將 Execution Graph 拿來運行;架構
Scheduler 組件負責 Task 的調度;app
Checkpoint Coordinator 組件負責協調整個任務的 Checkpoint,包括 Checkpoint 的開始和完成;框架
經過 Actor System 與 TaskManager 進行通訊;運維
其它的一些功能,例如 Recovery Metadata,用於進行故障恢復時,能夠從 Metadata 裏面讀取數據。spa
TaskManager 是負責具體任務的執行過程,在 JobManager 申請到資源以後開始啓動。TaskManager 裏面的主要組件有:線程
Memory & I/O Manager,即內存 I/O 的管理;blog
Network Manager,用來對網絡方面進行管理;
Actor system,用來負責網絡的通訊;
TaskManager 被分紅不少個 TaskSlot,每一個任務都要運行在一個 TaskSlot 裏面,TaskSlot 是調度資源裏的最小單位。
在介紹 Yarn 以前先簡單的介紹一下 Flink Standalone 模式。
在 Standalone 模式下,Master 和 TaskManager 能夠運行在同一臺機器上,也能夠運行在不一樣的機器上。
在 Master 進程中,Standalone ResourceManager 的做用是對資源進行管理。當用戶經過 Flink Cluster Client 將 JobGraph 提交給 Master 時,JobGraph 先通過 Dispatcher。
當 Dispatcher 收到客戶端的請求以後,生成一個 JobManager。接着 JobManager 進程向 Standalone ResourceManager 申請資源,最終再啓動 TaskManager。
TaskManager 啓動以後,會有一個註冊的過程,註冊以後 JobManager 再將具體的 Task 任務分發給這個 TaskManager 去執行。
以上就是一個 Standalone 任務的運行過程。
接下來總結一下 Flink 的基本架構和它在運行時的一些組件,具體以下:
Client:用戶經過 SQL 或者 API 的方式進行任務的提交,提交後會生成一個 JobGraph。
JobManager:JobManager 接受到用戶的請求以後,會對任務進行調度,而且申請資源啓動 TaskManager。
TaskManager:它負責一個具體 Task 的執行。TaskManager 向 JobManager 進行註冊,當 TaskManager 接收到 JobManager 分配的任務以後,開始執行具體的任務。
Yarn 模式在國內使用比較普遍,基本上大多數公司在生產環境中都使用過 Yarn 模式。首先介紹一下 Yarn 的架構原理,由於只有足夠了解 Yarn 的架構原理,才能更好的知道 Flink 是如何在 Yarn 上運行的。
Yarn 的架構原理如上圖所示,最重要的角色是 ResourceManager,主要用來負責整個資源的管理,Client 端是負責向 ResourceManager 提交任務。
用戶在 Client 端提交任務後會先給到 Resource Manager。Resource Manager 會啓動 Container,接着進一步啓動 Application Master,即對 Master 節點的啓動。當 Master 節點啓動以後,會向 Resource Manager 再從新申請資源,當 Resource Manager 將資源分配給 Application Master 以後,Application Master 再將具體的 Task 調度起來去執行。
Yarn 集羣中的組件包括:
ResourceManager (RM):ResourceManager (RM)負責處理客戶端請求、啓動/監控 ApplicationMaster、監控 NodeManager、資源的分配與調度,包含 Scheduler 和 Applications Manager。
ApplicationMaster (AM):ApplicationMaster (AM)運行在 Slave 上,負責數據切分、申請資源和分配、任務監控和容錯。
NodeManager (NM):NodeManager (NM)運行在 Slave 上,用於單節點資源管理、AM/RM通訊以及彙報狀態。
Container:Container 負責對資源進行抽象,包括內存、CPU、磁盤,網絡等資源。
以在 Yarn 上運行 MapReduce 任務爲例來說解下 Yarn 架構的交互原理:
首先,用戶編寫 MapReduce 代碼後,經過 Client 端進行任務提交。
ResourceManager 在接收到客戶端的請求後,會分配一個 Container 用來啓動 ApplicationMaster,並通知 NodeManager 在這個 Container 下啓動 ApplicationMaster。
ApplicationMaster 啓動後,向 ResourceManager 發起註冊請求。接着 ApplicationMaster 向 ResourceManager 申請資源。根據獲取到的資源,和相關的 NodeManager 通訊,要求其啓動程序。
一個或者多個 NodeManager 啓動 Map/Reduce Task。
NodeManager 不斷彙報 Map/Reduce Task 狀態和進展給 ApplicationMaster。
當全部 Map/Reduce Task 都完成時,ApplicationMaster 向 ResourceManager 彙報任務完成,並註銷本身。
Flink on Yarn 中的 Per Job 模式是指每次提交一個任務,而後任務運行完成以後資源就會被釋放。在瞭解了 Yarn 的原理以後,Per Job 的流程也就比較容易理解了,具體以下:
首先 Client 提交 Yarn App,好比 JobGraph 或者 JARs。
接下來 Yarn 的 ResourceManager 會申請第一個 Container。這個 Container 經過 Application Master 啓動進程,Application Master 裏面運行的是 Flink 程序,即 Flink-Yarn ResourceManager 和 JobManager。
最後 Flink-Yarn ResourceManager 向 Yarn ResourceManager 申請資源。當分配到資源後,啓動 TaskManager。TaskManager 啓動後向 Flink-Yarn ResourceManager 進行註冊,註冊成功後 JobManager 就會分配具體的任務給 TaskManager 開始執行。
在 Per Job 模式中,執行完任務後整個資源就會釋放,包括 JobManager、TaskManager 都所有退出。而 Session 模式則不同,它的 Dispatcher 和 ResourceManager 是能夠複用的。Session 模式下,當 Dispatcher 在收到請求以後,會啓動 JobManager(A),讓 JobManager(A) 來完成啓動 TaskManager,接着會啓動 JobManager(B) 和對應的 TaskManager 的運行。當 A、B 任務運行完成後,資源並不會釋放。Session 模式也稱爲多線程模式,其特色是資源會一直存在不會釋放,多個 JobManager 共享一個 Dispatcher,並且還共享 Flink-YARN ResourceManager。
Session 模式和 Per Job 模式的應用場景不同。Per Job 模式比較適合那種對啓動時間不敏感,運行時間較長的任務。Seesion 模式適合短期運行的任務,通常是批處理任務。若用 Per Job 模式去運行短期的任務,那就須要頻繁的申請資源,運行結束後,還須要資源釋放,下次還需再從新申請資源才能運行。顯然,這種任務會頻繁啓停的狀況不適用於 Per Job 模式,更適合用 Session 模式。
Yarn 模式的優勢有:
資源的統一管理和調度。Yarn 集羣中全部節點的資源(內存、CPU、磁盤、網絡等)被抽象爲 Container。計算框架須要資源進行運算任務時須要向 Resource Manager 申請 Container,Yarn 按照特定的策略對資源進行調度和進行 Container 的分配。Yarn 模式能經過多種任務調度策略來利用提升集羣資源利用率。例如 FIFO Scheduler、Capacity Scheduler、Fair Scheduler,並能設置任務優先級。
資源隔離。Yarn 使用了輕量級資源隔離機制 Cgroups 進行資源隔離以免相互干擾,一旦 Container 使用的資源量超過事先定義的上限值,就將其殺死。
自動 failover 處理。例如 Yarn NodeManager 監控、Yarn ApplicationManager 異常恢復。
Yarn 模式雖然有很多優勢,可是也有諸多缺點,例如運維部署成本較高,靈活性不夠。
關於 Flink on Yarn 的實踐在社區官網上面有不少課程,例如:《Flink 安裝部署、環境配置及運行應用程序》 和 《客戶端操做》都是基於 Yarn 進行講解的,這裏就再也不贅述。
社區官網: https://ververica.cn/developers/flink-training-course1/