[[439440]]

 前言

寫這種文章的初衷就是，在開發的過程中不知道怎么去選擇，各種模式不是太充分了解。現在花點時間去找資料研究對比了一番，所以出此篇。

此篇以先以了解flink組件開始，再以簡單模式Local 和 Standlone 正式進入正題。本篇主要是以Yarn 方式下三種模式展開細講，當然還有Kubernetes方式(本篇不細說)。

組件

在了解提交模式之前，先了解一下Flink組件與組件之間的協作關系。

資源管理器(Resource Manager)

(1)主要負責管理任務管理器TaskManager的插槽slot。

(2) 當作業管理器JM申請插槽資源時， RM會將有空閑插槽的TM分配給JM。如果 RM沒有足夠的插槽來滿足JM的請求。

(3)它還可以向資源提供平臺發起會話，以提供啟動 TM進程的容器。

作業管理器(JobManager)

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

(2) JM會先接收到要執行的應用程序，這個應用程序會包括：作業圖(Job Graph)、邏輯數據流圖( ogical dataflow graph)和打包了所有的類、庫和其它資源的JAR包。

(3) JM會把 Jobgraph轉換成一個物理層面的 數據流圖，這個圖被叫做 “執行圖”(Executiongraph),包含了所有可以并發執行的任務。Job Manager會向資源管理器( Resourcemanager)請求執行任務必要的資源，也就是 任務管理器(Taskmanager)上的插槽slot。一旦它獲取到了足夠的資源，就會將執行圖分發到真正運行它們的TM上。而在運行過程中JM會負責所有需要中央協調的操作，比如說檢查點(checkpoints)的協調。

任務管理器(Taskmanager)

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

(2) 啟動之后，TM會向資源管理器注冊它的插槽;收到資源管理器的指令后， TM就會將一個或者多個插槽提供給JM調用。TM就可以向插槽分配任務tasks來執行了。

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

分發器(Dispatcher)

(1)可以跨作業運行，它為應用提交提供了REST接口。

(2)當一個應用被提交執行時，分發器就會啟動并將應用移交給JM。

(3)Dispatcher他會啟動一個 WebUi，用來方便地 展示和監控作業執行的信息。

Local模式

JobManager 和 TaskManager 共用一個 JVM,只需要jdk支持，單節點運行，主要用來調試。

Standlone模式

Standlone 是Flink自帶的一個分布式集群，它不依賴其他的資源調度框架、不依賴yarn 等。

充當Master角色的是JobManager。

充當Slave/Worker角色是TaskManager

配置與啟動

(1)conf 目錄下有兩個文件：masters 和 workers 指定地址。

(2)需要配置 conf/flink-conf.yaml 的自行配置。

(3)分發各個機器。

(4)啟動集群 bin/start-cluster.sh

(5)提交任務 flink run

Yarn 模式

首先認識下提交流程

(1)提交App之前，先上傳Flink的Jar包和配置到HDFS，以便JobManager和TaskManager共享HDFS的數據。

(2)客戶端向ResourceManager提交Job，ResouceManager接到請求后，先分配container資源，然后通知NodeManager啟動ApplicationMaster。

(3)ApplicationMaster會加載HDFS的配置，啟動對應的JobManager，然后JobManager會分析當前的作業圖，將它轉化成執行圖(包含了所有可以并發執行的任務)，從而知道當前需要的具體資源。

(4)接著，JobManager會向ResourceManager申請資源，ResouceManager接到請求后，繼續分配container資源，然后通知ApplictaionMaster啟動更多的TaskManager(先分配好container資源，再啟動TaskManager)。container在啟動TaskManager時也會從HDFS加載數據。

(5)TaskManager啟動后，會向JobManager發送心跳包。JobManager向TaskManager分配任務。

Session Mode

Session模式提前初始化好一個集群，然后向這個集群提交應用。所有應用都在同一個集群中執行，共享資源。這里JobManager僅有一個。提交到這個集群的作業可以直接運行。如圖所示

Session模式共享Dispatcher 和 ResourceManager，作業共享集群資源。

Session多個作業之間又不是隔離的，如果有一個TaskManager掛掉，它上面承載著的所有作業也會失敗。同樣來說，啟動的Job任務越多，JobManager的負載也就越大。

所以，Session模式適合生命周期短資源消耗低的場景。

提交

./bin/flink run -t yarn-session \ 
  -Dyarn.application.id=application_XXXX_YY \ 
  ./examples/streaming/TopSpeedWindowing.jar 

Per-Job Cluster Mode

在Per-Job模式下，每個提交到YARN上的作業會有單獨的Flink集群，擁有專屬的JobManager和TaskManager。也即:一個作業一個集群，作業之間相互隔離。

以Per-Job模式提交作業的啟動延遲可能會較高，因為不需要共享集群，所以在PipelineExecutor中執行作業提交的時候，創建集群并將JobGraph以及所需要的文件等一同提交給Yarn集群，進行一系列的初始化動作，這個時候需要些時間。提交任務的時候會把本地flink的所有jar包先上傳到hdfs上相應的臨時目錄，這個也會帶來大量的網絡的開銷。

優點就是作業之間的資源完全隔離，一個作業的TaskManager失敗不會影響其他作業的運行，JobManager的負載也是分散開來的，不存在單點問題。當作業運行完成，與它關聯的集群也就被銷毀，資源被釋放。

所以，Per-Job模式一般用來部署那些長時間運行的作業。

提交

/bin/flink run -t yarn-per-job --detached ./examples/streaming/TopSpeedWindowing.jar 

「其他操作」

# List running job on the cluster 
./bin/flink list -t yarn-per-job -Dyarn.application.id=application_XXXX_YY 
# Cancel running job 
./bin/flink cancel -t yarn-per-job -Dyarn.application.id=application_XXXX_YY <jobId> 

Application Mode

Application 模式嘗試去將per-job 模式的資源隔離性和輕量級，可擴展的應用提交進程相結合。為了實現這個目的，它會每個Job 創建一個集群，但是 應用的main()將被在JobManager 執行。

Application 模式為每個提交的應用程序創建一個集群，該集群可以看作是在特定應用程序的作業之間共享的會話集群，并在應用程序完成時終止。在這種體系結構中Application模式在不同應用之間提供了資源隔離和負載平衡保證

在JobManager 中執行main()方法，可以節省所需的CPU周期。還有個好處就是，由于每個應用程序有一個JobManager，因此可以更平均地分散網絡負載。

提交

./bin/flink run-application -t yarn-application ./examples/streaming/TopSpeedWindowing.jar 

「其他操作」

# List running job on the cluster 
./bin/flink list -t yarn-application -Dyarn.application.id=application_XXXX_YY 
# Cancel running job 
./bin/flink cancel -t yarn-application -Dyarn.application.id=application_XXXX_YY <jobId> 

Application mode中的多個job，實際在代碼上的表現就是能夠允許在一個Application里面調用多次execute/executeAsyc方法。但是execute方法會被阻塞，也就是只有一個job完成之后才能繼續下一個job的execute，但是可以通過executeAsync進行異步非阻塞執行。

Yarn 模式總結