Flink Client 提交JobMananger流程
Client
客户端,负责将用户代码转换为执行计划,提交给 JobManager。
流程
逻辑计划生成→优化→物理计划生成→资源调度→任务执行
各组件分工:
- Client 负责 “翻译” 用户代码为可执行计划;
- Dispatcher 负责接收作业并启动 JobMaster;
- JobMaster 负责生成物理计划并申请资源;
- ResourceManager 负责资源分配;
- TaskManager 负责实际执行任务。
Client提交JobManager流程
1. Client本地预处理
- 初始化执行环境,生成逻辑执行图(StreamGraph)
- 优化执行计划,生成作业图
主要优化包括 - 算子链优化 - 设置资源需求 - 补充元数据 :
添加作业 ID、并行度、Checkpoint 配置、依赖的 JAR 包路径等信息。 - JobGraph :
是优化后的逻辑图,是 Client 提交给集群的核心数据结构,每个节点对应一个 “作业顶点(JobVertex)”,包含了执行所需的所有元信息。 - 上传依赖资源
若作业依赖外部 JAR 包(如自定义函数、第三方库),Client 会将这些资源上传至集群的分布式文件系统(如 HDFS)或 JobManager 的本地目录,确保 TaskManager 后续能下载并加载这些依赖。
2. 与集群交互提交
Client 完成本地预处理后,需将 JobGraph 提交到集群的 JobManager,具体步骤取决于部署模式(Standalone、YARN、K8s 等),但核心逻辑一致。
- Standalone模式:直连Dispatcher固定端口(默认8081)
- YARN/K8s模式: Client 先通过资源管理器(YARN ResourceManager/K8s API Server)获取 Dispatcher 的地址,再建立连接。
3. JobManager内部处理(集群侧)
JobManager 接收作业后,由内部组件协同完成任务调度和执行,核心是将 JobGraph 转换为可在 TaskManager 上运行的物理任务。
- Dispatcher 启动 JobMaster
Dispatcher 为每个作业启动一个 JobMaster(作业的专属管理器),并将 JobGraph 传递给 JobMaster。JobMaster 是单个作业的 “大脑”,负责后续的计划生成和任务调度。 - JobMaster生成物理执行图
JobMaster 对JobGraph进行进一步转换,生成执行图(ExecutionGraph):
- 将 JobVertex 拆分为多个 “执行顶点(ExecutionVertex)”:每个 ExecutionVertex 对应 JobVertex 的一个并行实例(由并行度决定,如并行度为 3 则拆分为 3 个 ExecutionVertex);
- 处理数据分片与依赖:明确每个 ExecutionVertex 需处理的数据分片,以及与其他顶点的依赖关系;
- 绑定 Checkpoint 配置:为状态算子(如 window、aggreate)配置状态后端和 Checkpoint 策略。
- ExecutionGraph:是物理执行图,直接对应集群中可运行的任务,每个 ExecutionVertex 最终会被调度到 TaskManager 的 Slot 中执行。
- 资源申请与任务调度
JobMaster 向 JobManager 中的 ResourceManager 申请资源:- ResourceManager 管理集群中所有 TaskManager 的 Slot(每个 Slot 代表一组固定的 CPU 和内存资源);
- 根据 ExecutionGraph 的资源需求,ResourceManager 为每个 ExecutionVertex 分配合适的 Slot(优先本地性,减少数据传输)。
- 分发任务到 TaskManager 执行
JobMaster 将分配到 Slot 的 ExecutionVertex 封装为 “任务(Task)”,并将任务代码(序列化的算子逻辑)、依赖资源、状态信息等发送到对应的 TaskManager:- TaskManager 接收到任务后,在指定 Slot 中启动线程执行任务;
- 任务启动后,从数据源(如 Kafka)读取数据,执行算子逻辑,并通过网络将结果发送到下游任务。
- 作业状态监控与反馈
JobMaster 持续监控任务执行状态(如是否正常运行、是否触发 Checkpoint),并通过 Dispatcher 向 Client 反馈作业状态(如 “已提交”“运行中”“失败”)。Client 可通过日志或 Flink UI 查看这些状态。