FlinkPerJob模式和Application模式的区别
PerJob 模式
考虑到集的资源隔离情况，⼀般⽣产上的任务都会选择per job模式，也就是每个任务启动⼀个flink集，各个集之间独⽴运⾏，互不影响，且每个集可以设置独⽴的配置。
特点：每次递交作业都需要申请⼀次资源
优点：作业运⾏完成，资源会⽴刻被释放，不会⼀直占⽤系统资源
缺点：每次递交作业都需要申请资源，会影响执⾏效率，因为申请资源需要消耗时间
应⽤场景：适合作业⽐较少的场景、⼤作业的场景
Application 模式
flink-1.11 引⼊了⼀种新的部署模式，即 Application 模式。⽬前，flink-1.11 已经可以⽀持基于 Yarn 和 Kubernetes 的 Application 模式。
Session模式：所有作业共享集资源，隔离性差，JM 负载瓶颈，main ⽅法在客户端执⾏。
Per-Job模式：每个作业单独启动集，隔离性好，JM 负载均衡，main ⽅法在客户端执⾏。
通过以上两种模式的特点描述，可以看出痛点
1 main⽅法都是在客户端执⾏，社区考虑到在客户端执⾏ main() ⽅法来获取 flink 运⾏时所需的依赖项，并⽣成 JobGraph，提交到集的操作都会在实时平台所在的机器上执⾏，那么将会给服务器造成很⼤的压⼒。尤其在⼤量⽤户共享客户端时，问题更加突出。
2 这种模式提交任务的时候会把本地flink的所有jar包先上传到hdfs上相应的临时⽬录，这个也会带来⼤量的⽹络的开销，所以如果任务特别多的情况下，平台的吞吐量将会直线下降。
因此，社区提出新的部署⽅式 Application 模式解决该问题。
Application 模式下，
⽤户程序的 main ⽅法将在集中⽽不是客户端运⾏！
⽤户程序的 main ⽅法将在集中⽽不是客户端运⾏！
⽤户程序的 main ⽅法将在集中⽽不是客户端运⾏！
⽤户将程序逻辑和依赖打包进⼀个可执⾏的 jar 包⾥，集的⼊⼝程序 (ApplicationClusterEntryPoint) 负责调⽤其中的 main ⽅法来⽣成 JobGraph。Application 模式为每个提交的应⽤程序创建⼀个集，该集可以看作是在特定应⽤程序的作业之间共享的会话集，并在应⽤程序完成时终⽌。
在这种体系结构中，Application 模式在不同应⽤之间提供了资源隔离和负载平衡保证。在特定⼀个应⽤程序上，JobManager 执⾏
main() 可以节省所需的 CPU 周期，还可以节省本地下载依赖项所需的带宽。
main⽅法⼊⼝点运⾏的在client还是cluster端的不同
有图为证：
Application Mode
其他所有的部署模式，其应⽤的main()⽅法都是在client端运⾏的。运⾏的过程包括下载应⽤的依赖到本地，执⾏main()⽅法导出Flink能执⾏的dataflow graph，⽐如JobGraph，然后把依赖和JobGraph(s)发给Flink集。这种⽅式是的客户端资源消耗⽐较严重，因为需要⼤量的⽹络带宽去下载依赖和传送最终的⼆进制代码⽚段给FLink集，并且需要CPU时间⽚来执⾏main()⽅法。如果你的client端还有其他的⽤户应⽤的话，问题将会更加凸显。
基于上述的理解，Application模式创建的只有⼀个job的集，并且应⽤程序的main()⽅法在JobManager上运⾏。⼀个application模式的集我们其实可以看做是包含⼀个应⽤程序包含了多个job的session模式的集。通过架构图，我们可以看出application模式的资源隔离，负载均衡保障和Per-J
ob模式是⼀样的，但是它们的粒度不同。Application模式下在JobManager上运⾏main()⽅法节省CPU时间，同时也节省了带宽和时间。
注意： 在application模式下，main()⽅法是执⾏在集上，不是像在其他模式下在client上运⾏。这可能对你的带有所影响，你的代码中要访问外部的某⼀个链接，那么jobmanager必须能访问这个链接才⾏，否则你的程序就会因为访问不到这个链接⽽产⽣问题。
对⽐Per-Job的模式，application模式允许提交的应⽤程序包含多个Job。Job的顺序不会受到不同的部署⽅式的影响，但是会受到execute()是什么时候调⽤的影响。我们程序中使⽤execute()开启多个Job的时候，会建⽴⼀个类似于同步队列的Job队列，也就是说只有当前⼀个job执⾏完成以后，后⾯的job才会开始执⾏。⽽使⽤executeAsync()开启多个Job，会简历⼀个异步的Job队列。
注意：Application模式上运⾏⼀个包含多个Job的应⽤程序时，HA是不⽀持这种部署的情况的。application模式下的HA只⽀持这个应⽤程序中只有⼀个Job.
Per-Job Mode
为了提供更好的资源隔离机制，Per-Job模式使⽤常⽤的资源调度框架(e.g. YARN,k8s)来为⼀个Job创建⼀个集。这个集只为这⼀个Job⽽⽣。当这个Job执⾏完毕，集也随之⽽关闭，其他中间产⽣
session和application的区别或缓存的⽂件将会被清理。这种资源隔离机制更好，因为当Job发⽣错误时只会使⾃⼰集的taskmanager挂掉。此外，它还能将⼯作负载分散到多个JobManager上，因为整个集就只有⼀个Job. 综上所
述，Per-Job模式是很多⽣产服务器喜欢采⽤的的模式。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。