一、Flink 整體架構
Flink 叢集整體遵循 Master ，Worker 這樣的架構模式。
JobManager 是管理節點，有以下幾個職責：
- 接受 application，包含 StreamGraph（DAG），JobGraph（優化過的）和 JAR，将 JobGraph 轉換為 Execution Graph
- 申請資源，排程任務，執行任務，儲存作業的中繼資料，如Checkpoint
- 協調各個 Task 的 Checkpoint。
TaskManager 是工作節點，負責資料交換，跑多個線程的 task，執行任務。
Client 是用戶端，接收使用者送出的 jar 包，産生一個 JobGraph 對象，送出到 JobManager。如果成功送出會傳回一個 JobClient，用來和 JobManager 通信獲得任務執行的狀态。
二、JobManager 内部組成原理
- 負責 Checkpoint 的協調，通過定時做快照的方式記錄任務狀态資訊；
- Job Dispatch 負責接收用戶端發送過來的 JobGraph 對象（DAG），并且在内部生成 ExecutionGraph（實體執行圖）；
- 将作業拆分成 Task，部署到不同的 TaskManager 上去執行；ctorSystem 是 基于 akka 實作的一個通信子產品，負責節點之間的通信，如 Client 和 JobManager 之間，JobManager 和 TaskManager 之間的通信；
- 負責資源管理，對于不同的部署模式，有相應的 ResourceManager 的實作；
- TaskManager 啟動時，會向 JobManager 注冊自己，并時刻和 JobManager 保持心跳。
三、TaskManager 内部原理
- TaskManager 是作為一個虛拟機程序存在，TaskManager 啟動的時候，會向 JobManager 注冊自己；
- JobManager 送出作業的時候，TaskManager 會啟動 Task 線程将 Job 運作起來，TaskManager 裡面有線程池負責線程的排程執行。
- 在 Flink 内部也會有類似 Spark 或者 MapReduce 節點 shuffle 的過程，比如進行了一個 GroupByKey 的操作，就會涉及到資料的互動；Network Manager 是基于 Netty 實作的一個資料傳輸子產品；
- 而節點和節點之間的通信是基于 akka 實作的 Actor System，來進行遠端的 rpc 通信；
- Memory Management 是記憶體管理子產品，當資料進來時，負責申請記憶體來運作任務。
TaskManager 如何負責資料傳輸
在一個運作的application中，它的tasks在持續交換資料。TaskManager負責做資料傳輸。
TaskManager的網絡元件首先從緩沖buffer中收集records，然後再發送。也就是說，records并不是一個接一個的發送，而是先放入緩沖，然後再以batch的形式發送。這個技術可以高效使用網絡資源，并達到高吞吐。
每個TaskManager有一組網絡緩沖池（預設每個buffer是32KB），用于發送與接受資料。
如發送端和接收端位于不同的TaskManager程序中，則它們需要通過作業系統的網絡棧進行交流。
流應用需要以管道的模式進行資料交換，也就是說，每對TaskManager會維持一個永久的TCP連接配接用于做資料交換。
在shuffle連接配接模式下（多個sender與多個receiver），每個sender task需要向每個receiver task，此時TaskManager需要為每個receiver task都配置設定一個緩沖區。下圖展示了此架構：
在上圖中，有四個sender 任務，對于每個sender，都需要有至少四個network buffer用于向每個receiver發送資料。
每個receiver都需要有至少四個buffer用于接收資料。
TaskManager之間的buffer以多路複用的方式使用同一網絡連接配接。為了提供平滑的資料管道型的資料交換，一個TaskManager必須能提供足夠的緩沖，以服務所有并行的出入連接配接。
對于shuffle或broadcast 連接配接，每個發送任務和每個接受任務之間都需要一個buffer。Flink的預設網絡緩沖配置足夠适用與小型與中型的叢集任務。對于大型的叢集任務，需要對此配置進行調優。
若sender與receiver任務都運作在同一個TaskManager程序，則sender任務會将發送的條目做序列化，并存入一個位元組緩沖。然後将緩沖放入一個隊列，直到隊列被填滿。Receiver任務從隊列中擷取緩沖，并反序列化輸入的條目。是以，在同一個TaskManager内，任務之間的資料傳輸并不經過網絡互動。
四、Client 内部原理
Client 是用戶端，當使用者寫好一個 Flink 的程式之後，會用 bin/flink run 這樣的方式去送出 jar 包。
然後會啟動一個 Client 的程序，找到 jar 包中的 main 方法，建立 Context Environment （執行環境），把代碼解析成 JobGraph （有向無環圖表示的作業），
向 JobManager 送出 JobGraph ，并傳遞使用者送出的 jar 包。
當程式部署在 jarn session 或者 kerbernetes Session 的時候，用戶端也會進行部署的操作。
五、JobGraph
不管使用者寫的程式是 DataStream Api，DateSet Api，或者是 Flink SQL，都會打成 jar 包，jar 包中會寫入 main 方法的類，Client 程序啟動的時候就會執行 main 方法，解析出程式中所表達的邏輯，生成 StreamGraph，再優化生成 JobGraph，再送出到 JobManager。
這裡說的 JobGraph 其實就是在 Flink UI 界面上看到的有向無環圖，如下圖：
另外，JobGraph 也是對叢集元件的一個解耦過程，不管什麼程式最終都生成 JobGraph ，JobGraph 作為 用戶端和 JobManager 送出的規範。
強烈推薦大家加入我的群，參與大資料技術文檔共建，公衆号回複：加群，即可擁有！