概述
本文档简要介绍Flink如何进行作业调度,及其如何表示和跟踪JobManager上的作业状态。
注意:本文flink官方的一篇文档的翻译,原文链接在这里。
调度(Scheduling)
Flink中的执行资源通过任务槽(Task Slots)来定义。每个TaskManager都有一个或多个任务槽,每个槽都可以运行一个并行任务管道(pipeline of parallel tasks)。管道由多个连续任务组成,例如MapFunction的第n个并行实例以及ReduceFunction的第n个并行实例。请注意,Flink经常并行执行连续任务(successive tasks):对于流程序,无论如何都会发生,但对于批处理程序,它经常发生。
下图说明了这一点。考虑一个带有数据源,MapFunction和ReduceFunction的程序。源和MapFunction以4的并行度(parallelism)执行,而ReduceFunction以3的并行度执行。管道由序列Source - Map - Reduce组成。在具有2个TaskManagers且每个具有3个插槽的群集上,程序将按如下所述执行。
在内部,Flink通过SlotSharingGroup和CoLocationGroup定义哪些任务可以共享一个槽(允许),哪些任务必须严格地放在同一个槽中。
JobManager数据结构
在作业执行期间,JobManager会跟踪分布式任务,决定何时安排下一个任务(或一组任务),并对已完成的任务或执行失败做出反应。
JobManager接收JobGraph,它是由运算符(JobVertex)和中间结果(IntermediateDataSet)组成的数据流的表示。每个运算算子(operator)都具有属性,例如并行性和它执行的代码。此外,JobGraph还有一组附加库,这些库是执行运算算子代码代码所必需的。
JobManager将JobGraph转换为ExecutionGraph。ExecutionGraph是JobGraph的并行版本:对于每个JobVertex,它包含每个并行子任务的ExecutionVertex。并行度为100的算子(operator)将具有一个JobVertex和100个ExecutionVertices。ExecutionVertex跟踪特定子任务的执行状态。来自一个JobVertex的所有ExecutionVertices都保存在ExecutionJobVertex中,它跟踪整个运营商的状态。除了顶点之外,ExecutionGraph还包含IntermediateResult和IntermediateResultPartition。前者跟踪IntermediateDataSet的状态,后者是每个分区的状态。
每个ExecutionGraph都有一个与之关联的作业状态。此作业状态指示作业执行的当前状态。
Flink作业首先处于创建状态(created state),然后切换到运行状态(running),并在完成所有工作后切换到已完成(finished)。如果出现故障,作业将首先切换为取消状态(failing),然后取消所有正在运行的任务。如果所有作业(job)顶点都已达到最终状态且作业无法重新启动,则作业将转换为已失败状态(failed)。如果可以重新启动作业,则它将进入重新启动状态(restarting)。作业完全重新启动后,将达到创建状态(created)。
在用户取消作业的情况下,它将进入取消状态。这还需要取消所有当前正在运行的任务。一旦所有正在运行的任务都达到最终状态,作业将转换为取消状态。
与完成,取消和失败的状态不同,它表示全局终端状态,因此触发清理作业,暂停状态仅在本地终端。本地终端意味着作业的执行已在相应的JobManager上终止,但Flink群集的另一个JobManager可以从持久HA存储中检索作业并重新启动它。因此,达到暂停状态的作业将不会被完全清除。
在执行ExecutionGraph期间,每个并行任务都经历多个阶段,从创建到完成或失败。下图说明了它们之间的状态和可能的转换。任务可以多次执行(例如在故障恢复过程中)。因此,在Execution中跟踪ExecutionVertex的执行。每个ExecutionVertex都有一个当前的Execution和先前的Executions。
总结
本文是一篇翻译文章,来自flink的官方。本文介绍了flink任务执行的大致过程,并对任务执行的状态转换进行了分析和说明。