Apache Flink 的 作業提交流程（Job Submission Process） 是指從用戶編寫完 Flink 應用程序，到最終在 Flink 集群上運行并執行任務的整個過程。它涉及多個組件之間的交互，包括客戶端、JobManager、TaskManager 和 ResourceManager。

---

🧩 一、Flink 作業提交整體流程圖解

[Client] → 提交 JobGraph↓
[JobManager / Dispatcher] → 調度與資源申請↓
[ResourceManager] → 分配 TaskManager Slot↓
[TaskManager] → 啟動 Task 并執行 Subtask↓
[JobManager] → 協調任務狀態、檢查點等

---

📌 二、Flink 作業提交詳細步驟說明

步驟	描述
1. 用戶編寫代碼	使用 DataStream API 或 SQL 編寫 Flink 作業
2. 構建 StreamGraph	客戶端將邏輯流轉換為 StreamGraph（DAG）
3. 轉換為 JobGraph	將 StreamGraph 轉換為 JobGraph，包含算子鏈、并行度等信息
4. 提交 JobGraph 到集群	通過 CLI、REST API 或 Web UI 提交到 Flink 集群
5. JobManager 接收并初始化	創建 ExecutionGraph，管理任務調度
6. ResourceManager 分配資源	根據資源需求向 TaskManager 申請 Slot
7. TaskManager 啟動任務	在分配的 Slot 上啟動 Task，并開始執行 Subtask
8. 執行計算任務	持續處理數據流，進行狀態更新和窗口計算
9. 狀態管理與容錯	Checkpoint/Savepoint 機制保障狀態一致性
10. 結果輸出或寫入外部系統	輸出到 Sink（如 Kafka、HDFS、MySQL 等）

---

?? 三、各組件職責詳解

組件	職責
Client	提交作業、打包 JAR、生成 JobGraph
JobManager	負責任務調度、協調 Checkpoint、維護 ExecutionGraph
Dispatcher	接收作業提交請求，負責創建 JobManager
ResourceManager	管理 TaskManager 的 Slot 資源，分配資源給 JobManager
TaskManager	執行具體的 Task，每個 Task 包含一個或多個 Subtask
ExecutionGraph	JobManager 內部的執行圖，用于調度 Subtask
Checkpoint Coordinator	協調 Checkpoint，確保狀態一致性

---

📦 四、作業提交方式匯總

方式	描述	命令示例
CLI 提交	最常用方式，適合本地測試和生產部署	flink run -c com.example.MyJob ./myjob.jar
Web UI 提交	圖形化界面上傳 JAR 文件并運行	http://localhost:8081
REST API 提交	適用于自動化部署、平臺集成	POST /jars/{jarid}/run
YARN Session 模式	多個作業共享一個 YARN ApplicationMaster	yarn session -n 2 -tm 2048
Application 模式	每個作業單獨啟動一個 ApplicationMaster	flink run-application -t yarn-application ./myjob.jar
Kubernetes Native 模式	在 Kubernetes 上直接部署 Flink 作業	使用 Operator 或 Native 部署模式

---

🧠 五、提交流程詳解（以 Standalone 或 YARN 模式為例）

? 1. 客戶端（Client）

• 編譯并打包 Flink 作業為 JAR 文件
• 使用 flink run 命令提交作業
• 生成 JobGraph 并發送至 JobManager

flink run -m yarn-cluster -p 4 -c com.example.WordCount ./wordcount.jar

? 2. JobManager（也稱作 Dispatcher + JobMaster）

• 接收 Client 提交的 JobGraph
• 創建 ExecutionGraph，描述任務執行計劃
• 請求 ResourceManager 分配資源

? 3. ResourceManager

• 根據 JobManager 請求，向 TaskManager 申請 Slot
• 協調資源分配，保證資源公平使用

? 4. TaskManager

• 收到 Slot 分配通知后，準備執行環境
• 加載 JAR 文件，啟動 Subtask
• 向 JobManager 報告執行狀態

? 5. ExecutionGraph 執行

• JobManager 監控所有 Task 的執行情況
• 觸發 Checkpoint，維護狀態一致性
• 處理失敗重試、反壓監控等

---

📊 六、JobGraph vs StreamGraph vs ExecutionGraph 對比

名稱	描述	特點
StreamGraph	用戶編寫的 DAG 流程	包含 operator chain 優化后的邏輯圖
JobGraph	提交到集群的任務圖	包含 operator chains、slot sharing group 等元數據
ExecutionGraph	JobManager 內部運行圖	包含實際執行的 Subtask 及其依賴關系

---

🔁 七、狀態恢復與 Checkpoint 流程

1. JobManager 定期觸發 Checkpoint
2. TaskManager 將狀態快照寫入配置的 Checkpoint 存儲路徑（如 HDFS）
3. JobManager 收集所有 Task 的 Checkpoint 成功信號
4. 如果發生故障，從最近成功的 Checkpoint 恢復狀態

---

🧪 八、完整提交命令示例（YARN 模式）

# 啟動 YARN Session
flink run-application -t yarn-application \-Djobmanager.memory.process.size=1024mb \-Dtaskmanager.memory.process.size=2048mb \-Dparallelism.default=4 \./my-flink-job.jar

# 提交到已有的 Session 集群
flink run -m yarn-cluster -p 4 -c com.example.MyJob ./myjob.jar

---

🧩 九、提交流程中的關鍵概念

概念	描述
Operator Chaining	算子鏈合并，減少網絡傳輸開銷
Slot Sharing Group	同一組內的算子可共享同一個 Slot
Parallelism	設置每個算子的并發數
Checkpoints	用于狀態一致性和容錯機制
Savepoints	手動觸發的狀態快照，用于升級、遷移等
Backpressure	當下游處理速度慢于上游時產生的壓力反饋機制

---

? 十、總結：Flink 作業提交流程的核心階段

階段	描述
1. 客戶端構建	將用戶代碼轉換為 StreamGraph → JobGraph
2. 提交作業	Client 提交到 JobManager
3. 資源調度	ResourceManager 分配 TaskManager Slot
4. 任務執行	TaskManager 啟動 Subtask 并執行邏輯
5. 狀態管理	Checkpointing 保障狀態一致性
6. 故障恢復	重啟失敗任務并從 Checkpoint 恢復

---

📘 十一、擴展學習方向

如果你希望我為你演示以下內容，請繼續提問：

• Flink on YARN 提交流程詳解
• Flink on Kubernetes 提交原理
• 自定義 Checkpoint 存儲路徑
• Savepoint 的使用與恢復
• ExecutionGraph 的結構與作用
• 如何查看 Web UI 中的 ExecutionGraph
• 作業失敗時的恢復機制詳解

---

📌 一句話總結：

Flink 作業提交流程是一個多組件協作的過程，核心是 JobGraph 的構建與 ExecutionGraph 的執行，結合 Checkpoint 實現高可用與狀態一致性。