本文是博主阅读官网文档、博客及书籍后自己所思所得，若是存在有误的地方，欢迎留言分享，谢谢！
一、任务调度
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。
二、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