Flink 核心元件 內部原理 多圖剖析

一、Flink 整體架構

Flink 叢集整體遵循 Master ，Worker 這樣的架構模式。

JobManager 是管理節點，有以下幾個職責：

• 接受 application，包含 StreamGraph（DAG），JobGraph（優化過的）和 JAR，將 JobGraph 轉換為 Execution Graph
• 申請資源，排程任務，執行任務，儲存作業的後設資料，如Checkpoint
• 協調各個 Task 的 Checkpoint；

TaskManager 是工作節點，負責資料交換，跑多個執行緒的 task，執行任務。

Client 是客戶端，接收使用者提交的 jar 包，產生一個 JobGraph 物件，提交到 JobManager。如果成功提交會返回一個 JobClient，用來和 JobManager 通訊獲得任務執行的狀態。

二、JobManager 內部組成原理

1. 負責 Checkpoint 的協調，通過定時做快照的方式記錄任務狀態資訊；
2. Job Dispatch 負責接收客戶端傳送過來的 JobGraph 物件（DAG），並且在內部生成 ExecutionGraph（物理執行圖）；
3. 將作業拆分成 Task，部署到不同的 TaskManager 上去執行；ctorSystem 是 基於 akka 實現的一個通訊模組，負責節點之間的通訊，如 Client 和 JobManager 之間，JobManager 和 TaskManager 之間的通訊；
4. 負責資源管理，對於不同的部署模式，有相應的 ResourceManager 的實現；
5. TaskManager 啟動時，會向 JobManager 註冊自己，並時刻和 JobManager 保持心跳。

三、TaskManager 內部原理

1. TaskManager 是作為一個虛擬機器程式存在，TaskManager 啟動的時候，會向 JobManager 註冊自己；
2. JobManager 提交作業的時候，TaskManager 會啟動 Task 執行緒將 Job 執行起來，TaskManager 裡面有執行緒池負責執行緒的排程執行。
3. 在 Flink 內部也會有類似 Spark 或者 MapReduce 節點 shuffle 的過程，比如進行了一個 GroupByKey 的操作，就會涉及到資料的互動；
   Network Manager 是基於 Netty 實現的一個資料傳輸模組；
4. 而節點和節點之間的通訊是基於 akka 實現的 Actor System，來進行遠端的 rpc 通訊；
5. Memory Management 是記憶體管理模組，當資料進來時，負責申請記憶體來執行任務。

TaskManager 負責資料的傳輸（重點說明）

在一個執行的application中，它的tasks在持續交換資料。TaskManager負責做資料傳輸。

TaskManager的網路元件首先從緩衝buffer中收集records，然後再傳送。也就是說，records並不是一個接一個的傳送，而是先放入緩衝，然後再以batch的形式傳送。這個技術可以高效使用網路資源，並達到高吞吐。

每個TaskManager有一組網路緩衝池（預設每個buffer是32KB），用於傳送與接受資料。

如傳送端和接收端位於不同的TaskManager程式中，則它們需要通過作業系統的網路棧進行交流。

流應用需要以管道的模式進行資料交換，也就是說，每對TaskManager會維持一個永久的TCP連線用於做資料交換。

在shuffle連線模式下（多個sender與多個receiver），每個sender task需要向每個receiver task，此時TaskManager需要為每個receiver task都分配一個緩衝區。下圖展示了此架構：

在上圖中，有四個sender 任務，對於每個sender，都需要有至少四個network buffer用於向每個receiver傳送資料。

每個receiver都需要有至少四個buffer用於接收資料。

TaskManager之間的buffer以多路複用的方式使用同一網路連線。為了提供平滑的資料管道型的資料交換，一個TaskManager必須能提供足夠的緩衝，以服務所有並行的出入連線。

對於shuffle或broadcast 連線，每個傳送任務和每個接受任務之間都需要一個buffer。Flink的預設網路緩衝配置足夠適用與小型與中型的叢集任務。對於大型的叢集任務，需要對此配置進行調優。

若sender與receiver任務都執行在同一個TaskManager程式，則sender任務會將傳送的條目做序列化，並存入一個位元組緩衝。然後將緩衝放入一個佇列，直到佇列被填滿。Receiver任務從佇列中獲取緩衝，並反序列化輸入的條目。所以，在同一個TaskManager內，任務之間的資料傳輸並不經過網路互動。

四、Client 內部原理

Client 是客戶端，當使用者寫好一個 Flink 的程式之後，會用 bin/flink run 這樣的方式去提交 jar 包。

然後會啟動一個 Client 的程式，找到 jar 包中的 main 方法，建立 Context Environment （執行環境），把程式碼解析成 JobGraph （有向無環圖表示的作業），
向 JobManager 提交 JobGraph ，並傳遞使用者提交的 jar 包。

當程式部署在 jarn session 或者 kerbernetes Session 的時候，客戶端也會進行部署的操作。

五、JobGraph

不管使用者寫的程式是 DataStream Api，DateSet Api，或者是 Flink SQL，都會打成 jar 包，jar 包中會寫入 main 方法的類，Client 程式啟動的時候就會執行 main 方法，解析出程式中所表達的邏輯，生成 StreamGraph，再優化生成 JobGraph，再提交到 JobManager。

這裡說的 JobGraph 其實就是在 Flink UI 介面上看到的有向無環圖，如下圖：

另外，JobGraph 也是對叢集元件的一個解耦過程，不管什麼程式最終都生成 JobGraph ，JobGraph 作為 客戶端和 JobManager 提交的規範。

寫在最後

歡迎大家加入我的微信群，大家正在共建一個大資料技術文件，一起提升一起學習，為明年跳槽準備