谈一下Flink的部署模式和常用的集群资源管理器
部署模式规定了集群下各成员的启动逻辑、生命周期，资源的隔离性和可拓展性，而集群资源管理器为这些部署模式提供了资源。
部署模式有：session、per-job、Application以及Native模式，常用的集群资源管理器有：Flink standalone、Hadoop Yarn、K8s等。

一、部署模式：浅聊资源管理和Client端的压力

根据集群的生命周期、资源隔离方式，以及程序的main方法是在Client，还是在JobManager下执行划分为以下四种模式

1. session模式

job之间共享JobManager 和TaskManager 。

支持此模式的资源管理器：Local集群、Flink standalone集群、Yarn、K8s等

优点：
资源能够共享，提升资源利用率。job在Flink session集群集中管理，运维简单；

缺点：
资源隔离较差，存在任务干扰，尤其当一个任务达到业务高峰时可能导致整个节点下其他任务的运行延迟和卡顿；
TM不易拓展，Slot计算资源伸缩性较差。

2. Per-job模式

每个job单独启动都会启动一个Flink集群。集群的生命周期随着job停止，而消亡。

支持此模式的资源管理器：Yarn、K8s等

优点：Job之间是资源隔离的，TM中slot数量可以根据Job情况指定。
缺点：因为每一个job都会单独启动一个Jobmanager，所以会比较浪费资源；所有job的管理完全交给ClusterManagement，管理较复杂。

3. Session集群和Per-job集群的问题

每次都需要下载jar运行依赖，然后调用submit去上传jar和JobGraph，如果jar包过大（上百兆），那Client和jobManager之间就会有非常大的网络消耗。而且client本身生成JobGraph会消耗CPU资源。

当提交的任务比较多时，client的压力会非常大，造成稳定性的问题，且可能造成提交作业堵塞等待的问题。

优化：可以将上述工作直接交给JobManager减轻client的压力。Application模式就是这样的。
 

4. Application模式（1.11提出）

client只负责Job的提交，对于Dependencies jar下载和上传和JobGraph的生成，则交给JobManager，所以main方法会运行在JobManager。

支持此模式的资源管理器：Yarn、K8s等

优点：有效降低client和jobmanager之间的带宽消耗和client负载；
缺点：功能较新，未经过生产验证，且仅支持Yarn和k8s。

5. Native模式

Native模式下，当在某个资源管理器上启动Session集群时，只启动JobManager，不启动TaskManager。 当提交job-1时，集群根据Job的资源申请，动态启动TaskManager满足启动需求。此后，提交job-2，3。。。都会向资源管理器上申请TaskManager的资源，然后启动。

支持此模式的资源管理器：Yarn、K8s等

简单的说session集群会根据job的需求来动态的申请和启动TaskManager的资源。

二、Flink集群管理器

1. Standalone

standalone集群仅支持session部署模式，即一个JobManager，多个taskManager。
集群模式下只有一个JobManager，也就是只有一个提交job的入口，所有提交的job会共享TaskManager资源。

HA模式下可以有多个JobManager即JM的高可用，这样不会出现单点故障。

2. Per Job on Yarn

Yarn的集群架构简介：
它是典型的主从架构，ResourceManager支持HA

下面我们描述job提交到Yarn的过程

1. run jar提交到Flink Client上，client解析生成JobGraph后，submit到Yarn-RM。 Yarn-RM接收到Flink client的请求后，申请资源，然后（在Container中）启动ApplicationMaster，AM所在的Container下会启动Flink-RM和JobManager。
2. JobManager向Flink-RM申请slot资源，申请到资源后，Flink-RM向NM发出启动TaskManager请求，TM启动后向Flink-RM注册自己，然后JobManager开始部署Task到TM。
   

参考：
https://time.geekbang.org/course/detail/100058801-278258