快速入門Flink(3)——Flink運作架構（面試必問，建議收藏）

        上一篇教大家如何搭建一個Flink叢集，本篇部落格給大家講解一下Flink運作時架構（面試必問）

一、Flink運作時元件

1.1 作業管理器（JobManager）

1. 控制一個應用程式執行的主程序，也就是說，每個應用程式都會被一個不同的Jobmanager所控制執行
2. Jobmanager會先接收到要執行的應用程式，這個應用程式會包括：作業圖（ Job Graph）、邏輯資料流圖（ ogical dataflow graph）和打包了所有的類、庫和其它資源的JAR包。
3. Jobmanager會把 Jobgraph轉換成一個實體層面的資料流圖，這個圖被叫做“執行圖”（Executiongraph),包含了所有可以并發執行的任務。Job Manager會向資料總管（ Resourcemanager）請求執行任務必要的資源，也就是（任務管理器（ Taskmanager）上的插槽slot。一旦它擷取到了足夠的資源，就會将執行圖分發到真正運作它們的 Taskmanager上。而在運作過程中Jobmanagera會負責所有需要中央協調的操作，比如說檢查點（ checkpoints的協調。

1.2 任務管理器（Taskmanager）

1. Flink中的工作程序。通常在 Flink中會有多個 Taskmanageria運作，每個 Taskmanageri都包含了一定數量的插槽（ slots）。插槽的數量限制了Taskmanageri能夠執行的任務數量。
2. 啟動之後， Taskmanager會向資料總管注冊它的插槽；收到資料總管的指令後， Taskmanageri就會将一個或者多個插槽提供給Jobmanageri調用。 Jobmanager就可以向插槽配置設定任務（ tasks）來執行了。
3. 在執行過程中，一個 Taskmanagera可以跟其它運作同一應用程式的Taskmanager交換資料。

1.3 資料總管（Resource Manager)

1. 主要負責管理任務管理器（ Task Manager）的插槽（slot)Taskmanger插槽是 Flink中定義的處理資源單元。
2. Flink為不同的環境和資源管理工具提供了不同資料總管，比如YARNMesos、K8s，以及 standalone部署。
3. 當 Jobmanagerl申請插槽資源時， Resourcemanager會将有空閑插槽的Taskmanager？配置設定給Jobmanager。如果 Resourcemanagery沒有足夠的插槽來滿足 Jobmanagerf的請求，它還可以向資源提供平台發起會話，以提供啟動 Taskmanageri程序的容器。

1.4 分發器（Dispatcher）

1. 可以跨作業運作，它為應用送出提供了REST接口。
2. 當一個應用被送出執行時，分發器就會啟動并将應用移交給Jobmanage
3. Dispatcher他會啟動一個WebUi，用來友善地展示和監控作業執行的資訊。
4. Dispatcher？在架構中可能并不是必需的，這取決于應用送出運的方式。

二、任務送出流程

1. 送出應用
2. 啟動并送出應用
3. 請求slots
4. 任務啟動
5. 注冊slots
6. 發出提供slot的指令
7. 提供slots
8. 送出要在slots中執行的任務
9. 交換資料

2.1 任務送出流程（YARN）

1. Flink 任務送出後，Client 向 HDFS 上傳 Flink 的 Jar 包和配置
2. 随後向 Yarn ResourceManager 提 交 任 務 ，ResourceManager 分 配 Container 資 源 并 通 知 對 應 的 NodeManager 啟 動
3. ApplicationMaster，ApplicationMaster 啟動後加載 Flink 的 Jar 包 和 配 置 構 建 環 境
4. 然 後 啟 動 JobManager ， 之 後 ApplicationMaster 向 ResourceManager 申 請 資 源 啟 動 TaskManager
5. ResourceManager 分 配 Container 資 源 後 ， 由 ApplicationMaster 通 知 資 源 所 在 節 點 的 NodeManager 啟動 TaskManager
6. NodeManager 加載 Flink 的 Jar 包和配置建構環境并啟動 TaskManager
7. TaskManager 啟動後向 JobManager 發送心跳包，并等待 JobManager 向其配置設定任務。

三、任務排程原理

3.1 TaskManager 和 Slots

1. Flink中每一個 Taskmanageri都是一個JMM程序，它可能會在獨立的線程上執行一個或多個 subtask
2. 為了控制一個 Taskmanageri能接收多少個task, Taskmanager通過 task slot來進行控制（一個 Taskmanager至少有一個slot）

3. 預設情況下，Fink允許子任務共享slot，即使它們是不同任務的子任務。這樣的結果是，一個slot可以儲存作業的整個管道。

4. Task Slot是靜态的概念，是指 Taskmanager具有的并發執行能力

3.2 程式與資料流（DataFlow）

1. 所有的 Flink程式都是由三部分組成的： Source、 Transformation和Sink
2. Source負責讀取資料源， Transformation利用各種算子進行處理加工，Sink負責輸出
3. 在運作時， Flink上運作的程式會被映射成“邏輯資料流”（ dataflows),它包含了這三部分
4. 每一個 dataflow以一個或多個 Sources開始以一個或多個 sinks結束。 dataflow類以于任意的有向無環圖（DAG)
5. 在大部分情況下，程式中的轉換運算（ transformations）跟 dataflow中的算子

3.3 執行圖（ExecutionGraph）

Flink中的執行圖可以分成四層：

Streamgraph -> Jobgraph -> Executiongraph -> 實體執行圖

1. Streamgraph：是根據使用者通過 Stream API編寫的代碼生成的最初的圖。用來表示程式的拓撲結構。
2. Jobgraph: Streamgraph經過優化後生成了 Jobgraph，送出給 Jobmanager的資料結構。主要的優化為，将多個符合條件的節點 chain在一起作為一個節點Execution Graph: Jobmanager根據 Jobgraph生成
3. ExecutiongraphExecution Graph是 Job Graphi的并行化版本，是排程層最核心的資料結構。
4. 實體執行圖： Jobmanager根據 Executiongraph對Job進行排程後，在各個Taskmanager上部署Task後形成的“圖”，并不是一個具體的資料結構。

   

3.4 并行度（Parallelism）

1. 特定算子的子任務（ subtask）的個數被稱之為其并行度（ parallelism)般情況下，一個 stream的并行度，可以認為就是其所有算子中最大的并行度。
2. 一個程式中，不同的算子可能具有不同的并行度
3. 算子之間傳輸資料的形式可以是 one-to-one( (forwarding）的模式也可以是redistributing的模式，具體是哪一種形式，取決于算子的種類
4. One-to-one: stream維護着分區以及元素的順序（比如 Sources和map之間）。這意味着map算子的子任務看到的元素的個數以及順序跟 Source算子的子任務生産的元素的個數、順序相同。map、 fliter.、 flatmap等算子都是 one-to-one的對應關系
5. Redistributing: stream的分區會發生改變。每一個算子的子任務依據所選擇的transformation發送資料到不同的目标任務。例如， keyby基于 hash Code重分區、而 broadcast和 rebalance會随機重新分區，這些算子都會引起distributer過程，而 redistribute過程就類似于 Spark中的 shuffle過程。

   

3.5 任務鍊（Operator Chains）

1. Flink采用了一種稱為任務鍊的優化技術，可以在特定條件下減少本地通信的開銷。為了滿足任務鍊的要求，必須将兩個或多個算子設為相同的并行度，并通過本地轉發（ ocal forward）的方式進行連接配接
2. 相同并行度的one-to-one操作， Flink這樣相連的算子連結在一起形成一個task，原來的算子成為裡面的 subtask并行度相同、并且是one-to-one操作，兩個條件缺一不可