Flink入門(mén) 04.原理初探

1   Flink角色分工

在實(shí)際生產(chǎn)中，F(xiàn)link 都是以集群在運(yùn)行，在運(yùn)行的過(guò)程中包含了兩類(lèi)進(jìn)程。

• JobManager

  它扮演的是集群管理者的角色，負(fù)責(zé)調(diào)度任務(wù)、協(xié)調(diào) checkpoints、協(xié)調(diào)故障恢復(fù)、收集 Job 的狀態(tài)信息，并管理 Flink 集群中的從節(jié)點(diǎn) TaskManager。

• TaskManager

  實(shí)際負(fù)責(zé)執(zhí)行計(jì)算的 Worker，在其上執(zhí)行 Flink Job 的一組 Task；TaskManager 還是所在節(jié)點(diǎn)的管理員，它負(fù)責(zé)把該節(jié)點(diǎn)上的服務(wù)器信息比如內(nèi)存、磁盤(pán)、任務(wù)運(yùn)行情況等向 JobManager 匯報(bào)。

• Client：

  用戶(hù)在提交編寫(xiě)好的 Flink 工程時(shí)，會(huì)先創(chuàng)建一個(gè)客戶(hù)端再進(jìn)行提交，這個(gè)客戶(hù)端就是 Client

2   Flink執(zhí)行流程

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提交任務(wù)并申請(qǐng)資源

3. ResourceManager分配Container資源并啟動(dòng)ApplicationMaster,然后AppMaster加載Flink的Jar包和配置構(gòu)建環(huán)境,啟動(dòng)JobManager

4. ApplicationMaster向ResourceManager申請(qǐng)工作資源,NodeManager加載Flink的Jar包和配置構(gòu)建環(huán)境并啟動(dòng)TaskManager

5. TaskManager啟動(dòng)后向JobManager發(fā)送心跳包，并等待JobManager向其分配任務(wù)

3   Flink Streaming Dataflow

官網(wǎng)關(guān)于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程序在執(zhí)行的時(shí)候會(huì)被映射成一個(gè)數(shù)據(jù)流模型

2. Operator:數(shù)據(jù)流模型中的每一個(gè)操作被稱(chēng)作Operator,Operator分為:Source/Transform/Sink

3. Partition:數(shù)據(jù)流模型是分布式的和并行的,執(zhí)行中會(huì)形成1~n個(gè)分區(qū)

4. Subtask:多個(gè)分區(qū)任務(wù)可以并行,每一個(gè)都是獨(dú)立運(yùn)行在一個(gè)線程中的,也就是一個(gè)Subtask

5. Parallelism:并行度,就是可以同時(shí)真正執(zhí)行的subtask數(shù)(分區(qū)數(shù))

3.2   Operator傳遞模式

數(shù)據(jù)在兩個(gè)operator(算子)之間傳遞的時(shí)候有兩種模式：

1. One to One模式

   兩個(gè)operator用此模式傳遞的時(shí)候，會(huì)保持?jǐn)?shù)據(jù)的分區(qū)數(shù)和數(shù)據(jù)的排序；如上圖中的Source1到Map1，它就保留的Source的分區(qū)特性，以及分區(qū)元素處理的有序性。--類(lèi)似于Spark中的窄依賴(lài)

2. Redistributing 模式：

   這種模式會(huì)改變數(shù)據(jù)的分區(qū)數(shù)；每一個(gè)operator subtask會(huì)根據(jù)選擇transformation把數(shù)據(jù)發(fā)送到不同的目標(biāo)subtasks,比如keyBy()會(huì)通過(guò)hashcode重新分區(qū),broadcast()和rebalance()方法會(huì)隨機(jī)重新分區(qū)。--類(lèi)似于Spark中的寬依賴(lài)

3.3   Operator Chain

客戶(hù)端在提交任務(wù)的時(shí)候會(huì)對(duì)Operator進(jìn)行優(yōu)化操作，能進(jìn)行合并的Operator會(huì)被合并為一個(gè)Operator，

合并后的Operator稱(chēng)為Operator chain，實(shí)際上就是一個(gè)執(zhí)行鏈，每個(gè)執(zhí)行鏈會(huì)在TaskManager上一個(gè)獨(dú)立的線程中執(zhí)行--就是SubTask。

3.4   TaskSlot And Slot Sharing

• 任務(wù)槽(TaskSlot)

  

  每個(gè)TaskManager是一個(gè)JVM的進(jìn)程, 為了控制一個(gè)TaskManager(worker)能接收多少個(gè)task，F(xiàn)link通過(guò)Task Slot來(lái)進(jìn)行控制。TaskSlot數(shù)量是用來(lái)限制一個(gè)TaskManager工作進(jìn)程中可以同時(shí)運(yùn)行多少個(gè)工作線程，TaskSlot 是一個(gè) TaskManager 中的最小資源分配單位，一個(gè) TaskManager 中有多少個(gè) TaskSlot 就意味著能支持多少并發(fā)的Task處理。

  Flink將進(jìn)程的內(nèi)存進(jìn)行了劃分到多個(gè)slot中，內(nèi)存被劃分到不同的slot之后可以獲得如下好處:

• TaskManager最多能同時(shí)并發(fā)執(zhí)行的子任務(wù)數(shù)是可以通過(guò)TaskSolt數(shù)量來(lái)控制的

• TaskSolt有獨(dú)占的內(nèi)存空間，這樣在一個(gè)TaskManager中可以運(yùn)行多個(gè)不同的作業(yè)，作業(yè)之間不受影響。

• 槽共享(Slot Sharing)

  

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

  比如圖左下角中的map和keyBy和sink 在一個(gè) TaskSlot 里執(zhí)行以達(dá)到資源共享的目的。

  允許插槽共享有兩個(gè)主要好處：

  注意:

• slot是靜態(tài)的概念，是指taskmanager具有的并發(fā)執(zhí)行能力

• parallelism是動(dòng)態(tài)的概念，是指程序運(yùn)行時(shí)實(shí)際使用的并發(fā)能力

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

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

4 Flink運(yùn)行時(shí)組件

Flink運(yùn)行時(shí)架構(gòu)主要包括四個(gè)不同的組件，它們會(huì)在運(yùn)行流處理應(yīng)用程序時(shí)協(xié)同工作：

• 作業(yè)管理器（JobManager）：分配任務(wù)、調(diào)度checkpoint做快照

• 任務(wù)管理器（TaskManager）：主要干活的

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

• 分發(fā)器（Dispatcher）：方便遞交任務(wù)的接口，WebUI

因?yàn)镕link是用Java和Scala實(shí)現(xiàn)的，所以所有組件都會(huì)運(yùn)行在Java虛擬機(jī)上。每個(gè)組件的職責(zé)如下：

1. 作業(yè)管理器（JobManager）

• 控制一個(gè)應(yīng)用程序執(zhí)行的主進(jìn)程，也就是說(shuō)，每個(gè)應(yīng)用程序都會(huì)被一個(gè)不同的JobManager 所控制執(zhí)行。

• JobManager 會(huì)先接收到要執(zhí)行的應(yīng)用程序，這個(gè)應(yīng)用程序會(huì)包括：作業(yè)圖（JobGraph）、邏輯數(shù)據(jù)流圖（logical dataflow graph）和打包了所有的類(lèi)、庫(kù)和其它資源的JAR包。

• JobManager 會(huì)把JobGraph轉(zhuǎn)換成一個(gè)物理層面的數(shù)據(jù)流圖，這個(gè)圖被叫做“執(zhí)行圖”（ExecutionGraph），包含了所有可以并發(fā)執(zhí)行的任務(wù)。

• JobManager 會(huì)向資源管理器（ResourceManager）請(qǐng)求執(zhí)行任務(wù)必要的資源，也就是任務(wù)管理器（TaskManager）上的插槽（slot）。一旦它獲取到了足夠的資源，就會(huì)將執(zhí)行圖分發(fā)到真正運(yùn)行它們的TaskManager上。而在運(yùn)行過(guò)程中，JobManager會(huì)負(fù)責(zé)所有需要中央?yún)f(xié)調(diào)的操作，比如說(shuō)檢查點(diǎn)（checkpoints）的協(xié)調(diào)。

2. 任務(wù)管理器（TaskManager）

• Flink中的工作進(jìn)程。通常在Flink中會(huì)有多個(gè)TaskManager運(yùn)行，每一個(gè)TaskManager都包含了一定數(shù)量的插槽（slots）。插槽的數(shù)量限制了TaskManager能夠執(zhí)行的任務(wù)數(shù)量。

• 啟動(dòng)之后，TaskManager會(huì)向資源管理器注冊(cè)它的插槽；收到資源管理器的指令后，TaskManager就會(huì)將一個(gè)或者多個(gè)插槽提供給JobManager調(diào)用。JobManager就可以向插槽分配任務(wù)（tasks）來(lái)執(zhí)行了。

• 在執(zhí)行過(guò)程中，一個(gè)TaskManager可以跟其它運(yùn)行同一應(yīng)用程序的TaskManager交換數(shù)據(jù)。

3. 資源管理器（ResourceManager）

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

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

• 當(dāng)JobManager申請(qǐng)插槽資源時(shí)，ResourceManager會(huì)將有空閑插槽的TaskManager分配給JobManager。如果ResourceManager沒(méi)有足夠的插槽來(lái)滿(mǎn)足JobManager的請(qǐng)求，它還可以向資源提供平臺(tái)發(fā)起會(huì)話(huà)，以提供啟動(dòng)TaskManager進(jìn)程的容器。

4. 分發(fā)器（Dispatcher）

• 可以跨作業(yè)運(yùn)行，它為應(yīng)用提交提供了REST接口。

• 當(dāng)一個(gè)應(yīng)用被提交執(zhí)行時(shí)，分發(fā)器就會(huì)啟動(dòng)并將應(yīng)用移交給一個(gè)JobManager。

• Dispatcher也會(huì)啟動(dòng)一個(gè)Web UI，用來(lái)方便地展示和監(jiān)控作業(yè)執(zhí)行的信息。

• Dispatcher在架構(gòu)中可能并不是必需的，這取決于應(yīng)用提交運(yùn)行的方式。

5 Flink執(zhí)行圖（ExecutionGraph）

由Flink程序直接映射成的數(shù)據(jù)流圖是StreamGraph，也被稱(chēng)為邏輯流圖，因?yàn)樗鼈儽硎镜氖怯?jì)算邏輯的高級(jí)視圖。為了執(zhí)行一個(gè)流處理程序，F(xiàn)link需要將邏輯流圖轉(zhuǎn)換為物理數(shù)據(jù)流圖（也叫執(zhí)行圖），詳細(xì)說(shuō)明程序的執(zhí)行方式。

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

1. 原理介紹

• Flink執(zhí)行executor會(huì)自動(dòng)根據(jù)程序代碼生成DAG數(shù)據(jù)流圖

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

• StreamGraph：是根據(jù)用戶(hù)通過(guò) Stream API 編寫(xiě)的代碼生成的最初的圖。表示程序的拓?fù)浣Y(jié)構(gòu)。

• JobGraph：StreamGraph經(jīng)過(guò)優(yōu)化后生成了 JobGraph，提交給 JobManager 的數(shù)據(jù)結(jié)構(gòu)。主要的優(yōu)化為，將多個(gè)符合條件的節(jié)點(diǎn) chain 在一起作為一個(gè)節(jié)點(diǎn)，這樣可以減少數(shù)據(jù)在節(jié)點(diǎn)之間流動(dòng)所需要的序列化/反序列化/傳輸消耗。

• ExecutionGraph：JobManager 根據(jù) JobGraph 生成ExecutionGraph。ExecutionGraph是JobGraph的并行化版本，是調(diào)度層最核心的數(shù)據(jù)結(jié)構(gòu)。

• 物理執(zhí)行圖：JobManager 根據(jù) ExecutionGraph 對(duì) Job 進(jìn)行調(diào)度后，在各個(gè)TaskManager 上部署 Task 后形成的“圖”，并不是一個(gè)具體的數(shù)據(jù)結(jié)構(gòu)。

2. 簡(jiǎn)單理解：

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

• JobGraph：將OneToOne的Operator合并為OperatorChain--在Client上生成

• ExecutionGraph：將JobGraph根據(jù)代碼中設(shè)置的并行度和請(qǐng)求的資源進(jìn)行并行化規(guī)劃!--在JobManager上生成

• 物理執(zhí)行圖：將ExecutionGraph的并行計(jì)劃,落實(shí)到具體的TaskManager上，將具體的SubTask落實(shí)到具體的TaskSlot內(nèi)進(jìn)行運(yùn)行。