《Flink 技术内幕之 Jobs and Scheduling》（官网翻译）

目录

一、Scheduling

二、JobManager Data Structures

---

本文简要描述了Flink如何调度作业，以及它如何表示和跟踪JobManager的作业状态。

一、Scheduling

Flink中的执行资源是通过任务槽（Task Slots）定义的。每个TaskManager将有一个或多个任务槽，每个任务槽可以运行一个并行任务管道。管道由多个连续的任务组成，例如MapFunction的第n个并行实例和ReduceFunction的第n个并行实例。注意，Flink经常并发地执行连续的任务:对于流媒体程序，这在任何情况下都会发生，对于批处理程序，这种情况也经常发生。

下图说明了这一点。假设一个带有data source、MapFunction和ReduceFunction的程序。source和MapFunction的并行度为4,ReduceFunction的并行度为3。管道由序列Source - Map - Reduce组成。在一个有2个TaskManager，每个TaskManager有3个插槽的集群上，程序将按如下所述执行。

在内部，Flink通过SlotSharingGroup和CoLocationGroup定义哪些任务可以共享一个插槽(允许的)，哪些任务必须严格放置在同一个插槽中。 

二、JobManager Data Structures

在作业执行期间，JobManager跟踪分布式任务，决定何时调度下一个任务(或一组任务)，并对完成的任务或执行失败做出反应。

JobManager接收JobGraph，它是由操作符(JobVertex)和中间结果(IntermediateDataSet)组成的数据流的表示。每个操作符都有属性，比如并行度以及它所执行的代码。此外，JobGraph还有一组附加的库，这些库是执行操作符代码所必需的。

JobManager将JobGraph转换为ExecutionGraph。ExecutionGraph是JobGraph的并行版本:对于每个JobVertex，它包含每个并行子任务的ExecutionVertex。并行度为100的操作符将有一个JobVertex和100个ExecutionVertices。ExecutionVertex跟踪特定子任务的执行状态。来自一个JobVertex的所有ExecutionVertices都保存在一个ExecutionJobVertex中，它作为一个整体跟踪操作符的状态。除了Vertex，ExecutionGraph还包含了IntermediateResult和IntermediateResultPartition。前者跟踪IntermediateDataSet的状态，后者跟踪IntermediateDataSet每个分区的状态。

每个ExecutionGraph都有一个与之关联的作业状态。此作业状态指示作业执行的当前状态。 

Flink作业首先处于created状态，然后切换到running，完成所有工作后切换到finished。如果发生故障，作业首先切换到failing，取消所有正在运行的任务。如果所有作业顶点都已达到最终状态，且作业不可重新启动，则作业转换为failed。如果作业可以重新启动，那么它将进入restarting状态。一旦作业完全重新启动，它将达到created的状态。

如果用户取消作业，它将进入cancelling 状态。这还需要取消当前运行的所有任务。一旦所有正在运行的任务都达到最终状态，作业转换到cancelled 状态。

与表示全局终端状态(会触发作业清理)的已完成、已取消和已失败状态不同，suspended （挂起）状态仅是本地终端。本地终端意味着作业的执行已经在各自的JobManager 上终止，但是Flink集群的另一个JobManager可以从持久HA存储中检索作业并重新启动它。因此，达到suspended 状态的作业不会被完全清除。

在执行ExecutionGraph期间，每个并行任务都经历多个阶段，从created 到finished 或failed 。下图说明了它们之间的状态和可能的转换。任务可以执行多次(例如在故障恢复过程中)。因此，ExecutionVertex的执行过程在Execution程中跟踪。每个ExecutionVertex都有一个当前Execution和先前Execution。 

参考：https://ci.apache.org/projects/flink/flink-docs-release-1.7/internals/job_scheduling.html

注：转载请注明出处