Flink入门教程--Jobs and Scheduling(任务和调度)

本文介绍了Apache Flink中Job的调度过程及其在JobManager上的表现与跟踪方式。通过任务槽(TaskSlot)定义执行资源,并利用SlotSharingGroup和CoLocationGroup来指定哪些任务共享同一任务槽。JobManager将JobGraph转换为ExecutionGraph来跟踪任务执行状态。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

原谅链接:https://ci.apache.org/projects/flink/flink-docs-release-1.3/internals/job_scheduling.html#jobs-and-scheduling

该文档简单描述了Flink是如何调度Job的,以及如何在JobManager上表现并跟踪Job状态。

调度

Flink通过任务槽(Task Slot)定义执行资源,每个TaskManager都有一或多个任务槽,每个任务槽都可以运行一个并行任务流,一个流包括多个连续的任务,例如一个MapFunction的第n个并行实例与一个ReduceFunction的第n个并行实例的连续任务。注意,Flink通常会并发执行连续的任务,对于Streaming 程序来说,任何情况都如此执行;而对于batch 程序,多数情况也如此执行。

下图举例说明。由一个data source、一个MapFunction和一个ReduceFunction组成的程序,data source和MapFunction的并发度都为4,而ReduceFunction的并发度为3。一个数据流由Source-Map-Reduce的顺序组成,在具有2个TaskManager,每个TaskManager都有3个Task Slot的集群上运行,则程序执行情况如图所述。

Assigning Pipelines of Tasks to Slots

Flink内通过SlotSharingGroupCoLocationGroup来定义哪些task共享一个task slot,也可以自定义某些task部署到同一个task slot中。

JobManager数据结构

在job执行期间,JobManager会持续跟踪分布式任务,来决定什么时候调度下一个task(或者tasks),并且对完成的或执行失败的任务进行响应。

JobManager接收JobGraph,JobGraph是数据流的表现形式,包括Operator(JobVertex)和中间结果(intermediateDataSet)。每个Operator都有诸如并行度和执行代码等属性。此外,JobGraph还拥有一些在Operator执行代码时所需要的附加库。

JobManager将JobGraph转换为ExecutionGraph,ExecutionGraph是JobGraph的并行版本:对每个JobVertex,它的每个并行子任务都有一个https://d.docs.live.net/72f746bc85b3dbdf/%E6%96%87%E6%A1%A3/Flink/Documents.one“>ExecutionVertex。一个并行度为100的Operator将拥有一个JobVertex和100个ExecutionVertex。ExecutionVertex会跟踪其特定子任务的执行状态。来自一个JobVertex的所有ExecutionVertex都由一个ExecutionJobVertex管理,ExecutionJobVertex跟踪Operator总体的状态。除了这些节点之外,ExecutionGraph同样包括了IntermediateResultIntermediateResultPartition,前者跟踪IntermediateDataSet的状态,后者跟踪每个它的partition的状态。

JobGraph and ExecutionGraph

每个ExecutionGraph具有与其相关联的作业状态。此作业状态指示作业执行的当前状态。

Flink job首先处于创建状态,然后切换到运行状态,并且在完成所有工作后,它将切换到完成状态。在失败的情况下,job切换到第一个失败点,即取消所有正在运行任务的地方。如果所有job节点都已达到最终(或者说不可更改)状态,并且job不可重新启动,则job将转换为失败。如果作业可以重新启动,那么它将进入重新启动状态。一旦完成重新启动,它将变成创建状态

在用户取消作业的情况下,将进入取消状态 ,这需要取消所有当前正在运行的任务。一旦所有运行的任务已经达到最终(或者说不可更改)状态,该作业将转换到已取消状态

完成状态不同,取消状态失败状态表示一个全局的终端状态,并且触发清理工作,而暂停状态仅处于本地终端上。本地终端意味着job的执行已在相应的JobManager上终止,但Flink集群的另一个JobManager可以从持久的HA存储中恢复这个job并重新启动。因此,处于暂停状态的job将不会被完全清理。

States and Transitions of Flink job

在执行ExecutionGraph期间,每个并行任务经过多个阶段,从创建完成失败 ,下图说明了它们之间的状态和可能的转换。任务可以执行多次(例如故障恢复)。所以,一个Execution跟踪一个ExecutionVertex的执行,每个ExecutionVertex都有一个当前Execution(current execution)和一个前驱Execution(prior execution)。

States and Transitions of Task Executions

### 定时任务在分布式系统中的批处理 #### 实现方式 在现代分布式环境中,传统的单体架构下的定时任务解决方案如QuartzSpring Scheduling已难以满足复杂的需求。随着业务扩展技术演进,分布式任务调度中间件成为更优的选择[^1]。 为了应对大规模分布式的挑战,可以采用专门构建用于支持跨多个节点的任务协调工具。这类工具有Apache Airflow, Apache Flink, Distributed Cron Jobs等。它们不仅能够提供基本的周期性触发功能,还具备强大的错误恢复机制、依赖关系管理工作流编排能力。 以下是基于Python的一个简单例子来展示如何利用`celery beat`作为中央控制器,在多台服务器上安排并行执行批量操作: ```python from celery import Celery from datetime import timedelta app = Celery('tasks', broker='pyamqp://guest@localhost//') @app.on_after_configure.connect def setup_periodic_tasks(sender, **kwargs): # 添加每小时一次的任务 sender.add_periodic_task(timedelta(hours=1), periodic_batch_processing.s(), name='Run hourly batch job') @app.task(bind=True) def periodic_batch_processing(self): print(f"Batch processing started.") try: # 执行实际的批处理逻辑... pass except Exception as exc: raise self.retry(exc=exc) if __name__ == '__main__': app.start() ``` 这段代码展示了设置一个名为 `periodic_batch_processing` 的定期任务,该任务将在每个整点被执行。如果遇到异常情况,则会自动重试直到成功完成整个过程[^2]。 #### 最佳实践 当涉及到大型系统的批处理作业规划时,需综合考量以下几个方面以确保高效稳定运行: - **数据准备时间**: 需要提前准备好所有必要的输入文件或其他形式的数据源,以便于批处理程序启动时不因等待外部资源而延迟。 - **系统资源利用率**: 尽量避开高峰时段来进行大批量计算密集型的工作负载分配;可以选择深夜或是非营业时间内进行此类活动,从而减少对在线服务的影响程度。 - **业务需求导向**: 根据具体应用场景调整计划表,比如某些报表可能只需要每周生成一次而非每天都要更新。 通过上述措施可以在不影响用户体验的前提下最大化硬件设施的投资回报率,并保持良好的性能表现水平[^3]。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值