分布式批量作业处理系统

技术领域

本申请涉及分布式处理领域，具体而言，涉及一种分布式批量作业处理系统。

背景技术

传统批处理调度任务基本都在单机上运行，同一机器上运行了大量的作业任务，共用相同的CPU等硬件资源，在任务不多、负荷不重的情况下，基本能满足要求，随着目前互联网信息爆炸式的增长，批处理的作业越来越多，要处理的数据越来越多，如何提升批处理作业的效率就势在必行，所以就有了分布式的批处理架构方案的诞生。

分布式批处理方案有很多好处，比如可以利用廉价的机器，可以(理论上)无限水平拓展，同时也带来了一系列棘手的问题，机器之间的网络通信，如何把流量均匀的分布于不同机器，如果有机器宕机了如何处理，每个问题都已经是一个庞大的技术领域。

对于调度的分布式问题，首先要解决的便是如何把任务分发到不同的机器上，这要求调度系统通常要至少分为两层，第一层决定一共要处理哪些任务并把任务分发到哪些机器上处理，第二层接到任务后具体执行。虽然描述起来很简单，但是这个处理过程实际上需要大量支撑系统的支持，比如在任务分发时如何判断哪些机器还可以处理任务，这可能需要一个可以感知整个集群运行状态的配置中心，又比如任务如何分发，是采用消息还是实时服务接口，如果是用消息派发则需要消息系统，如果是实时服务，又需要成熟的RPC的分布式服务框架。当系统达到这个复杂度，已经不是将任务捞起并处理这么单纯，而是多个关联系统复杂性的叠加。

分布式批作业调度技术在互联网、金融领域应用非常广泛，目前主流成熟的有quartz、azkaban、tbschedule、xxl-job等，都提供了相近似的分布式作业调度实现方案，所有的方案都包含、调度中心、调度执行器、调度管理等功能，架构大致如图1所示。由总调度对所有的任务进行分布式任务调度，所有的任务在分配时不区分大任务、小任务。

所以，主流的批处理框架按一定的策略分配任务到指定的节点运行，当有大任务运行的时候，不做具体业务拆分，因此并不能从根本上提升批作业的运行效率。

在大规模、大数据量的批处理作业模式下，批处理的作业调度分布节点越来越多，调用关系日益复杂。同时伴随着业务的要求，对批处理作业的时间要求越来越高，要求要在保障各批作业节点流程的正常运行下，要尽可能快的处理完成各种复杂的尤其大文件处理，如何在现有主流的分布式批处理作业模式下根本提升性能，是批处理作业中重点要关注的：

目前的分布式作业技术存在的技术问题如下：

第一，批任务按照功能和节点进行分配，大作业任务由于是单点运行，顺序运行，执行效率很差；

第二，不能灵活的按照任务节点进行扩展，如果扩展就需要修改整个总调度，重新进行任务分配；

第三，任务的监控不能详细监控到任务内部的详细运行过程，不能监控到负载模式运行下的子任务状态。

发明内容

本申请的主要目的在于提供一种分布式批量作业处理系统，以解决现有技术中分布式批量作业调度技术运行效率较差的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种分布式批量作业处理系统，包括：消息总线；主任务拆分模块，用于将主任务拆分为多个子任务，并将各所述子任务注册到所述消息总线上；子任务执行模块，用于从所述消息总线上订阅所述子任务，并执行所述子任务。

进一步地，所述系统还包括：汇集任务模块，用于在所有的所述子任务执行完成后，通过所述消息总线接收各所述子任务的执行结果，并将所述执行结果进行汇总。

进一步地，所述汇集任务模块将所述执行结果进行汇总，得到汇总结果后，将所述汇总结果反馈至所述主任务拆分模块。

进一步地，所述子任务执行模块将所述子任务的实时状态，发送至所述消息总线，所述消息总线将所述子任务的实时状态反馈至所述主任务拆分模块。

进一步地，所述系统还包括：监控界面，用于显示各所述子任务的执行状态。

进一步地，所述系统还包括：数据库，用于存储各所述子任务的执行状态。

进一步地，所述数据库为以下之一：MySQL、Microsoft Access、Microsoft SQL和Oracle。

进一步地，所述子任务执行模块为虚拟机，所述主任务拆分模块还用于根据所述虚拟机的数量调整所述子任务的个数。

进一步地，所述子任务执行模块为虚拟机，所述虚拟机的数量小于所述子任务的数量。

进一步地，所述主任务为以下至少之一：文件复制、内存运算。

应用本申请的技术方案，主任务拆分模块将主任务拆分为多个子任务，并将各上述子任务注册到上述消息总线上，子任务执行模块从上述消息总线上订阅子任务，并执行子任务。实现了对主任务的拆分以及子任务的分布式执行，提升了分布式批量作业调度技术的运行效率。相对于现有技术中的主流的批处理框架，当有大任务运行的时候，不做具体业务拆分，只是将大任务分配到指定的节点上运行的方案，大大提升了运行效率。

附图说明

构成本申请的一部分的说明书附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出了现有技术中的分布式批作业调度架构；

图2示出了本申请的实施例的分布式批量作业处理系统示意图；

图3示出了本申请的实施例的分布式批量作业处理流程示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

应该理解的是，当元件(诸如层、膜、区域、或衬底)描述为在另一元件“上”时，该元件可直接在该另一元件上，或者也可存在中间元件。而且，在说明书以及权利要求书中，当描述有元件“连接”至另一元件时，该元件可“直接连接”至该另一元件，或者通过第三元件“连接”至该另一元件。

为了便于描述，以下对本申请实施例涉及的部分名词或术语进行说明：

消息总线：消息总线是一种通信工具，可以在机器之间互相传输消息、文件等。消息总线扮演着一种消息路由的角色，拥有一套完备的路由机制来决定消息传输方向。发送段只需要向消息总线发出消息而不用管消息被如何转发，为了避免消息丢失，部分消息总线提供了一定的持久化存储和灾备的机制。

分布式批处理：分布式批处理采用作业调度与作业执行分离的架构来简化业务系统批处理的开发和运维；采用中间件和平台化的思路提升其应用的范围及价值；用于系统作业的调度、执行与管控。异步分布式的批处理框架包含中间件基础组件、作业调度管控中、协调注册中心、队列等。

主任务：是指分布式批处理中的主调度任务，一般由主任务进行子任务的拆分、状态监控等。

子任务：一般指独立的时间片任务，子任务可以有独立的处理流程。子任务处理完成之后，需要反馈任务状态到主任务。

正如背景技术所介绍的，现有技术中分布式批量作业调度技术运行效率较差，为了解决如上分布式批量作业调度技术运行效率较差的问题，本申请的实施例提供了一种分布式批量作业处理系统。

本申请的一种典型的实施例提供了一种分布式批量作业处理系统。如图2所示，该系统包括：

消息总线；

主任务拆分模块，用于将主任务拆分为多个子任务，并将各上述子任务注册到上述消息总线上；

子任务执行模块，用于从上述消息总线上订阅上述子任务，并执行上述子任务，即子任务执行模块可以实现对子任务的自动认领。

具体地，若主任务是对大文件进行复制，文件标号需要和任务记录进行匹配。

上述方案中，主任务拆分模块将主任务拆分为多个子任务，并将各上述子任务注册到上述消息总线上，子任务执行模块从上述消息总线上订阅子任务，并执行子任务。实现了对主任务的拆分以及子任务的分布式执行，提升了分布式批量作业调度技术的运行效率。相对于现有技术中的主流的批处理框架，当有大任务运行的时候，不做具体业务拆分，只是将大任务分配到指定的节点上运行的方案，大大提升了运行效率。

本申请的一种实施例中，如图2所示，上述系统还包括：汇集任务模块，用于在所有的上述子任务执行完成后，通过上述消息总线接收各上述子任务的执行结果，并将上述执行结果进行汇总。即本系统是一种总分总模型的分布式批量调度技术，分布式作业中大的任务(主任务)，在进行任务分解之后，得到多个子任务，将子任务注册到消息总线上；子任务执行模块再从消息总线上订阅子任务进行消费和执行，所有的子任务执行完成之后，结果再回溯到汇集任务模块，这样就构成了总分总的任务拆分、任务执行、任务汇集的技术机制，从而解决了大任务执行的性能效率问题，当然，在某些场景下可不进行任务汇集，直接子任务按照任务节点执行完成即可。

本申请的一种实施例中，上述汇集任务模块将上述执行结果进行汇总，得到汇总结果后，将上述汇总结果反馈至上述主任务拆分模块。

具体地，汇总任务有两种方式：一是所有的子任务完成后，触发统一的汇总任务执行汇总，这种方式一般偏向于内存运算或文件汇集。二是每个子任务流转到下一任务进行数据汇总，这种方式一般偏向于数据库等可并发处理的操作。汇总执行完成之后，通过消息总线实时同步状态到总调度(即主任务拆分模块)，同时任务处理结束。

本申请的一种实施例中，上述子任务执行模块将上述子任务的实时状态，发送至上述消息总线，上述消息总线将上述子任务的实时状态反馈至上述主任务拆分模块。即主任务拆分模块可以实时获取各子任务的执行情况。另外，主任务拆分模块可以向汇集任务模块发出指令，主任务拆分模块是整个系统的核心。

本申请的一种实施例中，如图2所示，上述系统还包括：监控界面，用于显示各上述子任务的执行状态。当然，监控界面还可以显示主任务的执行状态；可以更直观地监测到所有任务的详细执行状态，进一步地实现了更精准的任务监控。即时监控跟踪所有子任务的执行状态，通过任务状态明细查询跟踪所有的子任务信息。

本申请的一种实施例中，如图2所示，上述系统还包括：数据库，用于存储各上述子任务的执行状态。具体地，可以将各子任务的执行状态存储在数据库的表中。

本申请的一种实施例中，上述数据库为以下之一：MySQL、Microsoft Access、Microsoft SQL和Oracle。当然，也可以选择除MySQL、Microsoft Access、Microsoft SQL和Oracle以外的数据库。

本申请的一种实施例中，子任务执行模块执行的子任务的数量可以任意扩展，完成一个子任务的子任务执行模块，可以主动去检查是否有未完成的子任务，如果有未完成的子任务，可以继续领取子任务执行。直到所有的子任务执行完，由主任务拆分模块触发下一步的汇集任务。

本申请的一种实施例中，上述子任务执行模块为虚拟机，上述主任务拆分模块还用于根据上述虚拟机的数量调整上述子任务的个数。例如，本来将主任务拆分为5个子任务，在发现虚拟机的数量为10个时，将主任务拆分为10个子任务，使得在一个虚拟机上执行一个子任务，且同步执行，加快了任务的执行速度。也就是说可以根据子任务执行模块的数量，调整子任务的个数，以实现以最快的速度将主任务执行完。需要说明的是，本实施例中的“虚拟机”只是示意性的，子任务执行模块还可以为物理机、机器中的一个执行单元、或者服务器下的程序化模块。主任务拆分模块、子任务执行模块以及汇集任务模块都可以为服务器下的程序化模块。在服务器中运行各模块以实现任务的分布式执行，加快任务的执行效率。即在不修改整个总调度的情况下，就可以实现对主任务的重新分配。即实现了子任务节点的灵活配置。

本申请的一种实施例中，上述子任务执行模块为虚拟机，上述虚拟机的数量小于上述子任务的数量。例如，子任务的数量为10个，虚拟机为5个，一个虚拟机可以从消息总线上订阅两个子任务，并执行订阅的子任务。当然，由于虚拟机的性能差异，也可以第一个虚拟机执行一个子任务；第二个虚拟机执行三个子任务；第三个虚拟机执行两个子任务；第四个虚拟机执行两个子任务；第五个虚拟机执行两个子任务。

本申请的一种实施例中，上述主任务为以下至少之一：文件复制、内存运算。对于一些大文件的复制，采用本申请的方案可以大大提高文件的复制速度。

实施例

本实施例涉及一种具体的分布式批量作业处理流程，如图3所示。

主任务拆分模块将大作业进行拆分后，通过1.0投递消息到消息总线；

子任务执行模块通过2.1、2.2、2.3从消息总线上订阅子任务，子任务执行完成之后通过2.4、2.5、2.6反馈执行结果，同时子任务结束运行；

主任务拆分模块通过2.7接收各子任务的反馈，确认所有子任务已经执行完成后，流程进入下一步；

主任务拆分模块(即总调度任务)通过2.8投递下一任务给汇集任务模块；

汇集任务模块通过2.9进行汇总执行，执行完成之后通过3.0提交反馈任务到总调度，任务结束。

该系统的核心为任务拆分，分布运行，通过消息总线进行任务挂载和状态同步，从而快速高效的完成批量大作业任务。

从以上的描述中，可以看出，本申请上述的实施例实现了如下技术效果：

本申请的分布式批量作业处理系统，主任务拆分模块将主任务拆分为多个子任务，并将各上述子任务注册到上述消息总线上，子任务执行模块从上述消息总线上订阅子任务，并执行子任务。实现了对主任务的拆分以及子任务的分布式执行，提升了分布式批量作业调度技术的运行效率。相对于现有技术中的主流的批处理框架，当有大任务运行的时候，不做具体业务拆分，只是将大任务分配到指定的节点上运行的方案，大大提升了运行效率。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。