一种流任务和批任务一体化的分布式任务调度方法及系统与流程

1.本发明属于大数据技术领域，尤其涉及一种流任务和批任务一体化的分布式任务调度方法及系统。


背景技术：

2.在调度系统中，主要作用是定时，准确，高效触发任务启动，并且跟踪状态，直到结束，在大数据任务体系里，任务大致可以分为两类实时任务(流任务)，离线任务(批任务)。大数据主流引擎如spark和flink都提供了流任务和批任务的能力。离线任务：也称为批任务，一般在有限的时间内完成，对资源持有时间有限，通常不会超过小时级。实时任务：也称为流任务，任务会长时间运行，甚至一直运行，对资源也会一直持有。
3.不管是流任务和还是批任务，本质是处理数据，调度系统很重要的一个功能是有序的管理数据处理任务，比如常见的etl(extract-transform-load)任务，一定是先完成抽取数据，再进行业务处理，最后导出数据。而在现有的开源和公开的调度系统中，一般会将离线调度系统和实时任务管理系统分开管理，这个是由两种任务形态所决定的。
4.在现有开源的主流离线调度系统架构中，比如dolphinscheduler，xxl-job，quartz等任务，任务执行流程大致流程如图1，任务孵化提交实例后，交给线程池处理，线程池里的线程获取任务，初始化任务，运行任务，并提交任务给yarn，之后跟踪任务状态，直到正常结束或异常结束。线程监控了整个任务的状态。
5.对于实时任务而言，如果任务长期运行在调度系统中，该任务持有的线程将长期无法释放，任务越多，占用越多，最后消耗殆尽，导致后续任务无法执行，最后可能导致集群故障。目前现有开源的架构和公开的调度架构体系里，没有将离线和实时统一管理的架构。


技术实现要素：

6.实际上，在处理数据方面，流任务和批任务没有本质的区别，有鉴于此，本发明提出了一种分布式的流批一体的调度系统，和一种基于时间规则的方式，将流任务和批任务建立完整的依赖关系方式，实现了一种任务统一管理，资源的统一分配，权限的统一管控的流任务和批任务调度系统。
7.本发明第一方面公开的一种流任务和批任务一体化的分布式任务调度方法，包括以下步骤：
8.系统启动时master节点和worker向zookeeper进行注册，master节点之间通过zookeeper选出主master；
9.主和备master孵化任务，分发任务，用户创建dag后，master节点将dag孵化出具体dag实例和任务实例，然后根据任务依赖关系，依次将任务实例分发给worker节点；
10.worker节点收到消息后，将任务进行分类，通过本地任务线程池和远端任务线程池进行管理；
11.当远端任务提交后，将远端任务转移到任务状态监测队列，从而释放任务提交线
程，提升任务提交的并行度；
12.在状态检查流程中，采用定时扫描机制，共用少量线程完成大量任务的检查。
13.进一步的，在任务中启动一个线程，定时向worker汇报一次状态，从而将长时间的任务状态监控过程由一个线程和基于该线程的定时扫描，转化为队列里的一条记录和周期性消息。
14.进一步的，所述任务包括yarn的spark任务或flink任务，或mapreduce任务。
15.进一步的，yarn集群故障情况下，worker节点如果多个周期未收到任务状态消息，进行一次扫描，判断任务的状态。
16.进一步的，将流任务和批任务进行统一管理后，批任务持续探测检查流任务的数据处理时间，达到特定条件时触发批任务的调度。
17.进一步的，当流任务基于时间分区处理数据时，所述特定条件包括：下一个分区已经生成且当前分区多个周期内，数据未发生变化。
18.进一步的，当流任务不是基于时间分区处理数据时，在定制的算子里，周期性将当前处理的数据时间位置写入数据库，批任务的时间探测算子通过这个数据时间来判断flink的业务处理时间，触发批任务的运行。
19.进一步的，所述数据时间包括流的事件时间(eventtime)或者处理时间(processtime)时间。
20.本发明第二方面公开的一种流任务和批任务一体化的分布式任务调度系统，包括：
21.注册模块：系统启动时master节点和worker向zookeeper进行注册，master节点之间通过zookeeper选出主master；
22.分发模块：主和备master孵化任务，分发任务，用户创建dag后，master节点将dag孵化出具体dag实例和任务实例，然后根据任务依赖关系，依次将任务实例分发给worker节点；
23.分类模块：worker节点收到消息后，将任务进行分类，通过本地任务线程池和远端任务线程池进行管理；
24.线程释放模块：当远端任务提交后，将远端任务转移到任务状态监测队列，从而释放任务提交线程，提升任务提交的并行度；
25.状态检查模块：在状态检查流程中，采用主动汇报模式和防故障定时机制，共用少量线程完成大量任务的检查。
26.本发明的有益效果如下：
27.提供一套分布式调度架构，在现有的调度流程和分布式架构上，将远端任务转移到任务状态监测队列，从而释放任务提交线程，提升任务提交的并行度，保障调度的稳定运行。
28.提供一种支持流任务和批任务一体化的处理方式，同时，通过优化，对于离线任务本身也做了极大性能提升。
29.在保证流任务和批任务一体化基础上，提供一种将实时任务和离线任务建立依赖的方式，让实时任务和离线任务真正融合一体。
附图说明
30.图1现有的任务的执行方式示意图；
31.图2现有的调度任务专有名称图；
32.图3现有的数据引擎的分布式架构图；
33.图4现有的任务调度流程图；
34.图5本发明的流批一体的轮询查询状态机制；
35.图6本发明的流批一体的主动汇报状态机制；
36.图7本发明的流批建立依赖的方式。
具体实施方式
37.下面结合附图对本发明作进一步的说明，但不以任何方式对本发明加以限制，基于本发明教导所作的任何变换或替换，均属于本发明的保护范围。
38.本发明首先介绍现有的大数据分布式调度架构，参考图2，
39.算子：指某一相同功能的抽象化，比如http算子，主要完成http的调用功能。
40.任务：是将算子配上特点的业务，比如通过http算子配上特定的url获取页面的结果。
41.任务依赖：任务之间有先后的执行关系，比如图2中任务2依赖任务1，任务1完成后，才能开始运行任务2。
42.dag：将一个或者多个任务组成的整体。如图2左边，任务1，任务2，任务3组成gag1。
43.调度周期：任务按照某种规则周期性运行，比如dag1每天凌晨1点运行一次。一般通过cron表达式提供。
44.dag依赖：将两个不同的dag建立一种依赖关系，比如图2中dag2依赖dag1。
45.dag实例：dag每次调度产生的实例叫做dag实例，dag1每调度一次，生成一个带有时间刻度的实例。
46.任务实例：dag实例生成是会将dag里的所有任务生成一个task实例。实例带来时间特性。
47.该系统采用zookeeper作为分布式协调点，启动时master和worker会往zookeeper注册信息，注册成功后，master通过zookeeper选出主master，实现原理是：所有master节点往zookeeper的主master节点写一条记录，写成功的为主master，写失败的为备master。备master会监听主master状态，当主master故障后，所有节点重新竞争为主master。主master监控所有master和worker，当有master和worker故障时，主master将收到消息，并进行故障恢复。正常时，是一主master、多备master、多worker的集群，具体如图3所示。
48.集群正常时，主master和备master的职责一样，用于孵化任务，然后分发任务，当主master节点出现故障时，主master会停止孵化，优先处理故障情况，master和worker之间通过netty通讯。
49.任务分发流程：任务调度和分发是在合适的时间，将任务分发给合适机器，并进行启动运行，然后监听任务状态过程，在这套的调度系统里，任务从创建到被真正执行结束，会经过用户创建、master孵化、分发、worker拉起、任务执行、任务运行状态跟踪、任务结束，异常重试等几个过程。
50.如图4，当用户创建dag后，master会根据用户的要求，准确将dag孵化出具体dag实例和任务实例，然后根据任务依赖关系，依次将任务实例分发给worker，分发成功后，master会将任务实例转交给缓存等待消息的回送。消息发送是采用netty通信，消息的会送(callback)采用kafka和超低频率的扫描数据库，扫描数据库是防止消息的丢失而产生僵死。
51.worker收到消息后会将任务进行分类，采用不同的线程池管理，python/shell/sql类等快速执行的local任务由本地任务线程池(local task thread pool)管理；flink/spark等yarn类大数据任务采用远端任务线程池(remote task thread pool)提交任务。local任务会在线程中监听全过程，因为运行时间短，任务量少，线程池资源足够用；而对于flink/spark等remote任务，在任务提交后，转为队列来管理状态，释放远端任务线程池里占用的线程。
52.参考图5，本发明在上面的系统架构中，当remote任务提交后，将任务转移到任务状态监测队列，从而释放任务提交线程，提升任务提交的并行度。另外状态检查流程中，采用定时机制，线程共用，少量线程完成大量任务的检查。这样，流任务并不会长期占用资源，从而达到流任务和批任务一体的架构。
53.在一些实施例中，本发明减少任务的对调度资源的消耗。在上述的方案中，不管流任务还是批任务还是会消耗资源去yarn上轮询扫描状态；在百万级任务情况下，并发能力依旧受影响，所以采用更进一步优化方案，业务方主动汇报状态方案，具体方案如下：参考图6，不管是基于yarn的spark任务还是flink任务，或者是mapreduce任务，都在任务本身里启动一个线程，定时汇报一次状态。正常情况下，worker通过收到的任务消息来判断当前任务状态；yarn集群故障情况下，worker如果多个周期未收到任务状态消息，可以进行一次扫描，从而判断task的状态。因为主动触发，相应的发送周期可以比定时扫描周期更长，次数更少。除yarn集群整体故障等特殊情况下，都能准确发送状态信息，主动汇报，准时性更高。从被动的轮询检查转化为主动的汇报状态，节约了资源的消耗。
54.一个长时间的任务状态监控过程由一个线程和基于该线程的定时扫描，转化为队列里的一条记录和周期性消息，因为主动触发，所以大大的减少了资源的消耗，从而使得流批一体成为了可能。
55.流批之间可以依赖：实现流批一体后，还需支持使用者在流任务和批任务之间便利的建立可靠的依赖关系。
56.实时任务会一直运行，导致状态一直无法变更，所以不能简单的通过任务状态来建立依赖。任务的本质是对数据的处理，实时任务是对连续数据流的处理，离线任务是对批数据的处理。离线任务之间容易建立依赖是因为每个任务的时间片段十分清晰，而实时任务的时间跨度从表面上看是不够清晰的。如果能够划分好实时任务的时间片段，就可以对实时任务创建依赖关系。
57.参考图7，本发明提供了两种实时任务时间片段的划分方式：
58.1、流任务基于时间分区处理数据。
59.基于时间分区写数据，设计并使用分区探测算子，定时检查流输出的分区数据是否完全处理结束，检查规则很多种，我们采用的规则是检查2部分，
60.(1)下一个分区已经生成；
61.(2)当前分区多个周期内，数据未发生变化。
62.2、流任务不是基于时间分区处理数据。
63.这类任务无法感知的数据变化，所以在要求在业务方和定制的算子里，周期性将当前处理的数据时间位置写入数据库，比如flink的eventtime或者processtime时间。设计并使用时间探测算子将通过这个时间来判断flink的业务处理时间，触发离线任务的运行。
64.综上：当流批任务统一管理后，离线任务可以不停探测检查流任务的数据处理时间，达到特定条件时触发离线任务的调度，从而实现流批任务的依赖建立。
65.本发明还提供一种流任务和批任务一体化的分布式任务调度系统，包括：
66.注册模块：系统启动时master节点和worker向zookeeper进行注册，master节点之间通过zookeeper选出主master；
67.分发模块：主和备master孵化任务，分发任务，用户创建dag后，master节点将dag孵化出具体dag实例和任务实例，然后根据任务依赖关系，依次将任务实例分发给worker节点；
68.分类模块：worker节点收到消息后，将任务进行分类，通过本地任务线程池和远端任务线程池进行管理；
69.线程释放模块：当远端任务提交后，将远端任务转移到任务状态监测队列，从而释放任务提交线程，提升任务提交的并行度；
70.状态检查模块：在状态检查流程中，采用主动汇报模式和防故障定时机制，共用少量线程完成大量任务的检查。
71.本发明的有益效果如下：
72.本发明提供了一套分布式的大数据调度的实现方式，该方式是流批一体的基础。通过不断优化任务状态检查机制，将常见的线程消耗和扫描机制转换成了内存的一条数据以及不断收到的消息，降低了资源的消耗，从而实现了对流任务与批任务的统一化有效管理。
73.通过分区/时间探测算子，将流任务和批任务完全融为一体，建立了流任务和批任务的依赖关系，提升了数据的质量，防止了执行数据未准备，而离线任务提前执行，依赖的建立，不在需要在流批之间建立时间间隔，大大的提升了任务编排的便利程度。
74.本文所使用的词语“优选的”意指用作实例、示例或例证。本文描述为“优选的”任意方面或设计不必被解释为比其他方面或设计更有利。相反，词语“优选的”的使用旨在以具体方式提出概念。如本技术中所使用的术语“或”旨在意指包含的“或”而非排除的“或”。即，除非另外指定或从上下文中清楚，“x使用a或b”意指自然包括排列的任意一个。即，如果x使用a；x使用b；或x使用a和b二者，则“x使用a或b”在前述任一示例中得到满足。
75.而且，尽管已经相对于一个或实现方式示出并描述了本公开，但是本领域技术人员基于对本说明书和附图的阅读和理解将会想到等价变型和修改。本公开包括所有这样的修改和变型，并且仅由所附权利要求的范围限制。特别地关于由上述组件(例如元件等)执行的各种功能，用于描述这样的组件的术语旨在对应于执行所述组件的指定功能(例如其在功能上是等价的)的任意组件(除非另外指示)，即使在结构上与执行本文所示的本公开的示范性实现方式中的功能的公开结构不等同。此外，尽管本公开的特定特征已经相对于若干实现方式中的仅一个被公开，但是这种特征可以与如可以对给定或特定应用而言是期
望和有利的其他实现方式的一个或其他特征组合。而且，就术语“包括”、“具有”、“含有”或其变形被用在具体实施方式或权利要求中而言，这样的术语旨在以与术语“包含”相似的方式包括。
76.本发明实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以多个或多个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。上述提到的存储介质可以是只读存储器，磁盘或光盘等。上述的各装置或系统，可以执行相应方法实施例中的存储方法。
77.综上所述，上述实施例为本发明的一种实施方式，但本发明的实施方式并不受所述实施例的限制，其他的任何背离本发明的精神实质与原理下所做的改变、修饰、代替、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。