TL;DR

本文基于 Flink 1.20 源码，梳理 yarn-application 模式下一个任务从提交到运行起来的完整过程。

重点会放在这几件事上：

• 命令是怎么启动的
• Client 侧到底做了什么
• Yarn 上的 ApplicationMaster / JobManager 是怎么启动的
• TaskManager 是怎么向 Yarn 申请并拉起的
• 用户 main()、JobGraph 生成、submitJob() 分别发生在哪个角色里

为了避免范围过大，本文只聚焦 run-application -t yarn-application 这条主链路，不展开 Web 提交、Session 模式以及 SQL Gateway。

以一个最常见的启动命令为例：

1
2
3
4
5
6
7

./bin/flink run-application \
  -t yarn-application \
  -Djobmanager.memory.process.size=2048m \
  -Dtaskmanager.memory.process.size=4096m \
  -c com.example.WordCount \
  /path/to/job.jar \
  arg1 arg2

TL;DR

本文基于 Flink 1.20 源码，不再泛泛讨论“什么是流式计算”，而是聚焦两个问题：

1. 为什么 Flink 会成为主流流式处理引擎？
2. Flink 到底靠哪些关键机制，把无界数据流变成可按时间计算、可故障恢复、可做到 exactly-once 的系统？

如果把答案压缩成一句话，那就是：

Flink 真正领先的地方，不是单独提出了 window 或 watermark，而是把 事件时间、watermark、window、trigger、state、checkpoint 这些能力拼成了一套完整且能落地的运行时体系。

本文重点看两条主线：

• Flink 如何处理时间：event time、watermark、window、trigger
• Flink 如何保证精准一次：state、checkpoint barrier、snapshot、恢复