相信你讀完上一節的《10分鐘入門Flink--了解Flink》對Flink已經有初步了解了。這是繼第一節之後的Flink入門系列的第二篇，本篇主要内容是是：了解Flink運作模式、Flink排程原理、Flink分區、Flink安裝。
1、運作模式
Flink有多種運作模式，可以運作在一台機器上，稱為本地（單機）模式；也可以使用YARN作為底層資源排程系統以分布式的方式在叢集中運作，稱為Flink On YARN模式；還可以使用Flink自帶的資源排程系統，不依賴其他系統，稱為Flink Standalone模式。還有将Flink部署到Kubernetes的模式，稱為Flink On Kubernetes模式。
1.1、單機（本地）模式
直接下載下傳jar包後啟動。
1.2、Flink Standalone模式
先一起看下這種模式運作架構圖：
Flink Standalone模式為經典的主從（Master/Slave）架構，資源排程是Flink自己實作的。叢集啟動後，主節點上會啟動一個JobManager程序，類似YARN叢集的ResourceManager，是以主節點也稱為JobManager節點；各個從節點上會啟動一個TaskManager程序，類似YARN叢集的NodeManager，是以從節點也稱為TaskManager節點。
執行流程：Client接收到Flink應用程式後，将作業送出給JobManager。JobManager要做的第一件事就是配置設定Task（任務）所需的資源。完成資源配置設定後，Task将被JobManager送出給相應的TaskManager，TaskManager會啟動線程開始執行。在執行過程中，TaskManager會持續向JobManager彙報狀态資訊，例如開始執行、進行中或完成等狀态。作業執行完成後，結果将通過JobManager發送給Client。
各元件作用：
Client：Client是送出作業的用戶端，雖然不是運作時和作業執行時的一部分，但它負責準備和送出作業到JobManager，它可以運作在任何機器上，隻要與JobManager環境連通即可。
JobManager：JobManager根據用戶端送出的應用将應用分解為子任務，從資料總管（YARN等）申請所需的計算資源，然後分發任務到TaskManager執行，并跟蹤作業的執行狀态等。JobManager的主要作用是協調資源配置設定、任務排程、故障恢複等。整個叢集有且僅有一個活躍的JobManager。
TaskManager：TaskManager是Flink叢集的工作程序。Task被排程到TaskManager上執行。TaskManager互相通信，隻為在後續的Task之間交換資料。TaskManager工作内容：
- 接收JobManager配置設定的任務，負責具體的任務執行。TaskManager會在同一個JVM程序内以多線程的方式執行任務
- 負責對應任務在每個節點上的資源申請，管理任務的啟動、停止、銷毀、異常恢複等生命周期。
- 負責對資料進行緩存。TaskManager之間采用資料流的形式進行資料互動。
Task：Flink中的每一個操作算子稱為一個Task（任務）。Task是基本的工作單元，由Flink的Runtime來執行。每個Task在一個JVM線程中執行。多個Task可以在同一個JVM程序中共享TCP連接配接（通過多路複用技術）和心跳資訊。它們還可能共享資料集和資料結構，進而降低每個Task的開銷。
Task Slot：TaskManager為了控制執行的Task數量，将計算資源（記憶體）劃分為多個Task Slot（任務槽），每個Task Slot代表TaskManager的一份固定記憶體資源，Task則在Task Slot中執行。
1.3、Flink On YARN模式
先來回顧下yarn的叢集架構：
Flink On YARN模式遵循YARN的官方規範，YARN隻負責資源的管理和排程，運作哪種應用程式由使用者自己實作，是以可能在YARN上同時運作MapReduce程式、Spark程式、Flink程式等。
Flink On YARN模式下的運作架構：
1.4、Flink On Kubernetes模式
這種模式我沒用過，不做介紹，感興趣的朋友可以自行查閱。
2、排程原理
2.1、任務鍊
Flink中的每一個操作算子稱為一個Task（任務），算子的每個具體執行個體則稱為SubTask（子任務），SubTask是Flink中最小的處理單元，多個SubTask可能在不同的機器上執行。一個TaskManager程序包含一個或多個執行線程，用于執行SubTask。TaskManager中的一個Task Slot對應一個執行線程，一個執行線程可以執行一個或多個SubTask。他們的結構如下圖所示：
由于每個SubTask隻能在一個線程中執行，為了能夠減少線程間切換和緩沖的開銷，在降低延遲的同時提高整體吞吐量，Flink可以将多個連續的SubTask連結成一個Task在一個線程中執行。這種将多個SubTask連在一起的方式稱為任務鍊。任務鍊的結構如下圖所示：
2.2、并行度
Flink應用程式可以在分布式叢集上并行運作，其中每個算子的各個并行執行個體會在單獨的線程中獨立運作，并且通常情況下會在不同的機器上運作。為了充分利用計算資源，提高計算效率，可以增加算子的執行個體數（SubTask數量）。一個特定算子的SubTask數量稱為該算子的并行度，且任意兩個算子的并行度之間是獨立的，不同算子可能擁有不同的并行度。如下圖所示，将Source算子、map()算子、keyby()/window()/apply()算子的并行度設定為2，Sink算子的并行度設定為1。運作效果如下圖所示：
2.3、資料流
一個Flink應用程式會被映射成邏輯資料流（Dataflow），而Dataflow都是以一個或多個Source開始、以一個或多個Sink結束的，且始終包括Source、Transformation、Sink三部分。
Dataflow描述了資料如何在不同算子之間流動，将這些算子用帶方向的直線連接配接起來會形成一個關于計算路徑的有向無環圖，稱為DAG（Directed Acyclic Graph，有向無環圖）或Dataflow圖。各個算子的中間資料會被儲存在記憶體中。
Flink算子組成的DAG，如下圖所示：
程式的Dataflow圖，如下圖所示：
2.3、執行圖
Flink應用程式執行時會根據資料流生成多種圖，轉成執行圖，每種圖對應了作業的不同階段，根據不同圖的生成順序，主要分為4層：StreamGraph→JobGraph→ExecutionGraph→實體執行圖。具體過程見下圖：
- StreamGraph：流圖。使用DataStream API編寫的應用程式生成的最初的圖代表程式的拓撲結構，描述了程式的執行邏輯。StreamGraph在Flink用戶端中生成，在用戶端應用程式最後調用execute()方法時觸發StreamGraph的建構。
- JobGraph：作業圖。所有進階别API都需要轉換為JobGraph。StreamGraph經過優化（例如任務鍊）後生成了JobGraph，以提高執行效率。StreamGraph和JobGraph都是在本地用戶端生成的資料結構，而JobGraph需要被送出給JobManager進行解析。
- ExecutionGraph：執行圖。JobManager對JobGraph進行解析後生成的并行化執行圖是排程層最核心的資料結構。它包含對每個中間資料集或資料流、每個并行任務以及它們之間的通信的描述。
- 實體執行圖：JobManager根據ExecutionGraph對作業進行排程後，在各個TaskManager上部署Task後形成的“圖”。實體執行圖并不是一個具體的資料結構，而是各個Task分布在不同的節點上所形成的實體上的關系表示。
2.4、執行計劃
Flink的優化器會根據資料量或叢集機器數等的不同自動地為程式選擇執行政策。
3、資料分區
3.1、分區概念
在Flink中，資料流或資料集被劃分成多個獨立的子集，這些子集分布到了不同的節點上，而每一個子集稱為分區（Partition）。是以可以說，Flink中的資料流或資料集是由若幹個分區組成的。
3.2、分區數量
在運作期間，每個資料記錄将被配置設定給一個或多個分區，各個分區中的資料可以并行計算。我們已經知道，資料是由上遊算子的某個執行個體（SubTask）發往下遊算子的一個或多個執行個體，而一個算子執行個體隻負責計算一個分區的資料。是以，分區的數量是由下遊算子的執行個體數量（并行度）決定的，發往下遊算子的資料分區數量等于下遊算子的執行個體數量。
資料分區的一個原則是使得分區的數量盡量等于叢集節點CPU的核心數量。
3.3、分區政策
Flink分區政策決定了一條資料如何發送給下遊算子的不同執行個體。
- 轉發政策
- 廣播政策
- 鍵值政策
- 随機政策
- 全局政策
- 自定義政策
- 如果内置的分區政策不能滿足目前需求，則可以在程式中自定義分區政策。這塊後續再介紹。
4、安裝
具體安裝步驟參見下一篇。文中會介紹Flink Standalone的叢集安裝。
感謝你的閱讀，碼字不易，歡迎關注、點贊、收藏！！！
原文連結：https://mp.weixin.qq.com/s/GwNQNHTr0-NrrajCoRM6Ag
原文連結：http://www.mangod.top/articles/2023/07/24/1690190004151.html