CN104951908B - 一种事件触发调度系统和方法 - Google Patents

Abstract

本发明公开了一种事件触发调度系统和方法，涉及作业流调度技术领域。本发明实施例提供的事件触发调度系统和方法，是根据实际生产中，上一项作业执行成功之后才执行下一项的原则而开发的，所以，符合企业数据流的处理规范,不会出现上一项执行失败而执行下一项的情况，避免了后续产生一系列的错误，同时，由于通过事件触发下一项任务的执行，所以，作业流简单，减少了资源的浪费与占用。

Description

一种事件触发调度系统和方法

技术领域

本发明涉及作业流调度技术领域，尤其涉及一种事件触发调度系统和方法。

背景技术

目前，企业生产过程中，一般使用工作流任务调度器对工作流任务进行调度，以实现企业对工作流的批量管理。

其中，Azkaban是由Linkedin开源的一个批量工作流任务调度器。为了得到想要的数据，通常需要执行很多作业，一批作业执行完毕，再将中间结果进一步处理，最后得到有价值的数据，因此作业之间执行有先后顺序和依赖关系。这样的一组作业称为一个工作流，Azkaban就是用来构建、运行和管理工作流的工具，它提供友好的Web用户界面来维护和跟踪用户的工作流程。

Azkaban由三个重要的组件组成，mysql数据库，executor和webserver。其中Azkaban的webserver除了提供web页面响应服务，还负责项目管理，认证，调度，监控和发起执行，它是azkaban的大脑。executor则负责作业的执行，对执行过程及结果进行监控，并将执行状况汇报给AzkabanWebServer，两者采用http接口进行通信。

Azkaban中的调度主要是时间触发调度，工作流内依赖调度执行。而对于跨作业流，跨部门的作业，或者执行过程中对其他作业流的事件触发并不能很好的支持。因为，Azkaban主要是创建一个大的作业流，包含所有的作业，或者是执行定时调度。而把所有的作业都组成一个大的作业流，无形中增加了作业流的复杂度，并且难以理解和维护，如果是跨部门合作的话，作业流沟通也是一项很大的成本。而使用定时调度的方案也有可能产生信息滞后性，如当某项作业产生错误执行失败时，而后面的定时作业还会照常执行，就会产生后续的一系列错误，再进行作业恢复既耗时又耗力，耽误正常的作业流程。

而在企业生产过程中，数据来源于多个部门，多个作业流进行交叉运算，某个部门的作业流中的部分数据可能依赖于其他部门的计算结果，因此，对于作业流外依赖azkaban支持并不是很好。

发明内容

本发明的目的在于提供一种事件触发调度系统和方法，从而解决现有技术中存在的前述问题。

为了实现上述目的，本发明采用的技术方案如下：

一种事件触发调度的方法，包括如下步骤：

S1，判断当前执行作业是否执行成功，如果是，则转到S2，否则，继续执行；

S2，获取包括所述当前执行作业id和状态的待触发作业；

S3，获取所述待触发作业的每个状态的统计数，将所述当前执行作业状态的统计数增量加一并更新，得到待触发作业第一次更新后的每个状态的统计数；

S4，将待触发作业更新后的每个状态的统计数均减一并更新，得到待触发作业第二次更新后的每个状态的统计数；

S5，判断待触发作业第二次更新后的每个状态的统计数是否均大于等于0，如果是，则执行待触发作业；否则，转到S3。

进一步地，S1之前，还包括：获取所有作业流中所有作业子节点之间的依赖关系。

优选地，所述获取所有作业流中所有作业子节点之间的依赖关系之后，将依赖作业流存入redis中，则S2包括：

S201，获取当前执行作业的状态state；

S202，在redis中查找key为state的set集合；

S203，遍历set集合中所有的数据，根据当前执行作业的id为key，执行状态值为field，查找包括所述当前执行作业id和状态的待触发作业。

优选地，S203中，所述当前执行作业的id为key，执行状态值为field的结构为redis中的map集合["p-projectid-flowid-jobid",state,0]。

优选地，S1中，所述判断当前执行作业是否执行成功，如果是，则转到S2，同时，将当前执行作业执行成功的状态存储在队列中，则在S5中，所述则执行待触发作业，之后还包括，将队列中当前执行作业执行成功的状态清空，等待下一次填充。

进一步地，S1和S2之间还包括步骤：调用触发调度系统的http接口：http://hosts:port/trigger？project＝PROJECTID&flow＝FLOWID&job＝JOBID&state＝STATE，填充参数，然后发送请求到调度系统。

一种事件触发调度系统，包括：

计算模块：用于在待触发作业的状态中，将所述当前执行作业状态的统计数增量加一并更新；还用于将待触发作业更新后的每个状态的统计数均减一并更新；

判断模块：用于判断当前执行作业是否执行成功，还用于判断待触发作业第二次更新后的每个状态的统计数是否均大于等于0；

当前执行作业模块：用于获取当前执行作业的id和状态；

待触发作业模块：用于获取待触发作业的id和状态。

进一步地，还包括

存储模块：用于存储所有作业流中所有作业子节点之间的依赖关系；还用于存储当前执行作业执行成功的状态。

进一步地，还包括

查找模块：用于在redis中查找key为state的set集合；还用于遍历set集合中所有的数据，根据当前执行作业的id为key，执行状态值为field，查找包括所述当前执行作业id和状态的待触发作业。

进一步地，还包括

接口模块：用于调用触发调度系统的http接口。

本发明的有益效果是：本发明实施例提供的事件触发调度系统和方法，是根据实际生产中，上一项作业执行成功之后才执行下一项的原则而开发的，所以，符合企业数据流的处理规范,不会出现上一项执行失败而执行下一项的情况，避免了后续产生一系列的错误，同时，由于通过事件触发下一项任务的执行，所以，作业流简单，减少了资源的浪费与占用。

附图说明

图1是本发明实施例提供的事件触发调度方法流程示意图；

图2是本发明实施例提供的事件触发调度系统的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施方式仅仅用以解释本发明，并不用于限定本发明。

本发明主要是针对azkaban为主的调度系统的依赖关系进行改进，改进了对作业流的外部调用。提出的解决方案主要为：在执行作业流时，对作业流中每个作业子节点的执行作态存储到队列中，当队列中某个状态的产生正好触发某个其他作业流的执行条件，就触发另一条作业流的执行，并把存储队列清空,进行下一次等待。

本发明技术的关键点在于对现有的任务调度设计方案进行了扩展，增强适应业务复杂度的能力。在本发明中，使用redis作为存储容器，并对job结果状态的累积值做加减运算。当执行完发送一个状态值时，相应的作业状态值累计数加一，判断某条作业流所有的依赖值的累计数是否都大于0，如果都大于0，则执行一次，并遍历减一，否则，进行下一次等待。

具体的技术方案详述如下。

实施例一

如图1所示，本发明实施例提供了一种事件触发调度的方法，包括如下步骤：

S1，判断当前执行作业是否执行成功，如果是，则转到S2，否则，继续执行；

S2，获取包括所述当前执行作业id和状态的待触发作业；

S3，获取所述待触发作业的每个状态的统计数，将所述当前执行作业状态的统计数增量加一并更新，得到待触发作业第一次更新后的每个状态的统计数；

S4，将待触发作业更新后的每个状态的统计数均减一并更新，得到待触发作业第二次更新后的每个状态的统计数；

S5，判断待触发作业第二次更新后的每个状态的统计数是否均大于等于0，如果是，则执行待触发作业；否则，转到S3。

在本发明的一个优选实施例中，S1之前，还包括：获取所有作业流中所有作业子节点之间的依赖关系。

在实际的企业生产中，可能存在多个作业流，而每个作业流中的作业子节点之间可能存在依赖关系，所以，可以通过该依赖关系，完成对另一个作业流的触发调度。

在本发明的一个更加优选实施例中，所述获取所有作业流中所有作业子节点之间的依赖关系之后，将依赖作业流存入redis中，则S2包括：

S201，获取当前执行作业的状态state；

S202，在redis中查找key为state的set集合；

S203，遍历set集合中所有的数据，根据当前执行作业的id为key，执行状态值为field，查找包括所述当前执行作业id和状态的待触发作业。

本发明中采用的是redis作为存储,因为redis可支持的存储结构可以很好的满足作业状态的存储类型。如本领域技术人员可以理解的，不同企业或不同场景也可以根据自身的环境选择其他存储组件进行开发调用,常见的其他存储组件有zookeeper,mysql,ZeroMQ等。

其中，S203中，所述当前执行作业的id为key，执行状态值为field的结构为redis中的map集合["p-projectid-flowid-jobid",state,0]。

在本发明的一个优选实施例中，S1中，所述判断当前执行作业是否执行成功，如果是，则转到S2，同时，将当前执行作业执行成功的状态存储在队列中，则在S5中，所述则执行待触发作业，之后还包括，将队列中当前执行作业执行成功的状态清空，等待下一次填充。

在本发明的另一个优选实施例中，S1和S2之间还包括步骤：调用触发调度系统的http接口：

http://hosts:port/trigger？project＝PROJECTID&flow＝FLOWID&job＝JOBID&st ate＝STATE，填充参数，然后发送请求到调度系统。

上述实施例的实际操作过程可以为：

步骤一，把作业流依赖存入redis中。

步骤二，当其中一个作业流：A作业流中的作业子节点任务a-1job执行成功后，调用触发调度系统的http接口：

http://hosts:port/trigger？project＝PROJECTID&flow＝FLOWID&job＝JOBID&st ate＝STATE，填充参数后发送请求到调度系统。

步骤三，当服务端接收到步骤二中发送的请求后,首先在redis中查找key为state的set集合数据。

步骤四，遍历set集合中所有的数据，根据project，flow，job的id为key，执行状态值为field，查找相应的执行状态值的统计数。该结构为redis中的map集合["p-projectid-flowid-jobid",state,0]。

步骤五，在查找出相应统计数的基础上，对相应统计数增量加一并更新。

步骤六，对作业流的所有依赖做判断：当作业流中所有的state状态的值减一之后都大于或等于0时,表明触发了执行条件,调用执行接口进行调用执行；作业流中所有的state状态的值减一之后出现某个state状态的值小于0,则不符合执行条件,把state状态回滚(即加一)，然后进行下一次判断。

下面举例说明上述操作过程:

1.获取当前执行作业：project＝project_01,flow＝flow_01,job＝job_01,state＝pfj_01。

2.需要依赖state＝pjf_01状态的作业流包括：

{"pjf_01":["p-project_02-flow_02_job_02","p-project_12-flow_12_job_12"]},此数据已经存储到reids中。

3."p-project_02-flow_02_job_02"作业流的依赖项的初始状态为:{"p-project_02-flow_02_job_02","pfj_01","0"}；

"p-project_12-flow_12_job_12"作业流的依赖项的初始状态为：{"p-project_12-flow_12_job_12",{"pfj_01":"0","pjf_02:0"}}。

4.当"project_01-flow_01-job_01"任务执行成功后,调用http接口发送调度请求给jetty服务后台进行处理。

5.服务后台接收到上述请求后，redis会为每一个依赖"pfj_01"的作业状态的统计数加一,得到：

{"p-project_02-flow_02_job_02","pfj_01","1"},{"p-project_12-flow_12_job_12",{"pfj_01":"1","pjf_02:0"}}。

6.遍历作业流的每个状态统计数减一处理后，得到：

{"p-project_02-flow_02_job_02","pfj_01","0"},{"p-project_12-flow_12_job_12",{"pfj_01":"0","pjf_02:-1"}}。

7.对业流的依赖项进行判断，在本例中，{"p-project_02-flow_02_job_02","pfj_01","0"}的依赖项等于0,满足执行条件,则进行触发执行,而{"pfj_01":"0","pjf_02:-1"}}不满足条件,则进行回退{"pfj_01":"1","pjf_02:0"}},等待下一次执行。

实施例二

如图2所示，本发明实施例提供了一种事件触发调度系统，包括：

计算模块：用于在待触发作业的状态中，将所述当前执行作业状态的统计数增量加一并更新；还用于将待触发作业更新后的每个状态的统计数均减一并更新；

判断模块：用于判断当前执行作业是否执行成功，还用于判断待触发作业第二次更新后的每个状态的统计数是否均大于等于0；

当前执行作业模块：用于获取当前执行作业的id和状态；

待触发作业模块：用于获取待触发作业的id和状态。

该系统的实施方法可参见实施例一中的描述，在此不再赘述。

本发明实施例提供的事件触发调度系统，还包括

存储模块：用于存储所有作业流中所有作业子节点之间的依赖关系；还用于存储当前执行作业执行成功的状态。

本发明实施例提供的事件触发调度系统，还包括

查找模块：用于在redis中查找key为state的set集合；还用于遍历set集合中所有的数据，根据当前执行作业的id为key，执行状态值为field，查找包括所述当前执行作业id和状态的待触发作业。

本发明实施例提供的事件触发调度系统，还包括

接口模块：用于调用触发调度系统的http接口。

通过采用本发明公开的上述技术方案，得到了如下有益的效果：本发明实施例提供的事件触发调度系统和方法，是根据实际生产中，上一项作业执行成功之后才执行下一项的原则而开发的，所以，符合企业数据流的处理规范,不会出现上一项执行失败而执行下一项的情况，避免了后续产生一系列的错误，同时，由于通过事件触发下一项任务的执行，所以，作业流简单，减少了资源的浪费与占用。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域人员应该理解的是，上述实施例提供的方法步骤的时序可根据实际情况进行适应性调整，也可根据实际情况并发进行。

上述实施例涉及的方法中的全部或部分步骤可以通过程序来指令相关的硬件来完成，所述的程序可以存储于计算机设备可读取的存储介质中，用于执行上述各实施例方法所述的全部或部分步骤。所述计算机设备，例如：个人计算机、服务器、网络设备、智能移动终端、智能家居设备、穿戴式智能设备、车载智能设备等；所述的存储介质，例如：RAM、ROM、磁碟、磁带、光盘、闪存、U盘、移动硬盘、存储卡、记忆棒、网络服务器存储、网络云存储等。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

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

Claims (4)

1.一种事件触发调度的方法，其特征在于，包括如下步骤：

S1，判断当前执行作业是否执行成功，如果是，则转到S2，否则，继续执行；

S2，获取包括所述当前执行作业id和状态的待触发作业；

S3，获取所述待触发作业的每个状态的统计数，将所述当前执行作业状态的统计数增量加一并更新，得到待触发作业第一次更新后的每个状态的统计数；

S4，将待触发作业更新后的每个状态的统计数均减一并更新，得到待触发作业第二次更新后的每个状态的统计数；

S5，判断待触发作业第二次更新后的每个状态的统计数是否均大于等于0，如果是，则执行待触发作业；否则，转到S3；

S1之前，还包括：获取所有作业流中所有作业子节点之间的依赖关系；

所述获取所有作业流中所有作业子节点之间的依赖关系之后，将依赖作业流存入redis中，则S2包括：

S201，获取当前执行作业的状态state；

S202，在redis中查找key为state的set集合；

S203，遍历set集合中所有的数据，根据当前执行作业的id为key，执行状态值为field，查找包括所述当前执行作业id和状态的待触发作业。

2.根据权利要求1所述的事件触发调度的方法，其特征在于，S203中，所述当前执行作业的id为key，执行状态值为field的结构为redis中的map集合。

3.根据权利要求1所述的事件触发调度的方法，其特征在于，S1中，所述判断当前执行作业是否执行成功，如果是，则转到S2，同时，将当前执行作业执行成功的状态存储在队列中，则在S5中，所述则执行待触发作业，之后还包括，将队列中当前执行作业执行成功的状态清空，等待下一次填充。

4.一种事件触发调度系统，其特征在于，包括：

计算模块：用于在包括当前执行作业id和状态的待触发作业的状态中，将所述当前执行作业状态的统计数增量加一并更新；还用于将待触发作业更新后的每个状态的统计数均减一并更新；

判断模块：用于判断当前执行作业是否执行成功，还用于判断待触发作业第二次更新后的每个状态的统计数是否均大于等于0；

当前执行作业模块：用于获取当前执行作业的id和状态；

待触发作业模块：用于获取待触发作业的id和状态；

还包括

存储模块：用于存储所有作业流中所有作业子节点之间的依赖关系；还用于存储当前执行作业执行成功的状态；

还包括

查找模块：用于在redis中查找key为state的set集合；还用于遍历set集合中所有的数据，根据当前执行作业的id为key，执行状态值为field，查找包括所述当前执行作业id和状态的待触发作业；

还包括

接口模块：用于调用触发调度系统的http接口。