2.4 運行時

2.4.1 運行時結構

1.Task線程

線程是程序運行時的最小單元，是進程中的一個實體，是被系統獨立調度的基本單位，同屬一個進程的所有線程共享進程所擁有的全部資源。

Flink的每個Operator稱為一個任務（task），Operator的每個實例稱為子任務，每個任務（包括子任務）在一個JVM線程中執行。可以將多個子任務鏈接（chain）成一個任務，在一個線程中執行，這會降低線程上下文切換產生的開銷，減小緩存容量，提高系統吞吐量的同時降低延遲。此外，這種鏈接機制是可配置的，這增強了數據處理應用程序的靈活性。

機制與策略：理論指導引擎架構實現，但是實現通常考慮得更多。架構通常要權衡復雜度和靈活性，即引擎在簡化復雜度的情況下提供什么機制（提供什么能力）、應用程序將會獲得更豐富的實現策略（如何使用這些能力）。

在Programm 2.1中，Source[1]和map（）[1]、Source[2]和map（）[2]分別鏈接成一個任務，這種編排是因為Source和map的兩個實例之間采用直連模式，它們之間的數據傳輸可以通過緩存而不是網絡通信，正是這種針對性的優化提升了Flink的執行效率。整個應用程序由5個線程構成，如圖2-8所示。

從圖 2-8 中可見，應用程序由 Operator 的線程組成，也被稱為作業（Job）。其中同一作業的一個數據傳輸通路也被稱為一個管道，它用于連接多個命令，將一個命令的執行結果輸出給下一個命令。如Source[1]、map（）[1]、keyBy（）/window（）/apply（）[1]和Sink[1]。

管道這個概念最早出現在UNIX操作系統中，下面是UNIX（類UNIX系統）的一個例子：

上面的命令將當前登錄系統用戶的信息轉換為大寫后保存至/tmp/who.out文件中，輸出結果如下：

UNIX系統借用管道的模式將多個獨立的命令內聚在一起，以鏈的方式將它們串接成處理第一個命令（who）輸出文本信息的工作流，以降低軟件模塊（如本例中的命令）之間的耦合。

這是一種重要的軟件設計模式，實現了組件之間的“高內聚，低耦合”，降低了模塊間協同編程的難度。

這種設計模式在數據處理中有著廣泛應用，如何將一系列可伸縮的并行算子編排起來解決目標計算任務，是數據處理引擎的主要任務之一。

2.Manager進程

Flink由兩類運行時JVM進程（process）管理分布式集群的計算資源。

（1）JobManager進程負責分布式任務管理，如任務調度、檢查點、故障恢復等。在高可用（HA，High-Availability）分布式部署時，系統中可以有多個JobManager，即一個 leader 加多個 standby。JobManager 是 Flink 主從架構中的master。

（2）TaskManager 進程負責執行任務線程（Programm 2.1 物理部署形式中的Subtask），以及緩存和傳輸stream。TaskManager是Flink主從架構中的worker。

此外，作為作業的發起者，客戶端（client）向 JobManager 提交作業，但客戶端并不是Flink運行時的一部分，圖2-9描述了這三者的關系。

3.線程共享Slot

為了控制執行的任務數量，TaskManager 將計算資源劃分為多個Slot，每個Slot獨享給其分配的計算資源（如內存），這種靜態的資源管理方式有利于任務間資源隔離。

TaskManager可以配置成單Slot模式，這樣這個worker上運行的任務就獨占了整個JVM進程；同一個JVM進程上的多個任務可以共享TCP連接、心跳和數據。

Flink不允許屬于不同作業的任務共享同一個Slot，但允許屬于同一個作業的不同任務共享同一個 Slot，因此同一個作業的所有任務可共享同一個 Slot，如圖2-10所示。

2.4.2 任務調度

1.調度策略

以下代碼片段對應一個包括Source、map和reduce的Pipeline：

其中，Source和map的并行度設置為4（setParallelism（4）），reduce的并行度設置為3，Source和map實例間采用直連模式，每個map和所有reduce均有連接。這個Pipeline被調度在兩個TaskManager上執行，其中每個TaskManager有3個Slot。

出于提升執行效率的考慮，Flink 的任務調度系統會并發地執行流處理Pipeline中的任務，批處理通常也是如此。應用這種調度策略，本例的調度結果如圖2-11所示。

Flink通過CoLocationGroup和SlotSharingGroup管理任務的調度約束關系，CoLocationGroup 規定哪些任務必須被調度在同一個 Slot 上運行，而SlotSharingGroup則定義哪些任務可以被調度在同一個Slot上運行，Flink的任務調度系統可以根據集群資源使用情況最優化地調度執行作業任務。

2.作業控制

JobManager 將計算圖的邏輯形式（JobGraph）編譯成物理部署形式（ExecutionGraph）：

（1）JobGraph由Operator和傳輸通道的數據緩存（Intermediate Data Set）組成。其中，Operator是計算圖中的頂點（JobVertex），并行度控制其實例數量，處理函數（ProcessFunction）定義轉換函數。（2）ExecutionGraph由ExecutionVertex和Intermediate Result的多個分區組成。每個作業的JobVertex都對應一個ExecutionJobVertex，一個ExecutionJobVertex對應多個并行ExecutionVertex實例；數據緩存也被拆分成多個分區，即Intermediate Result Partition。

例如，一個 JobGraph 有 4 個頂點，分別記為 JobVertex（A）、JobVertex（B）、JobVertex（C）和JobVertex（D）；每個頂點的輸出都會有Intermediate Data Set。在對應的ExecutionGraph中，每個JobVertex對應一個ExecutionJobVertex，包括每個JobVertex 的所有并行實例，如 JobVertex（A）對應 ExecutionVertex A（0/2）和ExecutionVertex A（1/2）。整個作業控制的數據結構如圖2-12所示。

Flink通過狀態機管理ExecutionGraph的作業執行進度。在被創建時，作業的狀態為Created，然后被調度執行，作業的狀態流轉至Running，在所有JobVertex正常執行完處理任務后，作業結束，即處于 Finished 狀態。此外，作業在執行過程中可能會出錯，這時狀態會流轉至Failing、Restarting、Canceled或Failed；作業也可能被Client取消，這時狀態可能會流轉至Cancelling、Suspended或Canceled。作業的狀態機轉換過程，如圖2-13所示。

2.4.3 物理執行計劃

我們可以通過Web控制臺觀察作業的物理執行計劃。以Socket Window Word Count為例，單擊Web Flink Dashboard的“Add New+”按鈕來添加任務，如圖2-14所示。

選擇打包好的SocketWindowWordCount程序，并輸入參數（--port 9000），單擊“Show Plan”按鈕，則可獲取該程序的物理執行計劃，如圖2-15所示。