具体实施方式

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

分布式作业可以理解为将作业提交给分布式系统进行执行。图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需要配置的并发度、各stage的工作节点使用的资源（例如CPU资源、内存资源等）、数据传输方式等物理属性。例如，结合图1D示例，物理图描述了顶点V0需要配置3个工作节点（并发度为3），顶点V1、V2和V3分别需要配置2个工作节点（并发度为2）。也就是说，物理图能够表达DAG中顶点和连接边的物理属性。通过物理图描述的顶点和连接边的物理属性，主节点可以为各个stage调度工作节点和资源，以使得stage中的task可以被多个工作节点并行执行，实现作业在分布式系统中的执行。

本申请实施例所指的配置执行计划可以包括配置执行计划的逻辑，以及配置执行计划的物理属性。配置执行计划的逻辑可以认为是在逻辑图层面对执行计划进行配置，例如，配置执行计划的执行流程等。配置执行计划的物理属性可以认为是在物理图层面对执行计划进行配置，例如，配置执行计划各stage的并发度、资源、数据传输方式等物理属性。

如果执行计划在作业具体执行之前配置，并且执行计划配置之后无法在作业的具体执行过程中调整，这种执行计划称为静态执行计划。也就是说，静态执行计划在作业执行之前配置完成，并且无法在作业具体执行过程中调整。然而，在作业具体执行之前并无法准确预估执行计划各stage需要实际使用的资源，以及执行计划合理的执行路径，这无疑导致静态执行计划的配置难以合理和准确，降低了分布式系统执行作业的性能。

基于此，本申请实施例提供新型的执行计划配置方案，该方案能够在作业执行过程中，基于上游stage的数据输出结果，动态调整下游stage的配置，以使得下游stage的配置能够适应于上游stage的实际执行结果，从而使得下游stage的并发度、资源等配置能够贴合作业的具体执行情况，提升执行计划配置的合理性和准确性。

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

在步骤S210中，获取用户提交的作业。

在步骤S211中，生成所述作业的执行计划，所述执行计划包括多个stage，所述多个stage包括上游stage以及所述上游stage的直接下游stage。

终端向分布式系统提交作业之后，分布式系统中的主节点可解析作业，生成作业的执行计划，所述执行计划可由DAG描述。所述执行计划可以包括多个stage，该多个stage中可以包括上游stage，以及该上游stage的直接下游stage。在一些实施例中，该多个stage中任一存在下游stage的stage均可以视为是所述上游stage，在作业的具体执行过程中，上游stage的输出数据可输入直接下游stage进行处理。一个上游stage的输出数据可以输入一个或多个直接下游stage，一个直接下游stage也可能输入一个或多个上游stage的输出数据；也就是说，上游stage可以对应一个或多个直接下游stage，一个直接下游stage也可以对应一个或多个上游stage。在一些实施例中，上游stage可称为直接下游stage的上一stage，直接下游stage可称为上游stage的下一stage。

在一个示例中，结合图1C所示，V1为V2和V3的上游stage，V2和V3为V1的直接下游stage，在作业的执行过程中，V1的输出数据可输入V2和V3进行处理；而V2和V3又作为V4的上游stage，V4作为V2和V3的直接下游stage，V2和V3的输出数据可输入V4进行处理。本申请实施例关注的一个方面是直接下游stage需要配置多少并发度、资源等，来处理上游stage的输出数据；比如V2和V3分别需要配置多少并发度、资源等，来处理V1的输出数据，V4需要配置多少并发度、资源等，来处理V2和V3的输出数据。

在步骤S212中，在作业的执行过程中，获取所述上游stage的输出数据的Statistics（统计信息）。

在作业执行过程中，任一stage执行完成后，主节点可收集该stage的工作节点的输出数据的Statistics（统计信息）。基于此，在执行计划的某一上游stage执行完成后，主节点可收集到该上游stage的输出数据的统计信息。在一些实施例中，上游stage的输出数据的Statistics可以包括如下任一项：输出数据的数据量（例如输出数据分别在数据压缩前和压缩后的数据量）、输出数据的Partition（数据分区）的数据量分布信息、输出数据中每个Partition的Record（序列化数据记录）数量等。

在步骤S213中，根据所述Statistics，对所述直接下游stage进行配置，以使得所述直接下游stage基于配置结果执行作业。

基于上游stage的输出数据的统计信息，主节点可对直接下游stage进行配置，以使得直接下游stage的配置能够适应于上游stage的实际执行结果，从而使得下游stage的并发度、资源等配置能够贴合作业的具体执行情况；进而，直接下游stage可基于配置结果执行作业，实现直接下游stage相应的task能够被合理、高效的执行完成。

在作业执行过程中，以本申请实施例提供的方式，动态配置上游stage的直接下游stage，能够使得执行计划在作业执行过程中实现配置的动态调整，并使得执行计划的配置能够贴合作业的具体执行情况。也就是说，在作业执行过程中，本申请实施例可基于上游stage的输出数据与统计信息来对分布式作业进行动态调整，实现作业的动态调整效果。进而基于动态配置的执行计划实现作业的具体执行，能够使得分布式系统更为合理高效的完成作业执行，显著提升分布式系统执行作业的性能。

在一些实施例中，基于上游stage的输出数据的统计信息，对直接下游stage进行配置可以包括如下任一项：

根据所述统计信息，对直接下游stage配置并发度；

根据所述统计信息，为直接下游stage分配Partition；例如，将上游stage输出的Partition分配给直接下游stage的工作节点，或者，在Join（连接）场景下，将上游stage输出的Partition拆分后分配给直接下游stage，以在直接下游stage的工作节点进行Join操作；

根据所述统计信息，选择后续执行的直接下游stage；在执行计划中，上游stage的下游可以配置候选的多条执行路径，以便在作业具体执行过程中，基于上游stage的执行结果，从多条执行路径中选择实际执行的执行路径，使得执行计划的执行逻辑更为准确、合理；在此情况下，一条执行路径中的stage可以至少包括上游stage的直接下游stage；通过对上游stage后续候选的多条执行路径进行选择，能够实现执行逻辑的动态调整，并实现对后续执行的直接下游stage的选择。

针对于上述根据统计信息对直接下游stage进行配置的各种情况，后文将分别进行说明，此处不再展开。

本申请实施例提供的分布式作业调整方法中，主节点获取用户提交的作业之后，可生成作业的执行计划，所述执行计划包括多个stage，所述多个stage包括上游stage以及所述上游stage的直接下游stage。在作业执行过程中，主节点可获取上游stage的输出数据的统计信息，从而根据所述统计信息，对直接下游stage进行配置。由于本申请实施例能够在作业执行过程中，基于上游stage的数据输出结果，动态调整下游stage的配置，以使得下游stage的配置能够适应于上游stage的实际执行结果，从而使得下游stage的并发度、资源等配置能够贴合作业的具体执行情况，提升了执行计划配置的合理性和准确性。可见，本申请实施例提供的分布式作业调整方法，能够在作业执行过程中对执行计划的配置进行动态调整，实现作业配置的动态调整效果，并使得执行计划的配置能够贴合作业的具体执行情况；进而基于动态配置的执行计划实现作业的具体执行，能够使得分布式系统更为合理高效的完成作业执行，实现显著提升分布式系统执行作业的性能。

下面对基于上游stage的输出数据的统计信息，配置直接下游stage的并发度的实现方案进行介绍。

针对静态执行计划，执行计划各stage的并发度可以是由主节点通过预估规则确定。例如，主节点在作业提交后，可以根据作业的源数据总量，使用预估规则，配置执行计划各stage的并发度（可以视为是配置DAG中各顶点的并发度），或者，基于用户指定的不同种类的stage的并发度，对执行计划各stage的并发度进行配置。然而，分布式作业处理的源数据复杂多样，主节点往往难以依赖预估规则，来配置适应不同作业的并发度，这导致执行计划各stage的并发度配置并不准确。例如，对于处理数据量较小的stage，如果静态配置了较大的并发度，将导致分布式系统的计算资源浪费；而对于处理数据量较大的stage，如果静态配置了较小的并发度，将导致stage的执行时间延长，甚至带来内存使用超限等各种错误，导致作业执行失败。因此在静态配置并发度的实现中，为避免stage配置的并发度较低而难以处理海量数据的可能，stage往往需要配置较高并发度，这导致作业在实际执行过程中，存在较多的计算资源浪费。例如，对于一个Map（映射）-Reduce（归约）的作业而言，即使上游Map阶段在实际运行过程中只产生1KB的输出数据，但下游Reduce阶段还是会由于静态配置了较高的并发度，而调度较高数量的工作节点来处理这1KB的数据，这无疑导致了不必要的计算资源浪费。

基于此，在作业执行过程中，基于上游stage的输出数据结果，为上游stage的直接下游stage配置并发度显得尤为必要。在一些实施例中，针对上游stage的直接下游stage，主节点可将上游stage输出数据中的Partition（数据分区），按照Partition数量均匀的原则，分配给直接下游stage的工作节点。例如，直接下游stage的每个工作节点会处理上游stage输出的连续多个Partition，并且每个工作节点处理的Partition数量相同。这种方式可称为基于Partition数量的Even Reduction（均匀还原）策略，其在每个Partition的数据量均匀的情况下，能够达到较为理想的效果；但是在实际环境下，数据分布特性多种多样并经常具有不均匀特性，对于非均匀数据（每个Partition的数据量并不均匀），上述方式可能导致直接下游stage的单个工作节点出现数据倾斜问题，即单个工作节点的处理数据量远大于其他工作节点，从而进一步导致工作节点的长尾问题，致使作业执行时间被不必要的拉长。例如，图3A示例性的示出了直接下游stage的处理数据分配示意图。如图3A所示，上游stage输出的每个Partition的数据量并不均匀，上游stage输出的Partition内的数值可以代表对应Partition的数据量，如果只是简单的合并多个指定数目的Partition给直接下游stage的单个工作节点，虽然每个工作节点处理的Partition数量一致（例如图3A中直接下游stage的每个工作节点都处理2个Partition），但这可能带来直接下游stage的工作节点在数据处理量上的分配不均匀：一方面，部分工作节点处理的数据不合理的偏小(甚至可能存在工作节点完全没有需要处理的数据)，另一方面，部分工作节点会因为合并了个数据量较大的Partition，而进一步加剧数据倾斜问题，导致工作节点的运行时间被拉长而形成长尾。

此外，由于Partition的数量可能在整体上与实际计算需要的耗时是正相关的，但是对于一些数据类型（例如整型），其数据压缩率较大，有可能出现输出数据经过压缩后，数据文件被严重压缩的情况。在这种情况下，可能少量的Partition数量就对应着大量的数据记录（即数量较少的Partition中记录较大量的数据记录），因此简单的基于上游stage的Partition数量来做直接下游stage的并发度配置，在实际作业中可能带来较大的不确定性。

基于上述情况，本申请实施例提供在作业执行过程中，基于上游stage的输出数据的统计信息，对直接下游stage的并发度进行适应动态调整的方案，并保障直接下游stage中每个工作节点的数据处理量趋近于均衡。作为可选实现，图3B示出了本申请实施例提供的分布式作业调整方法的另一流程图。该方法流程可由主节点执行实现，参照图3B，该方法流程可以包括如下步骤。

在步骤S310中，获取用户提交的作业。

在步骤S311中，生成所述作业的执行计划，所述执行计划包括多个stage，所述多个stage包括上游stage以及所述上游stage的直接下游stage。

在步骤S312中，至少对所述多个stage中首先执行的stage初始化配置并发度。

主节点可对执行计划的并发度进行初始化配置。在一些实施例中，主节点可根据作业的源数据总量，使用预估规则，对执行计划的并发度进行初始化配置；或者，主节点可基于用户指定的不同种类的stage的并发度，对执行计划的并发度进行初始化配置。

在本申请实施例中，主节点可基于上游stage输出的数据量，来配置直接下游stage的并发度；基于此，由于执行计划中首先执行的stage没有上游stage，因此主节点在对执行计划的并发度进行初始化配置时，应至少对首先执行的stage初始化配置并发度，以使得首先执行的stage能通过初始化配置的并发度执行作业；而对于执行计划中非首先执行的stage，由于非首先执行的stage一般都具有上游stage，因此非首先执行的stage可以作为某一个或多个上游stage的直接下游stage，从而基于上游stage的输出数据的统计信息，来配置并发度。

由于执行计划中非首先执行的stage，能够在作业执行过程中动态调整并发度，因此在初始化配置并发度时，本申请实施例并不一定需要对非首先执行的stage初始化配置并发度。当然，本申请实施例也可支持对非首先执行的stage初始化配置并发度，本申请实施例对此并不设限。在一个示例中，结合图1C所示，V1作为首先执行的stage，需要初始化配置并发度，而V2、V3和V4均存在上游stage，本申请实施例并不限制一定要对V2、V3和V4初始化配置并发度。

在步骤S313中，在作业执行过程中，确定上游stage的输出数据的数据量分布信息，所述数据量分布信息包括输出数据对应的多个数据分区的数据量。

在作业执行过程中，主节点可按照上游stage的并发度，调度工作节点对上游stage的输入数据进行处理，从而上游stage调度的工作节点可在处理输入数据之后，产生上游stage的输出数据。上游stage的输出数据可以被切分为多个数据分区（Partition）。输出数据的数据分区的数据量可作为输出数据的数据量分布信息，即输出数据的数据量分布信息可以表示输出数据的每个数据分区所分布的数据量，该数据量分布信息可以携带在输出数据的统计信息中。

在本申请实施例中，上游stage的输出数据的数据量分布信息可以被主节点采集。

在一些实施例中，步骤S313中所指的上游stage可以是首先执行的stage，也可以是非首先执行的stage。需要说明的是，如果上游stage为首先执行的stage，则上游stage可基于初始化配置的并发度，调度工作节点处理数据；如果上游stage为非首先执行的stage，则上游stage可基于本申请实施例提供的方案动态调整并发度之后，再调度工作节点处理数据。

在步骤S314中，根据直接下游stage的工作节点对应的理想数据量（Ideal DataSize）以及所述数据量分布信息，确定为直接下游stage的工作节点分配的处理数据量。

在主节点采集上游stage的输出数据的数据量分布信息之后，主节点可基于该数据量分布信息，为直接下游stage的工作节点分配处理数据量。本申请实施例可在直接下游stage的工作节点分配处理数据量完成后，自动实现配置直接下游stage的并发度。

在一些实施例中，本申请实施例可预先设置直接下游stage的工作节点对应的理想数据量，工作节点的处理数据量如果超过理想数据量，则将超出工作节点的处理负荷，导致工作节点执行失败的可能性增大，因此在为直接下游stage的工作节点分配处理数据时，应使得处理数据的数据量贴近但不超出理想数据量。

基于所述数据量分布信息中表达了上游stage的数据分区的数据量，主节点在为直接下游stage的工作节点分配处理数据量时，可基于理想数据量以及所述数据量分布信息，确定直接下游stage的各工作节点分配的处理数据量，并使得为工作节点分配的处理数据量不超出所述理想数据量。

在一些实施例中，主节点可将上游stage输出的连续且总数据量不超出理想数据量的数据分区，分配给直接下游stage的一个工作节点，从而使得直接下游stage的工作节点能够分配到连续且总数据量不超出理想数据量的数据分区。在进一步的一些实施例中，主节点在将连续且总数据量不超出理想数据量的多个数据分区，分配给直接下游stage的一个工作节点的基础上，可保障各个直接下游stage分配的处理数据量尽可能的均衡。

在一个示例中，图3C示出了数据分区（Partition）分配给直接下游stage 的示例图。如图3C所示，上游stage输出的Partition具有多个，图3C中表示Partition的方框内的数值为Partition的数据量；可以看出，主节点在为直接下游stage分配处理数据量时，是将连续且总数据量不超出理想数据量的数据分区分配给直接下游stage的一个工作节点，并保障每个工作节点的处理数据量趋近于均匀分布。例如，直接下游stage的4工作节点分配的处理数据量分别为15、16、19和10。可以看出，在为直接下游stage的工作节点分配的处理数据量之后，主节点即可完成配置直接下游stage的并发度，例如，图3C中每个工作节点完成处理数据量的分配之后，主节点可确定需要4个工作节点（并发度为4）来处理上游stage的输出数据。通过本申请实施例提供的方式来配置并发，可避免直接下游stage的某一工作节点的处理数据量虽然未超出理想数据量，但相比于其他工作节点过高或过低的情况，从而使得各工作节点的处理数据量能够趋近于均衡、合理。

在步骤S315中，根据直接下游stage中分配处理数据量的工作节点的数量，配置直接下游stage的并发度。

主机节点在确定直接下游stage的工作节点分配的处理数据量之后，即可基于分配处理数据量的工作节点的数量，完成直接下游stage的并发度配置。

本申请实施例提供的分布式作业调整方法，可在生成作业的执行计划之后，至少对执行计划中首先执行的stage初始化配置并发度，从而使得作业能够实际执行。在作业执行过程中，主节点可确定执行计划的上游stage的输出数据的数据量分布信息，该数据量分布信息能够表达输出数据对应的多个数据分区的数据量；从而基于直接下游stage的工作节点对应的理想数据量，以及该数据量分布信息，确定为直接下游stage的工作节点分配的处理数据量；进而，主节点可根据直接下游stage中分配处理数据量的工作节点的数量，配置直接下游stage的并发度，并使得直接下游stage中的各工作节点能以不超出理想数据量的数据量来执行作业，降低了直接下游stage中单个工作节点的处理数据量过高而导致执行失败的概率。本申请实施例能够在作业执行过程中，基于上游stage的输出数据的数据量数据量分布信息，以及直接下游stage的工作节点对应的理想数据量，为直接下游stage的工作节点分配处理数据量，并实现自动配置直接下游stage的并发度，达到基于上游stage的输出数据结果，对直接下游stage的并发度进行动态自适应调整的效果，提升了直接下游stage的并发度配置的精确性和合理性，极大的减少了不合理的并发度配置而带来的计算资源浪费情况，能够显著提升分布式系统的性能。

本申请实施例提供的方案可称为基于Partition数据量的Fair-Parallelism（均匀相似）策略。作为可选实现过程，以上游stage实现数据shuffle（分布式作业执行中，对数据记录按照特定Hash函数计算散列值，并发送到对应工作节点的过程）为例，则主节点可获取上游stage的工作节点在数据shuffle之后，输出的Partition的数据量分布信息（每个Partition的数据量）。主节点可以按照Partition聚合来为直接下游stage的工作节点分配处理数据量，例如，通过将连续且总数据量不超过理想数据量的多个Partition分配给直接下游stage的一个工作节点。在上述分配过程中，如果分配给一个工作节点的多个Partition的数据总量达到理想数据量，则自动将后续连续且总数据量不超过理想数据量的Partition分配给下一个工作节点，以此类推，直至上游stage输出的所有Partition分配完毕为止。直接下游stage实际的并发度，可以在上游stage所有的Partition均分配完毕后自动确定，即基于直接下游stage中分配处理数据量的工作节点数量，确定直接下游stage的并发度。本申请实施例可将上游stage输出的Partition尽量均匀的分配给直接下游stage的每个工作节点，实现更为精准、合理的为直接下游stage配置并发度，并且避免了单个工作节点的长尾问题。

需要说明的是，在步骤S315为直接下游stage配置并发度之后，如果直接下游stage还通过连接边输入其他下游stage（即直接下游stage还具有下游stage），则步骤S315当前配置并发度的直接下游stage可成为上游stage，并基于本申请实施例提供的方案，继续为后续的下游stage调整并发度，直至执行计划的各stage均在作业执行过程中完成并发度的调整。

在进一步的一些实施例中，本申请实施例可进一步通过技术完善，以减少直接下游stage的工作节点出现数据倾斜的情况，从而满足作业执行的各种数据特点需求，具体来说：

当连续多个Partition的数据量都非常小时，可能会出现多个Partition的数据量加和还小于理想数据量的情况，这种极端情况下可能导致大量的Partition被分配到单个工作节点进行处理，而直接下游stage的工作节点如果顺序操作大量的Partition，这可能导致读写性能的回退。基于此，本申请实施例可以设置单个工作节点允许分配的Partition数量上限，从而在规避工作节点处理的数据量为零的前提下，对于加入工作节点的Partition数量上限进行控制。

当工作节点的运行时间与处理数据的大小的相关性较小，而与数据其它特征（比如数据记录的数目等）相关时，如果根据Partition的数据量大小来为工作节点分配处理数据，则可能将数据量较小但存在大量数据记录的Partition分配到单个工作节点，从而导致工作节点的运行时间被拉长，造成作业执行的瓶颈；此外，还需要考虑工作节点本身涉及的单位数据记录来计算复杂度，这可能与工作节点的算子数目，以及算子特点等因素相关，这些信息也需要作为计算并发度的考虑因素。基于此，在使用Partition的数据大小作为基准，来分配工作节点的处理数据量以外，本申请实施例可进一步结合Partition的Record数量，工作节点的算子数目，以及算子复杂度等特征，对分配给工作节点的处理数据量进行二次调整，并选取在这几个维度上得到的并发度较大的结果，从而完成直接下游stage的最终并发度的配置。基于此，在步骤S315的可选实现中，本申请实施例可进一步根据直接下游stage中分配处理数据量的工作节点的数量，分配给工作节点的Partition的Record数量、工作节点的算子数目、以及算子复杂度，完成直接下游stage的最终并发度配置。

本申请实施例在动态调整作业执行的并发度时，能够结合多个维度的数据特性，统计计算执行结果，对分布式系统引擎动态执行方式提供了更多的优化方向；本申请实施例应用于实际生产环境中，能够对生产作业整体的执行并发度带来数量级别的降低，显著提升分布式系统中工作节点的运算效率，极大程度上避免计算资源的浪费，以及工作节点频繁调度拉起的消耗。相比于简单直接的Even-Reduction策略，本申请实施例提出的Fair-Parallelism策略，能够有效的避免Even-Reduction策略下可能引入的严重数据倾斜，使得分布式作业中所有工作节点处理的数据量尽可能分布均匀，避免出现突出的长尾或者短板，可以避免长尾成为运行时间的瓶颈，也可以防止工作节点频繁处理较小的数据而导致反复启动工作节点造成的资源浪费。进一步的，通过在合并数据量较小的Partition时，限制连续合并的Partition数量上限，防止Partition过度合并引起下游stage在读数据性能的下降。进一步的，依据统计作业运行期间，每个工作节点生成的详细数据信息（包括数据量以及Record数量），本申请实施例可结合Record数量，算子数目与算子复杂度等信息，来做出更加均衡完善的并发度调整。可见，本申请实施例能够显著提升分布式系统的性能。

基于上游stage的输出数据的统计信息，本申请实施例提供了将多个Partition进行动态合并的方案。同时，对于一个数据量较大的Partition，本申请实施例也提供了Partition的拆分方案。下面对具体实现方案进行详细介绍。

对于数据编排和shuffle而言，有效的数据编排和shuffle，是分布式系统能够水平扩展的重要前提。对于Map-Reduce的执行阶段，高效的数据shuffle就一直是分布式作业执行性能的重要性能指标之一。然而全连接数据shuffle (full-shuffle)，只有在数据均匀分布的理想场景下，才能比较高效的执行。而在实际生产作业中，数据的分布往往并不均匀，数据的倾斜特性可能会在full-shuffle模式下被进一步放大，从而导致个别工作节点运行时间的大幅拉长而造成严重长尾。

需要说明的是，shuffle这个概念来自于Map-Reduce的计算模型，虽然现代的作业执行框架已经演进到了使用更通用的基于DAG来描述，但是Map-Reduce的运行模式依然是DAG中各个子图的重要描述。而众多更复杂DAG拓扑中，各个连接边上的数据流动，也可以通过各种shuffle模型来描述；例如在分布式执行框架中，DAG的连接边的一个重要物理属性就是边上数据的传输。边上数据的传输不仅可以使用full-shuffle，还允许引入更加动态和智能化的数据编排方式，并以此来解决许多实际场景中full-shuffle面临的问题。

以动态分区写入为例，对于一个典型的分布式数仓系统而言，分区表的使用是极为广泛的。将数据写入分区表，通常有静态分区写入和动态分区写入两种方式；对于需要写入分区的值能够事先指定时，直接使用静态写入指定分区是较为简单的方式；对于分区值无法事先判断，尤其是一个查询产出的数据分布在多个分区的时候，则使用动态分区(Dynamic Partition)写入，也就是数据写入Partition的值，将会在作业运行过程中根据具体产出数据来获取。比如在下面的SQL（Structured Query Language，结构化查询语言）语句中，数据写出指定为country这个分区列名，但是具体会写到哪些分区，其对应的分区数值则是在运行中获取的：

INSERT OVERWRITE TABLE Partitioned_sales Partition(country)；

SELECT country, item, price from sales。

在分布式系统中，由于分区数目的不确定，数据分布特性的多种多样以及不均匀特性，要实现通用的高效动态分区写入，一直是一个挑战性的问题。对此，分布式系统需要能既避免作业产生严重长尾，同时又不会由于小文件的大量产生而对存储系统带来严重的负担。

在一些实施例中，主节点可通过单Map stage的执行计划来实现动态分区。在此实现中，主节点生成的执行计划只包含一个Map stage，该一个Map stage可通过一个或多个工作节点执行task。Map stage的每个工作节点读取数据后，可按照分区值（例如上述示例中的country）来写出文件。也就是，一个工作节点如果处理了不同的country值对应的数据，就会产生对应的不同路径的文件。一个Map stage的执行计划简单而直观，但是对于实际大规模分布式系统而言会带来各种隐患，其中最突出的就是小文件碎片化的问题。在一个Map stage的执行计划中，假设Map stage的并发度为M，用户数据中country的取值可能为N个。在数据随机分布的情况下，因为Map stage的每个工作节点独立输出，最终可能造成每个分区都会写出M个文件。所以这种执行方式最终将会可能产生M * N个数据文件，而这其中有可能存在大量的小文件。这些大量碎片化小文件的存在，对于一个分布式系统会带来较大的负面影响：

对于分布式系统的存储而言，大量小文件的管理，需要消耗庞大的Meta（元）信息；极端情况下，甚至会打爆整个分布式系统的主节点，导致整个分布式系统不可用；同时从存储效率而言，存在碎片化的小文件也会带来较差的存储压缩比，占用更多存储空间；

数据生成后总是需要被处理的，上游stage产出小文件后，下游stage的计算消耗会变大，同时实际数据读取效率也会更加低下；

对于Map stage而言，由于要写出M * N的小文件，因此就要创建M * N的写服务（writer），每个writer保留一定的Memory Buffer（内存缓存）进行Encoding（编译）、Compress（压缩）等；而如果Buffer过大，则Map stage使用内存会过大，Buffer过小则导致Encoding和Compress的效果较差。

在另一些实施例中，主节点可基于全连接的Reshuffle方式来实现动态分区。为避免产生上述的小文件问题，主节点可在一个执行阶段产生输入数据后，先根据PartitionKey（键）进行一个全连接的Reshuffle，即，把相同Partition的数据聚合到一个工作节点上再写出。通过这种方式保证每个Partition的分区数值只产生一个分区文件。但这种强制限制，在降低了文件数的同时，也会带来另外一个负面效应：数据倾斜。

需要说明的是，对于执行阶段产生的数据而言，数据的分布是各种各样的，并且动态分区的数据分布在Query执行前无法获取。比如在上述的SQL语句的示例中，如果对某一平台的用户数据进行不同国家的分区，那么本国分区上的数据毫无疑问会远大于其他分区，这导致本国分区上的数据对应的工作节点产生严重长尾，导致整个作业的运行时间被大幅度拉长。对于倾斜严重的数据，这种长尾可能带来数百甚至上千倍的作业延迟，对于整个分布式系统的资源利用率也有非常坏的影响。

为了能缓解这个问题，Reshuffle的实现实际上还能通过额外引入了一个Randomshuffle Key（随机shuffle键）来进行优化。比如通过取值在[0, 9]的一个Reshuffle key，将数据随机打散到10个分区上来减少数据的倾斜程度。然而这样的解决方案仍然存在一定的问题：在数据倾斜严重的情况下，即使将数据切分成10份，切分后的数据仍然可能还是存在倾斜问题，甚至可能由一个数据长尾情况变成10个程度稍轻的数据长尾情况；对于没有倾斜的数据或者数据量本身很小的分区，如果同样切分成10份，又带来了最终文件数的增加（10 * N）；分布式系统强行加入Random Key的shuffle方式，可能破坏数据的幂等性，在分布式系统中，如果发生工作节点重跑，存在产生数据正确性的风险。

基于上述情况，本申请实施例依照上游stage（例如Map stage）实时产生的数据分布情况，进行智能的动态数据编排，在保证写出数据均衡性的同时，解决小文件问题，从而克服上述两种方案的缺点。

首先用图4A来简单描述一下shuffle方式（为了方便理解，这里省略了按照Reduce并发取模进行shuffle的细节），图4A示出了数据shuffle的示例图。如图4A所示，图4A中，相同线性的方框表示Map阶段产生的shuffle数据中相同Partition Key的数据；例如细虚线的方框、细实线的方框、粗虚线的方框、粗实线的方框分别表示相同Partition Key的数据。而方框内的数值则表示对应的数据量。在经过一次shuffle之后，同一Partition Key的数据将交给Reduce阶段的同一个工作节点进行处理。通过图4A可以看出，Reduce阶段的工作节点R#0处理的数据量为8，工作节点R#1处理的数据量为2，工作节点R#2处理的数据量为43，工作节点R#3处理的数据量为16；工作节点R#2处理的数据存在严重的数据倾斜，这导致工作节点R#2在执行Reduce阶段的任务时将存在非常严重的长尾。

对于动态分区插入等场景，同一分区数据只需要保证写到同一目录下，而不需要保证写到同一个数据文件。因此在shuffle过程中，并不需要保证所有相同Partition Key的数据，都交给同一个reduce的工作节点来处理。基于这个特点，本申请实施例可以对Map阶段产生的数据量较大的Partition进行自动拆分，然后交给Reduce阶段的多个工作节点进行处理。

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

在步骤S410中，获取用户提交的作业。

在步骤S411中，生成所述作业的执行计划，所述执行计划包括多个stage，所述多个stage包括上游stage以及所述上游stage的直接下游stage。

在一些实施例中，上游stage例如Map stage。直接下游stage例如Reduce stage。

在步骤S412中，在作业执行过程中，获取上游stage的输出数据的Statistics，所述Statistics包括：输出数据的Partition的数据量分布式信息。

在一些实施例中，上游stage的工作节点（一个或多个）可在执行task的过程中以及执行结束之后，将输出数据的Statistics上报给主节点。所述Statistics可以包括：输出数据的Partition的数据量分布信息，该数据量分布信息可以指示输出数据的每个Partition的数据量。在进一步的一些实施例中，所述Statistics还可以包括：输出数据的数据量（例如输出数据分别在数据压缩前和压缩后的数据量）、输出数据中每个Partition的Record数量等。

在步骤S413中，根据理想数据量，将上游stage的输出数据中数据量大于理想数据量的Partition进行拆分。

本申请实施例可预先设置直接下游stage的工作节点对于Partition的理想数据量。需要说明的是，执行阶段的不同stage作为直接下游stage时，所设置的理想数据量可以不同。主节点在获取上游stage的输出数据的Statistics之后，可确定输出数据中每个Partition的数据量。从而基于直接下游stage的工作节点对于Partition的理想数据量，判断输出数据中是否存在数据量大于理想数据量的Partition；对于输出数据中数据量大于理想数据量的Partition，本申请实施例可对该Partition进行拆分，并使得拆分后的Partition的数据量不大于理想数据量。

在一些实施例中，本申请实施例可根据理想数据量，对输出数据中数据量大于理想数据量的Partition进行拆分，使得拆分后的Partition的数据量不大于理想数据量且趋近于均匀分布。

在步骤S414中，将拆分后的Partition分配给直接下游stage，且一个拆分后的Partition配置为由直接下游stage的一个工作节点执行。

在对输出数据的Partition进行拆分后，本申请实施例可将拆分后的Partition分配给直接下游stage，并且，一个拆分后的Partition配置为由直接下游stage的一个工作节点执行，从而实现为直接下游stage配置需要处理的数据。

在进一步的一些实施例中，如果输出数据中存在数据量小于理想数据量的Partition，则本申请实施例可将输出数据中总数据量不大于理想数据量的至少两个Partition进行合并，该至少两个Partition中的各个Partition的数据量均小于理想数据量，从而将合并的Partition分配给直接下游stage，且一个合并的Partition配置为由直接下游stage的一个工作节点执行，以实现直接下游stage的计算资源的高效利用。

本申请实施例通过在作业执行过程中，获取上游stage的输出数据的Statistics，从而基于Statistics中指示的输出数据的每个Partition的数据量，对数据量大于理想数据量的Partition进行拆分，保障拆分后的Partition的数据量不大于理想数据量。进而将拆分后的Partition分配给直接下游stage，且一个拆分后的Partition配置为由直接下游stage的一个工作节点执行，实现了为直接下游stage的工作节点配置需要处理的数据。本申请实施例可依据上游stage的输出数据的Statistics，对配置给直接下游stage的Partition进行动态调整，保障直接下游stage中每个工作节点处理的一个Partition的数据量不会超过理想数据量，使得直接下游stage的工作节点处理的数据能够趋近于均匀分布，降低了直接下游stage的数据倾斜情况，避免了直接下游stage的个别工作节点由于需要处理较大数据量的Partition，而导致运行时间的大幅拉长的长尾问题。可见，本申请实施例能够使得直接下游stage的工作节点处理的数据趋近于均匀分布，降低直接下游stage的数据倾斜情况和工作节点的长尾问题，显著提升了分布式系统的性能。

在一些实施例中，针对于Map-Reduce阶段，Map可以认为是上游stage，Reduce可以认为是Map的直接下游stage。Map阶段的每个工作节点在运行过程中以及运行结束后，均可将输出的shuffle数据的Statistics上报给执行引擎（执行引擎可以是主节点）；例如，Map阶段可能存在一个或多个工作节点来执行task，每个工作节点执行task的过程中以及执行结束之后，均可将输出的shuffle数据的Statistics上报给执行引擎。在一些实施例中，shuffle数据的Statistics例如：shuffle数据在压缩前和压缩后的数据量、shuffle数据的每个Partition的数据量，以及Partition包含的Record数量等。

在一些实施例中，本申请实施例可定义Reduce阶段的一个Partition对应的理想数据量。对于Map阶段输出的任一Partition而言，如果Partition的数据量大于理想数据量，则本申请实施例可将Partition按照理想数据量进行拆分，并尽量保证Reduce阶段每个工作节点处理的数据量是均匀的；如果Partition的数据量小于理想数据量，则本申请实施例可将数据量小于理想数据量的多个Partition进行合并，并保障合并后的Partition的数据量不大于理想数据量。

在一个实现示例中，图4C示出了本申请实施例进行Partition拆分的示例图。结合图4C所示，Map阶段输出的4个shuffle数据可分成4个Partition（P#0、P#1、P#2和P#3），例如，4个shuffle数据中同一线性表达的数据聚合成一个Partition，其中，shuffle数据中的细虚线对应的数据聚合成P#0，细实线对应的数据聚合成P#1，粗虚线对应的数据聚合成P#2，粗实线对应的数据聚合成P#3。如图4C所示，4个Partition的数据量大小依次为8、2、 43和16。假设定义Reduce阶段的一个Partition对应的理想数据量为10，则P#0、P#1的数据量均小于10，且P#0、P#1合并后的数据量并不超出理想数据量10，因此P#0、P#1可合并为一个Partition，并分配到Reduce阶段的一个工作节点R#0进行处理。而由于P#2的数据量43大于理想数据量10，则P#2可按照理想数据量尽可能均匀的拆分为多个Partition，且拆分的每个Partition的数据量不大于理想数据量，如图4C所示，P#2可按照理想数据量尽可能的拆分为5个Partition，并分配给Reduce阶段的5个工作节点R#1至R#5进行处理，其中，R#1至R#4每个分配数据量为9的Partition，R#5分配数据量为7的Partition。同理，P#3的数据量由于大于理想数据量，因此被均分拆分为2个Partition，并分配到Reduce阶段的2个工作节点R#6和R#7进行处理。

上述对于Map阶段大于理想数据量的Partition进行拆分，小于理想数据量的Partition进行合并的机制可称为Adaptive（自适应）shuffle机制。在进一步的一些实施例中，基于Adaptive shuffle机制，Reduce阶段最终写出的文件数将主要依赖于输入的Partition数据量的大小，以及理想数据量的大小配置。假设输入Reduce阶段的理想Partition数量（Ideal Parallelism）定义为：shuffle数据总量除以理想数据量；则经过本申请实施例的Adaptive shuffle机制之后，Reduce阶段最终生成的文件数的最大值为Ideal Parallelism加上N。因此，如果要保证每个有输出数据的Partition上至少存在一个数据文件的话，只有数据量大于理想数据量的Partition经过拆分后会使文件数有所增加。但这种拆分产生的文件大小均为Partition的量级，而不是碎片化的小文件。基于此，在理想数据量的大小配置合理的情况下，无论产生多少文件，对于分布式系统都是合理的；即只要文件大小合适，海量的数据可以通过多一点的文件来存储。

也就是说，基于Adaptive shuffle机制，Reduce阶段的每个工作节点处理的数据量，不会超过给定的理想数据量，同时每个小于理想数据量的Partition均可在Reduce阶段由一个工作节点输出一个文件。这就从根本上，同时解决了大量小文件产生以及可能的数据倾斜问题，能够比较好的解决动态分区场景上面临的两难问题。此外还要说明的是，使用Adaptive shuffle机制，能够避免需要添加额外的Random shuffle Key来减少数据倾斜的情况。由于本申请实施例提供的Adaptive shuffle机制在整个过程是确定性，可重入的，因此在不稳定的分布式系统环境上，能从根本上保证在各种重试发生时，输出数据的正确性。

本申请实施例通过结合执行引擎（主节点）提供的作业运行期间的统计信息收集能力，以及多作业执行图和shuffle模式的动态调整能力，实现了自适应的数据编排；能够基于上游stage的输出数据的数据特性，来对输出数据进行智能化的分配与编排，包括倾斜的数据分区的自动拆分，以及多个数据量较大的小分区的合并，从根本上解决了在数据shuffle过程中可能带来的数据倾斜以及工作节点的长尾问题，同时避免了其他无shuffle方案下的数据碎片化问题，能够显著的提升分布式系统的性能。

除了对Partition合并和拆分的通用优化之外，本申请实施例针对特定的场景进行了专门性的优化。下面以Join场景为例，对基于上游stage的输出数据的统计信息，将上游stage输出的Partition拆分后，分配给直接下游stage来进行Join操作的实现方案进行介绍。

在分布式系统的作业执行过程中，Join操作是最常见、同时也是处理复杂度较高的操作之一。由于其涉及到多路数据的计算和处理，除了分布式系统中普遍需要解决的挑战之外，不同路数据在Join算子上发生交互，也衍生了更多数据处理的场景。然而，数据分配不均匀等情况，将导致Join操作出现数据倾斜和长尾问题，这成为分布式系统中比较常见且一直没有被系统化解决的问题。

图5A示例性的示出了分布式SQL的Join过程的示例图。如图5A所示，上游stage提供给下游stage的两路输入数据（如图 5A所示M1和M2）在下游stage进行Join操作，其中，M1和M2的两路输入数据可按照Partition写出，并且按照分区编号被shuffle到J3不同的工作节点上去实现数据Join。其中，中间数据会按照分区编排，被保存在物理介质上。

图5A展示的是上游stage的Partition数据分布比较均匀的情况，但是在实际的query（查询）和数据处理中，上游stage的Partition数据的分布很可能存在倾斜。图5B示出了分布式SQL的Join过程的另一示例图。如图5B所示，M1提供给J3的输入数据中的Partition1（分区编号为1的Partition）存在严重的数据倾斜，同时，M2提供给J3的输入数据中Partition1存在轻微的数据倾斜，在这种情况下，J3对Partition1进行Join操作时，J3的工作节点将存在严重的长尾，甚至由于内存超限而导致作业失败。

为解决上述问题，图5C示出了本申请实施例提供的分布式作业调整方法的又一流程图。该方法流程可由主节点执行实现，参照图5C，该方法流程可以包括如下步骤。

在步骤S510中，获取用户提交的作业。

在步骤S511中，生成所述作业的执行计划，所述执行计划包括多个stage，所述多个stage包括Join stage以及Join stage的直接上游stage，所述直接上游stage向Joinstage提供多路输入数据；其中，一路输入数据包括多个Partition。

在Join操作的情况下，Join stage作为某stage的直接下游stage，可输入该stage提供的多路输入数据，一路输入数据可以包括多个Partition。

在步骤S512中，在作业执行过程中，若任一路输入数据中存在数据倾斜的目标Partition，将所述目标Partition拆分为多个Partition，将所述多个子Partition分配给Join stage的多个工作节点。

在作业执行过程中，主节点可获取任一stage的输出数据的Statistics，基于Statistics，如果直接上游stage提供给Join stage的任一路输入数据中存在数据倾斜的Partition（为便于说明，存在数据倾斜的Partition可称为目标Partition），则本申请实施例可将目标Parititio拆分为多个Partition，并将多个Partition分配给Join stage的多个工作节点。

在一些实施例中，本申请实施例可针对任一路输入数据中的Partition，判断Partition的数据量是否大于第一数据量阈值，如果Partition的数据量大于第一数据量阈值，则确定Partition为存在数据倾斜的目标Partition。

在一些实施例中，在目标Partition进行拆分时，本申请实施例可基于第二数据量阈值，对目标Partition进行拆分，以使得目标Partition拆分后的多个子Partition的数据量均匀分布并且每个子Partition的数据量不大于第二数据量阈值。在进一步的一些实施例中，第二数据量阈值小于第一数据量阈值，第一数据量阈值和第二数据量阈值的具体数值可根据实际情况定义，本申请实施例并不设限。在一种实现示例中，第二数据量阈值可以例如前文描述的理想数据量。

在一些实施例中，将目标Partition拆分的多个子Partition，分配给Join stage的多个工作节点时，一个Partition可分配给Join stage的一个工作节点。

在步骤S513中，将其他路输入数据中与所述子Partition属于相同分区编号的Partition，广播到所述子Partition分配的工作节点。

为在Join stage能够实现正确的Join操作，本申请实施例在将某路输入数据的目标Partition拆分为多个子Partition，并将子Partition分配到Join stage的工作节点之后，针对目标Partition拆分后的各个子Partition，本申请实施例可确定其他路输入数据（多路输入数据中与该某路输入数据不同路的输入数据）中，与子Partition属于相同分区编号的Partition，从而将所确定的Partition广播到子Partition分配的工作节点，以使得子Partition与其他路输入数据中属于相同分区编号的Partition能够在Join stage进行正确Join。

在一些实施例中，直接上游stage提供的多路输入数据可以至少包括第一路输入数据和第二路输入数据，第一路输入数据和第二路输入数据可以是多路输入数据中的任意两路输入数据，多路输入数据的路数可以大于二，而不限于只有两路输入数据。在此情况下，多路输入数据中存在目标Partition可能存在如下几种情况。

第一种情况，多路输入数据中有一路输入数据存在一个目标Partition；在第一种情况下，以多路输入数据中的第一路输入数据中存在一个目标Partition为例，主节点可将第一路输入数据中的一个目标Partition拆分为多个子Partition，并将各子Partition分配给Join stage的工作节点；而其他路输入数据（多路输入数据中除第一路输入数据外的输入数据）中与目标Partition属于相同分区编号的Partition，将被广播到各子Partition分配的工作节点。

作为一个实现示例，针对于上述第一种情况，图5D示出了Join过程的再一示例图。如图5D所示，图5D展示了两路Join的输入（M1和M2），且其中一路存在数据倾斜的场景。假设执行Join的工作节点上不需要额外维护Partition、Sort等特性的算子，则主节点在统计了M1和M2输出的各个Partition的数据量后，可判断M1输出的Partition1为存在数据倾斜的目标Partition，从而将M1输出的Partition1拆分成多个子Partition。图5D中，M1的Partition1所在方框中的一个小方框可表示拆分的一个子Partition。M1的Partition1拆分成的多个子Partition，可分别分配到Join阶段的多个工作节点上进行Join处理。同时，为了在Join阶段，能够对于拆分后的子Partition进行正确的Join操作，主节点需将M2中与目标Partition相同分区编号的Partition，分别广播给各子Partition所分配的工作节点；例如，主节点需将M2所产生的Partition1广播给M1的各子Partition分配的工作节点。通过向Join阶段的多个工作节点广播M1和M2相同分区编号的Partition，能够在目标Partition拆分为多个子Partition的情况下，保障相同分区编号的数据可以被正确的Join并产出结果。

第二种情况，多路输入数据中有一路输入数据存在多个目标Partition；在第二种情况下，以多路输入数据中的第一路输入数据存在多个目标Partition为例，针对第一路输入数据中每个目标Partition的处理与第一种情况同理。在一些实施例中，针对第一路输入数据中的每个目标Partition，主节点可将目标Partition拆分为多个子Partition，并将目标Partition的子Partition分配给Join stage的工作节点，同时，其他路输入数据中与目标Partition属于相同分区编号的Partition，将被广播到各子Partition分配的工作节点。只不过在第一路输入数据存在多个目标Partition的情况下，每个目标Partition均需要按照上述方式进行处理。

也就是说，若第一路输入数据中存在一个目标Partition或多个目标Partition，则针对任一个目标Partition，本申请实施例可将该目标Partition拆分为多个子Partition，并将该目标Partition的各子Partition分配给Join stage的工作节点，同时，将其他路输入数据中与该目标Partition属于相同分区编号的Partition，广播到该目标Partition的各子Partition分配的工作节点。

进一步结合图5D所示，如果Join的单路输入中多个Parition均发生数据倾斜，则可对发生数据倾斜的每个Parition均进行拆分，并向Join阶段的工作节点广播另一路相同分区编号的Parition，以实现在Join阶段将拆分后的子Parition与另一路相同分区编号的数据进行正确Join。例如，假设图5D中，M1输出的Partition3也存在数据倾斜，则M1输出的Partition3也可拆分成多个子Partition，并分别分配到Join阶段的多个工作节点，同时，M2中的Partition3会被分别广播到M1的Partition3对应的子Partition分配的工作节点。

第三种情况，多路输入数据中有至少两路输入数据均存在一个目标Partition；在第三种情况下，以第一路输入数据和第二路输入数据均存在一个目标Partition为例，主节点可将第一路输入数据中的一个目标Partition拆分为多个子Partition，并将拆分的各子Partition分配给Join stage的工作节点；同时，主节点可将第二路输入数据中的一个目标Partition拆分为多个子Partition，并将拆分的各子Partition分配给Join stage的工作节点。针对于第一路输入数据和第二路输出中相同分区编号的子Partition，需要分别将子Partition广播到相同分区编号的其他路子Partition所分配的工作节点。例如，将第一路输入数据的子Partition，广播到第二路输入数据的相同分区编号的子Partition所分配的工作节点，将第二路输入数据的子Partition，广播到第一路输入数据的相同分区编号的子Partition所分配的工作节点。

图5E示出了Join过程的又一示例图。如图5E所示，M1和M2的Partition1均存在数据倾斜，左路M1输出的Partition1需要被拆分成多个子Partition，右路M2输出的Partition1需要被拆分成多个子Partition，则M1的Partition1拆分的多个子Partition会被分配到Join阶段的多个工作节点，M2的Partition1拆分的多个子Partition也会被分配到Join阶段的多个工作节点，且一个子Partition分配到一个工作节点。图5E中M1、M2的Partition1所在方框中的一个小方框可表示拆分的一个子Partition。为保障能够对M1和M2相同分区编号的子Partition进行正确Join，主节点可将M1的Partition1拆分的多个子Partition，广播到M2的相同分区编号的子Partition所分配的工作节点，同理，主节点可将M2的Partition1拆分的多个子Partition，广播到M1的相同分区编号的子Partition所分配的工作节点。

第四种情况，多路输入数据中有至少两路输入数据均存在多个目标Partition；在第四种情况下，以第一路输入数据和第二路输入数据均存在多个目标Partition为例，针对第一路输入数据和第二路输入数据中一个相同的目标Partition的处理过程与第三种情况同理。只不过在第一路输入数据和第二路输入数据均存在多个目标Partition的情况下，第一路输入数据和第二路输入数据每个相同的目标Partition均需要按照上述方式进行处理。

上述示例是以Join阶段的工作节点主要实现单纯的Join连接，而不包含数据sorted（排序）/Partitioned（分片）属性的算子。而在实际作业中，作为SQL语法中最为复杂和灵活的Join操作，其工作节点是有可能包含各种各样的算子。在这种情况下，对于输入Join的Partition发生数据倾斜时，除需要利用上述示例的方式将Partition进行拆分外，还需在完成数据Join之后加入一个union（联合）操作，从而实现将拆分后的子Partition在Join之后重新收拢起来。在数据的特殊属性需要得到保留（比如数据不是直接落盘，而是还有下游操作/stage）的时候，需要通过union操作来保证后续执行的正确性。

图5F为在图5D基础上进一步示出的union操作的示例图。结合图5D和图5F所示，在Join的单路输入M1的Parition1发生数据倾斜时，除利用图5D所示过程实现对M1的Parition1对应的子Parition，和M2的Parition1进行Join操作外，还需将各子Parition的Join操作结果进行联合，从而生成一个新的Parition1。

图5G为在图5E基础上进一步示出的union操作的示例图。在Join的多路输入M1和M2的Partition1均存在数据倾斜时，除利用图5E所示过程实现M1的Parition1的子Parition，和M2的Parition1的相同分区编号的子Parition进行Join操作外，还需将各子Parition的Join操作结果进行联合，从而生成一个新的Parition1。

也就是说，主节点还需要配置将属于相同数据分区的Join操作结果进行联合，所述相同数据分区的Join操作结果包括：一路输入数据的子数据分区与其他路输入数据中相同分区编号的数据分区的Join操作结果，或者，一路输入数据的子数据分区与其他路输入数据中相同分区编号的子数据分区的Join操作结果。

本申请实施例针对Join操作的输入数据的倾斜场景，能够在Join输入的多路或单路存在倾斜的Parition时，进行自适应的拆分与分配，实现Join操作的输入数据分布均匀，并保障新的shuffle模式下，Join操作的正确性。相比通过人工调整作业数据处理逻辑的方式，以及对数据的预处理等需要大量终端用户介入的操作，本申请实施例能够使得Join操作的输入数据的倾斜处理具有自适应性以及普适性。尤其是在主节点收集各stage的输出数据的统计信息的情况下，本申请实施例使得数据倾斜的调整能够自动化执行，而不需要用户手动调整。本申请实施例提供方案的自适应性使得其能够在作业运行期间，根据实际Join输入的数据特点作出动态决策，无需终端用户感知和参与，并且能够使得数据在多个分布式的工作节点间均匀分布，对于存在数据倾斜的作业能起到显著的加速作用，实现分布式系统性能的显著提升。

除了针对Partition的动态调整之外，根据上游stage的统计信息，本申请实施例可以自适应的选择后续执行的执行路径。下面对具体实现方案进行介绍。

本申请实施例可在作业执行过程中对执行计划的逻辑图进行动态调整（即在作业执行过程中对执行计划的逻辑进行动态调整）。需要说明的是，对于逻辑图的选择可能与数据分布和特性相关，而这些数据特性只能在作业执行过程中才能准确获得。不同的数据特性，可能需要配置不同逻辑的执行计划才能有效、准确的实现。因此针对静态执行计划而言，如果执行计划一旦确定且无法在作业的执行过程中动态调整，那么无疑无法对执行计划的逻辑实现合理、准确的配置。

以分布式SQL中的Join操作为例，要实现分布式作业的Join，有多种逻辑上完全等效不同Join算法，例如Sort Merge Join（排序合并连接）和Broadcast Join（广播连接）等。以实现Table1与Table2这两个源表的Join为例，下面对Sort Merge Join和BroadcastJoin的实现过程进行说明。

图6A示出了Sort Merge Join的示例图。如图6A所示，两个输入端源表Table1与Table2，可经过M1与M2读取并初步处理，例如M1对Table1进行数据filter（过滤）后，对输出数据按照shuffle/Join key进行分区；M1和M2的输出数据可在下游工作节点按照相同的key进行merge Join操作。在上述过程中，实现Merge Join需要对M1与M2的输出数据进行全量的shuffle 和sort（排序）操作，通过保证相同分区的数据都能被分配到同一个下游工作节点。然而在分布式系统中，Sort Merge Join依赖外排等具体实现能够做到对于任意数据量的处理，但是过程中涉及的大量的shuffle以及sort操作，需要消耗较多的计算及网络资源；并且在数据分布不均匀时，shuffle后的数据可能导致严重的长尾，影响执行效率。

图6B示出了Broadcast Join的示例图。分布式系统需要具备处理大表（例如事实表）与大表的Join能力，而对于大表与小表（例如维度表）的Join操作，如果小表数据源的大小能被载入单个工作节点内存，那么分布式shuffle和sort的计算/网络消耗能够被降低。结合图6B所示，图6B中的Table1为大表，Table2为小表，则小表的数据可以Broadcast到所有大表的工作节点，并根据小表数据建立全量的hash table（哈希表），从而大表数据读取后可通过hash table lookup（哈希表查表）来进行Join。这样大表（Table1）的数据只需要读取一次，而且不需要进行任何的数据shuffle和sort。同时，Broadcast Join除能避免shuffle和sort的计算/网络消耗以外，shuffle可能带来的数据倾斜以及长尾也能得以避免，这是因为在Broadcast Join的Join pattern（模式）中，Join的逻辑实际上发生在大表的读取逻辑中（例如，Map stage）。基于此，Broadcast Join也被称为Broadcast Map Join。当然，Broadcast Join在带来的资源/性能等众多好处时，也存在其特定的适用范围：用于建立hash table的小表数据，必须能全量被单个工作节点载入，如果优化器选择了Broadcast Join执行作业，但是执行过程中发现小表数据量超过了内存限制，那么整个作业就会失败。

基于前文的描述，Broadcast Join在性能方面具有显著优势，Sort Merge Join本身具有更好的通用性，因此分布式系统的优化器如果需要在两者之间选择合适的Join算法，那么就需要更为准确、合理的判断：在保证作业能成功完成的前提下，尽可能的配置高效的执行计划逻辑。但在实际线上场景中，优化器要在作业执行之前，就做出上述判断是非常困难的，主要原因如下：

缺失准确的统计信息，分布式系统存储的数据的来源多种多样，由于源表数据导入渠道以及导入时间等多种原因，都有可能造成源表数据的统计信息的缺失或不准确(比如一张表刚刚导入统计信息还未产生，或者，表内容的更新刚刚触及废弃统计数据的阈值等）。总之，统计信息的缺失以及不准确，使得优化器无法准确预估Join的上游输入的大小，Join的上游输入可能是源表，或者源表经过一定逻辑转换后的输出。

数据处理逻辑以及数据特性的复杂多变，即便在源表数据上能够获取完整准确的统计信息，但Join的操作客观上可能存在于一个数据处理流程中（DAG内部）的任意一个工作节点，源表的数据随着上游的selection（选择）/filter/ aggregation（聚集）等复杂转换，可能穿插各种用户自定义代码逻辑（UDF），这些都对优化器事先预估Join的输入数据量造成了困难。

正是由于上述这些局限，优化器如果在作业执行之前，静态的选择Join算法，就需要面对两难的取舍：一方面，在输入数据的大小预估不准的情况下，对于Map Join执行计划的选择只能尽量保守, 例如，将小表的门限设置的尽可能低，从而丧失了大量的优化机会。而即便小表门限已经配置得很低，由于数据预估错误，数据膨胀等原因，依然会因误判Broadcast Join导致作业执行失败的情况。由于这些极端情况下会导致作业执行失败的后果，因此反馈到优化器的策略上，优化器会进一步选择更加保守的策略，从而造成负面循环。另外，Broadcast Join的触发很大程度上基于人工手动添加的Map Join hint（MapJoin提示），即将Broadcast Join计划的产生交由用户来决定；这种优化器职能的外放，给用户逻辑维护带来了额外的困难，而实际上，用户只能比较准确的感知源表数据体量，而无法准确得知非源表数据在经过数据变化后的输出大小，因此用户指定Map Join hint同样无法避免数据及上游处理逻辑变化而导致的作业执行失败。

基于前文的描述，要求主节点的优化器在作业执行之前，就对Join算法做出准确选择，其准确度受到各种客观原因的影响。总体上来说，数据的特性（包括数据大小以及分布等）需要在作业执行过程中，由上游工作节点完成之后才能获得，因此要做出Join算法的准确判断，则需要在分布式作业的执行过程中进行判断，而不是在作业执行之前进行判断。然而，在作业执行过程中进行Join算法的判断和选择对于执行引擎的DAG动态能力提出了挑战：选择Sort Merge Join以及Broadcast Join等不同的Join算法时，所产生的执行计划不仅在物理属性（并发度，shuffle模式等）会有区别，而且在DAG的拓扑逻辑结构上，也会有较大的变化，因此如果要在作业执行过程中来进行动态调整，就需要提供动态逻辑图的能力（也就是说，执行计划的逻辑能够被动态调整）。需要说明的是，逻辑图的调整往往也伴随着执行计划的物理属性调整，因此这实际是对DAG动态逻辑图以及动态物理图能力均提出了要求。

基于上述描述的情况，图6C示出了本申请实施例提供的分布式作业调整方法的又另一流程图。该方法流程可由主节点执行实现。参照图6C，该方法流程可以包括如下步骤。

在步骤S610中，获取用户提交的作业。

在步骤S611中，生成所述作业的执行计划，所述执行计划包括多个stage以及控制节点，所述多个stage包括上游stage，其中，所述上游stage在下游存在候选的多条执行路径，一条执行路径包括所述上游stage的一个或多个下游stage；所述控制节点用于从所述多条执行路径中选择所述上游stage在下游实际执行的目标执行路径。

在本申请实施例中，作业的执行计划在生成时，可以在上游stage的下游携带候选的多条执行路径，一条执行路径可以包括该上游stage的一个或多个下游。例如，一条执行路径可以包括该上游stage的直接下游stage，或者，直接下游stage和间接下游stage。在一些实施例中，执行计划中的一个或多个上游stage可以在其下游携带候选的多条执行路径。

在本申请实施例中，执行计划除包括多个stage外，还可以在上游stage的下游设置控制节点，该控制节点可与该上游stage的多条执行路径相联通，并且可从该多条执行路径中选择一条执行路径，作为该上游stage在下游实际执行的目标执行路径。需要说明的是，该控制节点并不属于执行计划中的执行阶段，并不实际调度工作节点等计算资源，而是标识执行计划在上游stage的下游需要加入控制逻辑，以便从多条执行路径中选择实际执行的目标执行路径。

在一些实施例中，步骤S611所指的执行计划可由DAG描述，例如DAG的一个或多个上游stage可以在下游存在候选的多条执行路径。作为一种示例，图6D示例性的示出了携带多条执行路径的执行计划的示意图。如图6D所示，M1的下游存在候选的两条执行路径：Path0和Path1。并且M1的下游设置有控制节点C8_1，控制节点C8_1与Path0和Path1相联通，可用于从Path0和Path1中，选择M1的下游实际执行的目标执行路径。

在步骤S612中，在作业执行过程中，获取所述上游stage的输出数据的统计信息。

在步骤S613中，通过所述控制节点，基于所述统计信息，从所述多条执行路径中选择目标执行路径。

在作业执行过程中，主节点可采集执行计划的各个stage的输出数据的统计信息，其中包括下游携带多条执行路径的上游stage的输出数据的统计信息。例如，结合图6D所示，M1在作业执行过程中执行完成后，M1的输出数据的统计信息可被主节点采集。基于主节点采集的上游stage的输出数据的统计信息，主节点可通过控制节点，基于该统计信息，从上游stage在下游的多条执行路径中选择实际执行的目标执行路径。例如，结合图6D所示，控制节点C8_1可基于M1的输出数据的统计信息，从Path0和Path1中，选择M1的下游实际执行的目标执行路径。

本申请实施例可以在生成执行计划时，使得执行计划的上游stage可以在下游存在多条候选的执行路径，并且在作业执行过程中，基于上游stage的输出数据的统计信息，来从多条候选的执行路径中选择最终执行的目标执行路径。通过这样的方式可以在作业的执行过程中，根据上游stage的输出数据的实际情况来选取最终的执行路径，使得执行路径的选择更为合理、准确。基于合理、准确的执行路径来执行作业，能够显著提升分布式系统的性能。

作为一种可选实现，执行计划的上游stage在下游携带的候选执行路径可以包括两条执行路径，分别为第一执行路径和第二执行路径。图7A示例性的示出了生成携带多条执行路径的执行计划的流程图。该方法流程可由主节点执行实现。参照图7A，该方法流程可以包括如下步骤。

在步骤S710中，根据作业的源数据预估的数据大小，生成具有多个候选信息的物理计划，一个候选信息表示所述源数据在作业执行过程中可能使用的一个任务，所述多个候选信息包括第一候选信息以及第二候选信息。

在作业提交之时，优化器可预估作业的源数据（例如源表）的数据大小，如果预估的源数据的数据大小小于预设的第一门限值，则优化器可以触发conditional executionplan（有条件执行计划），基于源数据在作业执行过程中可能使用的任务，优化器可生成该源数据的多个candidates（候选信息），以及具有该多个candidates的物理计划。在一些实施例中，任务可以包括一个或多个算子（operator），例如通过算子的处理过程来实现具体任务的执行。

在一个示例中，假设源数据为源表，则源表在作业执行过程中进行Join操作时可以使用Broadcast Join和Sort Merge Join，因此优化器可基于源表在Join操作时可能使用的Broadcast Join和Sort Merge Join，生成该源表的两个candidates，其中一个candidate表示Broadcast Join，另一个candidate表示Sort Merge Join。在一些实施例中，物理计划可以认为是节点树的数据结构。

在步骤S711中，将物理计划转换为算子树，算子树包括物理计划的一个或多个原始任务，一个原始任务使用一个或多个算子。

在步骤S712中，当第一次遍历到预设算子时，根据与第一执行路径对应的第一候选信息，在算子树中新增第一执行路径的任务，以及将新增任务中的算子与原始任务中的相关算子进行data pipe（数据管道）连接，以在算子树中转化出第一执行路径。

为生成携带多条执行路径的执行计划，优化器在将物理计划转换为算子树后，可根据多个候选信息在算子树中转化出多条执行路径。在一些实施例中，优化器可对算子树进行多次遍历，并且预先设置进行执行路径转化的预设算子，当优化器第一次遍历到预设算子时，则可对多个候选信息中第一候选信息对应的第一执行路径进行转化。在一些实施例中，多个候选信息至少包括第一候选信息以及第二候选信息，其中，第一候选信息与第一执行路径相对应，可记录第一执行路径对应的任务，第二候选信息可与第二执行路径相对应，可记录第二执行路径对应的任务。

在一些实施例中，当优化器第一次遍历到预设算子时，可根据第一候选信息在算子树中新增第一执行路径的任务，新增的任务可以包括一个或多个算子，为使得第一执行路径的任务能够与算子树的原始任务进行联通，优化器可将新增任务的算子与原始任务中的相关算子进行管道连接，原始任务中的相关算子可以认为是原始任务中与新增任务的算子相关的算子（例如原始任务中处于新增任务的算子的上游、下游的算子）。通过上述处理，优化器可以在算法树中转化出第一执行路径。

在步骤S713中，当第二次遍历到预设算子时，根据与第二执行路径对应的第二候选信息，在算子树中新增第二执行路径的任务，以及将新增任务中的算子与已有任务中的相关算子进行data pipe连接，以在算子树中转化出第二执行路径。

在一些实施例中，当优化器第二次遍历到预设算子时，可根据第二候选信息在算子树中转化出第二执行路径。优化器可根据第二候选信息，在算子树中新增第二执行路径的任务，新增的任务可以包括一个或多个算子，为使得第二执行路径的任务能够与算子树中的已有任务进行联通，优化器可将新增任务的算子与已有任务中的相关算子进行datapipe连接，已有任务中的相关算子可以认为是已有任务中与新增任务的算子相关的算子（例如原始任务中处于新增任务的算子的上游、下游的算子）。通过上述处理，优化器可以在算法树中转化出第二执行路径。

作为可选实现，步骤S712可以认为是在算法树中基于第一候选信息转化第一执行路径的可选实现，步骤S713可以认为是在算法树中基于第二候选信息转化第二执行路径的可选实现。

在步骤S714中，在算子树的第一执行路径和第二执行路径的上游设置控制节点，以得到执行计划。

在算子树中完成第一执行路径和第二执行路径的转化之后，为使得作业执行过程中，能够在第一执行路径和第二执行路径的上游stage执行完成之后，实现从第一执行路径和第二执行路径中选择目标选择路径，优化器还可在算子树的第一执行路径和第二执行路径的上游设置控制节点，以通过控制节点实现作业执行过程中第一执行路径和第二执行路径的动态选择。通过上述过程，本申请实施例可生成携带多条执行路径的执行计划。

为便于说明上述生成携带多条执行路径的执行计划的过程，本申请实施例引入conditional execution plan（有条件执行计划）的概念：允许优化器在作业提交时，基于多个candidates（候选信息）产生具有多条执行路径的执行计划。最终哪个candidate的执行路径被选择使用，则是由主节点在作业执行过程中，根据上游stage产生的输出数据的统计信息，来进行动态选择。

作为一种可选实现，优化器可通过Cost-based Optimization（基于成本的优化）以及Execution plan generation（执行计划生成）两个环节，实现产生携带多条执行路径的执行计划。

在Cost-based Optimization环节，以Join场景为例，优化器可在Join的buildrule（构造规则）中通过源表统计等信息，估算Join的小表在内存中的数据大小，例如，基于小表的RowCount（行数）* AverageRowSize（平均行大小）估算得到小表在内存中的数据大小。进而，优化器可判断小表在内存中的数据大小是否小于预设的第一门限值（第一门限值可以预先设置并定义为threshold1）。如果小表在内存中的数据大小，小于预设的第一门限值，则优化器会触发数据库的conditional Map Join（有条件的映射连接），例如产生小表数据进行Map Join的多个candidates，一个candidate可以表示小表使用的一个Join算子（例如Broadcast Join或Sort Merge Join）。基于conditional Map Join提供的多个candidates来实现后继的动态决策，优化器可以将Cost-based Optimization环节的第一门限值threshold1配置的比较大（默认值为512M），也就是只要按照比较宽松的概率，判断出一个作业可能利用Broadcast Join，就产生conditional Map Join的计划，而最终选择执行路径的选择，则交给执行引擎在作业执行过程中来进行动态选择。

上述conditional Map Join的计划可以视为是physical plan（物理计划），而并不是最终的执行计划，physical plan可以是RelNode tree（控制节点树）的结构，其中RelNode表示relational expression（关系表达式）。在Cost-based Optimization环节，physical plan中包含了conditional Map Join这样的控制节点，而该控制节点内部基于多个candidates可以包含多条Path（执行路径），以表达进行Join算法可能选择的路径，例如Broadcast Join和Sort Merge Join对应的执行路径。而无论最终选择哪条Path，小表的计算和数据会在该多条Path共享。conditional Map Join在优化器的cost model中定义的cost可以介于Broadcast Join和Sort Merge Join两者的cost之间，并且根据最终选择的Path的概率来决定两者的cost比例。

在Execution plan generation环节，优化器将上一步产生的physical plan转化为最终的execution plan（执行计划），例如，将优化器产生的physical plan转化为能被runtime（运行时组件）理解的physical operator tree（物理算子树）以及构造出DAGtopology（拓扑结构）。因此最终的执行计划包括了由task和edge组成的DAG ，以及每个工作节点内部的operator tree（即物理算子树）。总体而言，上述过程是一个physical plan（物理计划）的后序遍历过程，并在遍历过程中动态切分task以及添加Edge。不同于普通query，conditional Map Join要实现运行时的动态决策和选择Path，那么在executionplan产生过程中需要添加控制任务和dependent edge（从属连接边），从而准确地通过dependent edge来描述上下游工作节点之间的调度依赖关系(无数据流动)以及一个单纯的控制节点。例如，将包含正常执行operator的普通工作节点通过dependent edge和控制节点相连。通过上述设置可以在DAG运行过程中，由控制节点通过判断小表实际运行后的大小，来选择后续的执行路径。

图7B、图7C、图7D和图7E示例性的示出了物理计划转化为执行计划的过程。其中，主节点完成图7B之后可执行图7C，完成图7C之后可执行图7D，完成图7D之后可执行图7E。其中，图示中的粗箭头指代data pipeline（数据管道连接）、细虚线箭头表示controlpipeline（控制管道连接）、细实线箭头表示runtime operator data flow（运行期间算子的数据流）。在一个实现示例中，当主节点在遍历physical plan的过程中，如果遍历到conditional Map Join，并准备转化conditional Map Join包含的多个Path时，主节点可将conditional Map Join的输入 relNode tree（控制节点树）转换为operator tree（算子树），operator tree中的operator可以形成图7B所示的M1和M2这两个task，例如M1使用TableScan1（表扫描1）和Filter1（过滤1）这两个operator，M2使用TableScan2（表扫描2）、Filter2（过滤2）和StreamlineWrite1（流线写1）这三个operator。

假设conditional Map Join包含的多个candidates为2个candidates，且其中一个candidate对应Path0，另一个candidate对应Path1，Path0可以对应Broadcast HashJoin的Join实现，Path1可以对应Sort Merge Join的Join实现。结合图7C所示，主节点在遍历operator tree的过程中，如果第一次遍历到M1的filter1，则可对Path0进行转化。具体来说，基于Path0的candidate记录的task，主节点可在算子树中新增Path0的task，以及将新增的task中的算子与M1和M2进行data pipe连接。结合图7C所示，R3为新增的task并且具有StreamlineRead1（流线读取1），StreamlineWrite2（流线写2）这两个新增的算子，R1中新增了StreamlineRead2（流线读取2）以及ConditionalMapJoin1。其中，M1中新增的ConditionalMapJoin1是Broadcast Hash Join的operator id（算子标识），其operator类型是HashJoin。

上述过程是第一次遍历到M1中的filter1时执行，以在算子树的基础上转化Path0，从而在执行计划中表达出Path0的执行路径；在这个过程中，主节点可对算子树中M1原本的operator进行记录以便后续进行copy（复制）。从当前新增加的四个operator可以推断出目前正在处理的是R3和M1，此时，将其记录下来作为一条候选的Path0。

然后开始对Path1做转化，Path1和Path0 共享的是StreamlineWrite和Filter，例如StreamlineWrite1和Filter1。基于Path1和Path0共享的算子Filter1，当主节点第二次遍历到Filter1时，可对Path1进行转化。具体来说，基于Path1的candidate记录的task，主节点可在已转化Path0的算子树上新增Path1的task，以及将新增的task中的算子与当前任务中的相关算子进行data pipe连接。结合图7D所示，M5和J6为新增的task，在新增M5的task时，可以将前面记录的M1的operator（例如图7D中的TableScan1和Filter1），copy到M5中，同时在M5中新增StreamlineWrite3（流线写3）算子。在新增J6的task时，可以在J6中新增StreamlineRead3（流线读取3）、StreamlineRead4（流线读取4）和ConditionalMapJoin1这三个算子，并且实现J6与M2和M5之间在算子层面的data pipe。

结合图7E所示，在完成Path0和Path1的转化之后，需要在算子树中创建控制节点C8，C8中只有一个operator，即Conditional operator，其作用是在表的实际作业过程中，基于表执行过程中的大小，来从Path0和Path1中选择进行Join的执行路径。

在进一步的一些实施例中，在生成带有多条执行路径的执行计划之后，主节点可以在作业执行过程中，获取上游stage的输出数据的数据量，判断该数据量是否小于预设的第二门限值，若是，则选择第一执行路径作为目标执行路径，若否，则选择第二执行路径作为目标执行路径。假设上游stage处理的数据为小表，则在作业执行过程时，如果小表对应的task执行完毕，则控制节点可根据小表实际执行的大小，判断小表的数据输出结果是否小于预设的第二门限值（定义为threshold2），若小表的执行输出结果小于第二门限值，则选中Broadcast Join的执行路径（即第一执行路径为执行Broadcast Join的执行路径）；若小表的执行输出结果大于第二门限值，则选中Sort Merge Join的执行路径（即第二执行路径为执行Sort Merge Join的执行路径）。需要说明的是，threshold2考虑的是在实际运行时，小表数据在内存加载成hash table所占用的内存大小，其默认值可以和threshold1一样（例如512M），当然本申请实施例也可设置threshold2与threshold1的数值不同。另外需要说明的是，只有在小表估算的大小满足threshold1，才能触发conditional Join plan，而在作业运行中，主节点收集到小表真正的大小时，是通过threhold2来决策小表进行Join最终的执行路径；所以threshold1是在优化器阶段做决策用，threshold2是在DAG运行阶段做决策用，通过threshold1和threshold2这两个数值的调整，以及优化器和DAG的互相配合来完成整个conditional （条件）的生成以及最终执行计划的选择。

在执行路径的动态选择方面，结合图6D所示，当作业初始提交时，因为还没有确认最终的执行路径，所以提交的DAG中包含了两条可能的执行路径（例如图6D虚线所示的两条执行路径Path0和Path1）。同时DAG中新增加了控制节点（C8_1），这个控制节点只有逻辑上的控制意义不会拉起任何工作节点，控制节点根据M1的输出来选择执行Path0还是Path1。例如，在作业执行过程中，M1在读取小表输出数据的candidate并做处理后，其实际输出的数据量会被主节点收集，并在控制节点基于小表实际输出的数据量进行执行路径的决策选择。如果选择执行Path0，则完整执行计划可以例如图7F所示，如果选择执行Path1，则完整执行计划可以例如图7G所示。

本申请实施例可以在作业执行之前对执行计划进行调整，使得执行计划的上游stage可以在下游存在多条候选的执行路径，并且在作业执行过程中，基于上游stage的输出数据的统计信息，来从多条候选的执行路径中选择最终执行的目标执行路径。通过这样的方式可以在作业的执行过程中，根据上游stage的输出数据的实际情况来选取最终的执行路径，使得执行路径的选择更为合理、准确，从而基于合理、准确的执行路径执行作业，能够显著提升分布式系统的性能。

随着深度学习（Deep-Learning）的广泛应用，分布式系统针对深度学习作业需要满足的处理需求越来越多，并且出现了多种适用于深度学习作业的执行引擎。然而针对深度学习作业，分布式系统在调度与执行上仍然存在各种缺陷。例如对于深度学习系统（比如Tensorflow）的原生逻辑而言，原生逻辑的调度与执行完全依赖外部系统而并没有配置在分布式系统的执行引擎内。以Parameter Server（参数服务器，PS）架构为例，分布式系统的工作节点可以分为两类：PS节点和Worker（工作器）节点，其中PS节点存放深度学习参数（例如深度学习模型的参数），而Worker节点用于计算深度学习参数的梯度。在深度学习的每个迭代过程，Worker节点从PS节点中获得深度学习参数，然后将计算的梯度返回给PS节点，PS节点聚合从Worker节点传回的梯度并更新深度学习参数，PS节点将更新的深度学习参数再广播给Worker节点，以此方式不断执行，从而实现深度学习参数迭代调整。在分布式系统的PS架构中，PS节点与Worker节点在运行过程中存在如下特点：

PS节点与Worker节点行使的职责有显著不同，并且对应执行计划的不同stage，其中。PS节点对应的stage可称为PS stage（参数服务器执行阶段），Worker节点对应的stage可称为Worker stage（工作器执行阶段）；

PS节点作为Parameter的serving entity（服务实体）, 可以独立运行；

Worker节点在使用和更新Parameter（参数）时，需要PS节点在运行后才能有效的运行，并且在运行过程中需要和PS节点持续的进行数据交互。

上述特点在许多分布式执行框架中描述起来是比较困难的：虽然PS节点和Worker节点之间存在调度上的前后依赖关系，但是因为PS节点与Worker节点能够同时运行，这种依赖关系无法映射到上游节点运行完毕再调度下游节点的逻辑中。基于此，在许多外部系统中，PS节点与Worker节点只能在执行计划中对应两个孤立无联系的stage来分开调度和运行，而这完全有可能导致Worker节点在PS节点调度起来之前就已经在空转，从而造成Worker节点的资源浪费。除此之外，由于缺失PS节点、Worker节点在不同stage之间的关系描述，许多基本功能和动态功能都无法实现。

在深度学习领域，深度学习作业使用的资源（尤其是GPU资源）一般都是直接开放给终端用户来指定。例如，终端用户指定深度学习作业的工作节点并发度、每个工作节点使用的资源大小（比如一个工作节点使用的GPU数量等）。然而让用户自己选择合适的资源是比较困难的，用户为了保证深度学习作业能够有足够使用的资源，往往会过量的申请资源，导致资源的浪费情况。例如，用户为了保证深度学习作业的GPU使用得到保障，会在对实际使用的GPU资源无法准确预测的情况下，为每个工作节点申请多张GPU卡，然而深度学习作业实际执行过程中，可能只利用了其中的25%，这导致剩余的GPU资源出现闲置而产生浪费。这种情况导致的一个累积效应就是分布式系统上大量的GPU资源由于用户的申请而被预留，甚至用户申请的GPU资源超过分布式系统的GPU资源总量，出现分布式系统的实际GPU资源利用率较低，而其他作业则需要排队使用GPU资源的现象。另一方面，许多深度学习作业对于资源（尤其是GPU资源）的使用是特别敏感的，如果盲目降低允许用户申请的资源上限，可能会导致深度学习作业的执行性能出现下降。

基于上述情况，如何保证深度学习作业的资源申请精度，并且提升分布式系统的资源利用率，以在节约分布式系统计算资源的同时，保证深度学习作业的执行性能不受影响，成为了亟待解决的问题。

为解决上述问题，基于DAG中的顶点和连接边都可以对应不同的逻辑与物理属性，本申请实施例在连接边的物理属性上引入sequential edge（顺序边）与concurrent edge（并行边）的物理属性，并使得顺序边和并行边与数据传输进行解耦。并行边描述的是并行边连接的上、下游stage的工作节点可以同时处于运行状态，但是调度上依然有先后，而且调度的时机可以自定义。例如并行边连接的上、下游stage的工作节点可以同步调度，也可以是下游stage的工作节点在上游stage的工作节点运行后进行调度，也可以下游stage的工作节点在上游stage的工作节点运行到一定阶段后再由事件触发调度等。而顺序边描述的是顺序边连接的下游stage的工作节点，需要等到上游stage的工作节点全部或者部分执行结束后才能调度运行。

基于并行边，深度学习作业的PS节点和Worker节点的关系能够更加准确的进行描述。图8A示例性的示出了并行边连接的PS stage（参数服务器执行阶段）和Worker stage（工作器执行节点）的示例图。如图8A所示，PS stage为PS节点在执行计划中对应的stage，Worker stage为Worker节点在执行计划对应的stage，在执行计划中PS stage通过并行边与Worker stage连接，且并行边由PS stage输入Worker stage。从而，Worker节点和Worker节点可以同时处于运行状态，并且调度时机可以进行自定义。在一些实施例中，下表1示例性的示出了并行边连接的下游节点的调度时机的类型（称为调度类型），可进行参照，其中，上游节点可以认为是并行边连接的上游stage对应的工作节点（例如图8A所示的PS stage对应的PS节点），下游节点可以认为是并行边连接的下游stage对应的工作节点（例如图8A所示的Worker stage对应的Worker节点）。

表1

基于连接边的顺序边、并行边的物理属性，以及下游节点的调度类型等内容，本申请实施例能够完整的描述各种复杂的DAG逻辑，从而支持各种负载，例如：批处理作业，流式作业，近实时/准实时作业，深度学习作业等。

针对深度学习作业，以PS作业为例，由于Worker节点可使用和更新Parameter，并且Worker节点在PS节点运行后才能运行，因此在深度学习作业的执行计划中，PS stage和Worker stage之间的连接边为并行边，且并行边由PS stage输入Worker stage；也就是说，在执行计划中，Worker stage作为PS stage的直接下游stage，并且通过并行边连接。由于Worker只能在PS开始运行后运行才有意义，因此下游的Worker节点的调度类型为SOURCE_TASK_STARTED，也就是说，上游的PS节点的实例启动后，开始调度下游的Worker节点。在数据生成方面，由于PS节点上的数据仅在其处于运行状态时有效，且上游数据源不感知下游状态，因此数据源类型为EPHEMERAL_STATELESS（短暂无状态）的类型；而在数据传输类型方面，由于PS节点与Worker节点的数据传输可以不由执行框架感知，因此数据传输类型为NONE（空）。因此连接PS stage和Worker stage的连接边可以描述为{CONCURRENT，EPHEMERAL_STATELESS，NONE，SOURCE_TASK_PROGRESS}。

基于上述描述，本申请实施例在深度学习作业的执行过程中，PS节点与Worker节点可以同时运行，同时Worker节点必须在PS节点运行起来以后才能调度资源进行数据处理。这种针对深度学习作业的执行计划的描述，使得作业运行过程中的动态调整成为可能。具体来说，深度学习的执行引擎需要终端用户为执行计划提供大量的配置参数，例如stage的并发度、需求的资源大小与类型、分布策略等，而这些配置参数由终端用户提供的难度极大。基于此，本申请实施例在分布式系统的执行引擎引入Resource Optimization（资源优化）节点，资源优化节点作为一个作业执行的控制节点，可以对资源相关请求进行协调和动态调整。

在一个示例中，以PS作业为例，本申请实施例在PS节点，Worker节点以外添加一个新的资源优化节点。资源优化节点负责根据一定的规则来决定如何动态调整Worker节点的资源。在此基础上，除了在执行计划中设置由PS stage输入Worker stage的并行边外，还需在执行计划中增加设置与Resource Optimization节点对应的Resource Optimizationstage（资源优化执行阶段），以及由Resource Optimization stage输入Worker stage的并行边。连接Resource Optimization stage和Worker stage的连接边可以描述为{CONCURRENT，EPHEMERAL_STATELESS，NONE，SOURCE_TASK_PROGRESS}。与连接PS stage和Worker stage的连接边的描述不同的是，连接Resource Optimization stage和Workerstage的连接边采用了下游节点是SOURCE_TASK_PROGRESS的调度类型。也就是说，Worker节点需要在上游的Resource Optimization节点的执行进度达到一定阈值后进行调度。

在作业执行过程中，PS节点和Resource Optimization节点会先启动，当PS节点的实例启动后会通知下游Worker节点进行调度，并且Resource Optimization节点的实例进度达到阈值时通知下游Worker节点进行调度。而Worker节点收到上述两个通知后，可基于Resource Optimization节点通知，更新调度的资源后启动相应实例（资源基于ResourceOptimization节点的控制而动态变化）。在一些实施例中，Resource Optimization节点可以动态调整Worker节点的以下资源：节点并发度，节点的GPU、CPU、MEMORY等资源的使用需求。

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

在步骤S810中，获取用户提交的深度学习作业。

在步骤S811中，生成深度学习作业的执行计划，所述执行计划包括多个stage，该多个stage包括：Worker stage和Resource Optimization stage。

在一些实施例中，Resource Optimization stage通过并行边输入Worker stage。

在进一步的一些实施例中，该多个stage包括还可以包括：PS stage。其中，PSstage和Resource Optimization stage分别通过并行边输入Worker stage。

在本申请实施例中，深度学习作业（例如PS作业）可以被描述成PS、Worker和Resource Optimization的结构。也就是说，在生成深度学习作业的执行计划时（执行计划可由DAG描述），执行计划中可以包括PS stage、Worker stage以及Resource Optimizationstage。并且在DAG图中，PS stage由并行边输入Worker stage，Resource Optimizationstage也由并行边输入Worker stage。在进一步的一些实施例中，PS stage和Worker stage的并行边描述，以及Resource Optimization stage和Worker stage的并行边描述，可参照前文相应的描述，此处不再展开。

在步骤S812中，在深度学习作业的执行过程中，调度Resource Optimizationstage对应的Resource Optimization节点，通过Resource Optimization节点确定当前适应于Worker stage的资源信息。

在本申请实施例中，Resource Optimization节点可以先于Worker节点进行调度，例如Resource Optimization节点的实例进度达到阈值时，才通知Worker节点进行调度。在一些实施例中，Resource Optimization节点调度之后，Resource Optimization节点可确定当前适应于Worker stage的资源信息。在一些实施例中，Resource Optimization节点可确定与深度学习作业的当前执行状态相匹配的历史使用的资源信息，将所述当前执行状态相匹配的历史使用的资源信息，作为当前适应于Worker stage的资源信息。

作为可选实现，与深度学习作业的当前执行状态相匹配的历史使用的资源信息可以包括：与所述当前执行状态相同或相似的历史执行状态历史使用的资源信息。

在一些实施例中，Resource Optimization节点可基于深度学习作业的当前执行状态，从历史数据库中确定适应于Worker stage的资源信息，历史数据库可以记录历史深度学习作业在各个历史执行状态实际使用的资源信息，也就是说，历史数据库可以记录历史执行结束的深度学习作业在各个执行状态实际使用的资源信息。从而ResourceOptimization节点可基于历史数据库中的记录，确定出适应于深度学习作业的当前执行状态的资源信息，来为Worker节点进行资源配置。

在一些实施例中，Resource Optimization节点可基于深度学习作业的当前执行状态，从历史数据库中查找与所述当前执行状态相似或者相同的历史执行状态，将查找的历史执行状态实际使用的资源信息，确定为当前适应于Worker stage的资源信息。作为可选实现，Resource Optimization节点可先从历史数据库中查找与当前执行状态相同的历史执行状态，若查找到，则将历史数据库中记录的该相同的历史执行状态相应的资源信息，作为当前适应于Worker stage的资源信息；若未查找到，则查找与当前执行状态相似的历史执行状态（例如查找与当前执行状态的差异最小的历史执行状态），将历史数据库中记录的该相似的历史执行状态相应的资源信息，作为当前适应于Worker stage的资源信息。在一些实施例中，深度学习作业的当前执行状态例如深度学习作业的当前学习模式、当前输入数据的特点（例如当前训练数据的数据量）、当前剩余的参数迭代次数等。

在步骤S813中，通过Resource Optimization节点，为Worker stage配置所述资源信息。

通过Resource Optimization节点确定出当前适应于Worker stage的资源信息（例如，与所述当前执行状态相匹配的历史使用的资源信息）后，主节点可通过ResourceOptimization节点为执行计划中的Worker stage配置该资源信息，以使得Worker stage配置的资源信息适应于深度学习作业的当前执行状态。进而，Worker节点调度时，Worker节点可基于所述资源信息调度使用的资源，使得Worker节点以合理的资源执行task，提升Worker节点的资源利用率。

在一些实施例中，Worker节点需在PS节点的实例启动后，以及ResourceOptimization节点的实例进度达到阈值时进行调度。

在一些实施例中，如果用户事先指定了Worker stage的资源信息，则ResourceOptimization节点可基于确定的当前适应于Worker stage的资源信息，对用户指定的资源信息进行调整，避免用户由于过量指定Worker stage的资源而导致资源闲置的情况。例如，用户指定了Worker节点使用2个CPU core（核）和1个GPU core（核）的资源单位，如果Resource Optimization节点基于深度学习作业的当前执行状态确定Worker节点实际不需要使用这么多的资源，则Resource Optimization节点可将用户事先指定的CPU core和GPUcore的数量进行调整，例如调整为Worker节点使用为1个CPU core 和半个GPU core，避免由于用户为Worker节点指定过多数量的CPU core和GPU core，而导致CPU和GPU资源的闲置浪费。

作为一些实现示例，图8C示出了Resource Optimization节点调整Worker节点的资源示例。如图8C所示，Worker节点计划配置的资源为200个CPU核和100个GPU核（可由用户指定），在深度学习作业的执行过程中，Resource Optimization节点可基于作业的当前执行状态，从历史数据库中查找相似或者相同的历史执行状态实际使用的资源信息，例如与作业的当前执行状态相似或者相同的历史执行状态实际使用100个CPU核和50个GPU核，则Resource Optimization节点可将Worker节点配置的CPU核数量调整为100个、GPU核数量调整为50个，使得Worker节点能够通过配置较低的资源，来保障深度学习作业的具体执行。

在进一步的一些实施例中，Resource Optimization节点可以预先设置Worker节点的多个资源需求方案，Resource Optimization节点可以根据的深度学习作业的当前执行状态，从多个资源需求方案中选择与当前执行状态相匹配的资源需求方案，并以选择的资源需求方案为Worker stage配置资源信息。与当前执行状态相匹配的资源需求方案可以认为是能够满足当前执行状态的作业执行，且资源需求量最少的方案。

本申请实施例可基于深度学习作业的当前执行状态，为Worker节点配置精度更高的资源，能够在保障Worker节点执行深度学习作业的执行性能不受影响的前提下，节约分布式系统计算资源，提升分布式系统的资源利用率。本申请实施例可以在大规模生产集群上线使用后，能够在不影响用户针对深度学习的实际训练耗时的前提下，大幅提升深度学习作业的资源（尤其是GPU资源）的利用率，同时带来了作业的吞吐率大幅度提升，用户作业排队的情况能够得到极大缓解。

本申请实施例能够可对Map-Reduce、离线作业运行模式等的执行计划进行描述扩展，使得执行计划能准确的描述包括PS在内的深度学习作业。这种执行计划的描述方式，能够避免工作节点的资源空转等待，并能够提供更准确的作业执行控制流程。并且，本申请实施例能够在作业运行期间，对深度学习作业所需要实际使用的GPU等资源进行动态选择和调整，确保资源的使用能根据作业实际运行需求和算法特点进行适配，保障高效的资源使用，从而避免了大规模多用户的分布式系统中，超量资源申请以及实际资源使用率较低的矛盾。

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

本申请实施例还提供一种分布式系统，该分布式系统的结构可以结合前文相应部分的描述，该分布式系统可以包括上述所述的主节点。

本申请实施例还提供一种物理机，该物理机可以设置本申请实施例提供的主节点。作为一种可选实现，图9示出了物理机的结构框图。如图9所示，该物理机可以包括：至少一个处理器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调用所述一条或多条计算机可执行指令，以执行本申请实施例提供的分布式作业调整方法。

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

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

上文描述了本申请实施例提供的多个实施例方案，各实施例方案介绍的各可选方式可在不冲突的情况下相互结合、交叉引用，从而延伸出多种可能的实施例方案，这些均可认为是本申请实施例披露、公开的实施例方案。

虽然本申请实施例披露如上，但本申请并非限定于此。任何本领域技术人员，在不脱离本申请的精神和范围内，均可作各种更动与修改，因此本申请的保护范围应当以权利要求所限定的范围为准。