跨子系统的空间任务依赖调度方法与系统

技术领域

本发明涉及任务调度技术领域，具体地，涉及一种跨子系统的空间任务依赖调度方法与系统。

背景技术

华为云DGC数据开发模块支持以事件触发的方式运行作业，因此通过DIS或者MRSKafka作为作业依赖纽带，可以跨空间实现作业调度。如图1，工作空间1中的Job1运行完成后，可以使用DIS Client或Kafka Client发送一条消息触发Job2；Job2配置事件触发调度，根据DIS Client或Kafka Client发送的消息触发运行作业。与华为云解决方案对比，本发明的跨空间工作流依赖调度方案，在工作流的依赖事件消息发送和消费上对原有的工作流是无感的，不需要添加任何额外的步骤或工作流。拓扑和工作空间的工作流流触发是相对独立的，因此耦合性更低。

专利文献CN114510235A(申请号：CN202210114410.3)公开了一种用于科学计算程序的全生命周期管理系统和方法，系统包括构建环境子系统和生产环境子系统，前者为科学计算程序的生命周期过程中的构建过程提供计算机资源；后者为科学计算程序的全生命周期过程中的测试、部署过程提供计算机资源。

阿里云DataWorks支持同区域下的工作空间进行跨工作空间依赖，根据调度依赖原理，通过将上游节点的输出作为下游节点的输入，以此形成节点依赖，实现跨工作空间的调度依赖。例如，将工作空间A中节点A的输出添加为工作空间B中节点B的输入，即可实现跨工作空间依赖。配置方法与通用场景的调度依赖配置相同，详细操作可参见配置同周期调度依赖。与阿里云解决方案对比，本发明的跨空间工作流依赖调度方案，支持一模板多实例模式，对于实际业务场景抽象程度更高，用户使用更灵活，可以复用已有的拓扑模板，配合动态传参来解决，创建大量类似拓扑或任务的问题，并且拓扑触发实例之间是业务隔离的，支持高并发调度拓扑模板启动相应的多个拓扑实例。

发明内容

针对现有技术中的缺陷，本发明的目的是提供一种跨子系统的空间任务依赖调度方法和系统。

根据本发明提供的跨子系统的空间任务依赖调度方法，包括：

步骤1：基于TSS分布式工作流调度平台，在工作空间下的工作流上配置事件触发器，在触发器中配置相应的上游依赖工作流以及相应的工作流运行状态结果最终触发规则，将多个工作流的事件触发器归属到一个调度拓扑模板中；

步骤2：在拓扑调度触发后获取归属于它的所有触发器，并通过预设算法将单向的多个触发器上下游工作流依赖关系解析成一个完整的跨空间流依赖拓扑关系，并找到起点工作流进行调度；

步骤3：在调度服务逻辑中使用消息总线机制来实现跨工作空间流依赖拓扑关系的上下游工作流依赖通知，在调度服务中集成流依赖消息触发和消息消费机制，基于TSS工作流调度平台的节点背压容错机制实现流控；

步骤4：基于不同的生产环境业务体量与资源分配，建立分布式内存总线机制，对消息总线进行抽象使用SPI机制实现TSS平台与消息列队服务以及相应的消费逻辑解耦，实现插件化消息列队服务。

优选的，基于工作流事件消息触发机制，上游的任务完成后由调度服务根据逻辑判断并发送事件消息到消息列队，下游的消息消费机制消费消息列队中的事件消息，实现跨工作空间流依赖事件推送触发。

优选的，设置异步流依赖事件触发节点宕机异常处理逻辑，根据拓扑实例以及相应的各种消息实例记录，以及已经完成的工作流实例状态，计算并恢复内存总线宕机前的状态。

优选的，对于拓扑实例触发器遇到触发异常时，如果触发异常判定为非资源过载或不满足逻辑规则层面的异常，则触发器根据用户配置的多种可选异常策略自动进行相应的异常处理；如果是调度平台资源暂时负载过重导致异常，则通过消息总线通知异步触发器消息补偿机制进行轮询异步处理，确保在集群负载下降后拓扑实例恢复正常调度。

优选的，基于单向触发器的上下游工作流依赖关系，通过预设算法计算得出整个拓扑模板中的所有起始和结束工作流节点，依据触发器中的单向上下游工作流依赖关系量化为方向，得到一个完整的有向图，然后基于Tremaux搜索结合DFS回溯算法，进行拓扑关系环路检测判断，确保用户在配置工作流事件触发器后，算法自动检测当前的触发器加入拓扑模板后是否会引入工作流依赖触发环路，若检测到环路则自动将环路上的所有工作流以及相应的触发器按照依赖顺序进行反馈提示。

根据本发明提供的跨子系统的空间任务依赖调度系统，包括：

模块M1：基于TSS分布式工作流调度平台，在工作空间下的工作流上配置事件触发器，在触发器中配置相应的上游依赖工作流以及相应的工作流运行状态结果最终触发规则，将多个工作流的事件触发器归属到一个调度拓扑模板中；

模块M2：在拓扑调度触发后获取归属于它的所有触发器，并通过预设算法将单向的多个触发器上下游工作流依赖关系解析成一个完整的跨空间流依赖拓扑关系，并找到起点工作流进行调度；

模块M3：在调度服务逻辑中使用消息总线机制来实现跨工作空间流依赖拓扑关系的上下游工作流依赖通知，在调度服务中集成流依赖消息触发和消息消费机制，基于TSS工作流调度平台的节点背压容错机制实现流控；

模块M4：基于不同的生产环境业务体量与资源分配，建立分布式内存总线机制，对消息总线进行抽象使用SPI机制实现TSS平台与消息列队服务以及相应的消费逻辑解耦，实现插件化消息列队服务。

优选的，基于工作流事件消息触发机制，上游的任务完成后由调度服务根据逻辑判断并发送事件消息到消息列队，下游的消息消费机制消费消息列队中的事件消息，实现跨工作空间流依赖事件推送触发。

优选的，设置异步流依赖事件触发节点宕机异常处理逻辑，根据拓扑实例以及相应的各种消息实例记录，以及已经完成的工作流实例状态，计算并恢复内存总线宕机前的状态。

优选的，对于拓扑实例触发器遇到触发异常时，如果触发异常判定为非资源过载或不满足逻辑规则层面的异常，则触发器根据用户配置的多种可选异常策略自动进行相应的异常处理；如果是调度平台资源暂时负载过重导致异常，则通过消息总线通知异步触发器消息补偿机制进行轮询异步处理，确保在集群负载下降后拓扑实例恢复正常调度。

优选的，基于单向触发器的上下游工作流依赖关系，通过预设算法计算得出整个拓扑模板中的所有起始和结束工作流节点，依据触发器中的单向上下游工作流依赖关系量化为方向，得到一个完整的有向图，然后基于Tremaux搜索结合DFS回溯算法，进行拓扑关系环路检测判断，确保用户在配置工作流事件触发器后，算法自动检测当前的触发器加入拓扑模板后是否会引入工作流依赖触发环路，若检测到环路则自动将环路上的所有工作流以及相应的触发器按照依赖顺序进行反馈提示。

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

本发明使用内存消息总线配合消息列队实现工作流依赖事件实时通知，这样直接避免访问存储层，极大的提高了调度处理性能，而且最大程度体现了分布式算力在面对业务体量增长时的横向扩展机制，支持动态增加集群调度节点应对业务压力，从而完美解决算力瓶颈问题。

附图说明

通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1为本发明系统结构示意图；

图2为本发明方法流程图。

具体实施方式

下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变化和改进。这些都属于本发明的保护范围。

实施例：

如图2，本发明提出了一种跨子系统的空间任务依赖调度方法，包括：基于工作空间下工作流模板与多实例模式下跨工作空间工作流依赖触发解决方案；设置工作流粒度的事件触发器，实现拓扑与工作流的关系解耦；基于TSS工作流调度平台实现跨工作空间的工作流上下游依赖通知，实现将消息的定时拉取模式改为事件触发推送模式，解决任务的消费实时性，任务量增长对存储层的访问压力等问题；基于归属拓扑模板的所有触发器，集中解析这些触发器的上下游工作流依赖关系，并最终解析出一个完整的工作流依赖拓扑关系，并找到启动的工作流节点；设置分布式结构的内存消息总线服务，配合TSS工作流调度平台，实现内存级别的MQ服务节省物理资源；设置插件化跨工作空间流依赖消息总线机制，适配第三方的MQ服务，尽可能提升TSS工作流调度平台可用性和适配性。

研发工作流事件触发器，可提供用户根据自身业务配置工作流的上下游依赖以及触发逻辑规则，超时策略等。

研发拓扑管理，将事件触发器归属到拓扑模板中，通过自研算法，统一计算解析并最终梳理出一个完整的工作流依赖触发拓扑关系。

研发工作流事件消息触发机制，上游的任务完成后由调度服务根据逻辑判断并发送事件消息到MQ，下游的消息消费机制消费MQ中的事件消息，实现跨工作空间流依赖事件推送触发。

研发流依赖消息触发TSS工作流调度任务，基于自研的TSS工作流调度平台的资源组以及相应的资源管理机制，实现跨工作空间流依赖调度任务的实时资源控制。

研发异步流依赖事件触发节点宕机异常处理逻辑，根据拓扑实例以及相应的各种消息实例记录，以及已经完成的工作流实例状态，计算并恢复内存总线宕机前的状态

研发消息总线插件化，使用SPI以配合抽象封装事件消息的生产消费接口，将具体的实际逻辑下沉到具体子类实现中，实现跨工作流依赖触发方案与MQ解耦。

对于拓扑实例触发器遇到触发异常时，如果触发异常判定为非资源过载或不满足逻辑规则层面的异常，触发器根据用户配置的多种可选异常策略自动进行相应的异常处理；如果是以为调度平台资源暂时负载过重导致异常，那么会通过消息总线通知异步触发器消息补偿机制进行轮询异步处理，确保在集群负载下降后拓扑实例恢复正常调度。

首先基于自研单向触发器的上下游工作流依赖关系，通过算法准确的计算得出整个拓扑模板中的所有起始和结束工作流节点，在获得这些节点后可以依据所触发器中的单向上下游工作流依赖关系量化为方向，最终得到一个完整的有向图。在得到拓扑有向图后，基于Tremaux搜索结合DFS回溯算法思想，实现自研的拓扑关系环路检测判断算法，确保用户在配置工作流事件触发器后，算法自动检测当前的触发器加入拓扑模板后是否会引入工作流依赖触发环路，如果检测到环路会自动将环路上的所有工作流以及相应的触发器按照依赖顺序进行反馈提示。

目前业界存在的跨工作空间流依赖产品或解决方案对于这个跨工作空间流依赖调度作业都是全局任务或工作流唯一的，例如，某个依赖的任务触发的实例在整个拓扑调度未完成前只能触发一次，或者是在一段时间内检测该任务是否被触发。这样的设计其实是不准确的，并且面对业务需求跨工作空间流依赖高频触发场景下根本无法确保执行的工作流和跨工作空间流依赖调度作业之间的一对一映射关系，进而会导致数据错乱，调度异常等严重问题。此外，目前主流的跨工作空间流依赖产品或解决方案大都使用，定间隔轮询的方式去监控判断依赖的工作流状态是否有变化，这样技术设计如果轮询间隔缩短对存储层的IO浪费严重，延长轮询间隔对调度任务依赖触发存在延迟问题，且对底层的查询压力与调度任务量成线性增长关系，因此定间隔轮询的技术方案面对后期业务体量增加，系统的性能和稳定性都成为瓶颈。因此自研设计事件消总线通知机制，根据每个工作流实例的运行转态的改变产生相应的通知消息，使用内存消息总线配合MQ实现工作流依赖事件实时通知，这样直接避免访问存储层，极大的提高了调度处理性能，而且最大程度体现了分布式算力在面对业务体量增长时的横向扩展机制，支持动态增加集群调度节点应对业务压力，从而完美解决算力瓶颈问题。

本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统、装置及其各个模块以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统、装置及其各个模块以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同程序。所以，本发明提供的系统、装置及其各个模块可以被认为是一种硬件部件，而对其内包括的用于实现各种程序的模块也可以视为硬件部件内的结构；也可以将用于实现各种功能的模块视为既可以是实现方法的软件程序又可以是硬件部件内的结构。

以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。