Flink运行时架构及各部署模式下作业提交流程

本文详细介绍了Apache Flink的运行时架构,包括JobManager、TaskManager和Dispatcher的角色及其交互。JobManager作为作业管理者,负责调度与协调;TaskManager是工作进程,执行实际计算任务;Dispatcher接收并分发作业。作业提交流程中,Client提交作业到Dispatcher,JobMaster解析JobGraph并申请资源,ResourceManager分配TaskManager的slots,最终TaskManager执行任务。此外,文章还对比了独立模式、会话模式和YARN上的作业提交流程。

1.运行时架构

1.1 核心组件

1.1.1 JobManager

作业管理器,对于一个提交执行的作业,JobManager 是真正意义上的“管理者”(Master),负责管理调度,是一个 Flink 集群中任务管理和调度的核心,是控制应用执行的主进程。在不考虑高可用的情况下只能有一个
JobManager ,只有一个是正在运行的领导节点(leader),其他都是备用节点(standby)

JobManager包含三大核心组件:

  • JobMaster
  1. JobMaster是JobManager的核心组件,负责处理单独的作业(job)
  2. JobMaster和Job是一一对应的,多个Job可以运行在一个Flink集群中, 每个Job都有一个自己的JobMaster
  3. 在作业提交时,JobMaster会先接收到要执行的应用,一般是由客户端提 交来的,包括 Jar包,数据流图(dataflow Graph)和作业图(JobGraph)
  4. jobMaster会将JobGraph转换为一个物理层面的数据流图执行图(ExecutionGraph),它包含所有可以并发执行的任务
  5. JobMaster会向资源管理器ResourceManager发出请求,申请必要的资源,一旦获取到足够的资源,就会将执行图分发到真正运行他们的TaskManager上
  6. 在作业的运行过程中,JobMaster会负责所有需要中央协调的操作,比如说检查点(checkpoints)的协调
  • ResourceManager

注意:该ResourceManager是Flink内置的,不是其他资源调度平台(如YARN)的 ResourceManager

  1. ResourceManager主要负责资源的分配和管理,在Flink集群中只有一个
  2. 资源主要指的是TaskManager的槽(task slots),任务槽是Flink集群中的资源调配单元,包含了机器用来计算的一组CPU和内存资源
  3. 每一个task都要分配到一个slot上进行
  4. Flink集群Standalone部署模式下,TaskManager是单独启动的(没有Per-Job模式),此时的ResourceManager只能分发可用的TaskManager任务槽,不能单独启动新的TaskManager
  5. Flink集群部署资源管理平台时(YARN 、K8s)等,ResourceManager 会将有空闲槽位的 TaskManager 分配给 JobMaster。若ResourceManager 没有足够的任务槽,它还可以向资源提供平台请求提供启动 TaskManager 进程的容器。另外,ResourceManager 还负责停掉空闲的 TaskManager,释放计算资源
  • Dispatcher
  1. Dispatcher分发器主要提供一个REST接口,用来提交应用
  2. 为每一个新提交的作业启动一个新的JobMaster组件
  3. 启动Web UI,方便地展示和监控作业信息
  4. 在架构中并不是必须的,在不同的部署模式下可能会被忽略
1.1.2 TaskManager

任务管理器,是Flink中的工作进程,称为Worker

  • 数据流的具体计算由它来完成,每个Flink集群至少一个TaskManager,每一个TaskManager包含一定数量的任务槽(slot),slot是资源调度的最小单位,slot的数量决定了TaskManager并行处理任务的数量
  • 启动后,TaskManager会向ResourceManager注册它的slots,收到ResourceManager的指令后,TaskManager就会将一个或多个slot提供给JobMaster调用,JobMaster就可以分配任务来执行了
  • 在执行过程中,TaskManager 可以缓冲数据,还可以跟其他运行同一应用的 TaskManager交换数据

1.2 作业图

![作业提交及运行流程图](https://img-blog.csdnimg.cn/53060720ff1746fc8eab39b8937c6213.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAaG1pMTAyNA==,size_20,color_FFFFFF,t_70,g_se,x_16

2. 作业提交流程

2.1 抽象流程

Flink 的提交流程,随着部署模式、资源管理平台的不同,会有不同的变化。首先我们从一个高层级的视角,来做一下抽象提炼,看一看作业提交时宏观上各组件是怎样交互协作的

Flink提交作业抽象流程

  1. Client向Dispatcher提交作业
  2. Dispatcher通过REST接口将作业(包含 JobGraph)提交给 JobMaster
  3. JobMaster将JobGraph解析成可执行的ExecutionGraph得到所需资源的数量,向ResourceManager申请作业所需要的slots
  4. ResourceManager判断当前是否有足够的可用资源,如果没有则启动新的TaskManager
  5. TaskManager启动之后,向ResourceManager注册可用的slot
  6. ResourceManager向TaskManager发出命令,为新作业提供slots
  7. TaskManager向JobMaster提供slots
  8. JobMaster向TaskManager分发任务
  9. TaskManager执行任务,相互之间可以交换数据

2.2 独立模式(Standalone)

在独立模式下,只有两种部署方式会话模式应用模式,没有分离模式。Flink的三种部署方式
两者整体的作业提交流程十分相似:TaskManager都需要手动启动,JobMaster向ResourceManager申请资源时,ResourceManager会直接要求TaskManager提供资源,区别在于,会话模式下,TaskManager是预先启动的,应用模式的TaskManager是作业提交时启动的

Standalone模式作业提交流程
该作业流程除了ResourceManager不需要启动TaskManager,而是直接向已有的TaskManager要求资源,和上述抽象流程完全一致

2.3 FLINK ON YARN

flink在资源管理平台的作业提交流程,以YARN集群为例

  • 会话模式

需要事先申请资源,如图所示:
FLINK ON YARN会话模式申请资源
这里只启动了 JobManager,在 JobManager 内部,由于还没有提交作业,故只有ResourceManager 和 Dispatcher 在运行,而 TaskManager 可以根据需要动态地启动。如图所示:
在这里插入图片描述

  1. Client提交任务到Dispatcher
  2. Dispatcher启动JobMaster
  3. JobMaster向ResourceManager(Flink)申请slots
  4. ResourceManager(Flink)向ResourceManager(YARN)申请Container资源
  5. ResourceManager(YARN)启动TaskManager
  6. TaskManager向ResourceManager(Flink)注册可用slots
  7. ResourceManager(Flink)向TaskManager请求slots
  8. TakManager向JobMaster提供slots
  9. JobMaster分发任务给TaskManager,TaskManager执行任务
  • 分离模式

在分离模式下,Flink 集群不会预先启动,而是在提交作业时,才启动新的 JobManager。具体流程如图所示:
FLINK ON YARN分离模式作业提交流程

  1. Client提交任务到ResourceManager(YARN)
  2. ResourceManager(YARN)分配Container资源,启动Flink的JobMaster,并将作业提交给JobMaster,此处省略Dispatcher(与会话模式的区别点)
  3. JobMaster向ResourceManager(Flink)请求slots
  4. ResourceManager(Flink)向ResourceManager(YARN)请求Container资源
  5. ResourceManager(YARN)启动新的TaskManager容器
  6. TaskManager向ResourceManager(Flink)注册可用的slots
  7. ResourceManager(Flink)向TaskManager请求slots
  8. TaskManager向JobMaster提供slots
  9. JobMaster分发任务给TaskManager,TaskManager执行任务
  • 应用模式
    应用模式与分离模式的提交流程非常相似,只是初始提交给 YARN 资源管理器的不再是具体的作业,而是整个应用。一个应用中可能包含了多个作业,这些作业都将在 Flink 集群中启动各自对应的 JobMaster.
<think> 嗯,用户这次想了解Flink提交作业模式。根据之前的对话历史,用户已经对Spark的作业提交方式有了较深的理解(spark-shell/spark-submit/spark-sql的区别),现在转向Flink框架的同问题,说明ta可能在对比两个流处理引擎的架构差异。 用户提供的引用材料非常聚焦,要来自Flink部署相关的技术文档(引用1-5)。这些材料清晰地展示了Flink的三种核心部署模式:会话模式、单作业模式、应用模式。有趣的是,用户特意标注了"并不是用户真正的需求",但根据上下文,这恰恰是ta当前需要的技术点——毕竟ta最后明确提问"Flink提交作业模式有哪些"。 从引用内容看,有三个关键维度需要展开: 1. 模式区别:会话模式(静态集群共享)vs 单作业模式(每作业独立JobManager)vs 应用模式(整个应用共享集群) 2. 资源管理:尤其注意引用2和引用5强调的独立模式特殊性——TaskManager需手动启动,这与YARN/K8s的自动管理截然不同 3. 适用场景:引用4提到单作业模式"资源隔离好但网络负载高",这点对生产环境选型很重要 用户作为大数据工程师,可能正在为实计算平台选型,需要评估不同模式对资源利用率、隔离性和运维成本的影响。因此在回答中要突出对比维度(如资源分配粒度、JobManager生命周期),并补充实际命令示例(如引用1的yarn-cluster提交方式)。 特别要注意纠正一个潜在误区:引用3提到应用模式"启动JobMaster",严格来说JobMaster是运行组件,回答中需明确"为应用启动专属JobManager"的表述。此外,用户上次对Spark的"cluster"模式很关注(driver部署位置),比到Flink应强调单作业模式的cluster级隔离。 </think>根据Flink架构设计,作业提交要有三种核心模式,它们在**集群生命周期**、**资源分配粒度**和**适用场景**上存在显著差异: --- ### 1. **会话模式 (Session Mode)** - **核心特点**: - **共享集群**:预先启动长期运行的`JobManager`和`TaskManager`,所有作业共享资源[^2][^3] - **资源隔离弱**:作业间可能竞争资源(如CPU/内存) - **提交命令示例**: ```bash # 先启动集群 bin/start-cluster.sh # 提交作业到现有集群 bin/flink run -d -c com.example.Job app.jar ``` - **适用场景**: - 短测试或开发环境 - 作业执行间短且资源需求稳定[^4] --- ### 2. **单作业模式 (Per-Job Mode)** - **核心特点**: - **作业级隔离**:每个作业启动独立的`JobManager`和专属`TaskManager`[^1][^3] - **资源控制精细**:通过参数指定资源(如`-ytm`设置TaskManager内存) - **提交命令示例**: ```bash bin/flink run \ -m yarn-cluster \ # YARN集群模式 -yqu high_priority \ # 指定队列 -ynm "Flink-ETL-Job" \ # 作业名称 -ys 2 \ # 每个TM的Slot数 -ytm 4096 \ # TM内存4GB -yjm 2048 \ # JM内存2GB -c com.example.ETLJob app.jar ``` - **适用场景**: - 生产环境关键作业(如实ETL) - 需要严格资源隔离的场景[^1][^4] --- ### 3. **应用模式 (Application Mode)** - **核心特点**: - **应用级隔离**:整个应用(含多个作业)共享一个集群,但与其他应用隔离[^3][^4] - **资源复用**:应用内作业复用`JobManager` - **工作流程**: 1. 提交应用启动专属`JobManager` 2. `JobManager`按需申请`TaskManager`资源[^3] - **优势**: - 避免客户端资源消耗(JAR包在集群端加载) - 适合微服务化部署[^4] - **提交命令**: ```bash bin/flink run-application \ -t yarn-application \ # YARN应用模式 -c com.example.Main app.jar ``` --- ### 关键对比总结 | **模式** | 集群生命周期 | 资源隔离粒度 | 适用场景 | 运维复杂度 | |----------------|--------------|--------------|--------------------------|------------| | **会话模式** | 长期运行 | 作业间共享 | 开发测试、临查询 | 低 | | **单作业模式** | 按作业启停 | 作业级隔离 | 生产环境关键任务 | 中 | | **应用模式** | 按应用启停 | 应用级隔离 | 微服务架构、持续生成作业 | 高 | > **部署差异**: > - 独立部署(Standalone)**不支持单作业模式**,需手动预启TaskManager[^2][^5] > - YARN/Kubernetes支持所有三种模式,且能自动管理资源[^1][^4] --- ### 模式选择建议 1. **开发阶段** → 会话模式(快速迭代) 2. **生产单作业** → 单作业模式(强隔离) 3. **流处理应用** → 应用模式(资源复用) 例如电商场景: - 实风控(高优先级)用 **单作业模式** - 用户行为分析流水线用 **应用模式** - 临数据探查用 **会话模式** ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值