8.一文搞定Flink单作业提交模式（per-job）的运行时状态

Posted 2023-03-20

参考技术A 在Flink进行数据处理的时候，有两个最重要的两个组件，分别是：作业管理器（JobManager）和任务管理器（TaskManager）。对于一个提交执行的作业，JM是真正的管理者，负责管理和调度工作。如果集群没有配置高可用的话，只能有一个JM。TM是负责工作的工作者，负责执行任务和处理数据，所以可以有很多个。

整个JM由三个部分组成，分别是JobMaster、ResourceManager、Dispatcher。

JMaster是JManager中最核心的组件，负责处理单独的作业。所以每一个Job都会有一个对应JobMaster与之对应，多个job可以同时运行在一个FLink集群中，也就证明一个Flink集群中可以有多个JobMaster同时存在。在作业被提交的时候，JMaster会率先接受到要执行的应用。这些应用包括：Jar包、数据流图（dataflow graph）、作业图（JobGraph）。然后将接收到的作业图转换成为一个物理层面的数据流图，也就是执行图，这个执行图包含了所有要并发执行的任务。随后JMaster会根据这个执行图去到RM中申请必要的资源。一旦获得到了足够的资源，就会将执行图发送到要运行执行图的TaskMaster上面。并且在程序运行的过程中，JobMaster会负责协调所有的需要中央协调的工作，如保存点机制。

RM在Flink的集群中只有一个，它主要负责的是资源的分配与管理，也就是对TaskManager上的solt的分配工作。并且在面对不同的环境的时候，RM也有不同的体现。如果是standalone，因为TM是独立运行的，所有RM只能分发可用的TM的任务槽，没办法单独启动TM。但是如果是yarn的工作模式下，RM能够将有空闲的TM发送给JMaster，如果资源不够使用的话，就会向yarn发起请求提供启动TM的容器。并且如果有的TM处于空闲状态，RM还负责停止它们的工作。

它主要负责提供Rest风格的接口来提交应用。并且还负责为每一个新提交的作业启动一个新的JMaster组件，并且还会启动一个WEB UI，方便用来展示和键控作业执行的信息。

TM负责FLink集群中的具体工作部分，数据流的计算就是由这个组件来完成的，每一个TM都会有一定数量的任务槽，这个任务槽是一个TM上最小的资源封装单位，solt的数量决定了TM能够并行处理的任务的数量。在TM启动之后，会向RM注册自己的solt，当收到RM对其发送的指令之后，就会根据要求发送能够提供计算的solt给JMaster调用，这样数据计算就能够实现了，并且在进行计算的过程中，TaskManager可以缓冲数据，还能够与其他的TM交互完成数据的交换。

因为我本人所接触的Flink的部署模式都是基于资源管理平台yarn来实现工作的，采用的作业提交方式也是通过per-job提交方式进行提交的，所以在本次讲述的过程中，也是以这个内容为蓝本展开讲解。

yarn-per-job作业提交流程：
在单作业模式下，Flink集群不会预先启动，而是在进行作业提交的时候，才会启动新的JobManager。

1.客户端向yarn提交作业，并且需要将Flink的Jar包和配置文件信息上传到HDFS，以便后续启动FLink相关组件的容器。
2.YARN资源管理器分配Container资源，启动Application Master，这个APP里面包含了Flink的JobManager，并且要将提交上来的作业交给JMaster。
3.JMaster向flink的rm请求资源。
4.flink的rm向yarn请求container资源。
5.yarn启动包含TM的container资源。
6.TM向JMaster注册自己拥有的solt数量。
7.flink的RM向TM申请solt。
8.TM连接到对应的JMaster，然后通过solt。
9.JMaster将要执行的任务分发给TM，执行。

大数据Flink进阶（十三）：Flink 任务提交模式

文章目录

Flink 任务提交模式

一、会话模式（Session Mode）

二、单作业模式（Per-Job Mode）

三、应用模式（Application Mode）

---

Flink 任务提交模式

Flink分布式计算框架可以基于多种模式部署，每种部署模式下提交任务都有相应的资源管理方式，例如：Flink可以基于Standalone部署模式、基于Yarn部署模式、基于Kubernetes部署模式运行任务，以上不同的集群部署模式下提交Flink任务会涉及申请资源、各角色交互过程，不同模式申请资源涉及到的角色对象大体相同，下面我们以Flink运行时架构流程为例来总体了解下Flink任务提交后涉及到对象交互流程，以便后续学习不同任务提交模式下任务提交流程。

上图是Flink运行时架构流程，涉及集群启动、任务提交、资源申请分配整个流程，大体步骤如下：

1. 启动Flink集群首先会启动JobManager，Standalone集群模式下同时启动TaskManager，该模式资源也就固定；其他集群部署模式会根据提交任务来动态启动TaskManager；
2. 当在客户端提交任务后，客户端会将任务转换成JobGraph提交给JobManager；
3. JobManager首先启动Dispatcher用于分发作业，运行Flink WebUI提供作业执行信息；
4. Dispatcher启动后会启动JobMaster并将JobGraph提交给JobMaster，JobMaster会将JobGraph转换成可执行的ExecutionGraph。
5. JobMaster向对应的资源管理器ResourceManager为当前任务申请Slot资源；
6. 在Standalone资源管理器中会直接找到启动的TaskManager来申请Slot资源，如果资源不足，那么任务执行失败；
7. 其他资源管理器会启动新的TaskManager，新启动的TaskManager会向ResourceManager进行注册资源，然后ResourceManager再向TaskManager申请Slot资源，如果资源不足会启动新的TaskManager来满足资源；
8. TaskManager为对应的JobMaster offer Slot资源；
9. JobMaster将要执行的task发送到对应的TaskManager上执行，TaskManager之间可以进行数据交换。

 以上就是Flink任务提交的整体流程信息，在Flink中任务提交还有多种模式，不同的Flink集群部署模式支持的任务提交模式不同，对应的任务执行流程略有不同，向Flink集群中提交任务有三种任务部署模式，分别如下：

• 会话模式 - Session Mode
• 单作业模式 - Per-Job Mode(过时)
• 应用模式 - Application Mode

以上三种任务提交模式的主要区别在于Flink集群的生命周期不同、资源的分配方式不同以及Flink 应用程序的main方法执行位置（Client客户端/JobManager）不同。

下面分别进行介绍：

一、会话模式（Session Mode）

Session模式下我们首先会启动一个集群，保持一个会话，这个会话中通过客户端提交作业，集群启动时所有的资源都已经确定，所以所有的提交的作业会竞争集群中的资源。这种模式适合单个作业规模小、执行时间短的大量作业。

优势：只需要一个集群，所有作业提交之后都运行在这一个集群中，所有任务共享集群资源，每个任务执行完成后就释放资源。

缺点：因为集群资源是共享的，所以资源不够了，提交新的作业就会失败，如果一个作业发生故障导致TaskManager宕机，那么所有的作业都会受到影响。

二、单作业模式（Per-Job Mode）

为了更好的隔离资源，Per-job模式是每提交一个作业会启动一个集群，集群只为这个作业而生，这种模式下客户端运行应用程序，然后启动集群，作业被提交给JobManager，进而分发给TaskManager执行，作业执行完成之后集群就会关闭，所有资源也会释放。

优势：这种模式下每个作业都有自己的JobManager管理，独享当下这个集群的资源，就算作业发生故障，对应的TaskManager宕机也不影响其他作业。如果一个Application有多个job组成，那么每个job都有自己独立的集群。

缺点：每个作业都在客户端向集群JobManager提交，如果一个时间点大量提交Flink作业会造成客户端占用大量的网络带宽，会加重客户端所在节点的资源消耗。

注意：Per-Job 模式目前只有yarn支持，Per-job模式在Flink1.15中已经被弃用，后续版本可能会完全剔除，替代的是Application模式，主要原因就是Application模式把main方法的初始化放到了集群组件的JobManager中，这样对于客户端来说从性能上有很大优化。

三、应用模式（Application Mode）

Session 模式和Pre-Job模式都是在客户端将作业提交给JobManager，这种方式需要占用大量的网络带宽下载依赖关系并将二进制包发送给JobManager,此外，我们往往提交多个Flink 作业都是在同一个客户端节点，这样更加剧了客户端所在节点的资源消耗，为了降低客户端这种资源消耗，我们可以使用Application Mode。

Application模式与Per-job类似，只是不需要客户端，每个Application提交之后就会启动一个JobManager，也就是创建一个集群，这个JobManager只为执行这一个Flink Application而存在，Application中的多个job都会共用该集群，Application执行结束之后JobManager也就关闭了。这种模式下一个Application会动态创建自己的专属集群（JobManager）,所有任务共享该集群,不同Application之间是完全隔离的，在生产环境中建议使用Application模式提交任务。

以上三种Flink任务部署方式生产环境中优先选择Application模式，三者区别总结如下：

1. Session 模式是先有Flink集群后再提交任务，任务在客户端提交运行，提交的多个作业共享Flink集群；
2. Per-Job模式和Application模式都是提交Flink任务后创建集群；
3. Per-Job模式通过客户端提交Flink任务，每个Flink任务对应一个Flink集群，每个任务有很好的资源隔离性；
4. Application模式是在JobManager上执行main方法，为每个Flink的Application创建一个Flink集群，如果该Application有多个任务，这些Flink任务共享一个集群。

Flink不同的集群部署模式支持不同的任务提交方式，后续会重点介绍Standalone资源管理和Yarn资源管理任务提交模式的支持。

---

• 📢博客主页：https://lansonli.blog.csdn.net
• 📢欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正！
• 📢本文由 Lansonli 原创，首发于 CSDN博客🙉
• 📢停下休息的时候不要忘了别人还在奔跑，希望大家抓紧时间学习，全力奔赴更美好的生活✨