CN112596876A - 一种任务调度方法、装置及相关设备 - Google Patents

Abstract

本申请提供了一种任务调度方法，该方法包括以下步骤：获取子作业的父作业的执行结果，该父作业的执行顺序早于子作业，其执行结果包括执行成功和执行失败；然后在执行结果为执行失败的情况下，确定子作业与该父作业之间的依赖关系，依赖关系包括强依赖关系和软依赖关系，强依赖关系是子作业的执行依赖于父作业的执行结果，软依赖关系是子作业的执行与父作业的执行结果无关；最后在子作业与其父作业之间的依赖关系是软依赖关系的情况下，执行子作业。该方法能够让作业关系配置更加多样化，任务调度更为灵活，更能满足实际业务场景中的任务调度关系需求。

Description

一种任务调度方法、装置及相关设备

技术领域

本发明涉及计算机技术领域，尤其涉及一种任务调度方法、装置及相关设备。

背景技术

Azkaban是由领英(Linkedin)公司开源的一款工作流任务调度工具，集成调度、编排、失败重试、邮件告警等功能为一体。

目前，Azkaban通过依赖(dependencies)参数定义作业之间的依赖关系，具有此种依赖关系的父作业和子作业，在父作业执行成功的情况下，子作业才能够被执行；在父作业执行失败的情况下，子作业无法被执行。但是，dependencies参数定义的依赖关系过于单一，导致现有的基于Azkaban的任务调度已经无法完全覆盖实际业务场景中任务调度之间的关系，无法满足业务需求，用户体验差。

发明内容

本申请实施例提供了一种任务调度方法，实现了作业关系配置的多样化，让任务调度更为灵活，更能满足实际业务场景中任务调度之间的关系需求。

第一方面，本申请提供了一种任务调度方法，该方法包括以下步骤：获取子作业的父作业的执行结果，其中，该父作业的执行顺序早于子作业，其执行结果包括执行成功和执行失败；在执行结果为执行失败的情况下，确定子作业与该父作业之间的依赖关系，其中，依赖关系包括强依赖关系和软依赖关系，强依赖关系是子作业的执行依赖于父作业的执行结果，软依赖关系是子作业的执行与父作业的执行结果无关；在子作业与其父作业之间的依赖关系是软依赖关系的情况下，执行子作业。

第二方面，本申请提供了一种任务调度装置，该装置包括：获取模块，用于获取子作业的父作业的执行结果，其中，父作业的执行顺序早于子作业，其执行结果包括执行成功和执行失败；确定模块，用于在执行结果为执行失败的情况下，确定子作业与其父作业之间的依赖关系，其中，依赖关系包括强依赖关系和软依赖关系，强依赖关系是子作业的执行依赖于父作业的执行结果，软依赖关系是子作业的执行与父作业的执行结果无关；执行模块，用于在子作业与其父作业之间的依赖关系是软依赖关系的情况下，执行子作业。

第三方面，本申请提供了一种计算设备，包括处理器和存储器，所述处理器和存储器可通过总线相互连接，也可以集成在一起。该处理器执行存储器中存储的代码实现如第一方面所描述的方法。

第四方面，本申请提供了一种计算机可读存储介质，包括程序或指令，当上述程序或指令在计算机设备上运行时，可使上述计算机设备执行如第一方面所描述的方法。

可以看到，本申请实施例通过使用两种不同的依赖关系，实现了作业关系配置的多样性，使得用户能够根据实际业务场景需求配置作业之间为软依赖关系或者强依赖关系，再通过获取父作业的执行结果以及子作业和父作业之间的依赖关系，来控制子作业的执行，任务调度更为灵活，能够更好地满足实际业务场景当中的任务调度关系需求，提升用户体验。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种Azkaban任务调度系统架构示意图；

图2是本申请实施例提供的一种作业间的依赖关系示意图；

图3是本申请实施例提供的一种软依赖关系示意图；

图4是本申请实施例提供的一种强依赖关系示意图；

图5是本申请实施例提供的一种任务调度方法的流程示意图；

图6是本申请实施例提供的一种任务调度装置的示意图；

图7是本申请实施例提供的一种计算设备的示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

为了便于理解本申请的实施例，下面对本申请涉及的部分术语进行解释说明。

大数据：无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合。大数据技术的战略意义在于对海量数据进行专业化处理，处理后的数据可以应用于各个行业，包括金融、汽车、餐饮、电信、能源等等。举例来说，利用大数据技术和物联网技术的无人驾驶汽车、利用大数据技术分析客户行为进行商品推荐、利用大数据技术实现信贷风险分析等等。

Hadoop：Hadoop是由java语言编写的、在分布式服务器集群上存储海量数据并运行分布式分析应用的开源框架。Hadoop由于具有高可靠性、高拓展性、高效性、高容错性等优点，在大数据处理中得以广泛应用，其核心部件是分布式文件系统(hadoopdistribution file system，HDFS)与MapReduce：HDFS为海量的数据提供了存储，引入存放文件元数据信息的服务器和实际存放数据的服务器，对数据进行分布式储存和读取；MapReduce是一个计算框架，为海量数据提供了计算，MapReduce的核心思想就是把计算任务分配给集群内的服务器执行，通过对计算任务的拆分(Map计算/Reduce计算)，再根据任务调度器对任务进行分布式计算。

任务调度：在计算机科学中，调度就是一种将任务分配给资源去执行的方法。任务可以是项目中的至少一个作业或者一个工作流，可以包括shell脚本(shell script)、java程序、MapReduce程序、hive脚本(hive script)等。各任务单元之间会存在时间先后以及前后依赖关系，并且存在着周期性重复，而给所有的任务运行定一个运行规则,再按照规则去安排任务的执行就可以理解为任务调度。常见的任务调度系统包括Azkaban、Ooize、Cascading等，调度系统最基本的功能是任务的定义和任务编排：任务定义主要是确定数据计算和加工的逻辑和规则，包括任务执行的频次、具体执行时间、对应的执行脚本和参数等内容；任务编排主要是确定不同任务的先后关系，确保任务有序且高效地进行。任务编排的输出结果是一个有向无环图(Directed Acyclic Graph，DAG)，方便用户查看任务的依赖关系及执行情况，对程序的运行过程进行可视化跟踪。调度系统一般还有任务重跑、历史补数、日志查看、邮件告警以及运行监控等功能，这里不再具体介绍。

H2:H2是一个java编写的关系型数据库，它可以被嵌入java应用程序中使用，或者作为一个单独的数据库服务器运行。

下面对本申请涉及的应用场景进行说明。

随着信息技术的发展，数据挖掘、机器学习、人工智能、统计分析等技术在数据分析领域获得广泛应用。与此同时为应对海量数据处理任务，出现了许多分布式计算框架，如Hadoop、kubernetes等。大数据分析处理任务大都包含多个数据处理步骤，比如数据的采集、传输、计算、展示等，每个步骤的数据处理算法需要提交到计算框架运行，其中有些步骤可以并发执行，有些步骤需要有依赖关系。在任务简单时可以人为控制，但是当任务非常多、关系复杂时，如果没有清晰的任务规划图，很容易在任务之间形成闭环从而出错，或者多个可并行的任务没有并行执行而浪费资源。而且，有些任务需要在某个特定的时间点去执行，还有些任务的执行具有一定的周期性，这时候只靠人为监控会浪费很多时间和精力。为了很好地组织起这样复杂的执行计划、将这种复杂的任务定时调度到分布式计算框架运行，出现了很多任务调度工具。

Azkaban就是其中一种主流的任务调度工具，可以用来对任务进行调度和监控，包括管理程序脚本、配置任务的依赖关系、检查程序是否执行正确、在程序出错时发出报警并重试等功能。应该理解的是，Azkaban并不限于在大数据领域中使用，凡是涉及到任务调度的，Azkaban都可以发挥其任务调度能力，比如说一个简单的定时发送邮件任务就可以通过在Azkaban上设置任务执行时间来定时调度执行。在Azkaban框架下是按照项目(project)、工作流(flow)、作业(job)依次来管理的。一个项目包含一个或多个工作流，一个工作流包含多个作业。job是在Azkaban中运行的一个进程，可以是简单的Linux命令，也可以是java程序，还可以是复杂的shell脚本、MapReduce程序、hive脚本或者Python脚本等。一个job可以依赖于另一个job的运行结果，各个job之间形成依赖关系，便组成了工作流，在一个工作流内以一个特定的顺序运行一组作业。

图1是本申请实施例提供的一种Azkaban任务调度系统100，Azkaban任务调度系统100可包括：管理服务器101(Azkaban Web Server)、执行服务器102(Azkaban ExecutorServer)和关系型数据库103(Relational Database)。管理服务器101、执行服务器102和关系型数据库103之间可通过网络连接，该网络可以是有线网络，也可以是无线网络，还可以是二者的混合。

关系型数据库103目前仅支持使用MySQL数据库，需要在MySQL服务器中创建Azkaban数据库并且完成初始化。Azkaban系统将配置文件信息和绝大多数的状态信息都保存在MySQL数据库103中，管理服务器101和执行服务器102都需要访问MySQL。

管理服务器101作为Azkaban主要的管理者，功能包括用户登录认证、项目创建、项目管理、上传任务、任务定时、查看任务执行状情况、查看历史任务等等。用户可通过浏览器104访问管理服务器101，并在管理服务器提供的用户界面(UserInterface，UI)上执行上述各种管理操作。

执行服务器102是整个调度系统中实际运行作业的节点，主要负责工作流的提交和执行，包括调度Hadoop任务、调度shell脚本任务、调度hive任务、单点故障等，并通过MySQL数据库103来协调各任务的执行。

也就是说，Azkaban的管理服务器101是作为分发者存在的，管理服务器101分发任务到执行服务器102中，执行服务器102再从Azkaban数据库103的项目文件(project_files)中拿到用户上传的压缩文件，并解压到本地的项目(projects)文件夹中，最终提交任务到线程池中，其执行的本质就是将每个job放置在线程池中执行。

Azkaban任务调度系统100中的各个模块部署十分灵活，比如有单服务器模式(solo-server)、双服务器模式(two-server)以及分布式多执行器模式(multiple-executor)，可以根据用户侧规模的不同以及任务数量的多少来进行不同的模式部署，灵活性较强。solo-server模式的数据库(DataBase，DB)使用的是一个内嵌的H2数据库,azkabanweb server和azkaban executorserver运行在同一进程里，一般用于任务量不大的学习和测试。Two-server模式适合生产环境，数据库使用的是MySQL，MySQL支持主从(master-slave)架构，azkaban web server和azkaban executorserver运行在不同的进程中，但部署在同一节点，即图1中的管理节点111和执行节点112实际为同一节点，这种模式下更新和升级对用户的影响较小。分布式多执行器模式适合严格的生产环境，DB使用的是MySQL，MySQL支持master-slave架构，理想情况下webserver和executorserver在不同节点上运行，即管理服务器101部署在管理节点111上，执行服务器102部署在执行节点112上，管理节点111和执行节点112为不同的节点，且有多个executorserver，该模式方便升级和维护，不会影响用户。分布式多执行器模式需要在MySQL的Azkaban数据库中添加各个执行服务器的网际互连协议(Internet Protocol，IP)/域名和端口，为每个执行节点下载并安装执行服务器，并且在webserver的配置中启用多个执行器模式，随后提交的job会根据一定的计算规则，选择一个部署有executorserver的合适的执行节点，然后将flow调度到选定的执行节点上运行。其中，管理节点111和执行节点112可以是物理服务器，比如X86服务器、ARM服务器等等，也可以是基于通用的物理服务器结合网络功能虚拟化(network functionsvirtualization,NFV)技术实现的虚拟机(virtual machine,VM)，虚拟机指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统，本申请不作具体限定。应理解，执行节点112可以是单个物理服务器或者单个虚拟机，还可以构成计算机集群，本申请不作具体限定。

大数据平台要求高可用性，往往采用的就是multipleexecutor模式，把Azkaban系统和大数据集群部署在一起。分别在大数据集群中的不同的主机上部署多个azkabanexecutorserver，可以应对高并发定时任务执行的情况，从而减轻单个服务器的压力。所述大数据集群可以是任何可以被Azkaban纳管的大数据集群，包括但不限于HDFS集群、Spark集群或Hadoop集群等等。例如，有一个Hadoop集群架构包括五个节点：2个主机master，3个从机slave，节点之间通过局域网连接，其中，两个master机器(master-1和master-2)主要负责总管分布式数据和分解任务的执行，三个slave机器主要负责分布式数据存储以及任务的执行。当Azkaban系统采用multiple-executor模式时，选择该Hadoop集群下的master-1和master-2作为azkabanexecutorserver的运行节点，web server可以选择部署在任一节点，需要做好相应的配置工作。在每次分发任务时，webserver可先判断某任务是否指定了executorserver的身份标识号(Identity Document，ID)，若没有指定则通过比较内存、中央处理器(Central Processing Unit，CPU)占用率等方式选择合适的executorserver去执行任务。当然，被选择的一个executor会判断是否设置作业粒度分配，如果未设置作业粒度分配，则在当前节点执行所有作业；如果设置了作业粒度分配，则当前节点会成为作业分配的决策者，即分配节点，分配节点获取各个executor的执行状态信息，然后根据选择策略选择executor分配作业，被分配到作业的executor即成为执行节点，执行作业，然后更新MySQL数据库103，具体是更新MySQL中存储的各作业的状态信息以及其他信息。

Azkaban定义了一种KV文件(properties)格式来建立任务之间的依赖关系，并提供一个易于使用的web用户界面维护和跟踪工作流。首先，用户需要新建一个以.job为拓展名的文件，一个.job文件即代表一个作业。所有的作业都需要一个指导它如何去执行的类型(type)，Azkaban默认的作业类型包括command、java等。定义完job类型后，在这个文件中添加这个任务所需的参数与参数值，可以添加的其中一种参数为dependencies参数，它定义了该文件所依赖的文件，值为被依赖文件的文件名，多个目标以逗号分隔，不加拓展名。保存为.job文件即创建好了一个job，定义好所有的参数后即定义好了一个job，如果添加了dependencies参数，便是配置了作业间的依赖关系以形成工作流。然后将所有.job文件以及所需要的资源文件(例如java程序包、hive脚本文件、MapReduce程序jar包等)打包成一个zip文件，在Azkaban提供的用户界面上传。Azkaban会对上传的zip文件进行解压缩，然后分析形成各个节点组成的有向无环图，也就是在web用户界面呈现一个作业间的依赖关系图，便于用户查看作业间的依赖关系以及各作业的执行状态等。依赖关系图中用实线连接具有依赖关系的节点，默认用灰色表示作业未执行，蓝色表示作业执行中，绿色表示作业执行成功，红色表示作业执行失败。然后用户选择配置定时调度(schedule)或者立即执行(execute)。若选择定时调度方式，则在达到定时调度的时间点时，执行服务102就会到Azkaban数据库103中读取配置文件，然后将需要的数据下载到本地。之后执行服务器102开始执行工作流，并将各作业的执行状态信息不断的放入到数据库103中，通过web管理服务器101可以查看执行状态信息等。

例如，图2示例性地给出了一种作业间的依赖关系图。用户在本地新创建一个A.job文件，再创建一个B.job文件，并且在B.job文件中添加语句“dependencies＝A”，即通过添加dependencies参数定义了B作业依赖于A作业的执行结果。同理，创建C.job文件，令C作业也依赖于A作业，再创建D.job文件，令D作业依赖于B作业及C作业，最后创建E.job文件，令E作业依赖于D作业。保存好5个job文件之后，将这5个job文件及各作业所需的资源文件一起打包成zip包(即配置文件)。在Azkaban的web管理界面新建一个项目，包括填写工作流名称、备注信息等等，然后上传这个zip包，从而一个工作流建好，调度系统将配置文件存储在azkaban数据库103中，最终呈现一个如图2所示的作业间的依赖关系图。根据图2所示的依赖关系图可以清楚地看出作业之间的依赖关系：B作业及C作业依赖于A作业的运行结果，B作业与C作业可以并行运行，而D作业依赖于B作业及C作业的运行结果，E作业依赖于D作业的运行结果。

为了便于描述，将Azkaban中使用dependencies参数所定义的依赖关系称为强依赖关系。对于具有此种强依赖关系的父作业和子作业，必须在父作业执行成功的情况下，子作业才能够被执行；在父作业执行失败的情况下，子作业无法被执行，会退出整个工作流。例如，图2中的B作业与A作业通过实线连接，B作业对于A作业具有强依赖关系，此时B作业是A作业的子作业，A作业是B作业的父作业。在A作业执行成功的情况下，B作业能够被执行；在A作业执行失败的情况下，B作业无法被执行，同时也会使得强依赖于B作业的D作业(D作业是B作业的子作业，B作业是D作业的其中一个父作业)以及其他下游作业E(E作业强依赖于D作业)都无法执行，会退出整个工作流。

然而，在实际的业务场景中往往会出现，期望子作业在父作业执行失败的情况下也能被执行。例如，在利用大数据技术分析用户行为进行电影推荐的场景中，父作业P1可以是抓取用户近10天内的行为数据，包括影片播放次数、播放时长、播放质量、用户评分等多维度信息，将获取的数据存储到数据库的数据表table1中；子作业P2可以是从数据表table1中获取用户行为数据，通过算法做兴趣推荐。那么在使用Azkaban设置任务流程时，现有的dependencies参数可以设置子作业P2强依赖于父作业P1，这时候P1作业为P2作业的父作业，P2作业为P1作业的子作业，在web管理界面形成的强依赖关系图可示例性地参见图3。在此种强依赖情况下，若P1作业执行失败，则会退出整个工作流，子作业P2是无法被执行的。而在实际的业务场景中，往往会希望即使父作业P1获取近10天内的数据失败，这时候数据表table1中暂时没有近10天内的用户行为数据，而子作业P2还能够从数据表table1中获取之前存储的历史数据来做兴趣推荐。而目前的强依赖关系已无法满足此类应用场景，也就是说，现有的基于Azkaban的任务调度已经无法完全覆盖实际业务场景中的作业调度关系需求，影响用户体验。如何实现作业关系配置的多样性，以满足更多实际应用场景下的任务调度需求，成为额待解决的问题。

为了解决上述问题，本申请提供了一种任务调度系统，该系统中存在强依赖关系和软依赖关系，其中，强依赖关系是指子作业的执行依赖于其父作业的执行结果，软依赖关系是指子作业的执行与其父作业的执行结果无关。结合这两种依赖关系，用户可以根据需要配置作业之间的依赖关系为强依赖关系和软依赖关系中的其中一种，然后将job文件打包上传至系统，解析为相应的工作流并显示对应的依赖关系图，所述依赖关系图可以根据作业的执行情况产生相应的变化。本申请使得作业关系配置更加多样化，任务调度更为灵活，更能满足实际业务场景中的任务调度关系需求。

对比图3中给出的强依赖关系图，将上述例子中的P2作业配置为软依赖于P1作业，形成的软依赖关系图参见图4。在所述软依赖关系下，若P1作业执行成功，即获取到了近10天内的用户行为数据到数据表table1中，则P2作业能够正常执行，基于数据表table1中的最新数据做兴趣推荐，提供准确性；若P1作业执行失败，P2作业也能够从数据表table1中获取之前存储的历史数据做兴趣推荐。虽然说P2作业没能用到最近10天的用户行为数据做兴趣推荐会缺乏一定的准确性，但是用历史数据做兴趣推荐在大多数情况下也能给出不错的结果，不太会影响兴趣推荐功能的使用以及下游任务的执行，提供了可靠性，提升用户体验。

下面结合附图，对本申请提供的任务调度方法的具体步骤进行详细介绍。

如图5所示，本申请实施例提供了的一种任务调度方法，该方法可以包括如下步骤：

S501：读取配置文件。

具体的，上述配置文件包括全部作业之间的依赖关系。该配置文件是用户根据实际业务需求编写全部作业之间的依赖关系后生成的，具体可以是job文件。该配置文件还可以包括各job文件所需要的资源文件，例如job文件中实际要执行的java程序包、shell脚本文件等。应理解，用户可以通过浏览器104访问Azkaban任务调度系统100中的管理服务器101，并在管理服务器提供的web页面上传编写好的上述配置文件。关于Azkaban任务调度系统架构及其部署模式可参考图1相关的描述，这里不重复赘述。

在一种可能的实施例中，该配置文件中，作业之间的强依赖关系用第一依赖参数标识，作业之间的软依赖关系用第二依赖参数标识。例如，第一依赖参数可以是dependencies参数，第二依赖参数可以是soft_dependencies参数，用户可以根据实际业务需求,在配置文件中分别用soft_dependencies参数和dependencies参数标识作业之间的软依赖关系和强依赖关系。应理解，上述dependencies参数和soft_dependencies参数仅用于举例说明，具体实现中，第一依赖参数和第二依赖参数还可以存在其他表现形式，本申请不对此进行限定。

在一种可能的实施例中，在读取配置文件之后，还可以获取上述配置文件中全部作业之间的依赖关系，按照全部作业之间的依赖关系生成作业之间的依赖关系图，其中，该依赖关系图用于显示所有作业之间的依赖关系及执行状态，所述执行状态包括执行结果(执行成功和执行失败)、执行中和未执行。

在一种可能的实施例中，该依赖关系图中用第一线型标识表示强依赖关系，用第二线型标识表示软依赖关系。例如，参见图3的强依赖关系图，P2作业强依赖于P1作业，图中用实线连接P1作业和P2作业。再参见图4的软依赖关系图，P2作业此时软依赖于P1作业，图中用虚线连接P1和P2作业。应理解，上述实线形式的第一线型标识和虚线形式的第二线型标识仅用于举例说明，第一线性标识和第二线性标识还可以是颜色，或者其他用于区分的标识，本申请对第一线型标识和第二线型标识的表现形式不进行限定。

S502：获取子作业的父作业的执行结果，确定该父作业是否执行成功，在确定该父作业执行成功的情况下，执行步骤S503；在确定该父作业执行失败的情况下，执行步骤S504。

其中，父作业的执行顺序早于其子作业。获取子作业的父作业的执行结果，具体可以是执行服务器102从MySQL数据库103中获取该父作业的执行结果，执行结果包括执行成功和执行失败。应理解，子作业有至少一个父作业，在获取子作业的父作业的执行结果时，可能存在一个或多个父作业正处于执行中或者未执行的状态，所述子作业可以进行等待，周期性地去获取父作业的执行结果，关于执行结果的获取周期本申请不做限定。

在一种可能的实施例中，在上述依赖关系图中，执行结果为执行成功的父作业标注有第一状态标识。例如，参见图3中的强依赖关系图，P2作业强依赖于P1作业，在P1作业执行成功的情况下，用绿色表示此执行成功的父作业P1。

S503：执行子作业。

具体的，执行服务器102将每个job放置在线程池中执行。

S504：确定子作业与其父作业之间的依赖关系，在确定子作业与其父作业之间的依赖关系是强依赖关系的情况下，执行步骤S505；在确定子作业与其父作业之间的依赖关系是软依赖关系的情况下，执行步骤S503。

其中，上述依赖关系包括强依赖关系和软依赖关系，强依赖关系是子作业的执行依赖于其父作业的执行结果，软依赖关系是子作业的执行与其父作业的执行结果无关。

具体的，由上述配置文件中的子作业和父作业之间的依赖参数标识，来确定子作业与其父作业之间的依赖关系，在子作业和父作业之间的依赖参数标识是第一依赖参数标识的情况下，确定子作业与其父作业之间的依赖关系是强依赖关系；在子作业和父作业之间的依赖参数标识是第二依赖参数标识的情况下，确定子作业与其父作业之间的依赖关系是软依赖关系。

在一种可能的实施例中，在确定子作业与其执行失败的所有父作业之间都是软依赖关系的情况下，执行步骤S503。

在一种可能的实施例中，在上述依赖关系图中，执行结果为执行失败，且与对应子作业之间具有强依赖关系的父作业标注有第二状态标识。

在一种可能的实施例中，在上述依赖关系图中，执行结果为执行失败，且与对应子作业之间具有软依赖关系的父作业标注有第三状态标识。

例如，参见图3中的强依赖关系图，在P1作业执行失败的情况下，确定P1作业与P2作业之间的依赖关系，发现P2作业是强依赖于P1作业的，则在该强依赖关系图中用红色标注此执行失败的父作业P1。再参见图4中的软依赖关系图，在P1作业执行失败的情况下，确定P1作业与P2作业之间的依赖关系，发现P2作业此时软依赖于P1作业，则在该软依赖关系图中用黄色表示该执行失败的父作业P1。应理解，上述例子中用更为醒目的红色表示具有强依赖关系的父作业执行失败，更能警示用户及时查看错误问题并尽快解决，而用相对没那么显眼的黄色表示具有软依赖关系的父作业执行失败，既能够在一定程度上警示用户，又能和用红色显示的作业加以区分，表明该作业虽然执行失败，但是该错误的严重性没那么高，用黄色显示的作业的执行失败并没有太影响到整个工作流的执行，整个工作流还能继续往下执行。当在整个依赖关系图中出现了用红色显示的作业和用黄色显示的作业时，用户可以优先处理用红色显示的作业存在的问题，之后再去解决用黄色显示的作业节点出现的问题，更加有侧重点。需要注意的是，上述例子仅是为了举例说明如何用不同的状态标识去表示不同的父作业，本申请不对第一状态标识和第二状态标识的具体表现形式做具体限定。

在一种可能的实施例中，在父作业执行失败的情况下，用第四状态标识表示其子作业。例如，参见图4的软依赖关系图，P2作业软依赖于P1作业，在父作业P1执行失败的情况下，用浅黄色显示子作业P1。应理解的是，还可以用第四状态标识表示父作业的所有下游作业，表明由于该父作业的执行失败导致了下游的哪一些作业执行不了。需要注意的是，上述第一状态标识、第二状态标识、第三状态标识和第四状态标识可以是不同的颜色，也可以是阴影，还可以是不同的形状等等，本申请对此不做限定。

S505:不执行子作业，退出工作流。

在一种可能的实施例中，在步骤S504确定其中一个执行失败的父作业与该子作业之间为强依赖关系的情况下，不执行该子作业，退出整个工作流。

另外，在一种可能的实施例中，上述步骤S501～S505实施例所描述的方法应用于Azkaban任务调度系统。

综上可知，本申请实施例提供的任务调度方法，通过获取父作业的执行状态，再获取子作业与其父作业之间的依赖关系，判断是软依赖关系还是强依赖关系，来控制子作业的执行；而且根据作业之间的依赖关系显示一个依赖关系图，并根据作业执行状态的改变做出相应的变化，方便用户查看作业之间的依赖关系及各作业的执行状态。本申请通过两种不同的依赖关系，使得作业关系配置更加多样化，任务调度更为灵活，更能满足实际业务场景中的任务调度关系需求，提升用户体验。

图6是本申请实施例提供的一种任务调度装置600的结构示意图，该任务调度装置包括：获取模块601、确定模块602、执行模块603。

获取模块601，用于获取子作业的父作业的执行结果，其中，该父作业的执行顺序早于其子作业，上述执行结果包括执行成功和执行失败；

确定模块602，用于在父作业的执行结果为执行失败的情况下，确定子作业与其父作业之间的依赖关系，其中，依赖关系包括强依赖关系和软依赖关系，强依赖关系是子作业的执行依赖于其父作业的执行结果，软依赖关系是子作业的执行与其父作业的执行结果无关；

执行模块603，用于在子作业与其父作业之间的依赖关系是软依赖关系的情况下，执行子作业。

在一种可能的实施例中，该执行模块603还用于在子作业与其父作业之间的依赖关系是强依赖关系的情况下，不执行该子作业，退出整个工作流。

在一种可能的实施例中，该获取模块601还用于读取配置文件，其中，该配置文件包括全部作业之间的依赖关系，该配置文件是用户根据业务需求编写全部作业之间的依赖关系后生成的。

在一种可能的实施例中，该配置文件中，作业之间的强依赖关系用第一依赖参数标识，软依赖关系用第二依赖参数标识；

所述确定模块还用于，在子作业和父作业之间的依赖参数标识为第一依赖参数标识的情况下，确定子作业与其父作业之间的依赖关系是强依赖关系；在子作业和父作业之间的依赖参数标识为第二依赖参数标识的情况下，确定子作业与其父作业之间的依赖关系是软依赖关系。

在一种可能的实施例中，该任务调度装置还包括显示模块604，获取模块601用于获取配置文件中全部作业之间的依赖关系；该显示模块604用于根据上述全部作业之间的依赖关系向用户显示依赖关系图，其中，依赖关系图用于向用户显示所有作业之间的依赖关系及执行结果，该依赖关系图中用第一线型标识表示强依赖关系，用第二线型标识表示软依赖关系。

在一种可能的实施例中，所述显示模块604还用于：

在所述依赖关系图中，为所述执行结果为执行成功的所述父作业标注第一状态标识；

为所述执行结果为执行失败，且与对应子作业之间具有所述强依赖关系的所述父作业标注第二状态标识；

为所述执行结果为执行失败，且与对应子作业之间具有所述软依赖关系的所述父作业标注第三状态标识。

在一种可能的实施例中，该任务调度装置为Azkaban任务调度系统100。

需要说明的是，上述任务调度装置600的各个模块的功能实现可具体参考图5实施例的相关方法步骤描述，为了说明书的简洁，这里不再赘述。

综上可知，本申请实施例提供的任务调度装置，通过获取父作业的执行结果，再获取子作业和父作业之间的依赖关系，判断是软依赖关系还是强依赖关系，来控制子作业的执行；并根据全部作业之间的依赖关系显示依赖关系图，再由作业执行状态做出相应的变化，方便用户查看作业之间的依赖关系及作业的执行状态。本申请通过两种不同的依赖关系，使得作业关系配置更加多样化，任务调度更为灵活，更能满足实际业务场景中的任务调度关系需求。

图7是本申请实施例提供的一种计算设备700的结构示意图，该计算设备700可以是前述内容中的任务调度装置600。该计算设备可以是笔记本电脑、平板电脑以及云端服务器等计算设备，本申请不做限制。

计算设备700包括：处理器701、通信接口702以及存储器703，所述计算设备用于实行上述各个任务调度方法实施例中的步骤。其中，处理器701、通信接口702以及存储器703可以通过内部总线704相互连接，也可通过无线传输等其他手段实现通信。本申请实施例以通过总线704连接为例，总线704可以是外设部件互连标准(Peripheral ComponentInterconnect,PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture,EISA)总线等。总线704可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

处理器701可以由至少一个通用处理器构成，例如中央处理器(CentralProcessing Unit,CPU)，或者CPU和硬件芯片的组合。上述硬件芯片可以是专用集成电路(Application-Specific Integrated Circuit,ASIC)、可编程逻辑器件(ProgrammableLogic Device,PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(ComplexProgrammable Logic Device,CPLD)、现场可编程逻辑门阵列(Field-Programmable GateArray,FPGA)、通用阵列逻辑(Generic Array Logic,GAL)或其任意组合。处理器701执行各种类型的数字存储指令，例如存储在存储器703中的软件或者固件程序，它能使计算设备700提供多种服务。

存储器703用于存储程序代码，并由处理器701来控制执行，以执行上述实施例中任务调度方法的处理步骤。程序代码中可以包括一个或多个软件模块，这一个或多个软件模块可以为图6实施例中提供的软件模块，如获取模块、确定模块、执行模块。其中，获取模块用于获取子作业的父作业的执行结果，确定模块用于在父作业的执行结果为执行失败的情况下，确定子作业与其父作业之间的依赖关系，执行模块用于在子作业与其父作业之间的依赖关系是软依赖关系的情况下，执行子作业，具体可用于执行图5实施例中的步骤S501～S505，这里不再进行赘述。

需要说明的是，本实施例可以是通用的物理服务器实现的，例如，ARM服务器或者X86服务器，也可以是基于通用的物理服务器结合NFV技术实现的虚拟机实现的，虚拟机指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统，本申请不作具体限定。应理解，图7所示的计算设备还可以是至少一个服务器构成的计算机集群，本申请不作具体限定。

存储器703可以包括易失性存储器(Volatile Memory)，例如随机存取存储器(Random Access Memory，RAM)；存储器703也可以包括非易失性存储器(Non-VolatileMemory)，例如只读存储器(Read-Only Memory，ROM)、快闪存储器(Flash Memory)、硬盘(Hard Disk Drive，HDD)或固态硬盘(Solid-State Drive，SSD)；存储器703还可以包括上述种类的组合。存储器703可以存储有程序代码，具体可以包括用于执行图5实施例描述的步骤的程序代码，这里不再进行赘述。

通信接口702可以为有线接口(例如以太网接口)，可以为内部接口(例如高速串行计算机扩展总线(Peripheral Component Interconnect express,PCIe)总线接口)、有线接口(例如以太网接口)或无线接口(例如蜂窝网络接口或使用无线局域网接口)，用于与与其他设备或模块进行通信。

需要说明的，图7仅仅是本申请实施例的一种可能的实现方式，实际应用中，计算设备700还可以包括更多或更少的部件，这里不作限制。关于本申请实施例中未出示或未描述的内容，可参见前述图5实施例中的相关阐述，这里不再赘述。

本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在处理器上运行时，图5所示的方法流程得以实现。

本申请实施例还提供一种计算机程序产品，当计算机程序产品在处理器上运行时，图5所示的方法流程得以实现。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random AccessMemory，RAM)等。

以上所揭露的仅为本发明一种较佳实施例而已，当然不能以此来限定本发明之权利范围，本领域普通技术人员可以理解实现上述实施例的全部或部分流程，并依本发明权利要求所作的等同变化，仍属于发明所涵盖的范围。

Claims (10)

1.一种任务调度方法，其特征在于，所述方法包括：

获取子作业的父作业的执行结果，其中，所述父作业的执行顺序早于所述子作业，所述执行结果包括执行成功和执行失败；

在所述执行结果为执行失败的情况下，确定所述子作业与所述父作业之间的依赖关系，其中，所述依赖关系包括强依赖关系和软依赖关系，所述强依赖关系是所述子作业的执行依赖于所述父作业的执行结果，所述软依赖关系是所述子作业的执行与所述父作业的执行结果无关；

在所述子作业与所述父作业之间的依赖关系是软依赖关系的情况下，执行所述子作业。

2.根据权利要求1所述的任务调度方法，其特征在于，所述方法还包括：

在所述子作业与所述父作业之间的依赖关系是强依赖关系的情况下，不执行所述子作业，退出工作流。

3.根据权利要求1或2所述的任务调度方法，其特征在于，在所述获取子作业的父作业的执行结果之前，所述方法还包括：

读取配置文件，其中，所述配置文件包括全部作业之间的依赖关系，所述配置文件是用户根据业务需求编写所述全部作业之间的依赖关系后生成的。

4.根据权利要求3所述的任务调度方法，其特征在于，所述配置文件中，作业之间的所述强依赖关系用第一依赖参数标识，所述软依赖关系用第二依赖参数标识；

所述确定所述子作业与所述父作业之间的依赖关系包括：

在所述子作业和所述父作业之间的依赖参数标识为所述第一依赖参数标识的情况下，确定所述子作业与所述父作业之间的依赖关系是所述强依赖关系；

在所述子作业和所述父作业之间的依赖参数标识为所述第二依赖参数标识的情况下，确定所述子作业与所述父作业之间的依赖关系是所述软依赖关系。

5.根据权利要求3所述的任务调度方法，其特征在于，在读取配置文件之后，所述方法还包括：

获取所述配置文件中所述全部作业之间的依赖关系，按照所述全部作业之间的依赖关系生成所述全部作业之间的依赖关系图，其中，所述依赖关系图用于向用户显示所述全部作业之间的依赖关系及所述全部作业的执行结果，所述依赖关系图中用第一线型标识表示所述强依赖关系，用第二线型标识表示所述软依赖关系。

6.根据权利要求5所述的任务调度方法，其特征在于，

所述依赖关系图中，所述执行结果为执行成功的所述父作业标注有第一状态标识；

所述执行结果为执行失败，且与对应子作业之间具有所述强依赖关系的所述父作业标注有第二状态标识；

所述执行结果为执行失败，且与对应子作业之间具有所述软依赖关系的所述父作业标注有第三状态标识。

7.根据权利要求1至6任一项所述的任务调度方法，其特征在于，所述方法应用于Azkaban任务调度系统。

8.一种任务调度装置，其特征在于，所述装置包括：

获取模块，用于获取子作业的父作业的执行结果，其中，所述父作业的执行顺序早于所述子作业，所述执行结果包括执行成功和执行失败；

确定模块，用于在所述执行结果为执行失败的情况下，确定所述子作业与所述父作业之间的依赖关系，其中，所述依赖关系包括强依赖关系和软依赖关系，所述强依赖关系是所述子作业的执行依赖于所述父作业的执行结果，所述软依赖关系是所述子作业的执行与所述父作业的执行结果无关；

执行模块，用于在所述子作业与所述父作业之间的依赖关系是软依赖关系的情况下，执行所述子作业。

9.一种计算设备，其特征在于，包括存储器和处理器：

所述存储器，用于存储计算机程序；

所述处理器，用于执行所述存储器中存储的计算机程序，以使得所述计算设备执行如权利要求1-7中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，包括程序或指令，当所述程序或指令在计算机设备上执行时，如权利要求1-7中任一项所述的方法被执行。

Images