截至1.12.0版本,Flink有3种集群部署/运行模式:
- Flink Session Cluster
- Flink Job Cluster
- Flink Application Cluster
三种运行模式主要区别在3个方面:
- 集群的生命周期
- 集群的资源隔离
main()
方法在Client侧执行还是在集群侧执行
下面分别介绍一下。
Flink Session Cluster
该模式就是先有一个已经在运行的Flink集群(至少有JobManager),然后我们把任务提交上去,所有的任务都运行在这一个集群上面,典型的场景就是Standalone模式静态部署的普通集群。此时:
- 集群生命周期:独立于任务,任务的开始、结束等不影响集群的生命周期。
- 集群的资源隔离:所有任务都运行在一个集群上面,所以隔离性差。Flink的Slot仅能隔离内存,并不能隔离CPU资源。而且一个任务如果把TaskManager搞挂了,那上面的其它任务也会受牵连。
main()
方法在Client侧执行。
该模式以前也称为"Flink Cluster in session mode".
Flink Job Cluster
该模式就是每个Job动态创建一个属于自己专有的集群,此时:
- 集群生命周期:与任务生命周期同步,随任务运行而创建,随任务结束而消亡。
- 集群的资源隔离:任务独占集群,隔离性最好。
main()
方法在Client侧执行。
该模式以前也称为"Flink Cluster in per-job mode".
Flink Application Cluster
一个Application指包含一个或多个任务(Job)的程序,也就是包含多个execute
或executeAsync
。该模式下,一个Application动态创建一个属于自己专有的集群,Application内的所有任务共享该集群,很显然这是一种介于Session Cluster和Job Cluster之间的模式:不同Application之间是完全隔离的,类似Job Cluster;但一个Application内的任务是不隔离的,类似于Session Cluster。此时:
- 集群生命周期:与Application生命周期同步,随Application运行而创建,随Application结束而消亡。
- 集群的资源隔离:Application之间隔离,Application内的所有任务共享集群,隔离性一般。
main()
方法在集群侧执行。
该模式以前也称为"Flink Cluster in application mode".
三种模式对比
其实也没啥对比的,各自的优缺点非常简单明显。要对比的话,主要的对比点就是资源隔离、main()
方法的执行位置、集群是否是动态创建三个方面。
- 就资源隔离性而言,Flink Job Cluster、Flink Application Cluster、Flink Session Cluster隔离性依次降低。
- Flink Application Cluster的
main()
方法是在集群侧的JobManager中执行的,其它两种模式是在Client端执行的。这个对于一些比较大型或复杂的应用来说区别还是挺大的,毕竟集群侧的资源一般是比较充足的,而且可以负载均衡。Client测去执行main()
方法可能会是一个瓶颈,特别是有多个人共享这个Client的时候。 - 集群动态创建这个不是所有模式都支持的,一般只有依赖Kubernetes、YARN之类的模式才可以。动态创建的好处就是动态扩展会比较好,特别是横向的扩展。但弊端是每次提交任务都要先创建一个集群,对于那些执行时间短、频次高的任务可能就不是特别合适。
常见集群管理框架对三种模式的支持
Flink也支持一些第三方的集群管理框架,当使用这些框架时,集群的资源管理都会交给这些框架。目前支持:
- Standalone:即不使用第三方集群管理框架,Flink自己管理集群。此时支持的运行模式包括:Session Cluster(Session Mode)、Application Cluster(Application Moe)。当容器化部署时(比如在Docker、K8s上面),也只支持这2种模式,不支持Job Cluster(Per-job mode)。
- Native Kubernetes:即使用K8s作为集群管理框架,Flink 1.12版本中已经正式可用,可参见我的这篇文章:Flink快速了解(4)——NativeKubernetes&HA. 需要注意该方式和在k8s上面部署Standalone集群是不一样的:Native Kubernetes是深度集成,将集群资源管理交给了k8s;而Standalone on K8s只是容器化部署而已,集群管理还是完全由Flink自己做的。该模式也不支持Job Cluster(Per-job mode),其它2种都支持。
- YARN:Hadoop生态最常用的资管管理、任务调度框架,功能很强大,一般在Hadoop生态部署Flink的,都会使用YARN管理Flink集群。Flink的3种运行模式在YARN上面都支持,且一般生产环境比较推荐Job Cluster(Per-job Mode)和Application Cluster(Application Mode)。
- Mesos:一个“古老”、强大且被广泛使用的集群管理器,与Flink集成时,不支持Application Cluster(Application Moe),其它2种都支持。
表格看着更清楚:
- | Session Cluster | Job Cluster | Application Cluster |
---|---|---|---|
Standalone(包括on Docker,on K8s) | 支持 | 不支持 | 支持 |
Native Kubernetes | 支持 | 不支持 | 支持 |
YARN | 支持 | 支持 | 支持 |
Mesos | 支持 | 支持 | 不支持 |
参考:
Yarn管理的资源,在Flink WebUI 上提交的Job好像只能使用Session Cluster模式,请问有办法设置为Job Cluster模式么(除了使用sh方式提交)?
纠正博主一个错误
Job Cluster用的比较多,Application Cluster主要是方便云化工具提交任务
Session Cluster生产不用的
是的,笔误了,应该是:
session cluster一般是有专门提供一个flink平台供其他组使用时采用。
已修正。
请问这三种模式在Standalone部署和其他资源管理器如Yarn上部署都可以吗
评论区不好说清楚,我已经在原文最后面增加一节说明,请查看。
博主太棒了 ,是我Flink文档看的不仔细。麻烦博主了
客气了 ?
application模式下提交任务成功后,之前起client作用的在集群端运行的应用实例会一直占用不释放吗?跟detach与否有关么?
不会,Application模式启动后,可以认为“没有”这个client了,这部分功能由JobManager代劳了:相当于此时JobManager接受到的不是一个JobGraph了,需要它自己做转化。detach这个概念是Session模式中的,Application没有这个说法。