Flink原理（四）——任务及调度

本文是博主阅读官网文档、博客及书籍后本身所思所得，如果存在有误的地方，欢迎留言分享，谢谢！

---

1、任务调度

　　Flink是经过task slot的来定义执行资源的，为优化资源的利用率，Flink经过slot共享，能够将多个连续的task任务组成的一个pipeline放在一个slot中运行。当任务并行度>1时，并行任务中的每一个pipeline就会分配到一个slot去执行，这样就会有一个问题，如果任务的并行度大于集群中slot的个数了，会咋办？首先，毫无疑问的一点是集群中的slot中都会有pipeline在跑；其次，多的任务就会等待现有的运行结束再去运行。下面结合官网中提供的例子说明通常状况下pipeline的分配状况[1]。

　　下图中，一个pipeline由Source - Map - Reduce组成，其中MapFunction的并行度为4，ReduceFunction的并行度为3，集群有两个TaskManager，其中每一个TaskManager有3个slot。

 

 　　图中，每个pipeline由一个颜色表示，其中包含3个小圈，每个圈表明一个算子，ReduceFunction的并行度为3，而MapFunction的为4，因此从Map->Reduce会发生shuffer。图中，任务会以ExecutionVertex 组成的 DAG 图的形式分配到两个TaskManage的slot中，在TaskManager2的slot中，运行在其中一个slot的DAG仅有两个ExecutionVertex ，这里会发生网络shuffer。

 2、JobManager 数据结构

　　运行在各个TaskManager的slot中任务的调度是经过JobManager完成，除此以外，JobManager还负责失败任务的重启等。

　　当JobManager接受到JobGraph（JobGraph 是数据流的表现形式，包括JobVertex和中间结果IntermediateDataSet，每一个算子都有诸如并行度和执行代码等属性）会将其转换为ExecutionGraph，二者之间的关系以下图所示：

　　对每一个 JobVertex，能够当作是通过算子优化组成一个个operator chain（每一个operator chain能够是一个或多个算子）和相关信息组成，而ExecutionVertex能够看作是JobVertex的并行版，假设组成一个JobVertex的operator chain的并行度为100，则在ExecutionGraph中，ExecutionVertex有100个，对应关系能够多看看上图。

　　在JobGraph转换到ExecutionGraph的过程当中[2]，主要发生了如下转变： 

• 加入了并行度的概念，成为真正可调度的图结构
• 生成了与JobVertex对应的ExecutionJobVertex，ExecutionVertex，与IntermediateDataSet对应的IntermediateResult和IntermediateResultPartition等，并行将经过这些类实现。

 每一个 ExecutionGraph 都有一个与其相关联的做业状态。此做业状态指示做业执行的当前状态，具体的状态图以下：

　　图中各个状态说明状况很清楚，就不详细说明，须要注意的是暂停状态的做业将可能不会被彻底清理。暂停状态（suspended）仅处于本地终止状态，在Flink的HA模式下，意味着做业的执行仅在相应的 JobManager 上终止，但集群的另外一个 JobManager 能够从持久的HA存储中恢复这个做业并从新启动。

Ref：

[1]https://ci.apache.org/projects/flink/flink-docs-release-1.6/internals/job_scheduling.html

[2]http://www.javashuo.com/article/p-khdfegoi-mh.html