Flink入門 04.原理初探

1   Flink角色分工

在實際生產中，Flink 都是以集羣在運行，在運行的過程中包含了兩類進程。

• JobManager

  它扮演的是集羣管理者的角色，負責調度任務、協調 checkpoints、協調故障恢復、收集 Job 的狀態信息，並管理 Flink 集羣中的從節點 TaskManager。

• TaskManager

  實際負責執行計算的 Worker，在其上執行 Flink Job 的一組 Task；TaskManager 還是所在節點的管理員，它負責把該節點上的服務器信息比如內存、磁盤、任務運行情況等向 JobManager 彙報。

• Client：

  用戶在提交編寫好的 Flink 工程時，會先創建一個客戶端再進行提交，這個客戶端就是 Client

2   Flink執行流程

https://blog.csdn.net/sxiaobei/article/details/80861070

https://blog.csdn.net/super_wj0820/article/details/90726768

https://ci.apache.org/projects/flink/flink-docs-release-1.11/ops/deployment/yarn_setup.html

2.1   Standalone版

2.2   On Yarn版

1. Client向HDFS上傳Flink的Jar包和配置

2. Client向Yarn ResourceManager提交任務並申請資源

3. ResourceManager分配Container資源並啓動ApplicationMaster,然後AppMaster加載Flink的Jar包和配置構建環境,啓動JobManager

4. ApplicationMaster向ResourceManager申請工作資源,NodeManager加載Flink的Jar包和配置構建環境並啓動TaskManager

5. TaskManager啓動後向JobManager發送心跳包，並等待JobManager向其分配任務

3   Flink Streaming Dataflow

官網關於Flink的詞彙表

https://ci.apache.org/projects/flink/flink-docs-release-1.11/concepts/glossary.html#glossary

3.1   Dataflow、Operator、Partition、SubTask、Parallelism

1. Dataflow:Flink程序在執行的時候會被映射成一個數據流模型

2. Operator:數據流模型中的每一個操作被稱作Operator,Operator分爲:Source/Transform/Sink

3. Partition:數據流模型是分佈式的和並行的,執行中會形成1~n個分區

4. Subtask:多個分區任務可以並行,每一個都是獨立運行在一個線程中的,也就是一個Subtask

5. Parallelism:並行度,就是可以同時真正執行的subtask數(分區數)

3.2   Operator傳遞模式

數據在兩個operator(算子)之間傳遞的時候有兩種模式：

1. One to One模式

   兩個operator用此模式傳遞的時候，會保持數據的分區數和數據的排序；如上圖中的Source1到Map1，它就保留的Source的分區特性，以及分區元素處理的有序性。--類似於Spark中的窄依賴

2. Redistributing 模式：

   這種模式會改變數據的分區數；每一個operator subtask會根據選擇transformation把數據發送到不同的目標subtasks,比如keyBy()會通過hashcode重新分區,broadcast()和rebalance()方法會隨機重新分區。--類似於Spark中的寬依賴

3.3   Operator Chain

客戶端在提交任務的時候會對Operator進行優化操作，能進行合併的Operator會被合併爲一個Operator，

合併後的Operator稱爲Operator chain，實際上就是一個執行鏈，每個執行鏈會在TaskManager上一個獨立的線程中執行--就是SubTask。

3.4   TaskSlot And Slot Sharing

• 任務槽(TaskSlot)

  image-20210224144810752

  每個TaskManager是一個JVM的進程, 爲了控制一個TaskManager(worker)能接收多少個task，Flink通過Task Slot來進行控制。TaskSlot數量是用來限制一個TaskManager工作進程中可以同時運行多少個工作線程，TaskSlot 是一個 TaskManager 中的最小資源分配單位，一個 TaskManager 中有多少個 TaskSlot 就意味着能支持多少併發的Task處理。

  Flink將進程的內存進行了劃分到多個slot中，內存被劃分到不同的slot之後可以獲得如下好處:

• TaskManager最多能同時併發執行的子任務數是可以通過TaskSolt數量來控制的

• TaskSolt有獨佔的內存空間，這樣在一個TaskManager中可以運行多個不同的作業，作業之間不受影響。

• 槽共享(Slot Sharing)

  Flink允許子任務共享插槽，即使它們是不同任務(階段)的子任務(subTask)，只要它們來自同一個作業。

  比如圖左下角中的map和keyBy和sink 在一個 TaskSlot 裏執行以達到資源共享的目的。

  允許插槽共享有兩個主要好處：

  注意:

• slot是靜態的概念，是指taskmanager具有的併發執行能力

• parallelism是動態的概念，是指程序運行時實際使用的併發能力

• 資源分配更加公平，如果有比較空閒的slot可以將更多的任務分配給它。

• 有了任務槽共享，可以提高資源的利用率。

4 Flink運行時組件

Flink運行時架構主要包括四個不同的組件，它們會在運行流處理應用程序時協同工作：

• 作業管理器（JobManager）：分配任務、調度checkpoint做快照

• 任務管理器（TaskManager）：主要幹活的

• 資源管理器（ResourceManager）：管理分配資源

• 分發器（Dispatcher）：方便遞交任務的接口，WebUI

因爲Flink是用Java和Scala實現的，所以所有組件都會運行在Java虛擬機上。每個組件的職責如下：

1. 作業管理器（JobManager）

• 控制一個應用程序執行的主進程，也就是說，每個應用程序都會被一個不同的JobManager 所控制執行。

• JobManager 會先接收到要執行的應用程序，這個應用程序會包括：作業圖（JobGraph）、邏輯數據流圖（logical dataflow graph）和打包了所有的類、庫和其它資源的JAR包。

• JobManager 會把JobGraph轉換成一個物理層面的數據流圖，這個圖被叫做“執行圖”（ExecutionGraph），包含了所有可以併發執行的任務。

• JobManager 會向資源管理器（ResourceManager）請求執行任務必要的資源，也就是任務管理器（TaskManager）上的插槽（slot）。一旦它獲取到了足夠的資源，就會將執行圖分發到真正運行它們的TaskManager上。而在運行過程中，JobManager會負責所有需要中央協調的操作，比如說檢查點（checkpoints）的協調。

任務管理器（TaskManager）

• Flink中的工作進程。通常在Flink中會有多個TaskManager運行，每一個TaskManager都包含了一定數量的插槽（slots）。插槽的數量限制了TaskManager能夠執行的任務數量。

• 啓動之後，TaskManager會向資源管理器註冊它的插槽；收到資源管理器的指令後，TaskManager就會將一個或者多個插槽提供給JobManager調用。JobManager就可以向插槽分配任務（tasks）來執行了。

• 在執行過程中，一個TaskManager可以跟其它運行同一應用程序的TaskManager交換數據。

資源管理器（ResourceManager）

• 主要負責管理任務管理器（TaskManager）的插槽（slot），TaskManger 插槽是Flink中定義的處理資源單元。

• Flink爲不同的環境和資源管理工具提供了不同資源管理器，比如YARN、Mesos、K8s，以及standalone部署。

• 當JobManager申請插槽資源時，ResourceManager會將有空閒插槽的TaskManager分配給JobManager。如果ResourceManager沒有足夠的插槽來滿足JobManager的請求，它還可以向資源提供平臺發起會話，以提供啓動TaskManager進程的容器。

分發器（Dispatcher）

• 可以跨作業運行，它爲應用提交提供了REST接口。

• 當一個應用被提交執行時，分發器就會啓動並將應用移交給一個JobManager。

• Dispatcher也會啓動一個Web UI，用來方便地展示和監控作業執行的信息。

• Dispatcher在架構中可能並不是必需的，這取決於應用提交運行的方式。

5 Flink執行圖（ExecutionGraph）

由Flink程序直接映射成的數據流圖是StreamGraph，也被稱爲邏輯流圖，因爲它們表示的是計算邏輯的高級視圖。爲了執行一個流處理程序，Flink需要將邏輯流圖轉換爲物理數據流圖（也叫執行圖），詳細說明程序的執行方式。

Flink 中的執行圖可以分成四層：StreamGraph -> JobGraph -> ExecutionGraph -> 物理執行圖。

1. 原理介紹

• Flink執行executor會自動根據程序代碼生成DAG數據流圖

• Flink 中的執行圖可以分成四層：StreamGraph -> JobGraph -> ExecutionGraph -> 物理執行圖。

• StreamGraph：是根據用戶通過 Stream API 編寫的代碼生成的最初的圖。表示程序的拓撲結構。

• JobGraph：StreamGraph經過優化後生成了 JobGraph，提交給 JobManager 的數據結構。主要的優化爲，將多個符合條件的節點 chain 在一起作爲一個節點，這樣可以減少數據在節點之間流動所需要的序列化/反序列化/傳輸消耗。

• ExecutionGraph：JobManager 根據 JobGraph 生成ExecutionGraph。ExecutionGraph是JobGraph的並行化版本，是調度層最核心的數據結構。

• 物理執行圖：JobManager 根據 ExecutionGraph 對 Job 進行調度後，在各個TaskManager 上部署 Task 後形成的“圖”，並不是一個具體的數據結構。

簡單理解：

• StreamGraph：最初的程序執行邏輯流程，也就是算子之間的前後順序--在Client上生成

• JobGraph：將OneToOne的Operator合併爲OperatorChain--在Client上生成

• ExecutionGraph：將JobGraph根據代碼中設置的並行度和請求的資源進行並行化規劃!--在JobManager上生成

• 物理執行圖：將ExecutionGraph的並行計劃,落實到具體的TaskManager上，將具體的SubTask落實到具體的TaskSlot內進行運行。

---

歡迎關注微信公衆號：大數據AI

本文分享自微信公衆號 - 大數據AI（songxt1990）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。