CN115269150A - 用于调度作业的方法 - Google Patents

Abstract

本申请提供了一种用于调度作业的方法，通过使用多DAG图层来实现外部父节点完成时原子性地更新该外部父节点的状态，有助于更高效地实现任务失败后的重跑调度。

Description

用于调度作业的方法

技术领域

本申请涉及计算机技术，特别地涉及一种用于调度作业的方法。

背景技术

已存在多种大数据处理工具，例如分布式计算框架Hadoop、数据仓库工具Hive、基于内存计算的分布式系统Spark、大规模图数据计算平台Giraph等。借助于多种多样的计算平台，数据开发人员每天会提交各种类型的作业来加工、分析数据。作业之间可能相互依赖，而且每个作业上还可能有开始调度时间的限制或要求。另外，在将任务分发到多个计算节点上运行时，需要考虑节点之间的负载是否均衡，以获得最大的总体效率。

发明内容

依据本申请的第一方面，提供了一种基于多DAG图层来调度作业的方法，包括：

生成包含初始全部作业的基础DAG图层；

对于运行失败后需要重跑的第一作业，在所述基础DAG图层中确定以该作业为根节点的子DAG图层；以及

当作为所述子DAG图层中的第二作业的外部父作业的第三作业成功执行时，在所述基础DAG图层和所述子DAG图层中分别通知第三作业的成功执行。

依据本申请的第二方面，提供一种计算机可读介质，其上存储有计算机可读指令，所述指令被执行时可实施如本申请所述的任一用于调度作业的方法。

本申请的实施方案的用于调度作业的方法能够进行多层DAG图中的作业的有序调度，避免了单层重复调度的资源浪费，同时防止多层调度时由于信息交换的制约而造成故障。

附图说明

图1示出了作业之间的依赖关系。

图2示出了多个作业节点形成的DAG图。

图3示出了本申请利用DAG图来实施作业调度的示例。

图4示出了根据本申请示例性实施例的调度作业的方法。

图5示出了根据本申请示例性实施的定时调度的流程图。

图6示出了根据本申请示例性实施例的依赖调度的流程图。

图7示出了根据本申请示例性实施例的基础DAG图层和子DAG图层。

图8示出了根据本申请示例性实施例的使用多DAG图层进行依赖调度的流程图。

图9示出了根据本申请示例性实施例的多DAG图层的示意图。

图10示出了根据本申请示例性实施例的Node和作业Hash分布的示意图。

图11是本申请示例性实施例的用于调度作业的系统的架构图。

图12是根据本申请的示例性实施例，按照依赖和定时进行作业调度的流程图。

具体实施方式

现在将参照若干示例性实施例来论述本申请的内容。应当理解，论述了这些实施例仅是为了使得本领域普通技术人员能够更好地理解且因此实现本申请的内容，而不是暗示对本申请的范围的任何限制。

如本文中所使用的，术语“包括”及其变体要被解读为意味着“包括但不限于”的开放式术语。术语“基于”要被解读为“至少部分地基于”。术语“一个实施例”和“一种实施例”要被解读为“至少一个实施例”。术语“另一个实施例”要被解读为“至少一个其他实施例”。如本文中所使用的，术语“任务”、“作业”可以指任何一种可执行单元，包括但不限于进程、线程、模块或其集合。

当存在多项计算任务时，任务之间可能存在依赖关系，即一项任务的开始需要另一任务的成功完成(例如后一任务的输出是前一任务所需要的输入)。经常以有向无环图(DAG)来示出任务之间的依赖关系。图1示出了作业之间的依赖关系的实例。节点B、E、F和G分别表示4个作业，而图中的箭头则表示各个作业节点的依赖关系。图中，G作业节点的执行依赖于B、E和F节点的执行结果，只有当B、E和F节点都执行成功后G节点才能得以执行，即B、E和F节点为G节点的父依赖节点。

图2示出了DAG图又一个示例。如果某个作业没有父依赖，则计算平台在接收作业时只要接收作业本身即可，例如图中的A节点和D节点，它们又被称为该DAG图的根节点或初始作业节点。

图3示出了本申请利用DAG图来实施作业调度的示例。每个任务节点设置有一个观察器(Watcher)，每一条边设置有一个监听器(Listener)。Watcher会观察对应作业的状态。当作业完成或者失败后，会通过每条边上的监听器通知(可以是主动通知)下游节点其父节点的状态。例如当节点D完成后，节点D上的Watcher首先会修改节点D的状态，并且通过边D至F和D至C两条边上的Listener通知节点F和C的父节点D已完成。在本申请的实施方案中，上述通知消息可以采用已知的分布式协调服务(例如Zookeeper)的消息通知机制来发送。

本申请的实施例提供了用于调度作业的方法，以下参照图4、图5和图6进行说明。

如图4所示，在S101中，接收用户提交的作业及作业之间的依赖关系，并构造体现所述依赖关系的DAG图(例如图2所示的DAG图)。

在S102中，检测一作业是否设置有开始时间的约束。作业的开始时间约束意味着只有到达预定时间时，才开始执行该项作业。

在S103中，如果所述作业节点设置有开始时间的约束，则将所述作业加入待调度的作业的队列(可以称之为时间队列)以按照定时进行调度(定时调度)。

定时调度管理的一个例子如图5所示。在S1031中，周期性地从所述时间队列中取出到达开始时间的作业。可以在时间队列中将各个作业按到达时间的先后顺序进行排列，并周期性地检查排在时间队列队首的作业是否达到预定时间。若发现已经到达预定时间则对该作业进行S1032中的操作。

在S1032中，检查所述到达开始时间的作业是否具有未执行成功的父依赖作业。

在S1033中，若所述到达开始时间的作业不具有未执行成功的父依赖作业，则直接将所述到达开始时间的作业加入待执行的队列(可以是分布式队列)中。

在本申请的一些实施例中，一个作业可能同时具有时间约束和依赖约束，即便已经到达该作业的预定时间也不代表可以执行该作业节点进行执行，必须等待时间约束和依赖约束的条件同时满足时，才可以准备执行该作业。

通过检测到达开始时间的作业的父依赖作业的执行情况，将不具有未执行成功的父依赖作业的作业加入依赖调度的队列中，而该队列中的作业的执行情况会影响依赖调度的情况，由此建立定时调度与依赖调度的联系和交互。

回到图4，在S104中，如果所述作业未设置有开始时间约束，则通过作业进行依赖调度。

未设置有开始时间约束的作业，其执行与否虽然不受时间的影响，但由于其与其他作业或许存在的依赖关系，受依赖约束。因而需要通过依赖调度管理保证作业的有序执行。依赖调度的一个实施例如图6中所示。

在S1041中，将不具有父依赖作业的初始作业加入待调度的队列。该队列可以是分布式队列，也可以是其他类型的队列，例如先来先执行即FIFO队列。

在S1042中，从所述待调度队列中取出作业(可以是周期性地取出)(此阶段称为工作作业)，并通过调度算法(例如如下所述的根据本发明实施例的一致性Hash调度算法)将所述作业分发到任务提交器节点(Node)上以执行。Node可以根据工作作业的作业ID从数据库中获取作业的代码、资源信息、参数值等信息，构造作业提交命令，然后向计算集群提交作业以执行。

在S1043中，若执行工作作业成功，则将执行该工作作业成功的消息通知所述作业的子作业。

在S1044中，若所述子作业的所有父依赖作业都执行成功且所述子作业不在所述时间队列中，则将所述子作业加入待调度的作业队列中。反之，如果该子作业在所述时间队列中，则按照它在时间队列中的位置及其开始时间约束，按照图5所示的过程执行定时调度。

在采用分布式队列作为待调度队列的实施方案中，工作作业完成后，Node通过分布式协调服务机制的消息通知机制告知作业对应的Watcher，该作业已完成。当作业状态是失败时，Node调度器给下游所有依赖作业发送停止调度消息，下游作业不再运行。作业成功时则通过DAG图中每条边上Listener通知下游作业此父作业已执行成功。下游作业收到该父作业执行成功的消息后，检查该子作业的所有父依赖作业是否都执行成功且该子作业不在时间队列中，即可将该子作业加入分布式队列中等待被作为工作作业取出执行。

通过从待调度队列不断取出工作作业并予以执行，并且根据该工作作业的执行结果结合时间队列中的信息，将新的作业放入待调度队列，直至DAG图中的所有作业全都执行成功。由此，通过检测子作业的父依赖作业的状况和该子作业是否在时间队列中来确定是否将该子作业加入待调度队列。通过如上所述的依赖调度管理的方法，可以在确保时间约束和依赖约束都达到条件的同时将DAG图中的所有作业执行完毕，在保证精准执行的同时保证了效率。

本申请中的实施方案由此实现了兼顾依赖调度和定时调度的混合式调度方法。既非单纯依据固定的开始执行时间的定时调度，也非仅依据DAG图中的依赖关系的依赖调度。混合式调度方法同时兼顾了作业的依赖和定时，使作业调度更为有序，节省了不必要的操作和无谓的计算，节省了时间、计算资源和传输资源，还能防止由于系统间沟通不畅或延时而导致的作业完成时间的拖延甚至由于信息未及时更新而造成的计算的错误。

当某个作业失败后，需要重跑此作业及下游子作业，但原DAG调度过程中其下游任务可能还尚未完成，导致下游节点在调度器中存在多个实例。在逻辑上，当用户每次重跑某个子任务及下游任务时，都相当于一次“子DAG图层”的调度，该子DAG图层是以此节点为根节点的子图层。

如图7所示，图7-(a)是正常调度的DAG图层(可以称为基础DAG图层)，图7-(b)是重跑子任务节点C的子DAG图层，图7-(c)是重跑子任务节点E的子DAG图层。基础DAG图层和子DAG图层的关键区别在于前者每个任务节点的父任务节点都在同一图层中，而后者的父任务节点在新的DAG图层的并不完整，有些父任务节点存在于其他DAG图层中。例如在重跑子节点C时，节点B的父节点A并不在该子图层图7-(b)中，只有节点C在新的DAG图中。在重跑子节点E的时，节点G的父节点B存在于基础DAG图层和重跑子节点C的图层中，本申请把不在当前图层的父节点统称为外部父节点。在调度过程中，外部父任务节点需要向当前图层的任务节点发送消息，告知其运行状态。

图8示出了根据本发明实施例的重跑子节点时，使用多层DAG图进行依赖调度的方法。

在S1045中，若执行子作业失败，则创建以该子作业为根节点的子DAG图层，以重新执行所述子作业以及所述子DAG图层中该子作业的下游作业。

在S1046中，当所述子作业重新执行成功时，通知其下游作业，并且当所述子作业节点是其他图层的外部父节点时，通过分布式协调服务机制(例如Zookeeper)维护所述子作业节点作为所述其他图层的外部父节点在所述其他图层的完成状态。

在S1047中，执行所述下游作业节点时，通过分布式协调服务机制查询所述下游作业节点的外部父节点的完成状态，若所述下游作业节点不具有未执行成功的外部父节点和父依赖作业节点且到达所述下游作业节点的开始执行时间则将所述下游作业节点加入所述分布式队列中。若所述下游作业节点不具有未执行成功的外部父节点和父依赖作业节点但其预定的开始执行时间还未到达，则可以将所述下游作业加入时间队列中。

参考图7，在重跑子节点的调度过程中，需要区分不同图层的调度，而且多个图层之间还需要消息通信。可以给每次正常调度或者重跑分配为一个调度ID(ScheduleId),即用<ScheduleId，JobId>来唯一标识一个作业的一次调度。因此对任务节点F来说，调度器中可能同时存在<ScheduleId-All,F>，<ScheduleId-C,F>，<ScheduleId-E,F>三个Watcher，分别表示正常调度、重跑子节点C、重跑子节点E三个图层的作业。

由于重跑子任务时，子图中的某些节点的父节点是外部父节点，而外部父节点是不需要在该图层中重跑的，但是需要根据外部父节点的状态来判断是否调度这些节点。例如在重跑图7-(b)的子节点C时，节点B需要根据外部父节点A的状态来决定自身是否开始调度。下面以重跑子节点C为例来分析重跑子节点时外部父节点如何通知子图层内的节点。对于节点B来说，当其外部父节点A已完成时，可直接更新父节点A的状态已完成；当父节点A在运行过程中，可以按照正常调度的机制建立外部父节点A到节点B的Listener，但是此时节点A可能刚刚完成，已经触发完成所有的Listener，因此新建的<ScheduleId-All,A>到<ScheduleId-C,B>的Listener可能被忽略掉。因此，在本申请的一些实施方案中，重跑子节点时，对于外部父节点不再建立Listener，而是通过分布式协调服务机制(例如Zookeeper)来实施任务节点状态的修改，以保证对外部父节点状态的更新操作是本领域所熟知的“原子性”操作，从而保证该更新操作的不可分割性及全局一致性。在分布式协调服务机制上维护每个节点在不同图层上的父节点的完成状态及已完成的父节点的数目。当图层ScheduleId-All中的B的父节点A完成时，在更新图层ScheduleId-All中节点B的父节点状态时，也会更新图层ScheduleId-C中节点B的父节点状态信息。

图9示出了根据本发明实施例的多层DAG图调度的示意图，以阐述父节点状态的更新机制。在图9中，节点G同时属于三个图层G1、G2及G3，其中子图层G1＝{B，E，F，G}，G2＝{E，F，G}，G3＝{B，E，G}。G1是基础图层，G2及G3属于重跑子节点的子图层。对于子图层G1，节点G会建立B->G、E->G、F->G的监听器。当B、E、F中任意节点完成时，会发送消息给G，G收到消息后会修改父节点的状态，当节点G的所有父节点均成功完成时，开始调度G；对于子图G2，节点G只会建立E->G、F->G的监听器，外部父节点B完成时通过分布式协调服务机制来修改图层G2中外部父节点的状态。当一个节点完成时，通过监听器会通知本图层内的下游节点，当该节点是其他图层的外部父节点时，会通过分布式协调服务机制来原子性修改其他图层中该父节点的状态，但是不会通知其他图层内的节点。例如图9中G2图层中的节点F完成，G2图层中标记父节点F状态为完成，F是图层3的外部节点，因此G3图层同样标记节点的G的父节点F为完成状态。同时，F是G1图层的内部节点，因此G1图层不作处理。

传统基于DAG的调度方法只考虑单层DAG图的调度。对于每次重跑某个作业及下游作业时，都会产生一个新的DAG子图的调度。根据本申请的实施例的多层调度方法能同时支持多个DAG图层的一体调度，通过分布式协调服务机制原子性修改父节点的执行完成状态，可以避免在一体调度多个DAG图层时由于信息传输不畅或更新不及时而造成的故障。

在向多个任务提交器节点(Node)分发任务时，确保节点之间的负载均衡是有益的。如果简单地把作业分发给Node，可能导致多个Node上的负载不均衡，且无法动态增加和删除Node。本申请的实施方案提出了一种一致性哈希算法，能保证底层每个Node的负载均衡，并且支持Node的动态增加和删除。

通常，在作业分发时，Node调度器并不是直接把作业发送给一个Node进行作业提交，而是在主控(Master)端缓存每个Node待派发的作业列表，然后根据资源管理中的资源信息来决定是否向Node下发作业。在大数据的真实生产场景中，每个DAG子图中可能有成千上万个作业，Node调度器需要把这些作业分发到有限的Node节点上。传统Hash调度或者轮询调度不能保证每个Node上的负载均衡，且不支持动态的增加或者删除节点。例如对于N个Node节点的情形，如果按照下述Hash方法把作业分发到不同的Node上，由于Hash过度依赖ScheduleId和JobId的值，很可能导致每个节点的负载不均衡。

hash(ScheduleId+JobId)％N (式1)

假如此时一台Node-m因物理原因死机，所有映射到该机器的作业都会失效，而此时Node的数目改为N-1，映射公式改为hash(ScheduleId+JobId)％(N-1),这导致所有的作业缓存失效。如果要增加一台机器作业新的Node节点，同样会引发此问题。

因此，本申请的实施方案提出采用一致性Hash算法进行作业的分发，不仅能保证各个Node的负载均衡，而且在删除或者增加Node节点时，只有极少数作业的映射路由发生变化，其他作业不受影响。图10示出了按照该算法的示例。图中示出了存在三台Node节点，有4个作业需要分发。把三台Node的独特性标识符(例如Mac地址)进行Hash映射到一个32位的Hash值，即0～(2^32)-1的数字空间中(也可以使用能提供足够大空间的位值，例如64位甚至更多)。把这些数字头尾相连，可以构成一个闭合的环形(可以采用合适的数据结构来实施此环形构造)，再把节点的标识符的Hash值标记到环上，如图10中的灰色节点所示。然后再把4个作业的的ScheduleId和JoId映射为32位的Hash值，添加到环形上。对于每个作业，沿着顺时针方向(也可以沿逆时针方向)寻找最近的Node，则把该作业分发给该Node。例如下图中作业A分发给Node1，作业C和D分发给Node3。新增Node时，只需将新节点的标识符映射到环上即可使新节点接受任务分配。如有节点被删除，则从环上删除该节点，并且被分配的任务跳过该节点，改为分配到既定方向上下一个最接近的节点。。

图11示例性地示出了一个本申请的实施例可在其上运行的系统。所示系统主要包括三个部分：用户层、调度层及计算层。

1.用户层

本方案支持多用户(user，又称租户)的作业调度，每个租户可通过例如RestfulAPI向调度层提交作业及父依赖作业，还可查询作业的运行状态、开始时间、结束时间、日志等信息。

2.调度层

调度层接受用户提交的作业及作业关系来构造DAG图，并负责作业的调度。主要包括用户管理器、依赖作业管理器、定时作业管理器、作业状态监听器、资源管理器、Node调度器。

a)用户管理器

给每位用户分配计算、存储空间，能够保证各个用户的作业之间互不影响，即按照用户进行隔离。

b)依赖作业管理器

用于检查作业的上游节点是否完成。如果作业的上游依赖均完成且作业不在定时作业管理器中，则把作业追加到待调度的队列(例如分布式调度队列)中进行调度。

c)定时作业管理器

存储带有开始执行时间约束的作业。当某个作业到达开始执行时间且上游依赖全部执行完成，把作业追加到待调度的队列中开始调度。

d)作业状态监听器

通过分布式协调服务机制(例如Zookeeper)来监听已下发作业的执行状态。当作业执行完成后，通知下游作业此父作业已完成，下游作业再根据父作业的完成情况及是否到达开始执行时间来决定是否开始调度。

e)资源管理器

负责下层Node的资源管理及Node的删除及增加。

f)Node调度器

从待调度队列中取出待分发的作业，采用一致性Hash算法把作业下发给执行Node。Node再向底层的Hadoop、Spark、Giraph等计算平台提交作业。

3.计算层

由分布式的Hadoop、Spark、Giraph等集群组成，负责作业的执行，并对外提供查询作业状态、停止作业、查询作业日志等接口。

图12示例性地示出了根据本申请实施例的作业调度的流程。在图12中，左边虚线框包括了定时调度管理；右边虚线框包括了依赖调度管理。两者在调度过程中会相互通信，以此来保证只有当作业的父依赖均完成且到达开始约束时间后才开始进行调度。图12的流程包括以下步骤1-11：

1.构造DAG图。对于一个输入任务，调度器首先检查此任务是否设置有开始时间约束。如果有则加入到左侧定时调度管理器中的时间队列，否则由右侧依赖调度管理器进行管理，视情况添加到待调度的分布式队列中。然后定时调度器周期执行步骤2-3，依赖调度器周期执行步骤4-11。

2.左侧的定时调度管理器周期检查时间队列中的是否有作业到达开始时间。如果有，则从队列头部取出作业，执行步骤3；否则等待一定间隔时间后，再去检测时间队列。

3.检查作业的父依赖作业是否都完成。如果完成，则直接加入到分布式队列中；否则不作处理，因为依赖完成后，右侧的依赖调度管理器会自动把作业加入到分布式队列中。

4.右侧的依赖调度管理器周期检查分布式队列中是否有作业。如果有，则取出作业，执行步骤5；否则等待一定间隔时间后，再去检查分布式队列。

5.对于每个作业，采用一致性Hash调度算法将其分发到所指定的Node上。

6.Node根据作业ID从数据库中获取作业的代码、资源信息、参数值等，构造作业提交命令，然后向计算集群提交作业。

7.监听作业的状态，作业完成后，Node通过Zookeeper的消息通知机制告知Watcher作业已完成，并执行步骤8。当作业状态是失败时，调度器直接给下游所有依赖节点发送停止调度消息，下游不再运行。

8.作业执行成功时则通过每条边上Listener通知下游节点此父节点已完成。

9.当下游节点收到父节点的消息后，更新父节点的状态。

10.检查节点的所有父节点是否都完成，如果是执行步骤11，否则不作处理。

11.检查节点是否在时间队列中，如果不在，则说明节点的父节点都完成且到达开始约束时间，把节点加入到分布式队列尾部；反之，不作处理(此时节点的父节点均已完成，但未到达开始时间，步骤2-3会作处理)。

本申请实施例还提供一种电子设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现前述方法。

本申请实施例还提供一种计算机可读介质，其上存储有计算机可读指令，所述指令被执行时可实施本申请各实施例的方法。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁存储设备存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

根据需要，本申请各实施例的系统、方法和装置可以实现为纯粹的软件(例如用Java和SQL来编写的软件程序)，也可以根据需要实现为纯粹的硬件(例如专用ASIC芯片或FPGA芯片)，还可以实现为结合了软件和硬件的系统(例如存储有固定代码的固件系统或者带有通用存储器和处理器的系统)。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

以上所述仅是本申请实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请实施例的保护范围。

Claims (6)

1.一种基于多DAG图层来调度作业的方法，包括：

生成包含初始全部作业的基础DAG图层；

对于运行失败后需要重跑的第一作业，在所述基础DAG图层中确定以该作业为根节点的子DAG图层；以及

当作为所述子DAG图层中的第二作业的外部父作业的第三作业成功执行时，在所述基础DAG图层和所述子DAG图层中分别通知第三作业的成功执行。

2.根据权利要求1所述的方法，其中，在所述子DAG图层中通过分布式协调服务机制获得所述第三作业成功执行的通知。

3.根据权利要求2所述的方法，其中，在所述子DAG图层中原子性地更新所述第三作业的完成状态。

4.根据权利要求1所述的方法，其中，在所述基础DAG图层中通过任务之间的监听器获得所述第三作业成功执行的通知。

5.根据权利要求1所述的方法，其中，对既位于所述基础DAG图层又位于所述子DAG图层中的作业在两个图层中的调度设置不同的标识符。

6.一种计算机可读介质，其上存储有计算机可读指令，所述指令被执行时可实施如权利要求1至5中任一权利要求所述的方法。

Images