目录
1. Session Mode
1.1 流程
1.2 优缺点总结
1.3 适用场景
2.Per-Job mode
2.1 流程
2.2 优缺点总结
2.3 适用场景
3. Session mode VS Per-Job mode
4. Application mode（flink 1.11+版本）
1. Session Mode
1.1 流程
（1）session mode会预分配资源，根据指定资源实现创建一个flink集群常驻与Yarn中，并启动一个JobManager和若干TaskManager。
（2）这时可以直接提交作业，节省了申请和分配资源的开销
1.2 优缺点总结
（1）该模式下所有job共享这些固定的资源，而且作业之间不能隔离，会出现资源竞争的情况。
（2）当一个TM发生故障，那么所有在这个节点上的job都会失败。
（3）当提交的作业越来越多时，JM的负载会越来越高。
1.3 适用场景
适合部署一些运行时间短，对延迟性要求不高的任务。
2.Per-Job mode
2.1 流程
每个Job提交到Yarn上，都会形成独立的flink集群，即拥有自己独立的JobManager和TaskManager。
2.2 优缺点总结
（1）由于提交作业时需要单独申请资源，因此启动时延迟会高一些。
（2）作业之间资源是独立的，也即Job之间是独立的互不影响，一个Job的TaskManager故障，不会影响其他Job。
（3）JM也是独立的，因此JM负载不会很高。
（4）Job完成后，会释放资源。不像Session mode，资源是常占的。
2.3 适用场景
Per-Job一般适用长时间运行的作业，通常生产环境可以使用这种模式。
3. Session mode VS Per-Job mode
以上两种模式，都需要一个客户端入口向Yarn发起提交请求，用来执行作业。在main方法执行之前，直到evn.execute()，客户端还需要做一些工作：
（1）获取作业相关依赖
（2）分析执行环境，并获取逻辑计划，通常讲就是从StreamGraph到JobGraph生成的过程。
（3）将依赖和JobGraph上传到集群。
如果在初始化分析阶段和获取依赖阶段，如果依赖东西非常多，那么就会占用更多带宽；
如果业务执行计划非常复杂，那么在解析转换逻辑计划，生成JobGraph时就需要更多CPU和内存，考虑到这种情况，如果在客户端做大量准备工作，客户端资源可能会成为瓶颈。
Session mode 和 Per-Job mode都存在这种情况，于是出现了下面的第3中mode，即Application mode.
4. Application mode（flink 1.11+版本）
（1）针对在客户端大量的准备工作，client所做的一些事情被转移到JM中，也就是说程序主方法在集群中执行，入口点在ApplicationClusterEntryPoint。client只负责提交即可。
（2）针对大量依赖占用带宽的问题，可以将flink作业依赖的jar包提前上传至hdfs即可，然后通过yarn.provided.lib.dirs来指定依赖存储的路径即可，这样就会从hdfs上拉取，NodeManager也会缓存一些依赖，进一步加速作业提交。
# 使用Application mode提交作业的demo bin/flink run-application -t yarn-application -Djobmanager.memory.process.size=2048m -Dtaskmanager.memory.process.size=4096m -Dtaskmanager.numberOfTaskSlots=2 -Dparallelism.default=10 -Dyarn.application.name="MyFlinkApp" -Dyarn.provided.lib.dirs="hdfs://myhdfs/flink-common-deps/lib;hdfs://myhdfs/flinkcommon-deps/plugins"
以上内容是在学习《大数据技术架构手册（公众号：进击吧大数据）编制》一书时做的总结，感谢知识分享。
