flink运行架构详解
一、开发模式
per-job-cluster 提交模式
1.一个Job会对应一个Flink集群，每提交一个作业会根据自身的情况，都会单独向yarn申请资源，直到作业执行完成，一个作业的失败与否并不会影响下一个作业的正常提交和运行。独享Dispatcher和ResourceManager，按需接受资源申请；适合规模大长时间运行的作业。
2.优点
每次提交都会创建一个新的flink集群，任务之间互相独立，互不影响，方便管理。任务执行完成之后创建的集群也会消失。
Session-Cluster
1.Session-Cluster模式需要先启动Flink集群，向Yarn申请资源。以后提交任务都向这里提交。这个Flink集群会常驻在yarn集群中，除非手工停止。
2.缺点
如果提交的作业中有长时间执行的大作业, 占用了该Flink集群的所有资源, 则后续无法提交新的job.
3.优点
Session-Cluster适合那些需要频繁提交的多个小Job, 并且执行时间都不长的Job.
（因为使用其他模式 频繁提交多个小job，导致申请资源时间大于 执行job时间）
二、运行时架构
1 job manager
1>ResourceManager
整个 Flink 集群中只有一个 ResourceManager. 注意这个ResourceManager不是Yarn中的ResourceManager, 是Flink中内置的, 只是赶巧重名了而已.
主要负责管理任务管理器（TaskManager）的插槽（slot），TaskManger插槽是Flink中定义的处理资源单元。
2>Dispatcher
负责接收用户提供的作业，并且负责为这个新提交的作业启动一个新的JobMaster 组件. Dispatcher也会启动一个Web UI，用来方便地展示和监控作业执行的信息。Dispatcher在架构中可能并不是必需的，这取决于应用提交运行的方式。
3> JobMaster
JobMaster负责管理单个JobGraph的执行.多个Job可以同时运行在一个Flink集群中, 每个Job都有一个自己的JobMaster.
2.TaskManager
Flink中的工作进程。通常在Flink中会有多个TaskManager运行，每一个TaskManager都包含了一定数量的插槽（slots）。插槽的数量限制了TaskManager能够执行的任务数量。
启动之后，TaskManager会向资源管理器注册它的插槽；收到资源管理器的指令后，TaskManager就会将一个或者多个插槽提供给JobManager调用。JobManager就可以向插槽分配任务（tasks）来执行了。
任务流程
- Flink任务提交后，Client向HDFS上传Flink的Jar包和配置
- 向Yarn ResourceManager提交任务，ResourceManager分配Container资源
- 通知对应的NodeManager启动ApplicationMaster，ApplicationMaster启动后加载Flink的Jar包和配置构建环境，然后启动JobManager
- ApplicationMaster向ResourceManager申请资源启动TaskManager
- ResourceManager分配Container资源后，由ApplicationMaster通知资源所在节点的NodeManager启动TaskManager
- NodeManager加载Flink的Jar包和配置构建环境并启动TaskManager
TaskManager启动后向JobManager发送心跳包，并等待JobManager向其分配任务。
三、核心概念
什么是slot？
插槽，每个TaskManager 默认配置 1。 一般配置和cpu核心数，多个slot均分 TaskManager 的内存资源，与其他slot之间 内存隔离，共享cpu资源。slot内共享（多个task 和共享一块内存）
一个job 分配多少个 slot？
所有slot共享组最大并行度之和
slot 共享组？
.slotSharingGroup("group1")
默认只有一个共享组。不同的共享组之间一定占用不同的slot
任务链？
多个算子 之间 组成任务链
Stream在算子之间传输数据的形式可以是one-to-one(forwarding)的模式也可以是redistributing的模式，具体是哪一种形式，取决于算子的种类。
- One-to-one：
stream(比如在source和map operator之间)维护着分区以及元素的顺序。那意味着flatmap 算子的子任务看到的元素的个数以及顺序跟source 算子的子任务生产的元素的个数、顺序相同，map、fliter、flatMap等算子都是one-to-one的对应关系。
- Redistributing：
stream(map()跟keyBy/window之间或者keyBy/window跟sink之间)的分区会发生改变。每一个算子的子任务依据所选择的transformation发送数据到不同的目标任务。例如，keyBy()基于hashCode重分区、broadcast和rebalance会随机重新分区，这些算子都会引起redistribute过程，而redistribute过程就类似于Spark中的shuffle过程。
并行度相同的 前后两个算子，并且one_to_one传输，则flink （自动优化）会将这两个 task合并。
目的：减少数据交换产生的消耗，在减少时延的同时提升吞吐量。
当然也可以断开这两个算子
* 算子.startNewChain() => 与前面断开
* 算子.disableChaining() => 与前后都断开
* env.disableOperatorChaining() => 全局都不串
断开操作链的好处在于减少某个slot的压力。