算子与作业提交
一、Flink执行模式
Flink对流处理和批处理采用统一的处理方式，执行模式可以通过execute.runtime-mode来配置。有三种可选的值：STREAMING：流模式，BATCH：批模式，AUTOMATIC：由系统决定。
1.流执行模式
在流模式下，所有任务需要一直在线运行，所以集群需要一次性分配足够的资源来运行所有任务。这样每个任务都可以立即执行新的记录，达到连续和低延迟的流处理。
流执行模式下，网络shuffle是流水式的，在网络层进行一些缓冲然后传递到下一个处理节点，在任务之间没有数据点。
2.批执行模式
在批处理模式下，作业可以一个阶段接一个阶段执行，集群只需要分配单个阶段的资源就可以运行任务。分阶段处理时Flink会将任务的中间结果保存到一些非永久性存储中，上游任务执行完毕可以下线，下游任务从存储中读取中间结果继续执行。
二、Flink拓扑图
1.基本概念
flink程序从编写到提交过程中执行图的转化涉及很多概念，在进行介绍执行图之前先了解一下Job、Operation、Task、SubTask、Task Slot等。
- Operation：由Flink Stream API提供的一系列操作算子，包括输入算子、计算算子和输出算子。
- Job：由用户将一系列Operation组合而成的程序，一个Job就是一个可以提交给Flink执行的作业。
- Task：在JobGraph中由一个算子或者多个算子链接在一起转化而来的逻辑上的运算节点
- SubTask：flink是一个并行的程序，因此按照并行度每个算子Task可以有多个算子子任务SubTask，每个算子子任务是彼此独立并在不同的线程中执行。
- TaskSlot：每个TaskManager都是一个JVM进程，包含的多个Task Slot是线程，每个TaskSlot可以执行一个或者多个SubTask。
2.拓扑图生成过程
Flink的应用程序是由flink算子组合而的dataflow所组成，Flink会将程序直接映射成数据流图StreamGraph，在提交到集群前会优化生成JobGraph。JobManager会根据并发度生成执行图ExecutionGraph，然后调度部署到TaskManager的TaskSlot中形成物理执行图。
Flink中从程序到最后的物理执行分为四层：StreamGraph->JobGraph->ExecutionGraph->物理执行。
- StreamGraph：是将用户Stream API算子组成的代码生成的数据流算子拓扑图。
- JobGraph：将数据流拓扑图中一些算子进行优化合并成一个Task拓扑图，这样可以减少两个算子之间数据的交换产生的延迟和消耗。
- ExecutionGraph：由JobManager根据JobGraph和并发度生产的可调度的subTask拓扑图。
- 执行图：集群调度时，各个TaskManager上Task Slot部署subTask的部署情况。
三、拓扑生成和优化
1.应用程序
应用程序用用户自定义的算子组成，由输入算子、计算算子、输出算子三类组成。
2.逻辑视图
在程序执行过程中，一个流可以有多个分区，也就是每个算子可以有多个子任务，每个任务并行的处理各自的数据。每个算子子任务的数量就是这个算子的并行度。
算子之间传输数据分为两种情况：
- 一对一模式：保留元素分区和顺序信息，也就是上游算子的输出的数据和顺序跟下游算子完全一致，也就是同一个分区数据只会进入下游算子的同一分区。
- 重新分发模式：会改变数据的分区信息，不同的算子会根据一些信息将数据重新发送到不同分区的下游算子。比如keyBy()会根据散列值重新分区。
3.算子链
如果将每个算子都转化成一个任务，这样计算过程可能会需要线程切换、中间结果缓冲等，增加了调度开销和系统的延迟，所以会把一些算子算作一个任务进行调度，可以减少开销和延迟。如果增加算子链优化后，逻辑执行图如下：
4.Task Slots
每个TaskManager都是一个JVM进程，包含的多个TaskSlot是线程，每个TaskSlot可以执行一个或者多个SubTask。
Flink支持SubTask共享slot，即来自同一个作业的SubTask由同一个TaskSlot执行。这样所需要的TaskSlot和作业并行度一致，可以更好的利用资源，增加并行度。
四、作业调度
1.调度
Flink集群中JobManager负责调度SubTask在TaskManager上的执行。TaskManager通过TaskSlot来定义执行资源，每个TaskSlot可以执行一个SubTask或者来自同一个作业的多个SubTask。
比如：由一个数据源、并行度为4的Map和并行度为3的Reduce组成的作业。那么在TaskManager实际分配资源如下。
2.拓扑图数据结构
在JobGraph中的Task由数据结构JobVertex表示，包含并行度和运行的代码。
在ExecutionGraph中的SubTask由数据结构ExecutionVertex表示，ExecutionVertex负责跟踪子任务的执行状态，而数据结构ExecutionJobVertex会负责跟踪任务的执行状态。
3.Job状态转化
Flink 作业刚开始会处于 created 状态，然后切换到 running 状态，当所有任务都执行完之后会切换到 finished 状态。
- 如果遇到失败的话，作业首先切换到 failing 状态以便取消所有正在运行的 task。
- 如果所有 job 节点都到达最终状态并且 job无法重启， 那么 job 进入 failed 状态。
- 如果作业可以重启，那么就会进入到 restarting状态，当作业彻底重启之后会进入到 created 状态。
- 如果用户取消了 job 话，它会进入到 cancelling 状态，并取消所有正在运行的 task。当所有正在运行的 task 进入到最终状态的时候，job 进入 cancelled 状态。
Finished、canceled 和 failed 会导致全局的终结状态，并且触发作业的清理。跟这些状态不同，suspended 状态只是一个局部的终结。局部的终结意味着作业的执行已经被对应的 JobManager 终结，但是集群中另外的 JobManager 依然可以从高可用存储里获取作业信息并重启。因此一个处于 suspended 状态的作业不会被彻底清理掉。
4.Task状态转化
在整个 ExecutionGraph 执行期间，每个并行 task 都会经历多个阶段，从 created 状态到 finished 或 failed。下图展示了各种状态以及他们之间的转换关系。由于一个 task 可能会被执行多次(比如在异常恢复时)，ExecutionVertex 的执行是由 Execution 来跟踪的，每个 ExecutionVertex 会记录当前的执行，以及之前的执行。
总结
主要介绍Flink执行模式以及Flink作业提交过程中拓扑图的生产和优化，还有作业调度和其中涉及的数据结构。
参考链接
1.Flink官网