Flink支持多种运行模式:
- Session Mode
- Per-Job Mode
- Application Mode
- Native Mode
我们知道Flink主要的组件有Client,JobManager和TaskManager。这4中运行模式区别是如何管理这些组件的生命周期。
这篇文章主要介绍这四种运行模式的介绍以及在不同的资源管理器上支持哪些模式。
运行模式
Session Mode
特点:
- 所有job共享相同的JobManager和一定数量的TaskManager
- JobManager/TaskManager的生命周期不受job影响,在job提交之前集群预先将JobManager和TaskManager创建好,并且job执行结束之后不会被销毁
- Client中生成JobGraph,然后提交给JobManager
优点:
- 资源共享,提升资源利用率
- 运维简单,不需要重复创建销毁JobManager和TaskManager
缺点:
- 资源隔离比较差,所有任务运行在相同的JobManager和TaskManager中
- 非Native类型部署,TaskManager不易扩展,Slot计算资源伸缩性差
- Client生成JobGraph会消耗大量CPU,并且生成之后发送给JobManager消耗网络带宽,如果频繁提交任务,Client的压力会非常大。并且Client是顺序提交任务的,一旦某一个任务执行时间过长就会阻塞后面提交的任务。
Per-Job Mode
特点:
- 每一个job都有单独的JobManager和TaskManager,随着job的提交而创建,job结束而销毁
- Client中生成JobGraph,然后提交给JobManager
优点:
- 资源隔离
- 根据不同的job可以申请不同大小的资源,slot数量可以不一样
缺点:
- 资源浪费,重复创建和销毁JobManager和TaskManager
- JobManager和TaskManager的生命周期全部交给CLusterManagement管理,管理复杂
- Client生成JobGraph会消耗大量CPU,并且生成之后发送给JobManager消耗网络带宽,如果频繁提交任务,Client的压力会非常大。并且Client是顺序提交任务的,一旦某一个任务执行时间过长就会阻塞后面提交的任务。
Application Mode
特点:
- 1.11版本之后支持
- Client将jar包等发送给JobManager,在JobManager中生成JobGraph。
优点:
- 降低客户端和网络压力
- Application实现资源隔离,Application中实现资源共享
缺点:
- 仅支持Yarn和kubernetes
Native Mode
特点:
- 支持Yarn,Mesos,Kubernetes
- Native模式是对Session和Per-Job的优化,把生成多少TaskManager交给资源调度器。
以Yarn为例:
-
Native Session
- 在一开始向Yarn申请资源创建ApplicationMaster,并在里面运行JobManager,所有的Job都是提交到这个JobManager中的。他的生命周期与Job无关。
- 其他Job提交的时候是共享同一个ApplicationMaster的,并在里面创建新的JobManager。
- Job的提交时,Yarn计算需要的资源之后分配Container,在Container中创建TaskManager执行任务
- Job运行结束TaskManager销毁,JobManager不销毁。
-
Native Per-Job
- Job提交的时候分配资源运行ApplicationMaster,并在里面创建JobManager。
- 其他Job提交的时候Yarn会创建新的ApplicationMaster,并在里面创建新的JobManager。
- Job提交的时候不需要提交TaskManager的数量,Yarn会计算需要的资源,分配Container,在Container中创建TaskManager执行任务
- Job运行结束的时候TaskManager和JobManager一起销毁,ApplicationMaster也会被销毁。
资源管理器
Flink可以运行在所有常见的资源管理器中,包括:
- Local
- Standalone
- Yarn
- Mesos
- Docker
- Kubernetes
各种资源调度器中支持的运行模式:
© 版权声明
文章版权归作者所有,未经允许请勿转载。
THE END