一、Flink 整體架構(gòu)

Flink 集群整體遵循 Master ，Worker 這樣的架構(gòu)模式。

JobManager 是管理節(jié)點，有以下幾個職責(zé)：

接受 application，包含 StreamGraph（DAG），JobGraph（優(yōu)化過的）和 JAR，將 JobGraph 轉(zhuǎn)換為 Execution Graph
申請資源，調(diào)度任務(wù)，執(zhí)行任務(wù)，保存作業(yè)的元數(shù)據(jù)，如Checkpoint
協(xié)調(diào)各個 Task 的 Checkpoint。

TaskManager 是工作節(jié)點，負(fù)責(zé)數(shù)據(jù)交換，跑多個線程的 task，執(zhí)行任務(wù)。

Client 是客戶端，接收用戶提交的 jar 包，產(chǎn)生一個 JobGraph 對象，提交到 JobManager。如果成功提交會返回一個 JobClient，用來和 JobManager 通信獲得任務(wù)執(zhí)行的狀態(tài)。

二、JobManager 內(nèi)部組成原理

負(fù)責(zé) Checkpoint 的協(xié)調(diào)，通過定時做快照的方式記錄任務(wù)狀態(tài)信息；
Job Dispatch 負(fù)責(zé)接收客戶端發(fā)送過來的 JobGraph 對象（DAG），并且在內(nèi)部生成 ExecutionGraph（物理執(zhí)行圖）；
將作業(yè)拆分成 Task，部署到不同的 TaskManager 上去執(zhí)行；ctorSystem 是基于 akka 實現(xiàn)的一個通信模塊，負(fù)責(zé)節(jié)點之間的通信，如 Client 和 JobManager 之間，JobManager 和 TaskManager 之間的通信；
負(fù)責(zé)資源管理，對于不同的部署模式，有相應(yīng)的 ResourceManager 的實現(xiàn)；
TaskManager 啟動時，會向 JobManager 注冊自己，并時刻和 JobManager 保持心跳。

三、TaskManager 內(nèi)部原理

TaskManager 是作為一個虛擬機進程存在，TaskManager 啟動的時候，會向 JobManager 注冊自己；
JobManager 提交作業(yè)的時候，TaskManager 會啟動 Task 線程將 Job 運行起來，TaskManager 里面有線程池負(fù)責(zé)線程的調(diào)度執(zhí)行。
在 Flink 內(nèi)部也會有類似 Spark 或者 MapReduce 節(jié)點 shuffle 的過程，比如進行了一個 GroupByKey 的操作，就會涉及到數(shù)據(jù)的交互；Network Manager 是基于 Netty 實現(xiàn)的一個數(shù)據(jù)傳輸模塊；
而節(jié)點和節(jié)點之間的通信是基于 akka 實現(xiàn)的 Actor System，來進行遠(yuǎn)程的 rpc 通信；
Memory Management 是內(nèi)存管理模塊，當(dāng)數(shù)據(jù)進來時，負(fù)責(zé)申請內(nèi)存來運行任務(wù)。

TaskManager?如何負(fù)責(zé)數(shù)據(jù)傳輸

在一個運行的application中，它的tasks在持續(xù)交換數(shù)據(jù)。TaskManager負(fù)責(zé)做數(shù)據(jù)傳輸。

TaskManager的網(wǎng)絡(luò)組件首先從緩沖buffer中收集records，然后再發(fā)送。也就是說，records并不是一個接一個的發(fā)送，而是先放入緩沖，然后再以batch的形式發(fā)送。這個技術(shù)可以高效使用網(wǎng)絡(luò)資源，并達(dá)到高吞吐。

每個TaskManager有一組網(wǎng)絡(luò)緩沖池（默認(rèn)每個buffer是32KB），用于發(fā)送與接受數(shù)據(jù)。

如發(fā)送端和接收端位于不同的TaskManager進程中，則它們需要通過操作系統(tǒng)的網(wǎng)絡(luò)棧進行交流。

流應(yīng)用需要以管道的模式進行數(shù)據(jù)交換，也就是說，每對TaskManager會維持一個永久的TCP連接用于做數(shù)據(jù)交換。

在shuffle連接模式下（多個sender與多個receiver），每個sender task需要向每個receiver task，此時TaskManager需要為每個receiver task都分配一個緩沖區(qū)。下圖展示了此架構(gòu)：

在上圖中，有四個sender 任務(wù)，對于每個sender，都需要有至少四個network buffer用于向每個receiver發(fā)送數(shù)據(jù)。

每個receiver都需要有至少四個buffer用于接收數(shù)據(jù)。

TaskManager之間的buffer以多路復(fù)用的方式使用同一網(wǎng)絡(luò)連接。為了提供平滑的數(shù)據(jù)管道型的數(shù)據(jù)交換，一個TaskManager必須能提供足夠的緩沖，以服務(wù)所有并行的出入連接。

對于shuffle或broadcast 連接，每個發(fā)送任務(wù)和每個接受任務(wù)之間都需要一個buffer。Flink的默認(rèn)網(wǎng)絡(luò)緩沖配置足夠適用與小型與中型的集群任務(wù)。對于大型的集群任務(wù)，需要對此配置進行調(diào)優(yōu)。

若sender與receiver任務(wù)都運行在同一個TaskManager進程，則sender任務(wù)會將發(fā)送的條目做序列化，并存入一個字節(jié)緩沖。然后將緩沖放入一個隊列，直到隊列被填滿。Receiver任務(wù)從隊列中獲取緩沖，并反序列化輸入的條目。所以，在同一個TaskManager內(nèi)，任務(wù)之間的數(shù)據(jù)傳輸并不經(jīng)過網(wǎng)絡(luò)交互。

四、Client 內(nèi)部原理

Client 是客戶端，當(dāng)用戶寫好一個 Flink 的程序之后，會用 bin/flink run 這樣的方式去提交 jar 包。

然后會啟動一個 Client 的進程，找到 jar 包中的 main 方法，創(chuàng)建 Context Environment （執(zhí)行環(huán)境），把代碼解析成 JobGraph （有向無環(huán)圖表示的作業(yè)），向 JobManager 提交 JobGraph ，并傳遞用戶提交的 jar 包。

當(dāng)程序部署在 jarn session 或者 kerbernetes Session 的時候，客戶端也會進行部署的操作。

五、JobGraph

不管用戶寫的程序是 DataStream Api，DateSet Api，或者是 Flink SQL，都會打成 jar 包，jar 包中會寫入 main 方法的類，Client 進程啟動的時候就會執(zhí)行 main 方法，解析出程序中所表達(dá)的邏輯，生成 StreamGraph，再優(yōu)化生成 JobGraph，再提交到 JobManager。

這里說的 JobGraph 其實就是在 Flink UI 界面上看到的有向無環(huán)圖，如下圖：

另外，JobGraph 也是對集群組件的一個解耦過程，不管什么程序最終都生成 JobGraph ，JobGraph 作為客戶端和 JobManager 提交的規(guī)范。

--end--

掃描下方二維碼
添加好友，備注【交流】
可私聊交流，也可進資源豐富學(xué)習(xí)群

Flink 核心組件原理 多圖剖析

一、Flink 整體架構(gòu)

二、JobManager 內(nèi)部組成原理

三、TaskManager 內(nèi)部原理

TaskManager?如何負(fù)責(zé)數(shù)據(jù)傳輸

四、Client 內(nèi)部原理

五、JobGraph

--end--

Flink 核心組件原理多圖剖析

二、JobManager 內(nèi)部組成原理

三、TaskManager 內(nèi)部原理