[发明专利]一种分布式作业流任务管理和调度系统及方法

说明书

本文提供了一种分布式作业流任务管理和调度系统及方法，其中，系统包括：数据库节点、主调度节点及子调度节点；数据库节点用于存储作业配置信息，其中，作业配置信息包括子调度节点最大作业量、计算平台最大作业量、作业资源消耗量；主调度节点连接数据库节点及子调度节点，用于根据作业配置信息及待处理作业队列，生成作业分发信息并将其发送至子调度节点，其中，作业分发信息包括待处理作业、子调度节点及计算平台关联关系；子调度节点用于根据作业分发信息，将待处理作业提交至相应计算平台处理，其中，作业由计算平台的待处理作业逻辑封装得到。本文能够将调度与作业相分离，消除计算平台的技术特征差异，实现统一调度。

技术领域

本文涉及业务调度领域，尤其涉及一种分布式作业流任务管理和调度系统及方法。

背景技术

大数据时代，诸多开源或者商业大数据计算引擎系统，均存在海量的复杂数据分析或者计算任务，且作业链路依赖复杂。为解决或适配该类场景，当前开源和商业软件领域均有一定的解决方案涌现，各有优缺点。当前主流的几类开源和商业的批量作业调度系统主要有如下几类：

Azkaban，主要应用于开源大数据生态圈相关批量处理场景，经过特定封装也可以应用在商业计算引擎领域，功能较全面，调度支持能力良好，但在大规模作业配置和上线的流程上存在缺陷，单一作业的调整，需要重新调整全部作业依赖和触发图，变更灵活度不够。且针对同一时间就绪的作业海量作业，缺乏一定的优先级调度功能。

Airflow，为轻量级的开源调度工具，二次开发的成本较高，并发控制很难做到根据调度场景调整，小问题比较多，需要去定制化改造源代码。

Oozie，不支持准时间或微批调度场景，更多的是针对于hadoop的整合配置，扩展性较差，对传统商用计算平台的任务作业支持能力不足，针对跨计算引擎平台的作业任务调度能力支持不足，Web监控功能较弱。一般小规模个性化的集群任务调度可以采用，但大批量的任务调度不适用。

Control-M，商用重量级的作业流调度工具，功能强大，支持跨平台的海量任务调度能力，但商业授权费用昂贵，使用复杂，且无容器化部署方案案例。

现有开源或商业的作业流任务管理和调度系统能够解决特定场景下的作业流任务统一调度和分发执行，每种调度系统都只能在特定场景下提供任务调度支持，在综合性复杂场景下的任务调度，则显得不足，例如各类开源计算引擎(例如GreenPlum，Kylin，ClickHouse，Hadoop等)和商业计算引擎(例如Teradata，Oracle，IBM InfoSphereDataStage，IBM DB2等)共存，且彼此之间存在复杂的数据流交互的综合场景。如果针对每套计算引擎都部署一套独立的调度，则在日常数据需求开发交付时效上和数据对外服务时效上均存在一定的滞后。同时，如何对数据开发人员基础不同，开发能力强弱不均的痛点，并在短时间内有效的组织大规模作业流任务的上线部署和验证，均存在很大的挑战。

发明内容

本文用于解决现有技术中，在综合性复杂场景下的任务调度存在调度与作业融合，没有统一管理不同计算平台的统一调度方案，且对数据开发人员能力要求较高的问题。

为了解决上述问题，本文的第一方面提供一种分布式作业流任务管理和调度系统，包括：数据库节点、主调度节点及子调度节点；

所述数据库节点用于存储作业配置信息，其中，所述作业配置信息包括子调度节点最大作业量、计算平台最大作业量、作业资源消耗量；

所述主调度节点连接所述数据库节点及子调度节点，用于根据所述作业配置信息及待处理作业队列，生成作业分发信息并将其发送至所述子调度节点，其中，所述作业分发信息包括待处理作业、子调度节点及计算平台关联关系；

所述子调度节点用于根据作业分发信息，将待处理作业提交至相应计算平台处理，其中，所述待处理作业由计算平台的作业逻辑封装得到。