CN113434302A - 分布式作业执行方法、主节点、系统、物理机及存储介质 - Google Patents

Abstract

本申请实施例提供一种分布式作业执行方法、主节点、系统、物理机及存储介质，其中方法包括：检测在线服务启动指令，拉起管理进程；通过管理进程，获取多任务管理进程的启动文件；以及，通过管理进程，基于多任务管理进程的启动文件，拉起多任务管理进程；获取用户提交的作业，通过管理进程进行作业的资源调度管理，以及通过多任务管理进程对作业相应的DAG进行管理。本申请实施例通过将主节点的资源调度管理和DAG的管理进行解耦，提升了分布式系统的稳定性、可扩展性等。进一步的，本申请实施例可对作业的DAG进一步切分子图，使得子图内的顶点以准实时模式执行，子图外的顶点以离线模式执行，以兼顾作业执行的低执行时延以及高资源利用率。本申请实施例能够显著提升分布式系统的性能。

Description

分布式作业执行方法、主节点、系统、物理机及存储介质

技术领域

本申请实施例涉及分布式技术领域，具体涉及一种分布式作业执行方法、主节点、系统、物理机及存储介质。

背景技术

分布式系统是多个物理机通过通信线路互联而构成的系统，具有分布性、自治性、并行性、全局性等特点。利用分布式系统执行用户提交的作业，可通过分布式系统的分布式计算能力，提升作业执行效率。

基于分布式系统的广泛应用，本领域技术人员一直致力于优化分布式作业在分布式系统的执行方式，以提升分布式系统的性能。

发明内容

有鉴于此，本申请实施例提供一种分布式作业执行方法、主节点、系统、物理机及存储介质，以优化分布式作业在分布式系统的执行方式，提升分布式系统的性能。

为实现上述目的，本申请实施例提供如下技术方案。

第一方面，本申请实施例提供一种分布式作业执行方法，所述方法应用于主节点，所述方法包括：

检测在线服务启动指令，拉起管理进程；

通过管理进程，获取多任务管理进程的启动文件；以及，通过管理进程，基于多任务管理进程的启动文件，拉起多任务管理进程；

获取用户提交的作业，通过管理进程进行作业的资源调度管理，以及通过多任务管理进程对作业相应的DAG进行管理。

第二方面，本申请实施例提供一种分布式作业执行方法，包括：

获取用户提交的作业；

生成作业的执行计划，所述执行计划由DAG描述；

配置DAG中顶点和连接边的物理属性，所述连接边的物理属性包括顺序边和并行边；

遍历DAG中的每个顶点，判断遍历的每个顶点是否满足预设的加入子图的目标条件；

根据每个顶点的判断结果，调整DAG中连接边的物理属性，直至DAG中的顶点遍历完成；

在DAG中的顶点遍历完成之后，基于调整物理属性的连接边，获得DAG的子图；所述子图由并行边连接的顶点形成；其中，子图中的顶点以准实时模式执行，子图外的顶点以离线模式执行。

第三方面，本申请实施例提供一种主节点，所述主节点被配置为执行如上述第一方面所述的分布式作业执行方法，或者如上述第二方面所述的分布式作业执行方法。

第四方面，本申请实施例提供一种分布式系统，包括：主节点以及多个工作节点；所述主节点如上述第三方面所述的主节点，所述分布式系统的在线服务具有一个或多个服务版本。

第五方面，本申请实施例提供一种物理机，包括：至少一个存储器以及至少一个处理器，所述存储器存储一条或多条计算机可执行指令，所述处理器调用所述一条或多条计算机可执行指令，以执行如上述第一方面所述的分布式作业执行方法，或者如上述第二方面所述的分布式作业执行方法。

第六方面，本申请实施例提供一种存储介质，所述存储介质存储一条或多条计算机可执行指令，所述一条或多条计算机可执行指令被执行时，实现如上述第一方面所述的分布式作业执行方法，或者如上述第二方面所述的分布式作业执行方法。

本申请实施例在分布式系统的在线服务启动时，主节点可拉起管理进程和多任务管理进程，从而针对用户提交的作业，管理进程可用于作业的资源调度管理，多任务管理进程可对作业相应的DAG进行管理。本申请实施例通过将主节点的资源调度管理和DAG的管理进行解耦，并分别由管理进程和多任务管理进程负责，提升了分布式系统的稳定性、可扩展性、以及可维护性等，能够有效提升分布式系统的性能。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1A为分布式系统的结构示意图。

图1B为执行计划的示意图。

图1C为DAG的示意图。

图1D为逻辑图与物理图的映射示意图。

图2A为分布式系统的另一结构示意图。

图2B为分布式作业执行方法的流程图。

图2C为不同服务版本下的MJM进程与Labor进程的关系示意图。

图2D为资源调度和DAG调度的解耦示意图。

图3A为离线模式下的DAG示意图。

图3B为准实时模式下的DAG示意图。

图3C为分布式作业执行方法的另一流程图。

图3D为准实时模式下工作节点的数据流转示意图。

图3E为初始状态下配置了物理属性的DAG示意图。

图3F为DAG切分子图后的示意图。

图4A为分布式作业执行方法的再一流程图。

图4B、图4C、图4D和图4E分别为当前顶点与当前子图存在循环依赖关系的示例图。

图5为子图的资源申请示例图。

图6为物理机的框图。

具体实施方式

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

分布式作业可以理解为将作业提交给分布式系统进行执行。图1A示例性的示出了分布式系统的结构示意图。如图1A所示，分布式系统可以包括：主节点110和多个工作节点120。主节点110和工作节点120可以视为是分布式系统中的计算节点，计算节点可承载于具有数据计算能力的物理机，一个物理机可以承载一个或多个计算节点。

在分布式系统中，主节点110为用于管理、控制的计算节点。例如，主节点110可以管理工作节点120、协调作业在执行计划的各执行阶段相应的并发度和资源等。在一些方面，主节点110作为分布式系统中的中心管控节点，也称为分布式系统的执行引擎。工作节点120为分布式系统中具体执行作业的计算节点，可受主节点110的管理和协调来执行作业。

在分布式系统执行作业时，作业可由用户通过终端提交给集群资源管理器，集群资源管理器拉起主节点110。从而主节点110可解析作业，生成执行计划。执行计划描述的是作业的数据从最开始的源表，在经历一系列的数据流动、执行、以及变化后，最终产生输出的过程。图1B示例性的示出了执行计划的示意图。如图1B所示，执行计划可以包括：多个具有层级关系的stage（执行阶段）。在一些实施例中，stage之间可以是树状的层级结构。一个stage可以包括一个或多个task（执行任务）。针对每个stage，主节点110可以通过配置工作节点数量（并发度）、所使用的资源等来实现调度多个工作节点并行执行stage的task，从而实现作业在分布式系统中的执行。

在一些实施例中，作业一般是由终端以请求的方式提交给分布式系统。在一个示例中，终端提交的作业包括查询数据库的查询语句，例如SQL（Structured QueryLanguage，结构化查询语言）语句。

在进一步的一些实施例中，执行计划可以通过DAG（Directed Acyclic Graph，有向无环图）进行描述。DAG包括多个顶点（vertex）以及顶点之间的连接边（edge）。图1C示例性的示出了DAG的示意图。需要说明的是，DAG实际的顶点数量、层级、连接边可能相比于图1C更为复杂，图1C仅是出于便于理解目的而示出的简易DAG示例。如图1C所示，DAG可以包括4个顶点V1至V4，以及连接边11、12、13和14。其中，连接边11连接顶点V1和V2、连接边12连接顶点V1和V3、连接边13连接顶点V2和V4、连接边14连接顶点V3和V4。

DAG中的一个顶点可以表示执行计划中一个独立的stage。顶点之间的连接边可以是有向连接边，表示顶点之间的关系。基于连接边指向的关系，顶点连接的连接边可能是顶点的输入连接边（输入连接边指向顶点），也可能是顶点的输出连接边（输出连接边由顶点指向其他顶点）。例如图1C中，连接边12指向V3，为V3的输入连接边；连接边14由V3输出，为V3的输出连接边；而连接边12是由V1输出，因此连接边12又作为V1的输出连接边；连接边14输入V4，因此连接边14又作为V4的输入连接边。

连接边连接的两个顶点中，连接边输出的顶点称为另一顶点的直接上游顶点，连接边输入的顶点称为另一顶点的直接下游顶点。例如图1C中，连接边12连接V1和V3中，V1输出连接边12且连接边12输入V3，则V1可称为V3的直接上游顶点，V3可称为V1的直接下游顶点。一个顶点可能具有一个或多个直接上游顶点、一个或多个直接下游顶点。需要说明的是，一个顶点除具有直接上游顶点之外，可能还具有间接上游顶点，间接上游顶点与该顶点并不直接连接，而是处于该顶点的上层并且与该顶点之间通过一个或多个顶点相连接。例如图1C中，V1处于V4的上层，V1通过V2或V3与V4连接，因此V1可称为V4的间接上游顶点。显然，一个顶点除具有直接下游顶点之外，可能还具有间接下游顶点，间接下游顶点与该顶点并不直接连接，而是处于该顶点的下层并且与该顶点之间通过一个或多个顶点相连接。例如图1C中，V4处于V1的下层，且通过V2或V3与V1连接，因此V4可称为V1的间接下游顶点。顶点的上游顶点可以包括直接上游顶点和间接下游顶点，顶点的下游顶点可以包括直接下游顶点和间接下游顶点。

顶点的执行可能依赖于直接上游顶点，即顶点与直接上游顶点存在执行依赖关系，顶点需要在直接上游顶点执行后才能执行；顶点的执行也可能不依赖于直接上游顶点，而是可与直接上游顶点并行执行。

在进一步的一些实施例中，DAG可以具有两个层面的表述：逻辑图与物理图。逻辑图可以认为是执行计划的一个自然延伸，描述的是用户针对作业想要实现的数据执行流程。物理图则体现了执行计划的各stage映射到分布式系统的物理属性，描述的是执行计划的各stage在执行层面的并发度、资源、数据传输方式等物理属性。

图1D示例性的示出了逻辑图与物理图的映射示意图。为便于示例，图1D仅以执行计划具有4个stage进行示意。如图1D所示，逻辑图描述了执行计划的4个顶点（顶点V0、V1、V2和V3）以及各个顶点的关系（例如，顶点V0指向顶点V2，顶点V1和顶点V2指向顶点V3），一个顶点对应执行计划的一个stage。逻辑图可以体现执行计划的数据执行流程。在将逻辑图映射为物理图之后，物理图可以描述各个stage需要配置的工作节点数量、资源（例如CPU资源、内存资源等）、数据传输方式等物理属性。例如，结合图1D示例，物理图描述了顶点V0需要配置3个工作节点（并发度为3），顶点V1、V2和V3分别需要配置2个工作节点（并发度为2）。也就是说，物理图能够表达DAG中顶点和连接边的物理属性。通过物理图描述的顶点和连接边的物理属性，主节点可以为各个stage调度工作节点和资源，以使得stage中的task可以被多个工作节点并行执行，实现作业在分布式系统中的执行。

针对作业的不同特点，分布式系统提供不同的作业执行模式：离线模式和准实时模式。

离线模式是指在作业执行过程中，主节点按照stage的资源需求，按需申请资源；然后基于申请的资源拉起进程来执行stage中的task。进程可以视为执行stage使用的工作节点。在离线模式下，每个stage独立执行，按需申请资源，采用数据落盘模式进行中间的数据shuffle（shuffle描述不同stage之间进行数据交互的过程，例如数据从map task输出到reduce task输入的过程）。在离线模式下，1个主节点管理1个作业，面向的是吞吐量和资源利用优先的海量数据规模的作业。

准实时模式是指分布式系统中预先拉起包含多个常驻进程的服务。常驻进程中的工作节点构建起预拉起资源池（也称为准实时资源池），这些常驻进程在作业提交时均处于被拉起的状态；从而在作业执行过程中，主节点直接调度常驻进程来执行stage，以减少执行每个stage时需要再拉起进程所带来的消耗。在准实时模式下，可以采用gangscheduling（成组调度）的方式申请并使用预拉起资源，并对多个stage采用一体化执行方式和基于内存或网络的数据Shuffle。在准实时模式下，1个主节点可以管理多个作业，面向的是执行时延优先的中小数据规模的作业。

对于分布式系统而言，分布式系统每天运行着上千万的分布式作业，而绝大部分作业都是通过准实时模式执行。在这样的作业体量上，对于分布式系统的稳定性、可扩展性，以及可维护性等方面，都出了很高的要求。另外，随着分布式系统的服务版本的更新迭代，分布式版本每年都会有若干次大版本发布和几十次小版本的发布需求，当需要在线上发布一个新的服务版本时，必须有一种机制可以在不影响已发布版本的情况下，对新服务版本进行灰度发布，从而支持将用户作业分批的切换到新的服务版本；因此，分布式系统需要支持多服务版本的能力。

在本申请实施例中，主节点110和工作节点120可以形成分布式系统的Master（主）、Slave（从）架构。主节点110作为Master角色主要用于服务管理，工作节点120作为Slave角色主要用于作业的计算负载，实现作业的具体执行。在一些实施例中，工作节点可以是常驻工作节点，运行在预拉资源池中，并在准实时模式下被主节点110直接调度。

图2A示例性的示出了本申请实施例提供的分布式系统的另一结构示意图。结合图1A和图2A所示，图2A所示分布式系统中，主节点110可以包括：Admin（管理）进程111和多个MJM（MultiJobManger，多任务管理）进程112。工作节点120可以包括：Agent（代理）进程121和多个Labor（工作）进程122。

在本申请实施例中，主节点中的Admin进程可用于作业的资源调度管理，例如管理资源池的资源调度。在一些实施例中，Admin进程可管理预拉资源池的资源调度，预拉资源池运行常驻工作节点，主要用于作业的准实时模式。在另一些实施例中，Admin进程也可以作为AM（Application Master，作业管理器）进程的内部组件，管理离线资源池的资源调度。离线资源池中的资源需要当场申请，而不是在作业提交时预先拉起，离线资源池主要用于作业的离线模式。

主节点中的MJM进程可用于对DAG进行管理，例如对DAG进行生命周期管理，涉及：DAG的调度管理、状态收集、容错处理等。在一些实施例中，一个MJM进程可以同时管理多个作业。需要说明的是，主节点实际需要设置的MJM进程实例数目，可随着主节点需要同时管理的作业数目，以及作业的复杂度等做动态调整（例如水平横向扩展）。

工作节点中的Agent进程和Labor进程可以用于执行作业计算逻辑，并将执行结果上报给主节点。

作为一种可选实现，图2B示出了本申请实施例提供的分布式作业执行方法的流程图。该方法流程图可由主节点执行实现。参照图2B，该方法流程可以包括如下步骤。

在步骤S210中，检测在线服务启动指令，拉起Admin进程。

当分布式系统启动在线服务时，主节点可检测到在线服务启动指令，从而拉起Admin进程。可以理解的是，分布式系统启动在线服务，则用户可通过分布式系统提交作业，以便利用在线服务实现作业在分布式系统的执行。

在步骤S211中，通过Admin进程，获取MJM进程的启动文件。

在步骤S212中，通过Admin进程拉起MJM进程。

Admin进程启动之后，Admin进程可获取MJM进程的启动文件，并基于MJM进程的启动文件，拉起MJM进程。例如，Admin进程可通过主节点中的NodeManager（节点管理）进程拉起MJM进程。

在进一步的一些实施例中，针对准实时模式，由于工作节点需要预先被拉起，因此主节点还可在执行步骤S211和步骤S212的过程中，通过Admin进程拉起工作节点的Agent进程（此处的工作节点可以是预拉起资源池中的常驻工作节点）。工作节点的Agent进程被拉起之后，Agent进程可用于拉起工作节点中的Labor进程；例如，Agent进程可基于Admin进程的通知，获取Labor进程的启动文件，从而Agent进程可基于Labor进程的启动文件，拉起Labor进程。

在步骤S213中，获取用户提交的作业，通过Admin进程进行作业的资源调度管理，以及通过MJM进程对作业相应的DAG进行管理。

当分布式系统的在线服务启动之后，用户可通过终端提交作业。作业可由终端提交到分布式系统并由主节点获取作业。在主节点中，主节点可通过Admin进程进行作业的资源调度管理，例如，由Admin进程确定执行作业使用的工作节点，并与该工作节点的Agent进程进行通信，从而确定Agent进程管理的用于执行作业的Labor进程。主节点中的MJM进程可对作业相应的DAG进行管理，例如进行DAG的资源调度管理等。

在一些实施例中，主节点中的Admin进程获取用户提交的作业后，Admin进程可将作业转交给MJM进程。MJM进程可生成作业的执行计划，并由DAG描述执行计划。从而，MJM进程可配置DAG的物理属性（即映射DAG的物理图）；进而，在工作节点中的Labor进程被拉起后，MJM进程可与工作节点中的Labor进程进行通信，以使得Labor进程基于MJM进程配置的DAG的物理属性，执行作业。

本申请实施例在分布式系统的在线服务启动时，主节点可拉起Admin进程和MJM进程，从而针对用户提交的作业，Admin进程可用于作业的资源调度管理，MJM进程可对作业相应的DAG进行管理。本申请实施例通过将主节点的资源调度管理和DAG的管理进行解耦，并分别由Admin进程和MJM进程负责，提升了分布式系统的稳定性、可扩展性、以及可维护性等，显著提升了分布式系统的性能。

在一些实施例中，分布式系统可以提供在线服务，以支持作业的在线执行。分布式系统的在线服务可能具有多个服务版本（例如在线服务的老服务版本以及新服务版本等）。本申请实施例可在主节点中配置各个服务版本相应的MJM进程，以及在各个工作节点中配置各个服务版本相应的Labor进程。一个服务版本在主节点中可配置有相应的一个或多个MJM进程，并且一个服务版本可在一个工作节点中配置有相应的一个或多个Labor进程。在一些实施例中，相同服务版本相应的MJM进程和Labor进程进行通信，以执行相同服务版本的作业，并且不同服务版本相应的MJM进程和Labor进程相互隔离。例如，一个服务版本相应的MJM进程只会与相同服务版本相应的Labor进程进行通信，并执行相同服务版本的作业，而不同服务版本相应的MJM进程和Labor进程相互隔离、互不影响。从而，针对在线服务的一个服务版本而言，该服务版本相应的MJM进程可作为该服务版本的作业的管理角色（一个服务版本相应的MJM进程可管理该服务版本的多个作业），该服务版本相应的Labor进程可作为该服务版本的作业的执行角色。

作为一种示例，图2C示出了不同服务版本下的MJM进程与Labor进程的关系示意图。如图2C所示，主节点110可以设置MJM进程0至n，用于分别管理服务版本0至n的作业，例如MJM进程0管理服务版本0的作业、MJM进程1管理服务版本1的作业，以此类推。每个工作节点120可以设置Labor进程0至n，用于分别执行服务版本0至n的作业，例如一个工作节点中的Labor进程0执行服务版本0的作业、Labor进程1执行服务版本1的作业，以此类推。服务版本0相应的MJM进程0与服务版本0相应的Labor进程0进行通信，服务版本1相应的MJM进程1与服务版本1相应的Labor进程1进行通信，以此类推，从而MJM进程和Labor进程在不同服务版本之间相互隔离、互不影响。

需要说明的是，图 2C仅以一个服务版本在主节点中对应一个MJM进程，在一个工作节点中对应Labor进程进行示例，本申请实施例也可支持一个服务版本在主节点中对应多个MJM进程的情况。

在一些实施例中，MJM进程管理DAG的生命周期，例如通过DAG来描述执行计划的调度，执行流程等。一个MJM进程可以管理多个DAG的并发执行，具备水平扩展的能力。在一些实施例中，在在线服务的多个服务版本下，每个服务版本相应的MJM进程可以根据对应服务版本的流量来进行自适应的增减，以实现MJM进程的动态负载均衡，保障多个服务版本下每个服务版本的高效处理。例如，主节点在检测到某服务版本的流量低于预设的流量阈值时，可降低该服务版本相应的MJM进程的数量。

本申请实施例提供的分布式系统，通过在主节点中设置Admin进程和MJM进程，从而将在线服务的资源调度管理和DAG调度管理，分解为由Admin进程和MJM进程分别管理，实现了资源调度和DAG调度的充分解耦。作为一种示例，图2D示出了资源调度和DAG调度的解耦示意图。如图2D所示，Admin进程管理资源（例如预拉资源池），并且作为API Server（接口服务端）接受外部的作业请求；同时，Admin进程可管理MJM进程，根据作业对应的服务版本以及该服务版本下各MJM进程的负载均衡，将提交的作业重定向给该服务版本相应的具体MJM进程，以实现服务版本控制以及MJM进程的负载均衡。MJM进程接收到作业之后，会针对每一个作业创建一个DAG，并根据DAG的特性来管理整个DAG的生命周期，并和相同服务版本的Labor进程通信，从而完成作业的执行。图2D中，MJM进程0可以认为是服务版本0相应的MJM进程，MJM进程1是服务版本1相应的MJM进程，DAG0为服务版本0的作业相应的DAG，DAG1为服务版本1的作业相应的DAG。

需要说明的是，分布式系统日均会有大量的准实时模式的作业，需要运行在预拉起的常驻工作节点上，因此要管理准实时模式大量的作业，对于分布式系统的稳定性以及可扩展性都提出了严峻的挑战。本申请实施例在Admin进程管理预拉起资源池，以及不同服务版本的MJM进程分别针对不同服务版本的作业实现DAG调度的情况下，能够提高准实时模式下大量作业的执行稳定性。并且通过动态调整（删除、增加）主节点中不同服务版本的MJM进程，提升了分布式系统对于服务版本的可扩展性。

作为一种可选实现，当分布式系统的在线服务启动时，主节点会拉起Admin进程。然后，主节点通过Admin进程向资源池申请资源，并通过NodeManger（节点管理）拉起工作节点中的Agent进程。之后，主节点可通过Admin进程，基于用户配置确定在线服务的服务版本列表（服务版本列表可记录在线服务的多个服务版本）；从而，Admin进程可基于服务版本列表中记录的在线服务的各服务版本，获取各服务版本相应的MJM进程的启动文件；进而，主节点可通过Admin进程，基于各服务版本相应的MJM进程的启动文件，拉起各服务版本相应的MJM进程。在Admin进程拉起MJM进程的过程中，Admin进程可将服务版本列表传输给工作节点的Agent进程，从而Agent进程可获取各服务版本相应的Labor进程的启动文件；进而，工作节点可通过Agent进程，基于各服务版本相应的Labor进程的启动文件，拉起各服务版本相应的Labor进程。

MJM进程启动后，MJM进程可向Admin进程汇报进程状态；同理，Labor进程启动后，Labor进程会向Agent进程汇报进程状态。Agent进程会将其管理的多个服务版本相应的Labor进程的进程信息进行汇总，并汇报给Admin进程。在分布式系统中，一个工作节点中的Agent进程与其管理的Labor进程可以共享一个资源组，且一个工作节点中的Labor进程所占用的CPU与内存等资源，不能超过共享的资源组的上限。在进一步的一些实施例中，为了避免多个Labor进程同时执行用户作业，导致占用过多资源，本申请实施例可规定在同一时刻，一个Agent进程下只有一个Labor进程执行作业。

在进一步的一些实施例中，用户可以通过RPC（Remote Procedure Call，远程过程调用）请求，动态的增加、删除服务版本。在一些实施例中，若用户请求增加的服务版本为第一服务版本，则主节点可获取到第一服务版本的新增请求，Admin进程会将第一服务版本的新增信息发送给Agent进程；同时，Admin进程获取启动第一服务版本的MJM进程的启动文件，基于第一服务版本的MJM进程的启动文件，在主节点中增加拉起第一服务版本的MJM进程。而工作节点中的Agent进程获取到第一服务版本的新增信息之后，可获取第一服务版本的Labor进程的启动文件；进而，Agent进程可基于第一服务版本的Labor进程的启动文件，在工作节点中增加拉起第一服务版本的Labor进程。

在一些实施例中，当用户请求删除服务版本时，若用户请求删除的服务版本为第二服务版本，则主节点可获取到第二服务版本的删除请求，从而Admin进程可将第二服务版本的删除信息发送给Agent进程；同时，Admin进程可通知NodeManager（节点管理），停止执行第二服务版本相应的MJM进程；并且，Agent进程也会通知NodeManager，停止执行第二服务版本相应的Labor进程。

在进一步的一些实施例中，考虑到分布式系统如果挂载了大量的服务版本，但又存在某一服务版本下没有作业提交，则会出现大量Labor进程空转的情况，造成分布式系统的资源浪费。基于此，若主节点检测到第三服务版本在指定的时间间隔内没有作业提交，Admin进程会向Agent进程发送通知，从而Agent进程可基于通知，停止执行第三服务版本相应的Labor进程。在第三服务版本相应的Labor进程停止执行之后，若主节点后续获取到第三服务版本的作业请求，则Admin进程可向Agent进程发送通知，从而Agent进程可基于通知，重新拉起第三服务版本相应的Labor进程。通过这种方式，本申请实施例可在某一服务版本长时间没有作业提交时，有效的节省资源，同时也不影响该服务版本下再次提交的作业的执行。

在一些实施例中，在准实时模式下，用户作业会被提交到主节点的Admin进程。用户可以在作业中指示希望使用的服务版本，若作业指示希望使用的服务版本为第四服务版本，则主节点中可通过Admin进程，将作业转交给第四服务版本对应的MJM进程。该MJM进程会向Admin进程请求执行作业的资源；从而主节点可响应该MJM进程的资源请求，通过Admin进程挑选空闲的目标Agent进程（空闲的Agent进程下的所有Labor进程处于空闲状态），将目标Agent进程下第四服务版本的Labor进程信息返回给该MJM进程。进而，第四服务版本相应的MJM进程和Labor进程可进行通信，以实现第四服务版本下的作业执行。

当目标Agent进程将第四服务版本的Labor进程信息返回给MJM进程之后，目标Agent进程停止调度与第四服务版本不同的作业，直至第四服务版本的作业执行结束。在一些实施例中，第四服务版本相应的Labor进程在执行作业时，可将作业执行信息上报给第四服务版本相应的MJM进程，从而第四服务版本相应的MJM进程可从第四服务版本相应的Labor进程，获取作业执行信息，以对作业状态进行收集。当第四服务版本的作业执行结束时，目标Agent进程下的Labor进程会通知目标Agent进程，并由目标Agent进程将通知发送给Admin进程；从而Admin进程可从目标Agent进程获取到通知，基于该通知，主节点可通过Admin进程将目标Agent进程重新标记为空闲状态。

本申请实施例通过在主节点配置各个服务版本相应的MJM进程，以及在工作节点配置各个服务版本相应的Labor进程，且一个服务版本相应的MJM进程与相同服务版本相应的Labor进程进行通信，并且MJM进程和Labor进程在不同服务版本之间相互隔离、互不影响，实现了分布式系统对于多个服务版本的支持能力。并且在服务版本的增加、删除等方面，本申请实施例可提供相应的MJM进程和Labor进程调整机制，能够有效支持分布式系统对于多个服务版本的水平扩展能力，实现了动态的负载均衡能力，保证了分布式系统对于资源和DAG的高效调度能力。进一步的，通过服务版本的Flighting（在新服务版本发布后，由发布团队通过提交作业完成的功能测试，对用户作业无影响）灰度机制，能够完成对于不同服务版本的测试、上线、下线等操作，并且确保所有操作对于用户的透明无感知。进一步的，对于多个服务版本，本申请实施例可在保证服务版本的功能完备的前提下，通过对空转的服务版本停止Labor进程以及后续存在作业请求时恢复Labor进程，确保分布式系统的资源能够被有效利用。本申请实施例能够显著提升分布式系统的性能。

基于分布式系统提供的离线模式和在线模式，离线模式采用的是按需申请资源的方式来执行作业，能够保证较高的资源使用率但无法取得较低的执行时延。准实时模式采用常驻进程预先拉起的方式来执行作业，能够保证作业较低的执行时延但同时会使用较高的资源。也就是说，离线模式是以追求高吞吐量（Throughput）为目标，准实时模式是以追求低时延（Latency）为目标，因此离线模式和准实时模式在各方面的性能指标会存在较大的区别。如果单纯采用离线模式执行作业，那么虽然能够得到高效的资源利用率，但是无法足够降低作业的执行时延；如果单纯采用准实时模式执行作业，虽然能够有效降低作业的执行时延，但是将带来较高的资源消耗。

基于此，为在离线模式的高效资源利用率和准实时模式的低执行时延之间寻求有效平衡，本申请实施例提供一种混合执行模式来执行作业，混合执行模式能够通过相比于单纯的离线模式和准实时模式更细粒度、更通用的方式来执行作业，从而达到高效资源利用率和低执行时延的有效平衡。

为便于理解，本申请实施例引入子图（bubble）的概念，针对bubble内的顶点，主节点基于准实时模式直接调度常驻进程来执行stage（具体是执行stage中的task）。而针对bubble之外的顶点，主节点按照stage的资源需求申请资源，即bubble之外的顶点以离线模式执行。在数据传输方式的体现上，bubble内的顶点一起申请运行资源，并且bubble内的顶点对应的上下游工作节点的数据通过网络、内存直连传输；而bubble之外连接边上的数据则通过数据落盘方式进行传输。

基于此，离线模式和准实时模式可以认为是bubble执行的两个极端场景：离线模式下，DAG中的每个顶点均单独作为单一的bubble；准实时模式下，DAG的所有顶点作为一个大的bubble。图3A示例性的示出了离线模式下的DAG示意图。图3A中一个虚线框表示一个bubble，可以看出，在离线模式下，DAG中的各个顶点均视为一个单一的bubble。图3B示例性的示出了准实时模式下的DAG示意图。由图3B可以看出，在准实时模式下，DAG中的所有顶点视为一个大的bubble。

本申请实施例提供的混合执行模式建立在对DAG进一步切分bubble的基础上。本申请实施例通过对DAG灵活自适应的进行子图切分，能够在离线模式和准实时模式这两个极端之间，提供一种更细粒度，更通用、更合理的作业执行模式（即混合执行模式），达到作业执行的高资源利用率和低执行时延的有效平衡。

图3C示出了本申请实施例提供的分布式作业执行方法的另一流程图。该方法流程可由主节点执行实现。在一些实施例中，可由主节点中的MJM进程执行该方法流程。在其他可能的实现中，也可由主节点中的Admin进程执行该方法流程。参照图3C所示，该方法流程可以包括如下步骤。

在步骤S310中，生成作业的执行计划，所述执行计划由DAG描述。

终端向分布式系统提交作业之后，分布式系统中的主节点可解析作业，生成作业的执行计划，该执行计划由DAG描述。其中，DAG可以包括多个顶点以及顶点之间的连接边。

在步骤S311中，配置DAG中顶点和连接边的物理属性，所述连接边的物理属性包括sequential edge（顺序边）和concurrent edge（并行边）。

主节点在生成执行计划之后，可以配置DAG中顶点和连接边的物理属性，使得DAG成为物理图，此时DAG的物理属性为初始状态下的物理属性。

在初始状态下，主节点为连接边配置的物理属性可以包括sequential edge（顺序边）和concurrent edge（并行边）。其中，顺序边表示连接边所连接的顶点存在先后的执行依赖关系，即顶点的执行需要依赖于直接上游顶点的执行；也就是说，顺序边连接的顶点中，直接上游顶点需要先执行，然后才执行直接下游顶点。并行边表示连接边连接的顶点同时并行执行。在一些实施例中，并行边连接的顶点可以采用准实时模式执行，顺序边连接的顶点可以采用离线模式执行。在进一步的一些实施例中，基于bubble的概念，连接边的顺序边和并行边的物理属性可以与连接边的数据传输方式相重合；例如，顺序边是以数据落盘方式传输数据，与离线模式相对应；并行边是以内存或网络连接方式传输数据，与准实时模式相对应。需要说明的是，在可能的实现中，并行边也可以通过数据落盘方式传输数据，上述并行边的内存或网络连接的数据传输方式，以及顺序边的数据落盘传输方式仅是一种可选实现。

作为可选实现，在初始状态下，主节点为连接边配置物理属性时，可以确定DAG的多个顶点中的barrier（阻塞）顶点，将barrier顶点的输出连接边配置为顺序边；并且，将DAG中非顺序边的其他连接边配置为并行边。在一些实施例中，barrier顶点可以认为是含有barrier算子的顶点。barrier算子可以认为是顶点中含有barrier特性而可能阻塞数据的pipeline（管线）的算子。

需要说明的是，对于准实时模式而言，数据在工作节点之间能否有效的进行pipeline处理，很大程度上决定了下游工作节点是否会因处于空转状态而带来资源浪费。图3D示例性的示出了准实时模式下工作节点的数据流转示意图。如图3D所示，图3D中的一个方框表示一个工作节点，在准实时模式下所有的工作节点在作业提交开始就被拉起，虽然这样的调度方式允许数据得以在需要的时候pipeline起来，从而加速数据的处理，但并不是所有的上下游工作节点都可以有理想化的pipelined dataflow（管线化数据流）；例如除根工作节点以外(比如图3D中M3、M4、M6和M7为根工作节点)，下游工作节点在某种程度上都会处于一定程度的空转状态而带来浪费资源（比如图3D中除M3、M4、M6和M7外的下游工作节点，会处于一定程度的空转状态）。

上述空转造成的资源低效使用，在数据处理流程上存在barrier算子而无法pipeline、以及DAG层级比较深时尤为明显。基于此，本申请实施例在将DAG切分子图，并以准实时模式执行子图内顶点的task，以离线模式执行非子图的顶点的task的情况下，当DAG的顶点包含barrier特性的算子而可能阻塞数据的pipeline时，本申请实施例不考虑将该顶点与其下游顶点切入同一个子图。在一个示例中，依赖global sort（全局排序）操作的算子（比如MergeJoin算子、SorteAggregate算子等）被认为会造成数据阻塞，而基于hash特性操作的算子则对于pipeline更加友好。例如，barrier算子可以为MergeJoin（合并）算子、SorteAggregate（聚合）算子等。

图3E示例性的示出了初始状态下配置了物理属性的DAG示意图。需要说明的是，图3E所示内容仅是作为一种示例进行。如图3E所示，该示例示出了DAG的10个顶点（V1至V10）以及顶点之间的连接边，并且该10个顶点形成第0层、第1层和第2层这三层层级，第0层可以认为是顶层，第2层可以认为是底层。图3E中虚线框所示的顶点表示barrier顶点、虚线的连接边表示顺序边、实线的连接边表示并行边。假设图3C中顶点V1和V3含有barrier算子，则V1和V3可被标记为barrier顶点，并且V1和V3的输出连接边会在初始状态下配置为顺序边，而其余连接边则在初始状态下配置为并行边。需要说明的是，图3E中顶点内的数值表示顶点配置的并发度（例如，顶点配置的工作节点数量），比如V1中的100表示顶点V1配置100个工作节点。并发度为顶点配置的物理属性的一种可选形式。

在步骤S312中，遍历DAG中的每个顶点，判断遍历的每个顶点是否满足预设的加入子图的目标条件。

在步骤S313中，根据每个顶点的判断结果，调整DAG中连接边的物理属性，直至DAG中的顶点遍历完成。

DAG的物理图是通过对逻辑图中顶点、连接边的物理特性（比如数据传输方式，调度时机，资源特性等）进行物化来实现，而初始状态下配置的连接边的物理属性并不一定合理，因此主节点可通过遍历DAG中的每个顶点，基于每个顶点的物理属性以及顶点在DAG中与其他顶点的关系，来调整连接边的物理属性，从而对DAG中顶点的离线模式和准实时模式作出更清晰、合理的表述。

在上述思路下，本申请实施例可预先设置顶点满足加入子图的目标条件，基于该目标条件，主节点在初始状态下对DAG配置物理属性之后，可遍历DAG中的每个顶点，并判断遍历的每个顶点是否满足目标条件。进而基于每个顶点的判断结果，对DAG中的连接边调整物理属性，直至DAG中的顶点遍历完成，以实现对DAG中顶点的离线模式和准实时模式作出更清晰、合理的表述。例如，主节点可在遍历到一个顶点时，基于该顶点是否满足目标条件的判断结果，主节点可对DAG中的连接边调整物理属性；从而，每遍历到一个顶点则执行一次上述过程，直至DAG中的顶点遍历完成，实现对DAG中连接边的物理属性进行不断迭代的调整。

在一些实施例中，遍历DAG中的每个顶点可以按照一定的遍历方向进行，例如在DAG具有多个层级的情况下，主节点可以按照自顶层往底层的遍历方向进行遍历（即自上往下的遍历DAG中的顶点），也可以按照自底层往顶层的遍历方向进行遍历（即自下往上的遍历DAG中的顶点）。

在一些实施例中，由于顶点的遍历方向与对DAG进一步切分子图的迭代方向是一致的，因此不同的遍历方向，可能导致DAG进一步切分的子图存在不同。基于此，作为可选实现，本申请实施例可按照线上作业的数据处理方向，确定顶点的遍历方向。例如，对于线上大部分作业而言，处理的数据往往呈倒三角型，对应的DAG也大多数是倒三角形态，因此可以采用自底层往顶层的遍历方向来遍历DAG中的顶点，也就是从距离根顶点最远的顶点开始遍历，来迭代切分子图。在一个示例中，结合图3E所示，主节点可从第2层的顶点开始遍历，遍历完成第2层的顶点之后，再遍历第1层的顶点，以此类推，直至遍历完成第0层的顶点。

在主节点遍历DAG的顶点的过程中，主节点每遍历到一个顶点，则可判断该顶点是否满足目标条件，并基于判断结果，调整一次DAG中连接边的物理属性，以此迭代的调整连接边的物理属性，从而在遍历DAG的顶点的过程中，主节点可不断迭代的切分子图，最终在遍历完成所有顶点之后，完成最终子图的切分。例如，在初始状态下，DAG在初始状态的当前子图可以包括并行边连接的顶点，而在遍历DAG的顶点的过程中，主节点调整了一次DAG中连接边的物理属性之后，则可对子图进行一次调整，比如在调整了一次连接边的物理属性之后，基于调整后的并行边连接的顶点形成当前子图，从而在遍历顶点的过程中，以此方式不断的迭代调整当前子图，直至遍历完成所有顶点之后，将最终调整得到的子图，作为DAG的子图切分结果。

在一些实施例中，顶点加入子图的目标条件可以基于顶点的物理属性，以及顶点与DAG中其他顶点的关系（例如依赖关系）来设置。为便于说明，将主节点当前遍历的顶点称为当前顶点，则在一种可选实现中，判断当前顶点是否满足目标条件可以包括：当前顶点与DAG中的当前子图之间不存在顺序边连接；以及，当前顶点与当前子图不存在循环依赖关系。

在一些实施例中，主节点在获得当前顶点是否满足目标条件的判断结果之后，若当前顶点满足目标条件，则主节点可搜索当前顶点的直接上游顶点和直接下游顶点，若搜索的顶点与当前顶点不能进行任务联通，则将搜索的顶点的输入连接边设置为顺序边，以在当前顶点满足目标条件的情况下，调整DAG中连接边的物理属性；若当前顶点不满足目标条件，则主节点可将当前顶点的输入连接边设置为顺序边，以在当前顶点不满足目标条件的情况下，调整DAG中连接边的物理属性。

在步骤S314中，在DAG中的顶点遍历完成之后，基于调整物理属性的连接边，获得DAG的子图；所述子图由并行边连接的顶点形成；其中，子图中的顶点以准实时模式执行，子图外的顶点以离线模式执行。

在DAG中的顶点遍历完成之后，主节点完成了对DAG中连接边的物理属性调整，并且将当前子图通过不断的迭代，完成了最终的子图切分。例如，在遍历顶点的过程中，基于不断调整物理属性的连接边，主节点可不断迭代的调整当前子图中的顶点（当前子图中的顶点始终由并行边连接的顶点形成，当并行边调整为顺序边时，相应的顶点将从当前子图中调整踢出）；从而在遍历到最后一个顶点时，基于最后一个顶点的判断结果，主节点调整连接边的物理属性之后，可得到最终的子图。在得到的最终子图中，顶点可被配置为以准实时模式执行，而子图外的顶点可被配置为以离线模式执行。

在一个示例中，图3F示出了DAG切分子图后的示意图。如图3F所示，主节点在从第2层遍历到第0层的过程中，基于前文描述的方式，每遍历一个顶点则调整一次连接边的物理属性之后，可在遍历完成第0层的节点之后，得到图3F所示的最终的子图：子图0和子图1。其中，子图0中的顶点V2、V4、V7和V8各自对应的task可基于准实时模式一体化并行执行，子图1中的顶点V6和V10各自对应的task可基于准实时模式一体化并行执行，而子图外的顶点V1、V3、V5和V9各自对应的task基于离线模式执行。

作为一种可选实现，步骤S311至步骤S314可以认为是配置DAG的物理属性的实现过程，涉及初始状态下配置DAG的物理属性，以及在遍历DAG的顶点的过程中，不断调整连接边的物理属性，直至实现最终的子图切分。

本申请实施例提供的分布式作业执行方法中，主节点可生成作业的执行计划，并由DAG描述执行计划，然后在初始状态下配置DAG中顶点和连接边的物理属性，所述连接边的物理属性包括顺序边和并行边。由于初始状态配置的连接边的物理属性并不一定合理，因此主节点可遍历DAG中的每个顶点，并判断遍历的每个顶点是否满足预设的加入子图的目标条件，进而基于每个顶点的判断结果，调整DAG中连接边的物理属性，直至DAG中的顶点遍历完成。在DAG中的顶点遍历完成之后，主节点可获得DAG最终的子图，最终的子图可以是在遍历过程中不断调整连接边的物理属性的情况下，聚集最终的并行边连接的顶点而形成；即，在顶点的遍历过程中，主节点通过不断调整连接边的物理属性，并最终聚集并行边连接的顶点形成最终的子图。在获得最终的子图时，子图中的顶点以准实时模式执行，子图外的顶点以离线模式执行，从而实现对DAG中顶点的离线模式和准实时模式作出更清晰、准确的表述。本申请实施例通过在顶点的遍历过程中不断调整连接边的物理属性，能够对顶点的离线模式和准实时模式作出更清晰、准确的表述，从而提供出混合准实时模式和离线模式的混合执行模式。

本申请实施例通过遍历DAG的顶点，以对DAG中连接边的物理属性进行不断的调整，从而基于不断调整物理属性的连接边，对DAG进行灵活自适应的子图切分，使得DAG中顶点的执行模式更为清晰、准确；从而基于最终切分得到的子图，本申请实施例能够在混合准实时模式和离线模式的情况下，对于DAG提出更细粒度、更通用、更合理的作业执行模式，兼顾了准实时模式的低执行时延以及离线模式的高资源利用率，达到作业执行时高资源利用率和低执行时延的有效平衡，显著提高了分布式系统的性能。

作为可选实现，图4A示出了本申请实施例提供的分布式作业执行方法的再一流程图。该方法流程可由主节点执行实现。参照图4A，该方法流程可以包括如下步骤。

在步骤S410中，生成作业的执行计划，所述执行计划由DAG描述。

在步骤S411中，配置DAG中顶点和连接边的物理属性，所述连接边的物理属性包括顺序边和并行边。

在步骤S412中，按照由底层至顶层的顺序，遍历DAG的各顶点。

在步骤S413中，针对当前遍历到当前顶点，判断当前顶点与当前子图之间是否不存在顺序边连接，以及，当前顶点与当前子图是否不存在循环依赖关系；若存在任一判断结果为否，则执行步骤S414，若判断结果均为是，则执行步骤S415。

在一些实施例中，在DAG图的初始状态下，当前子图包括初始状态配置的并行边连接的顶点。如果当前顶点为第一个遍历的顶点，则当前顶点可与初始状态下的当前子图进行步骤S413所示的判断。在第一个遍历的顶点之后，由于DAG中连接边的物理属性可能存在调整，因此基于并行边连接的顶点而形成的当前子图可能也存在调整；基于此，如果当前顶点为非第一个遍历的顶点，则当前顶点可基于调整后的当前子图进行步骤S413所示的判断。

在步骤S413的判断中，如果判断结果中存在任一否，即当前顶点与当前子图之间存在顺序边连接，或当前顶点与当前子图存在循环依赖关系，则可确定当前顶点不满足目标条件，后续执行步骤S414。在步骤S413的判断中，如果判断结果均为是，即当前顶点与当前子图之间不存在顺序边连接，以及当前顶点与当前子图不存在循环依赖关系，则可确定当前顶点满足目标条件，后续执行步骤S415。

在一些实施例中，当前顶点与当前子图不存在循环依赖关系可以包括：

（1）当前顶点的下游顶点中不存在顶点位于当前子图的上游。当前顶点的下游顶点可以包括当前顶点的下游直接顶点和下游间接顶点。如果当前顶点的任一下游顶点位于当前子图中任一顶点的上游，则当前顶点的下游顶点中存在顶点位于当前子图的上游，当前顶点与当前子图存在循环依赖关系。作为一种示例，图4B示出了当前顶点与当前子图存在循环依赖关系的一种示例。如图4A所示，V1作为当前顶点，V2和V4所在的子图41为当前子图， V3作为V1的下游顶点，由于V3位于V4（V4位于子图41中）的上游，则可确定当前顶点的下游顶点中存在顶点位于当前子图的上游，当前顶点与当前子图存在循环依赖关系。

（2）当前顶点的上游顶点中不存在顶点位于当前子图的下游。当前顶点的上游顶点可以包括当前顶点的上游直接顶点和上游间接顶点。如果当前顶点的任一上游顶点位于当前子图中任一顶点的下游，则当前顶点的上游顶点中存在顶点位于当前子图的下游，当前顶点与当前子图存在循环依赖关系。作为一种示例，图4C示出了当前顶点与当前子图存在循环依赖关系的另一种示例。如图4C所示，V3作为当前顶点，V0、V2、V4和V5所在的子图42为当前子图，V1作为V3的上游顶点，由于V1位于V0的下游，则可确定当前顶点的上游顶点中存在顶点位于当前子图的下游，当前顶点与当前子图存在循环依赖关系。

（3）当前顶点的下游子图中不存在顶点位于当前子图的上游。DAG当前可以存在多个子图，DAG当前存在的子图由当前并行边连接的顶点形成，且DAG当前存在的子图可以包括位于当前顶点下游的下游子图（例如，当前顶点的下游顶点所在的当前子图），以及位于当前顶点上游的上游子图（例如，当前顶点上游的顶点所在的当前子图）。将DAG当前存在的任一子图作为当前子图，从而在判断当前顶点与当前子图是否不存在循环依赖关系时，基于第（3）项的判断，如果当前顶点的下游子图中存在任一顶点，位于当前子图中任一顶点的上游，则当前顶点与当前子图存在循环依赖关系。

作为一种示例，图4D示出了当前顶点与当前子图存在循环依赖关系的再一种示例。如图4D所示，V1作为当前顶点，V2和V4所在的子图43以及V3和V5所在的子图44为DAG当前存在的两个子图，子图43和子图44均为V1的下游子图。当子图43作为当前子图与V1判断是否不存在循环依赖关系时，V1的下游子图44中存在顶点V5位于顶点V4（V4位于子图43中）的上游，因此可确定当前顶点的下游子图中存在顶点位于当前子图的上游，当前顶点与当前子图存在循环依赖关系。当子图44作为当前子图与V1判断是否不存在循环依赖关系时，第（3）项的判断过程以上述方式同理实现。

（4）当前顶点的上游子图中不存在顶点位于当前子图的下游。在当前顶点与当前子图判断是否不存在循环依赖关系时，基于第（4）项的判断，如果当前顶点的上游子图中存在任一顶点，位于当前子图中任一顶点的下游，则当前顶点与当前子图存在循环依赖关系。作为一种示例，图4E示出了当前顶点与当前子图存在循环依赖关系的又一种示例。如图4E所示，V4作为当前顶点，V0、V3、V5和V6所在的子图45，以及V1和V2所在的子图46为DAG当前存在的两个子图。当子图45作为当前子图与V4判断是否不存在循环依赖关系时，V4的上游子图46中存在顶点V1位于顶点V0（V0位于子图45中）的下游，因此可确定当前顶点的上游子图中存在顶点位于当前子图的下游，当前顶点与当前子图存在循环依赖关系。当子图46作为当前子图与V4判断是否不存在循环依赖关系时，第（4）项的判断过程以上述方式同理实现。

在一些实施例中，上述的（1）、（2）、（3）和（4）项均满足，则可确定当前顶点与当前子图不存在循环依赖关系。

在步骤S414中，将当前顶点的输入连接边设置为顺序边。

在遍历的当前顶点不满足目标条件时，主节点可将当前顶点的输入连接边的物理属性设置为顺序边。例如，结合图3E和图3F所示，假设顶点V9不满足目标条件，则在图3F中V9的输入连接边可由并行边设置为顺序边。V9的输入连接边例如图3E和图3F中由V5输入V9的输入连接边、由V6输入V9的输入连接边。

在步骤S415中，搜索当前顶点的直接上游顶点和直接下游顶点，若搜索的顶点不能进行任务联通，则将搜索的顶点的输入连接边设置为顺序边。

在遍历的当前顶点满足目标条件时，主节点可搜索当前顶点的直接上游顶点和直接下游顶点（即搜索与当前顶点通过输入连接边直接连接的顶点，以及通过输出连接边直接连接的顶点），若搜索的顶点与当前顶点不能进行任务联通，则将搜索的顶点的输入连接边的物理属性设置为顺序边。

在一些实施例中，主节点可按照广度优先遍历算法，先搜索当前顶点的直接上游顶点，然后再搜索当前顶点的直接下游顶点；从而针对先搜索的直接上游顶点，判断能否进行任务联通，然后再搜索直接下游顶点，针对搜索的直接下游顶点，判断能否进行任务联通。在一些实施例中，搜索的顶点能否进行任务联通表示搜索的顶点的并发度是否过高；在顶点的并发度过高时，若还将顶点加入子图，则由于子图的总并发度过高，将导致子图内的顶点在一体化申请资源时的失败概率提升，因此本申请实施例可在顶点的并发度过高时，认为顶点不能进行任务联通。作为可选实现，本申请实施例可设置并发度阈值，从而判断搜索的顶点的并发度是否高于并发度阈值，如果搜索的顶点的并发度高于并发度阈值，则搜索的顶点不能进行任务联通；如果搜索的顶点的并发度不高于并发度阈值，则搜索的顶点能进行任务联通。在搜索的顶点不能进行任务联通时，需将搜索的顶点的输入连接边的设置为顺序边。

需要解释的是，在准实时模式的一体化资源申请/运行下，当顶点配置的工作节点过多（并发度过高）时，可能无法为工作节点申请到资源，或者即使能为工作节点申请到资源，但后续执行失败的代价也可能是无法控制的。因此，本申请实施例需要限定子图的并发度总大小（例如，通过限制加入子图的顶点的并发度不高于并发度阈值），以避免过多的工作节点进行一体化运行所带来的负面影响。

结合图3F所示，假设当前顶点V2满足目标条件，按照广度优先遍历算法，由于V2没有上游节点，因此可直接搜索V2的输出连接边直接连接的下游节点V4、V5和V6，其中，V5并发度500高于并发度阈值，因此V5不能进行任务联通，需要将V5的输入连接边设置为顺序边。需要说明的是，并发度阈值的具体数值可根据实际情况设置，本申请实施例并不设限。

在步骤S416中，在DAG中的顶点遍历完成之后，基于调整物理属性的连接边，获得DAG的子图；所述子图由并行边连接的顶点形成；其中，子图中的顶点以准实时模式执行，子图外的顶点以离线模式执行。

在由底层至顶层遍历顶点的过程中，将每个遍历到的顶点视为当前子图，迭代的执行步骤S413至步骤S416，则在遍历DAG的顶点过程中，主节点可不断调整DAG中连接边的物理属性，且每遍历到一个顶点，则调整一次连接边的物理属性。基于每次调整的连接边的物理属性，DAG中当前存在的子图将不断的变化，从而使得子图迭代的切分，从而在遍历完成最后一个顶点时，主节点可完成最终的子图切分，获得DAG的子图。

结合图3F所示，在遍历完成所有顶点后，实线示意的并行边连接的顶点V2、V4、V7和V8可形成子图0，并行边连接的顶点V5和V10形成子图1，子图0和子图1为DAG最终的子图。在完成DAG的子图切分之后，子图中的顶点可基于准实时模式执行，子图外的顶点可基于离线模式执行。结合图3F所示，子图0中的顶点V2、V4、V7和V8可基于准实时模式一体化并行执行，子图0中的顶点V6和V10可基于准实时模式一体化并行执行，而子图外的顶点V1、V3、V5和V9可基于离线模式执行。

在进一步的一些实施例中，在数据Shuffle上，本申请实施例可根据子图内、外不同连接边的特点采用不同的shuffle方式，对于子图外或者穿越子图bourndary（边界）的顺序边（例如，与子图连接的顺序边），其数据shuffle的方式可与离线模式相同，即通过数据落盘的方式传输shuffle数据。而子图内的连接边（即子图内顶点相互连接的连接边）为并行边，具备充分的数据pipeline特性且传输数据量不大，因此对于子图内的并行边上的数据，可采用和准实时模式相同的网络、内存直连的方式实现数据shuffle。

在进一步的一些实施例中，在切分DAG的子图的过程中，还需考虑到任务的实际资源和预期运行时间等信息，比如工作节点的plan memory（计划内存）是否超过一定数值、工作节点中是否包含UDF（用户自定义）算子、作业执行过程中工作节点基于历史信息的预估执行时间是否超长等。为了进一步加速作业的计算执行，在一些实施例中，主节点可设置子图的工作节点来源于预先拉起的工作节点（例如预拉资源池中预先拉起的工作节点）。在其他可能的实现中，为实现灵活的可插拔性，在必要的情况下，本申请实施例也允许子图的工作节点当场申请资源。

在进一步的一些实施例中，在子图被触发调度后，主节点可通过Admin进程向资源管理申请资源，例如默认使用的是一体化成组调度的方式申请资源。图5示出了子图的资源申请示例图。结合图5所示，在以成组调度的方式申请资源的情况下，主机节点会以子图为一个bubble，整体构建子图的资源请求，从而基于该请求控制Admin进程进行资源分配。当Admin进程收到来自于子图的资源申请后，会使用预拉起资源池中的对应资源分配工作节点，从而实现子图在作业执行过程中的资源调度。

在进一步的一些实施例中，为了在紧张资源情况下，实现子图内的资源动态调整，子图还可支持渐进式的资源申请模式。这种模式允许子图内的每个顶点独立进行资源申请。对于这种申请，Admin只要有增量资源的调度，则会将增量资源的调度结果调度给子图内的顶点，直至满足了子图内所有顶点的资源申请。

在一些实施例中，本申请实施例在切分子图之后，基于切分的子图可实现混合执行模式，在子图内充分利用网络、内存直连和工作节点预先拉起等方式提升性能，而子图外顶点则使用离线模式执行，从而实现了作业执行过程中，高资源利用率和低执行时延之间的有效平衡，显著提高了分布式系统的性能。作为可选实现，在为DAG切分子图的实现中，主节点可以在对顶点的输入数据量、算子特性、作业规模等物理属性进行分析后，切分出多个子图，例如，主节点在为DAG切分子图时可以考虑以下几个因素：

DAG中顶点的算子特性，例如，当顶点包含barrier特性的算子而可能阻塞数据的pipeline时，则在初始状态，考虑不将该顶点与其下游顶点切入同一个子图，从而将包含barrier算子的顶点的输出连接边初始配置为顺序边；

子图切分的迭代方向，考虑线上作业处理的数据呈倒三角型，且DAG也大多数是倒三角形态，可以使用自底层往顶层的遍历方向对DAG中的顶点进行遍历；

设置顶点加入子图的目标条件，在遍历顶点的过程中，通过尝试聚合DAG的顶点，在顶点不满足目标条件时，将相应的并行边还原成顺序边，从而最终由更为准确、合理的并行边所连接的顶点形成子图。

在进一步的一些实施例中，DAG切分的子图可以由主节点反馈给用户终端，从而由用户对DAG中的子图进行手动调整，以使得DAG切分的子图介入人为调整过程，加入人为经验和要求，进一步提升DAG中最终子图切分结果的准确性。基于此，主节点可在对DAG完成子图切分之后，将包含子图的DAG反馈给终端，以便终端在获得子图的调整结果之后，主节点能够从终端再获取到包含调整后子图的DAG；其中，终端获得主节点反馈的包含子图的DAG后，可由终端用户人为使用终端对子图进行调整，以使得终端获得用户人为调整后的子图调整结果。

在进一步的一些实施例中，主节点可以在对多个DAG切分子图之后，基于各个DAG的子图切分结果形成学习经验，从而基于学习经验，主节点可以训练出能够对DAG实现自动切分子图的神经网络模型，以便利用神经网络模型实现对DAG进行高效、准确的子图切分。作为可选实现，主节点在对一个DAG切分子图之后，可将当前子图的切分结果与DAG的历史子图切分结果进行比对，计算出当前子图的切分结果与历史子图切分结果之间的差异，从而通过该差异对神经网络模型进行优化（例如对神经网络模型进行参数优化调整），以使得神经网络模型可以在主节点每次对DAG完成子图切分之后，实现不断的迭代优化，提升神经网络模型切分子图的准确性。基于此，主节点可在对DAG完成子图切分之后，确定DAG的子图与历史子图的差异，从而根据所述差异，训练或优化神经网络模型，其中，该神经网络模型具有对DAG切分子图的能力。在其他可能的实现中，神经网络模型也可在切分子图之后，基于人为调整结果进行学习，从而通过人为干预提升子图切分效果的准确性。

本申请实施例提供的混合执行模式，使作业执行过程能够更加灵活、自适应的匹配线上多种多样作业的特点，具有重要的意义：

一方面，混合执行模式使更多作业的加速成为可能。一体化并行调度的准实时模式具有作业规模的准入门槛，主要是面向中小数据规模的作业。这是出于有限资源的公平使用，也是为了控制工作节点运行失败带来的消耗。但对于中大型作业而言，虽然作业的规模超过准实时模式的准入门槛，但是DAG中的子图有可能是符合准实时模式的数据规模，且可以通过数据pipeline等方式来加速执行。因此通过混合执行模式，使得中大型作业的DAG中部分或全部子图通过准实时模式执行提供了可能。此外，线上部分工作节点由于其本身的特性而无法预先拉起，这导致工作节点无法使用准实时模式来执行作业，目前单一使用离线模式或者准实时模式的方式，会使得一个作业中只要包含有一个无法预先拉起的工作节点，则只能使用离线模式执行，而无法使用准实时模式加速执行，而通过混合执行模式能较好的解决此问题。

另一方面，混合执行模式将线上的离线资源池和准实时的预拉起资源池打通。离线资源池和准实时资源池作为两种特性不同的线上资源，目前是完全隔离，各自管理的分离状态。离线资源池和准实时资源池的分离状态，将导致资源的不合理使用和浪费。比如对于大规模作业，因为完全无法利用准实时资源池，而只能排队等待离线资源池中的资源，即便此时准实时资源池处于空闲状态。本申请实施例提供的混合执行模式能通过DAG的子图切分，拉通离线资源池和准实时资源池的混合使用，使得两者各自补充。

再一方面，混合执行模式可以整体上提高资源的利用率。从资源利用的角度来看，对于可以满足准实时模式准入的中型作业，虽然利用准实时模式，能够降低作业的执行时延，提升作业的执行速度，但客观上会造成一定程度资源的空转与浪费（尤其是DAG图的层级较深以及计算逻辑有barrier时）。这种情况下，本申请实施例通过设置顶点的并发度、确认barrier算子等条件，可将一个准实时模式下的DAG切分成多个子图，从而能够有效的减少空转消耗，而且在子图切分条件设置合理的情况下，执行时延方面的损失也可以做到较低。

又一方面，混合执行模式能有效降低单个工作节点执行失败的代价。一体化的准实时模式执行，由于其数据pipeline的特性，作业的容错粒度和资源调度的粒度是紧密挂钩的。也就是说，只要有一个工作节点执行失败，整个作业都要重新运行。而作业规模越大，作业运行过程中存在工作节点失败的概率也就越大，这无疑也限制了准实时模式能支持的作业规模。而混合执行模式则提供了一个更好的平衡点，即单个工作节点的失败，最多只影响该工作节点所处于的子图，而不会影响DAG的所有工作节点。

在本申请实施例切分子图并提供混合执行模式的情况下，将本申请实施例提供的混合执行模式、标准的离线模式、以及标准的准实时模式进行性能比较，可以发现：从执行时延来看，混合执行模式显然要优于标准的离线模式，而较标准的准实时一体化执行模式而言，混合执行模式的执行时延也并没有明显的增多；从资源消耗来看，标准的准实时作业的低执行时延，建立在资源消耗远大于混合执行模式和标准的离线模式的前提之上，而混合执行模式在执行时延低于标准的离线模式的同时，资源消耗则与标准的离线模式在整体上相近。因此，综合起来看，本申请实施例提供的混合执行模式可以很好的结合离线模式和准实时模式的优点：在执行时延层面，混合执行模式的执行时延比离线模式要短，接近于准实时模式的执行时延；在资源消耗层面，混合执行模式基本上和离线模式相当，相比于准实时模式有大幅度的减少。

本申请实施例能够面对各种规模和各种计算特点的分布式作业，均作出自适应的子图切分，实现了在一个作业内部多种资源和执行模式的混用使用。本申请实施例提供的混合执行模式具有较高的通用性，并且本申请实施例在执行作业时，能够充分结合离线的离线资源池以及预先拉起的准实时资源池，达到了更好的资源使用效果。本申请实施例实现了高资源利用率和低执行时延的有效平衡，显著提高了分布式系统的性能。

本申请实施例还提供一种主节点，主节点可被配置为执行本申请实施例提供的分布式作业执行方法。

本申请实施例还提供一种分布式系统，该分布式系统的结构可以结合前文相应部分的描述，该分布式系统可以包括上述所述的主节点。该分布式系统的在线服务可以具有一个或多个服务版本。

本申请实施例还提供一种物理机，该物理机可以设置本申请实施例提供的主节点。作为一种可选实现，图6示出了物理机的框图。如图6所示，该物理机可以包括：至少一个处理器1，至少一个通信接口2，至少一个存储器3和至少一个通信总线4。在本申请实施例中，处理器1、通信接口2、存储器3、通信总线4的数量为至少一个，且处理器1、通信接口2、存储器3通过通信总线4完成相互间的通信。可选的，通信接口2可以为用于进行网络通信的通信模块的接口。可选的，处理器1可能是CPU（中央处理器），GPU（Graphics ProcessingUnit，图形处理器），NPU（嵌入式神经网络处理器），FPGA（Field Programmable GateArray，现场可编程逻辑门阵列），TPU（张量处理单元），AI芯片，特定集成电路ASIC（Application Specific Integrated Circuit），或者是被配置成实施本申请实施例的一个或多个集成电路等。存储器3可能包含高速RAM存储器，也可能还包括非易失性存储器（non-volatile memory），例如至少一个磁盘存储器。其中，存储器3存储一条或多条计算机可执行指令，处理器1调用所述一条或多条计算机可执行指令，以执行本申请实施例提供的分布式作业执行方法。

本申请实施例还提供一种存储介质，该存储介质可以存储一条或多条计算机可执行指令，该一条或多条计算机可执行指令被执行时，实现如本申请实施例提供的分布式作业执行方法。

本申请实施例还提供一种计算机程序，该计算机程序可以执行实现如本申请实施例提供的分布式作业执行方法。

上文描述了本申请实施例提供的多个实施例方案，各实施例方案介绍的各可选方式可在不冲突的情况下相互结合、交叉引用，从而延伸出多种可能的实施例方案，这些均可认为是本申请实施例披露、公开的实施例方案。虽然本申请实施例披露如上，但本申请并非限定于此。任何本领域技术人员，在不脱离本申请的精神和范围内，均可作各种更动与修改，因此本申请的保护范围应当以权利要求所限定的范围为准。

Claims (21)

1.一种分布式作业执行方法，其中，所述方法应用于主节点，所述方法包括：

检测在线服务启动指令，拉起管理进程；

通过管理进程，获取多任务管理进程的启动文件；以及，通过管理进程，基于多任务管理进程的启动文件，拉起多任务管理进程；

获取用户提交的作业，通过管理进程进行作业的资源调度管理，以及通过多任务管理进程对作业相应的有向无环图DAG进行管理。

2.根据权利要求1所述的方法，其中，所述对作业相应的DAG进行管理包括：

生成作业的执行计划，所述执行计划由DAG描述；

配置DAG的物理属性。

3.根据权利要求1或2所述的方法，其中，还包括：

通过管理进程，拉起工作节点的代理进程；所述代理进程用于拉起工作节点的工作进程，所述代理进程和工作进程执行作业的计算逻辑，并将执行结果传输给主节点；

其中，主节点的多任务管理进程与工作节点的工作进程进行通信，以使得工作进程基于多任务管理进程配置的DAG的物理属性，执行作业。

4.根据权利要求3所述的方法，其中，所述在线服务具有多个服务版本，一个服务版本在主节点中配置有相应的一个或多个多任务管理进程，以及在一个工作节点中配置有相应的一个工作进程；相同服务版本的多任务管理进程和工作进程进行通信，以执行相同服务版本的作业，并且不同服务版本的多任务管理进程和工作进程相互隔离。

5.根据权利要求4所述的方法，其中，所述通过管理进程，获取多任务管理进程的启动文件包括：通过管理进程，获取在线服务的服务版本列表，所述服务版本列表记录有在线服务的多个服务版本；通过管理进程，基于服务版本列表中记录的各服务版本，获取各服务版本相应的多任务管理进程的启动文件；

所述通过管理进程，基于多任务管理进程的启动文件，拉起多任务管理进程包括：通过管理进程，基于各服务版本相应的多任务管理进程的启动文件，拉起各服务版本相应的多任务管理进程；

所述方法还包括：

通过管理进程，将所述服务版本列表传输给工作节点的代理进程，以使得代理进程在工作节点拉起各服务版本相应的工作进程。

6.根据权利要求4或5所述的方法，其中，还包括：

获取第一服务版本的新增请求，通过管理进程获取第一服务版本的多任务管理进程的启动文件，基于第一服务版本的多任务管理进程的启动文件，增加拉起第一服务版本的多任务管理进程；以及，通过管理进程将第一服务版本的新增信息发送代理进程，以使得代理进程获取第一服务版本的工作进程的启动文件之后，代理进程在工作节点中增加拉起第一服务版本的工作进程；

和/或，获取第二服务版本的删除请求，通过管理进程停止执行第二服务版本相应的多任务管理进程，以及，通过管理进程将第二服务版本的删除信息发送给代理进程，以使得代理进程停止执行第二服务版本相应的工作进程；

和/或，若检测第三服务版本在指定的时间间隔内没有作业提交，通过管理进程向代理进程发送通知，以使得代理进程停止执行第三服务版本相应的工作进程；

和/或，在第三服务版本相应的工作进程停止执行之后，若获取到第三服务版本的作业请求，通过管理进程向代理进程发送通知，以使得代理进程重新拉起第三服务版本相应的工作进程。

7.根据权利要求4或5所述的方法，其中，所述作业指示希望使用第四服务版本，所述方法还包括：

通过管理进程，将作业转交给第四服务版本的多任务管理进程；

响应第四服务版本的多任务管理进程的资源请求，通过管理进程挑选空闲的目标代理进程，以及将所述目标代理进程下第四服务版本的工作进程信息，返回给第四服务版本的多任务管理进程；其中，空闲的代理进程下的所有工作进程处于空闲状态；

通过第四服务版本的多任务管理进程，从第四服务版本的工作进程，获取作业执行信息，以对作业状态进行收集；

当第四服务版本的作业执行结束时，基于管理进程从所述目标代理进程获取的通知，将所述目标代理进程重新标记为空闲状态；其中，所述目标代理进程停止调度与第四服务版本不同的作业，直至第四服务版本的作业执行结束。

8.根据权利要求4或5所述的方法，其中，一个工作节点中的代理进程与该代理进程管理的工作进程，共享一个资源组；一个工作节点中的工作进程所占用的资源不超过共享的资源组的上限；并且在同一时刻，一个代理进程下只有一个工作进程执行作业。

9.根据权利要求2所述的方法，其中，所述DAG包括多个顶点以及顶点之间的连接边；所述配置DAG的物理属性包括：

配置DAG中顶点和连接边的物理属性，所述连接边的物理属性包括顺序边和并行边；

遍历DAG中的每个顶点，判断遍历的每个顶点是否满足预设的加入子图的目标条件；

根据每个顶点的判断结果，调整DAG中连接边的物理属性，直至DAG中的顶点遍历完成；

在DAG中的顶点遍历完成之后，基于调整物理属性的连接边，获得DAG的子图；所述子图由并行边连接的顶点形成；其中，子图中的顶点以准实时模式执行，子图外的顶点以离线模式执行。

10.根据权利要求9所述的方法，其中，所述遍历DAG中的每个顶点包括：

按照DAG的底层至顶层的遍历方向，或者，顶层至底层的遍历方向，遍历DAG中的每个顶点；

所述根据每个顶点的判断结果，调整DAG中连接边的物理属性包括：

若当前遍历到的当前顶点不满足所述目标条件，将当前顶点的输入连接边设置为顺序边；

若所述当前顶点满足所述目标条件，搜索当前顶点的直接上游顶点和直接下游顶点，若搜索的顶点不能进行任务联通，则将搜索的顶点的输入连接边设置为顺序边。

11.根据权利要求10所述的方法，其中，所述搜索当前顶点的直接上游顶点和直接下游顶点包括：

按照广度优先遍历算法，先搜索当前顶点的直接上游顶点，再搜索当前顶点的直接下游顶点；

所述若搜索的顶点不能进行任务联通，则将搜索的顶点的输入连接边设置为顺序边包括：

判断搜索的顶点的并发度是否高于并发度阈值；若是，则搜索的顶点不能进行任务联通，将搜索的顶点的输入连接边设置为顺序边。

12.根据权利要求9-11任一项所述的方法，其中，所述目标条件基于顶点的物理属性，以及顶点与DAG中其他顶点的关系进行设置。

13.根据权利要求12所述的方法，其中，所述判断遍历的每个顶点是否满足预设的加入子图的目标条件包括：

针对当前遍历到当前顶点，判断当前顶点与当前子图之间是否不存在顺序边连接，以及，当前顶点与当前子图是否不存在循环依赖关系；

其中，若存在任一判断结果为否，则所述当前顶点不满足所述目标条件，若判断结果均为是，则所述当前顶点满足所述目标条件。

14.根据权利要求13所述的方法，其中，所述当前顶点与当前子图不存在循环依赖关系包括：

当前顶点的下游顶点中不存在顶点位于当前子图的上游；

当前顶点的上游顶点中不存在顶点位于当前子图的下游；

当前顶点的下游子图中不存在顶点位于当前子图的上游；

当前顶点的上游子图中不存在顶点位于当前子图的下游。

15.根据权利要求9所述的方法，其中，所述配置DAG中连接边的物理属性包括：

在初始状态下，确定所述多个顶点中的阻塞barrier顶点，将barrier顶点的输出连接边配置为顺序边，以及，将DAG中非顺序边的其他连接边配置为并行边；所述barrier顶点为含有barrier算子的顶点；

其中，子图外或者穿越子图边界的顺序边，采用数据落盘的方式进行数据传输；子图内的并行边采用网络或者内存连接的方式进行数据传输。

16.根据权利要求9所述的方法，其中，所述方法还包括：

将包含子图的DAG反馈给终端，以便终端在获得子图的调整结果之后，获取包含调整后子图的DAG；

和/或，确定DAG的子图与历史子图的差异，根据所述差异训练或优化神经网络模型，所述神经网络模型具有对DAG切分子图的能力。

17.一种分布式作业执行方法，其中，包括：

获取用户提交的作业；

生成作业的执行计划，所述执行计划由DAG描述；

配置DAG中顶点和连接边的物理属性，所述连接边的物理属性包括顺序边和并行边；

遍历DAG中的每个顶点，判断遍历的每个顶点是否满足预设的加入子图的目标条件；

根据每个顶点的判断结果，调整DAG中连接边的物理属性，直至DAG中的顶点遍历完成；

在DAG中的顶点遍历完成之后，基于调整物理属性的连接边，获得DAG的子图；所述子图由并行边连接的顶点形成；其中，子图中的顶点以准实时模式执行，子图外的顶点以离线模式执行。

18.一种主节点，其中，所述主节点被配置为执行如权利要求1-16任一项所述的分布式作业执行方法，或者，如权利要求17所述的分布式作业执行方法。

19.一种分布式系统，其中，包括：主节点以及多个工作节点；所述主节点如权利要求18所述的主节点，所述分布式系统的在线服务具有一个或多个服务版本。

20.一种物理机，其中，包括：至少一个存储器以及至少一个处理器，所述存储器存储一条或多条计算机可执行指令，所述处理器调用所述一条或多条计算机可执行指令，以执行如权利要求1-16任一项所述的分布式作业执行方法，或者，如权利要求17所述的分布式作业执行方法。

21.一种存储介质，其中，所述存储介质存储一条或多条计算机可执行指令，所述一条或多条计算机可执行指令被执行时，实现如权利要求1-16任一项所述的分布式作业执行方法，或者，如权利要求17所述的分布式作业执行方法。

Images