CN107316124A - 大数据环境下大规模事务型作业调度与处理通用平台 - Google Patents

Abstract

大数据环境下大规模事务型作业调度与处理通用平台，包括作业适配器、作业调度中心和多个作业处理引擎。作业适配器通过统一的事务型作业接口接收来自上层业务应用系统的作业，转发给作业调度中心，将来自作业调度中心的作业执行结果反馈给上层业务应用系统。作业调度中心计算每个作业处理引擎响应评分，按调度顺序将作业推送给评分最高的作业处理引擎，根据作业执行情况对作业进行移除或上报，将作业处理结果反馈给作业适配器。每个作业处理引擎对作业进行处理，将作业执行情况和作业执行结果反馈给作业调度中心。本发明通过事务型作业接口减轻了上层应用系统开发工作，满足业务逻辑动态变更需求，实现了大规模事务型作业高效可靠地并行处理。

Description

大数据环境下大规模事务型作业调度与处理通用平台

技术领域

本发明涉及大数据环境下大规模事务型作业调度与处理通用平台，属于大数据技术领域。

背景技术

在大数据时代，信息技术飞速发展，应用系统规模迅速扩大，产生的数据呈爆炸式增长。从多源、异构、海量的数据中提取出有价值信息已远远超出了传统信息系统的处理能力，由此大数据技术应运而生。在大数据领域，通常将数据处理过程划分为若干个作业进行处理。如何对大规模作业进行高效、合理调度和处理，同时保证作业执行的原子性和一致性，以及作业间的共享资源并发访问控制成为当前亟需解决的难题。

为了解决这一问题，国内外开展了大量研究，涌现出一些大数据处理框架。例如：Apache发布了Storm实时数据流处理框架，其预先将业务逻辑封装在拓扑中，集群基于拓扑进行调度和处理。在最新版本Storm中还引入了事务性拓扑，对作业执行异常采取容错处理。该框架所使用的拓扑为静态图结构，拓扑在提交后无法在线调整，不能满足业务逻辑动态变更的需求，而且新提出的事务处理机制粒度不够精细。微软发布了Dryad分布式运算框架，基于动态的DAG图来调度计算节点Vertex执行。该框架适用场景固然灵活，但代价是增加了上层应用系统的开发难度，易用性有待提高。

中国专利公开号CN104050261A，公开日2014年9月17日，发明创造名称为基于Storm的可变逻辑的通用数据处理系统，该申请案公开了一种基于Storm可支持业务逻辑在线调整的数据处理系统，该系统通过修改约束和处理逻辑配置文件，来实现业务逻辑在线变更。这种方式需要人工修改配置文件，不能针对作业实时自动变更。中国专利公开号CN104461722A，公开日2015年3月25日，发明创造名称为一种用于云计算系统的作业调度方法，该申请案公开了一种采用先进先出工作方式、考虑作业等待分配时延的作业调度方法，能提高系统资源利用率，节省作业请求者时间。但该方法在调度时未考虑作业之间的依赖关系。中国专利公开号CN106156939A，公开日2016年11月23日，发明创造名称为基于作业流的分布式调度系统及应用方法，该申请案公开了一种将调度逻辑处理与作业具体执行分开到不同节点的作业调度系统，提高了作业调度和执行效率。但该发明在选择执行代理时只依据代理类型，未考虑代理上负载状况，可能造成各代理负载不均衡。

发明内容

本发明的技术解决问题是：克服现有技术的不足，提供大数据环境下大规模事务型作业调度与处理通用平台，能够满足业务逻辑动态变更的需求，并在作业执行过程中采用细粒度事务控制，可以有效解决作业间共享资源并发访问控制问题，实现了大规模事务型作业高效可靠地并行处理。此外平台还提供简单友好的事务型作业接口供上层应用系统使用，大大减轻了上层应用系统开发工作。

本发明的技术解决方案是：大数据环境下大规模事务型作业调度与处理通用平台，包括一个作业适配器、一个作业调度中心和多个作业处理引擎；

作业适配器通过统一的事务型作业接口，接收来自上层业务应用系统的作业，并将接收的作业转发给作业调度中心，将来自作业调度中心的作业执行结果反馈给上层业务应用系统；所述事务型作业接口定义了所接收作业的模板，该模板包括作业类型、作业对应的执行控制点以及请求使用资源的许可级别，所述每个执行控制点对应一类资源；所述作业类型按照作业的即时性要求程度、执行时间长短、是否易耗内存、I/O访问是否频繁进行划分；所述请求使用资源的许可级别为共享或独占；

作业调度中心接收并存储来自作业适配器的作业，根据该作业对应的执行控制点以及请求使用资源的许可级别，确定作业的调度顺序；查询作业处理引擎的运行状态，计算每个正常运行的作业处理引擎响应评分，按调度顺序将作业推送给评分最高的作业处理引擎；接收作业处理引擎反馈的作业执行情况和作业执行结果，当作业执行完成时，将作业移除，并将作业执行结果反馈给作业适配器；当作业执行异常时，上报人工处理；

每个作业处理引擎拥有多个作业执行器，作业处理引擎接收作业调度中心发送的作业，将其分配给空闲的作业执行器进行处理；同时作业处理引擎监控各作业执行器的执行状态，当发现处理异常时，终止该作业执行器的执行，将作业重新分配给其他的空闲作业执行器进行处理；作业执行结束后，作业处理引擎从作业执行器采集作业的执行情况和作业执行结果，并反馈给作业调度中心。

所述作业调度中心包括作业计划图和作业调度器；

作业计划图是由各个执行控制点组成的一个动态有向无环图，每个执行控制点由许可区和排队区两部分组成，进入作业调度中心的作业首先进入所声明执行控制点的排队区等待，执行控制点按照作业请求使用资源的许可级别决定排队区的作业能否进入许可区，作业计划图将进入许可区的作业发送给作业调度器进行调度；接收作业处理引擎反馈的作业执行情况和作业执行结果，当作业执行完成时，将作业移除，并将作业执行结果反馈给作业适配器；当作业执行异常时，上报人工处理；

作业调度器每接收到一个作业，首先查询作业处理引擎的运行状态，计算每个正常运行的作业处理引擎响应评分，将接收到的作业推送给评分最高的作业处理引擎。

所述作业调度器利用如下公式计算第n个正常运行的作业处理引擎响应评分S_n：

式中F_n表示第n个作业处理引擎上空闲作业执行器个数；T_n表示该引擎上作业执行器总数；Q_n表示该引擎上作业执行队列中等待执行作业个数；Cpu_n表示该引擎剩余可用CPU余量；Mem_n表示该引擎剩余可分配内存大小；A_n表示该引擎的类型；A_task表示当前作业类型；符号⊙表示同或运算，当作业类型与引擎类型相同时，该运算结果为1，即提高该引擎评分，反之该运算结果为0；k₁、k₂、k₃、k₄、k₅的取值保证k₃Cpu_n、k₄Mem_n、k₅A_n⊙A_task的值均在0-1之间。

所述每个作业处理引擎周期性地向作业调度中心发送心跳信息，若作业调度中心未收到某作业处理引擎的心跳信息，则说明该作业处理引擎出现故障，作业调度中心将该作业处理引擎上所有未处理的作业回收，重新进行调度。

所述事务型作业接口的作业模板还定义了作业的划分方式，上层业务应用系统根据该作业划分方式将每个作业划分为多个Action操作，并为每个Action操作定义了事务开始位置、结束位置和回滚方式，其中每个Action操作为不可再分的原子操作。

每个作业执行器工作过程如下：

(6.1)以Action操作为最小处理单元执行接收到的作业；

(6.2)判断是否出现某一Action操作执行失败，若有进入步骤(6.4)，否则进入(6.3)；

(6.3)判断作业中的所有Action操作是否全部执行完成，若是，则向作业处理引擎反馈作业执行完成信息；否则，继续执行未执行的Action操作，返回步骤(6.2)；

(6.4)根据定义的回滚方式回滚该Action操作并进行重新执行，若执行成功，进入步骤(6.3)；否则，继续重新执行回滚后的Action操作，当重新执行次数达到预设上限时，终止该作业执行，并向作业处理引擎上报作业执行异常信息。

与现有技术相比，本发明具有如下有益效果：

(1)本发明定义了基于执行控制点的作业计划图，对作业执行许可进行合理有序调度，避免了共享资源抢占造成混乱，保障了作业按照业务逻辑有序执行，有效解决了作业间共享资源并发访问控制问题；同时作业计划图根据执行控制点的变化而动态变化，不需要人工修改，能及时应对各种业务需求变化，满足业务逻辑动态变更的需求，具备广泛适用性。

(2)本发明在作业调度过程中充分考虑了各作业处理引擎上空闲作业执行器比例、等待作业个数、剩余可用计算资源情况及引擎的主要用途等因素，实现了大规模作业高效合理调度和负载均衡的目的。

(3)本发明在作业执行过程中采用细粒度的事务控制，保障了处理结果的正确性和一致性；同时事务粒度精细到Action，在执行出错时，针对出错Action进行回滚再执行，相较于整个作业重新执行，明显提高了作业处理效率。

(4)本发明通过事务型作业接口定义了接收作业的模板，从而规范了上层业务应用系统的作业定义形式，上层业务应用系统通过套用模板，无需考虑作业并行处理、负载均衡等繁琐的处理细节，全交由平台来完成，这样降低了上层应用系统的开发难度，提高了平台的易用性。

(5)本发明对各作业处理引擎进行实时监控，能对异常情况及时处理，具有高容错性和高可用性。

附图说明

图1为本发明通用平台组成示意图；

图2为作业计划图示意图；

图3为作业调度中心进行作业调度流程图；

图4为通用平台作业执行基本流程图。

具体实施方式

如图1所示，本发明提出的大数据环境下大规模事务型作业调度与处理通用平台由一个作业适配器(Adapter)、一个作业调度中心(Scheduler)和多个作业处理引擎(Engine)组成。

作业适配器(Adapter)通过统一的事务型作业接口，与各异构上层业务应用系统进行无缝对接，接收来自上层业务应用系统的作业，并将接收的作业转发给作业调度中心，将来自作业调度中心的作业执行结果反馈给上层业务应用系统。事务型作业接口定义了所接收作业的模板，上层业务应用系统根据该模板对作业信息进行整理，以符合该模板要求的形式将作业发送给作业适配器。该模板包括作业类型、作业对应的执行控制点、请求使用资源的许可级别以及作业的划分方式，每个执行控制点对应一类资源；作业类型按照作业的即时性要求程度、执行时间长短、是否易耗内存、I/O访问是否频繁进行划分；请求使用资源的许可级别为共享或独占。上层业务应用系统根据业务具体情况和模板定义的划分方式，将作业细粒度划分为多个Action操作，为每个Action操作定义了事务开始位置、结束位置和回滚方式，其中每个Action操作为不可再分的原子操作。

作业调度中心(Scheduler)主要负责将作业合理调度给各作业处理引擎，并监视其运行状态。作业调度中心基于ZooKeeper分布式协调系统实现，主要分为作业计划图和作业调度器两个部分。作业调度中心通过作业适配器接收各事务型作业，对作业进行存储并加入作业计划图。

如图2所示，作业计划图是由若干个执行控制点组成的一个动态有向无环图，每个执行控制点可以看成一个FIFO的队列，可以用来表示作业执行中需要用到的共享资源或作业间依赖关系。执行控制点由许可区和排队区两部分组成。作业加入作业计划图后，先进入所声明执行控制点的排队区等待，执行控制点按照作业请求使用资源的许可级别和/或作业间依赖关系决定排队区的作业能否进入许可区。作业进入许可区即获得执行许可，允许由作业调度器进行调度。作业计划图接收作业处理引擎反馈的作业执行情况和作业执行结果，当作业执行完成时，将作业移除，并将作业执行结果反馈给作业适配器；当作业执行异常时，将作业移除，并上报人工处理。

作业请求使用资源的许可级别包括：独占(X)和共享(S)。独占是指是一个作业获得该执行控制点的许可后，排队区的其它作业必须等待，直到该作业退出执行控制点，其它作业才能获得许可；共享是指多个作业可以同时获得许可，直到下一个作业请求独占为止。

作业调度器基于作业计划图检测作业的执行许可，当作业进入许可区后，查询各在线工作的作业处理引擎当前运行状态，综合考虑当前各引擎上空闲作业执行器个数和等待执行的作业个数、引擎剩余可用计算资源情况、引擎主要用途及该作业的类型等多方面因素，按公式1计算各正常运行的作业处理引擎响应评分，将作业推送给分配给评分最高的作业处理引擎进行处理。

第n个正常运行的作业处理引擎响应评分S_n计算公式如下：

式中S_n表示该作业处理引擎的评分；F_n表示该引擎上空闲作业执行器个数；T_n表示该引擎上作业执行器总数；Q_n表示该引擎上作业执行队列中等待执行作业个数；Cpu_n表示该引擎剩余可用CPU余量；Mem_n表示该引擎剩余可分配内存大小；A_n表示该引擎的类型；A_task表示当前作业类型；符号⊙表示同或运算，当作业类型与引擎类型相同时，该运算结果为1，即提高该引擎评分，反之该运算结果为0；k₁、k₂、k₃、k₄、k₅为保证各项指标平衡的比例系数。k₁、k₂、k₃、k₄、k₅的取值保证k₃Cpu_n、k₄Mem_n、k₅A_n⊙A_task的值均在0-1之间。

如图3所示，作业调度中心进行作业调度具体步骤如下：

步骤一、作业调度中心通过作业适配器接收事务型作业，存储于Redis内存数据库中，执行步骤二；

步骤二、将作业加入作业计划图中，进入所声明执行控制点的排队区等待执行许可，执行步骤三；

步骤三、检测作业执行许可，若作业进入许可区，执行步骤四，否则等待然后继续执行步骤三；

步骤四、查询各作业处理引擎当前运行状态，并按公式1计算各引擎响应评分，选择评分最高的引擎，将作业推送给该引擎。

作业调度中心会周期性检查各作业处理引擎发送的心跳信息，若未收到某引擎的心跳信息则说明该引擎出现故障，需将该引擎上所有未处理的作业回收，重新交由作业调度中心进行调度。

作业处理引擎(Engine)主要负责作业具体分配执行，并向作业调度中心汇报作业执行情况和作业执行结果。一个作业处理引擎可拥有多个作业执行器(Executor)，并行执行多个作业。作业处理引擎接收来自作业调度中心分配的作业，并将其加入作业执行队列尾部；引擎从作业执行队列头部取出作业，分配给空闲的作业执行器进行处理；同时引擎监控各作业执行器的执行状态，当发现处理超时等异常时，终止该作业执行器的执行，将作业重新分配给其他的空闲作业执行器进行处理。作业执行结束后，作业处理引擎从作业执行器收集作业的执行情况和作业执行结果，并汇报给作业调度中心。

作业处理引擎可根据引擎所拥有资源特点和实际用途划分引擎类型，如：用于处理实时性要求高的作业、用于处理I/O操作频繁的作业、用于处理长时间的作业、用于处理计算复杂度高的作业、用于处理内存消耗大的作业等，引擎类型与作业类型相对应。

作业执行器(Executor)主要负责作业的具体执行，每个作业执行器同时只处理一个作业，并保证作业执行过程的事务性。由于事务型作业接口已将作业划分为多个Action操作，作业执行器以Action为最小单元进行处理。当某一Action操作执行失败后，根据异常类型进行相应处理：若异常为不可恢复异常，则直接终止该作业执行，向作业处理引擎上报“作业执行异常”；若异常为可恢复异常，则回滚该Action操作并进行重试；当重试执行次数达到预设上限，则终止该作业执行，并将执行错误上报给作业处理引擎。若经过重试成功，则判断作业中的所有Action操作是否全部执行完成，若是，则向作业处理引擎反馈作业执行完成信息，否则，继续执行未执行的Action操作。

如图4所示，平台对作业全生命周期进行监视和管理，作业执行基本流程如下：

步骤一、由作业适配器接收事务型作业，发送给作业调度中心，执行步骤二；

步骤二、作业调度中心将作业加入作业计划图中，将作业状态设为“等待执行”，执行步骤三；

步骤三、作业调度中心基于作业计划图检测作业执行许可，若作业位于排队区，等待并继续执行步骤三；若作业进入许可区，取出作业准备执行，执行步骤四；

步骤四、依据公式计算各作业处理引擎响应评分，将作业推送给评分最高的作业处理引擎，并将作业状态设为“正在执行”，执行步骤五；

步骤五、作业处理引擎将作业分配给空闲的作业执行器进行处理，并监视作业执行情况汇报给作业调度中心，执行步骤六；

步骤六、检查作业执行情况，若为“完成”，则执行步骤七；若为“继续执行”，则执行步骤一；若为“异常”，则执行步骤八；

步骤七、将作业状态设置为“完成”，从作业计划图中移除该作业，流程结束；

步骤八、将作业状态设置为“错误”，保存作业相关信息，从作业计划图中移除该作业，并上报给人工处理，若人工处理选择重试，执行步骤二，若取消，则将作业状态设置为“取消”，流程结束。

本发明通用平台采用基于执行控制点的作业计划图对作业进行合理调度，能够满足业务逻辑动态变更的需求，可以有效解决作业间共享资源并发访问控制问题，并在作业执行过程中采用细粒度事务控制，实现了大规模事务型作业高效可靠地并行处理。此外平台还提供简单友好的事务型作业接口供上层应用系统使用，大大减轻了上层应用系统开发工作。另外，本发明在作业调度过程中充分考虑了各作业处理引擎上空闲作业执行器比例、等待作业个数、剩余可用计算资源情况及引擎的主要用途等因素，实现了大规模作业高效合理调度和负载均衡的目的。

本发明说明书中未作详细描述的内容属于本领域专业技术人员的公知技术。

Claims (6)

1.大数据环境下大规模事务型作业调度与处理通用平台，其特征在于：包括一个作业适配器、一个作业调度中心和多个作业处理引擎；

作业适配器通过统一的事务型作业接口，接收来自上层业务应用系统的作业，并将接收的作业转发给作业调度中心，将来自作业调度中心的作业执行结果反馈给上层业务应用系统；所述事务型作业接口定义了所接收作业的模板，该模板包括作业类型、作业对应的执行控制点以及请求使用资源的许可级别，所述每个执行控制点对应一类资源；所述作业类型按照作业的即时性要求程度、执行时间长短、是否易耗内存、I/O访问是否频繁进行划分；所述请求使用资源的许可级别为共享或独占；

作业调度中心接收并存储来自作业适配器的作业，根据该作业对应的执行控制点以及请求使用资源的许可级别，确定作业的调度顺序；查询作业处理引擎的运行状态，计算每个正常运行的作业处理引擎响应评分，按调度顺序将作业推送给评分最高的作业处理引擎；接收作业处理引擎反馈的作业执行情况和作业执行结果，当作业执行完成时，将作业移除，并将作业执行结果反馈给作业适配器；当作业执行异常时，上报人工处理；

每个作业处理引擎拥有多个作业执行器，作业处理引擎接收作业调度中心发送的作业，将其分配给空闲的作业执行器进行处理；同时作业处理引擎监控各作业执行器的执行状态，当发现处理异常时，终止该作业执行器的执行，将作业重新分配给其他的空闲作业执行器进行处理；作业执行结束后，作业处理引擎从作业执行器采集作业的执行情况和作业执行结果，并反馈给作业调度中心。

2.根据权利要求1所述大数据环境下大规模事务型作业调度与处理通用平台，其特征在于：所述作业调度中心包括作业计划图和作业调度器；

作业计划图是由各个执行控制点组成的一个动态有向无环图，每个执行控制点由许可区和排队区两部分组成，进入作业调度中心的作业首先进入所声明执行控制点的排队区等待，执行控制点按照作业请求使用资源的许可级别决定排队区的作业能否进入许可区，作业计划图将进入许可区的作业发送给作业调度器进行调度；接收作业处理引擎反馈的作业执行情况和作业执行结果，当作业执行完成时，将作业移除，并将作业执行结果反馈给作业适配器；当作业执行异常时，上报人工处理；

作业调度器每接收到一个作业，首先查询作业处理引擎的运行状态，计算每个正常运行的作业处理引擎响应评分，将接收到的作业推送给评分最高的作业处理引擎。

3.根据权利要求2所述大数据环境下大规模事务型作业调度与处理通用平台，其特征在于：所述作业调度器利用如下公式计算第n个正常运行的作业处理引擎响应评分S_n：

式中F_n表示第n个作业处理引擎上空闲作业执行器个数；T_n表示该引擎上作业执行器总数；Q_n表示该引擎上作业执行队列中等待执行作业个数；Cpu_n表示该引擎剩余可用CPU余量；Mem_n表示该引擎剩余可分配内存大小；A_n表示该引擎的类型；A_task表示当前作业类型；符号⊙表示同或运算，当作业类型与引擎类型相同时，该运算结果为1，即提高该引擎评分，反之该运算结果为0；k₁、k₂、k₃、k₄、k₅的取值保证k₃Cpu_n、k₄Mem_n、k₅A_n⊙A_task的值均在0-1之间。

4.根据权利要求1所述大数据环境下大规模事务型作业调度与处理通用平台，其特征在于：所述每个作业处理引擎周期性地向作业调度中心发送心跳信息，若作业调度中心未收到某作业处理引擎的心跳信息，则说明该作业处理引擎出现故障，作业调度中心将该作业处理引擎上所有未处理的作业回收，重新进行调度。

5.根据权利要求1所述大数据环境下大规模事务型作业调度与处理通用平台，其特征在于：所述事务型作业接口的作业模板还定义了作业的划分方式，上层业务应用系统根据该作业划分方式将每个作业划分为多个Action操作，并为每个Action操作定义了事务开始位置、结束位置和回滚方式，其中每个Action操作为不可再分的原子操作。

6.根据权利要求5所述大数据环境下大规模事务型作业调度与处理通用平台，其特征在于：每个作业执行器工作过程如下：

(6.1)以Action操作为最小处理单元执行接收到的作业；

(6.2)判断是否出现某一Action操作执行失败，若有进入步骤(6.4)，否则进入(6.3)；

(6.3)判断作业中的所有Action操作是否全部执行完成，若是，则向作业处理引擎反馈作业执行完成信息；否则，继续执行未执行的Action操作，返回步骤(6.2)；

(6.4)根据定义的回滚方式回滚该Action操作并进行重新执行，若执行成功，进入步骤(6.3)；否则，继续重新执行回滚后的Action操作，当重新执行次数达到预设上限时，终止该作业执行，并向作业处理引擎上报作业执行异常信息。