数据规约方法、装置及系统与流程

本申请涉及高性能计算领域中的数据处理技术领域，尤其是涉及一种数据规约方法、装置及系统。

背景技术：

在高性能计算领域中，规约是一个基本的集合通信原语，其目标是将分散在各个节点上的多个数据规约为一个结果并将结果返回给特定的进程。例如，利用规约可以对分散在各节点上的数据求和，并将求和结果放在指定的节点上。目前，最常用的规约实现为mpi(multipointinterface，多点接口)的规约接口mpi_reduce。

在实践中，我们发现当在商用大规模集群的环境中对较大规模的数据体进行规约时，现有的mpi_reduce没有考虑复杂环境。而在复杂环境中，可能存在其他进程的干扰，或者节点本身的原因导致某个节点的规约速度非常慢。在现有的mpi_reduce接口中，当节点中出现慢节点时，规约的时间将显著变长。

技术实现要素：

本申请实施例的目的在于提供一种数据规约方法、装置及系统，以提高数据规约对复杂环境的适应能力。

为达到上述目的，一方面，本申请实施例提供了一种数据规约方法，包括：

主节点接收多个从节点异步发送的规约操作请求；

所述主节点根据所述多个从节点当前的规约性能，动态确定所述规约操作请求的规约树节点队列，根据所述规约树节点队列处理所述规约操作请求并向所述从节点返回对应的规约任务；

所述主节点接收所述从节点在执行完所述规约任务后返回的携带规约操作结果的规约消息。

本申请实施例的数据规约方法，还包括：

在规约过程中，所述主节点根据从节点提供的心跳消息周期性检测所述从节点是否存在规约故障；

当检测到从节点存在规约故障时，所述主节点根据预设的规约故障处理策略处理所述规约故障。

本申请实施例的数据规约方法，还包括：

在规约过程中，所述主节点记录全局数据的存储位置及状态，并从节点出现规约故障时，发起规约故障节点上的数据备份任务。

本申请实施例的数据规约方法，所述当前的规约性能包括该从节点在指定历史规约次数范围内的规约耗时平均值。

本申请实施例的数据规约方法，所述规约树节点队列的树结构包括二叉树。

另一方面，本申请实施例还提供了另一种数据规约方法，包括：

多个从节点向主节点异步发送规约操作请求；

所述从节点接收所述主节点返回的规约任务；所述规约任务是由所述主节点根据规约操作请求的规约树节点队列处理规约操作请求后生成的，所述规约操作请求的规约树节点队列是由所述主节点根据所述多个从节点当前的规约性能动态确定的；

所述从节点执行所述规约任务，并在执行完所述规约任务后，向所述主节点返回的携带规约操作结果的规约消息。

本申请实施例的数据规约方法，还包括：

在向主节点异步发送规约操作请求之前，所述多个从节点将本地的待规约数据异步发送给非本地从节点进行备份。

本申请实施例的数据规约方法，还包括：

在向主节点异步发送规约操作请求之前，所述从节点申请执行规约任务的槽空间；

相应的，所述从节点在对应分配的槽空间下执行所述规约任务。

本申请实施例的数据规约方法，还包括：

在规约过程中，所述从节点记录本地数据的存储位置及状态，并在自身出现规约故障时，接收并处理主节点分配的数据备份任务。

另一方面，本申请实施例还提供了一种主节点，包括：

规约调度器，用于接收多个从节点异步发送的规约操作请求，根据所述多个从节点当前的规约性能，动态确定所述规约操作请求的规约树节点队列，根据所述规约树节点队列处理所述规约操作请求并向从节点返回对应的规约任务，接收所述从节点在执行完所述规约任务后返回的携带规约操作结果的规约消息；

规约性能计数器，用于获取从节点当前的规约性能。

本申请实施例的主节点，该主节点还包括：

第一容错模块，用于在规约过程中根据从节点提供的心跳消息周期性检测所述从节点是否存在规约故障；当检测到从节点存在规约故障时，所述主节点根据预设的规约故障处理策略处理所述规约故障。

本申请实施例的主节点，该主节点还包括：

第一数据可靠性模块，用于在规约过程中记录全局数据的存储位置及状态，并从节点出现规约故障时，发起规约故障节点上的数据备份任务。

另一方面，本申请实施例还提供了一种从节点，包括：

规约执行器，用于向主节点异步发送规约操作请求；接收所述主节点返回的规约任务；所述规约任务是由所述主节点根据规约操作请求的规约树节点队列处理规约操作请求后生成的，所述规约操作请求的规约树节点队列是由所述主节点根据多个从节点当前的规约性能动态确定的；执行所述规约任务，并在执行完所述规约任务后，向所述主节点返回的携带规约操作结果的规约消息。

本申请实施例的从节点，该从节点还包括：

第二容错模块，用于在规约过程中周期性向所述主节点提供心跳消息，以供所述主节点进行故障检测。

本申请实施例的从节点，该从节点还包括：

第一数据可靠性模块，用于在规约前将本地的待规约数据异步发送给非本地从节点进行备份；在规约过程中记录本地数据的存储位置及状态，并在从节点出现规约故障时，接收并处理主节点分配的数据备份任务。

本申请实施例的从节点，该从节点还包括：

槽管理器，用于申请执行规约任务的槽空间，以便于所述规约执行器在对应分配的槽空间下执行所述规约任务。

另一方面，本申请实施例还提供了一种数据规约系统，该系统包括上述的主节点；以及上述的从节点。

由以上本申请实施例提供的技术方案可见，本申请实施例中，规约调度器可以根据多个从节点当前的规约性能来动态确定规约操作请求排序，从而确定规约任务的分配顺序。这保证了已进入就绪状态且规约性能稿的从节点可以优先分配到规约任务，从而降低了慢节点对整体性能的影响，这样才能降低规约所耗费的时间，从而提高数据规约系统对复杂环境的适应能力。此外，本申请实施可以支持容错处理和异步规约，同时，也对大规模、高并发规约操作实现了支持。

附图说明

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

图1为本申请一实施例中数据规约系统的结构示意图；

图2为本申请一实施例中将不同的规约操作划分到不同的域的示意图；

图3为本申请一实施例中数据规约系统的数据规约方法的流程图；

图4为本申请一实施例中主节点侧的数据规约方法的流程图；

图5为本申请一实施例中从节点侧的数据规约方法的流程图；

图6为本申请一实施例中数据规约方法与现有的openmpi阻塞规约接口的性能对比示意图；

图7为本申请一实施例中数据规约方法与现有的openmpi阻塞规约接口的性能对比示意图；

图8为本申请一实施例中数据规约方法与现有的openmpi的并行异步规约性能对比示意图。

具体实施方式

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

本申请一些实施例的数据规约系统可以包括一个主节点以及一个或多个从节点。主节点与从节点，以及从节点之间均可以进行通信，以配合数据规约。

在本申请一实施例中，主节点可以包括规约调度器和规约性能计数器等。规约调度器可以用于接收多个从节点异步发送的规约操作请求，根据所述多个从节点当前的规约性能，动态确定所述规约操作请求的规约树节点队列，根据所述规约树节点队列处理所述规约操作请求并向从节点返回对应的规约任务，接收所述从节点在执行完所述规约任务后返回的携带规约操作结果的规约消息。规约性能计数器可以用于获取从节点当前的规约性能。在本申请一示例性实施例中，从节点当前的规约性能例如是该从节点在指定历史规约次数范围(例如最近5次规约、最近10次规约、最近50次规约等)内的规约耗时平均值。

由此可见，在本申请一实施例中，由于从节点是异步发送规约操作请求的，可以确保优先进入就绪状态的从节点优先进行规约计算。而且，对于已发送了规约操作请求的多个从节点，规约调度器可以根据多个从节点当前的规约性能来动态确定规约操作请求排序，从而确定规约任务的分配顺序。这保证了已进入就绪状态且规约性能高的从节点可以优先分配到规约任务，从而降低了慢节点对整体性能的影响，这样才能降低规约所耗费的时间，从而提高数据规约系统对复杂环境的适应能力。

现有的mpi_reduce不支持容错。当有节点故障时，参与规约的数据或规约的中间结果数据可能会丢失，从而导致规约无法继续进行。为解决这一问题，参考图1所示，在本申请一实施例中，主节点还可以包括容错模块。该容错模块可检测故障节点，记录所有故障的从节点，并控制故障恢复。具体而言，该容错模块可用于在规约过程中根据从节点提供的心跳消息周期性检测所述从节点是否存在规约故障；当检测到从节点存在规约故障时，根据预设的规约故障处理策略处理所述规约故障。从而使得规约系统具有容错能力，提高了数据规约的可靠性。

参考图1所示，在本申请一实施例中，主节点还可以包括数据可靠性模块。该数据可靠性模块用于在规约过程中记录全局数据的存储位置及状态，并从节点出现规约故障时，发起规约故障节点上的数据备份任务。

在本申请一实施例中，从节点可以包括规约执行器等。规约执行器可以用于向主节点异步发送规约操作请求；接收所述主节点返回的规约任务；所述规约任务是由所述主节点根据规约操作请求的规约树节点队列处理规约操作请求后生成的，所述规约操作请求的规约树节点队列是由所述主节点根据多个从节点当前的规约性能动态确定的；执行所述规约任务，并在执行完所述规约任务后，向所述主节点返回的携带规约操作结果的规约消息。

参考图1所示，在本申请一实施例中，从节点还可以包括容错模块。该容错模块可用于在规约过程中周期性向所述主节点提供心跳消息，以供所述主节点进行故障检测。此外，该容错模块在接收到某个从节点故障事件后，还可以进行容错响应。容错响应的策略是根据当前故障的影响范围来决定的，如果故障的从节点正好在进行规约任务计算，那故障发生后，主节点可以重新生成这个任务，并重新调度给其他节点进行计算。如果发生故障的节点已经提交过任务了，那故障不会影响规约结果，可以忽略。此外，故障节点上所备份的原始规约数据还可以进行转移，以确保数据的可靠性。

参考图1所示，在本申请一实施例中，从节点还可以包括数据可靠性模块。该数据可靠性模块可用于在规约前将本地的待规约数据异步发送给非本地从节点进行备份；在规约过程中记录本地数据的存储位置及状态，并在从节点出现规约故障时，接收并处理主节点分配的数据备份任务。数据可靠性模块的目的是通过可靠性存储保证原始规约数据的可靠性。可靠性存储的具体实现可以是将原始规约数据通过多副本机制写在一个或多个非本地从节点的本地盘上。在一示例性实施例中，默认的副本数量可以为2。此外，当有从节点故障时，数据可靠性模块还可以将该从节点磁盘上的原始规约数据重新在其他从节点上恢复出来。

现有的mpi_reduce不支持内存资源控制。如此，当上层并行应用同时发起大量的异步规约时，尤其是当每个异步规约的完成时间又比较长时，这就需要大量的数据存储在内存中，然而，当内存资源不够时，根据现有的mpi_reduce标准，mpi_reduce将报错。为解决这一问题，参考图1所示，在本申请一实施例中，该从节点还可以包括槽管理器。槽管理器可用于申请执行规约任务的槽空间，以便于所述规约执行器在对应分配的槽空间下执行所述规约任务。槽管理器可通过槽机制对规约用到的内存空间进行管理和控制。槽机制的目标是保证内存不会被过度使用，具体实现方式例如可以是在槽空间不足时，将规约数据换出到磁盘上，等到需要计算时再将数据换入到内存中。此外，槽管理器还可以通过实时维护一系列计数器来表征当前从节点的规约性能。这些计数器可作为规约调度器在调度规约任务时的参考指标。

在本申请一些实施例中，每个规约操作可对应一个标识符，标识符可将不同的规约操作划分到不同的域中，即每个规约操作可以是独立进行且互不干扰，例如图2所示；在图2中q表表示队列，s表示规约调度器。每个规约操作可对应一个规约调度器和一组规约执行器，其中，规约调度器位于规约的主节点上，每个从节点上都对应有一个规约执行器。规约操作可被拆分为一组规约计算任务，由规约调度器根据各个从节点的情况，动态的将规约任务到调度最优的规约执行器上。

在本申请一实施例中，数据规约系统的数据规约方法的主要流程可如图3所示。图3中，q1和q2表示队列，s表示规约调度器，w1和w2表示从节点。

其中，主节点侧的数据规约方法可以如图4所示，其可以包括如下步骤：

s401、主节点接收多个从节点异步发送的规约操作请求。

s402、所述主节点根据所述多个从节点当前的规约性能，动态确定所述规约操作请求的规约树节点队列，根据所述规约树节点队列处理所述规约操作请求并向所述从节点返回对应的规约任务。

s403、所述主节点接收所述从节点在执行完所述规约任务后返回的携带规约操作结果的规约消息。

而在本申请另一实施例中，在规约过程中，所述主节点还可以根据从节点提供的心跳消息周期性检测所述从节点是否存在规约故障；当检测到从节点存在规约故障时，所述主节点根据预设的规约故障处理策略处理所述规约故障。此外，在本申请另一实施例中，在规约过程中，所述主节点还可以记录全局数据的存储位置及状态，并从节点出现规约故障时，发起规约故障节点上的数据备份任务。

其中，从节点侧的数据规约方法可以如图5所示，其可以包括如下步骤：

s501、多个从节点向主节点异步发送规约操作请求；

s502、所述从节点接收所述主节点返回的规约任务；所述规约任务是由所述主节点根据规约操作请求的规约树节点队列处理规约操作请求后生成的，所述规约操作请求的规约树节点队列是由所述主节点根据所述多个从节点当前的规约性能动态确定的；

s503、所述从节点执行所述规约任务，并在执行完所述规约任务后，向所述主节点返回的携带规约操作结果的规约消息。

而在本申请另一实施例中，在向主节点异步发送规约操作请求之前，所述多个从节点还可以将本地的待规约数据异步发送给非本地从节点进行备份。在本申请另一实施例中，在向主节点异步发送规约操作请求之前，所述从节点还可以申请执行规约任务的槽空间；相应的，所述从节点可以在对应分配的槽空间下执行所述规约任务。在本申请另一实施例中，在规约过程中，所述从节点还可以记录本地数据的存储位置及状态，并在自身出现规约故障时，接收并处理主节点分配的数据备份任务。

在本申请一示例性实施例中，数据规约系统的数据规约方法具体流程可以包括以下步骤。其中，为便于理解和描述，本示例性实施例对初始化过程也进行了相关解释说明。方法具体如下：

步骤1、初始化数据可靠性模块。

在本示例性实施例中，默认的副本数量可以为2。当有从节点故障时，数据可靠性模块可将该从节点磁盘上的原始规约数据重新在其他从节点上恢复出来。可靠性模块的初始化过程，具体可以包括以下步骤：

步骤1.1、在从节点上，初始化存储规约数据的目录列表。从节点上的每块磁盘可对应一个目录项。

步骤1.2、在主节点上，初始化备份数据映射表。该映射表可以为键值对集合，其中键和值可以为32位整型。键可由规约操作标识符和进程号构成，规约操作标识符和进程号可以为16位整型。规约操作标识符可占据键的高16位，进程号可占据键的低16位。备份数据的映射表则可以由存储该规约数据副本的两个进程号构成，每个进程号占据16位。进程号即为对应从节点上的规约进程标识，因此进程号与从节点一一对应，进程号也可以用于标识从节点。而下文中提及的进程号亦可参见该部分对进程号的解释，在此不再赘述。

步骤1.3、在从节点上，初始化数据存储位置映射表。该映射表可以为键值对集合，其中键的类型可以为32位整型，值的类型可以为16位整型。键可以由规约操作标识符和进程号构成，规约操作标识符和进程号可以都是16位整型，规约操作标识符可以占据键的高16位，进程号可以占据键的低16位。值可以为目录标识，表示该键值对应的数据具体存储在当前从节点的哪个磁盘上。

步骤1.4、在主节点上，初始化故障进程标识符集合。该集合存储所有故障从节点的进程标识符(即进程号)。

步骤1.5、在从节点上，初始化数据写线程。规约数据的可靠性存储可以是异步进行的，所有的存储请求都可以放在存储队列中。数据写线程可依次从队列中取出存储请求并进行处理。

步骤1.6、在主节点上，初始化规约数据存储状态映射表。规约数据的存储状态可以有三种，分别为：

1)、尚未存储，表示尚未有副本被存储。

2)、1副本，表示已经有1个副本存储完毕。

3)、2副本，表示2个副本都已经存储完毕。

步骤1.7、在主节点上，初始化数据拷贝调度器。当出现从节点故障时，需要将存储在故障从节点上的数据在其他健康从节点上恢复出来。而数据拷贝调度器的功能是调度数据拷贝任务。

步骤1.8、在从节点上，初始化数据拷贝执行器。数据拷贝执行器的任务是执行数据拷贝任务。

步骤2、初始化规约管理器模块。

规约管理器模块可以包括规约执行器映射表，规约调度器映射表以及槽管理器。规约执行器映射表建立了规约操作标识符和规约执行器的映射关系。同样，规约调度器建立了规约操作标识符和规约调度器的映射关系。

步骤2.1、从节点上，初始化规约执行器映射表。规约执行器映射表可以为键值对集合，键可以为规约操作标识符，值可以为规约执行器。

步骤2.2、主节点上，初始化规约调度器映射表。规约调度器映射表可以为键值对集合，键可以为规约操作标识符，值可以为规约调度器。

步骤2.3、从节点上，初始化槽管理器。槽的初始值可以由用户指定，根据该初始值对槽管理进行一系列初始化。具体包括以下几个步骤：

步骤2.3.1、初始化槽总数、空闲槽数量、可用槽数量。

步骤2.3.2、初始化槽映射表，槽映射表可以由向量实现，记录每个槽对应于哪个规约执行器。

步骤2.3.3、初始化规约执行器-槽映射表，规约执行器-槽映射表可以为键值对集合，其中键可以为规约操作标识符，值可以为该规约执行器对应的槽编号以及槽状态。槽状态具体可以分为以下四种：

1)、data_in，表示规约数据已换入。该状态的规约数据可被换出。

2)、data_using，表示规约数据正在使用。该状态的规约数据不可以被换出。

3)、data_out，表示规约数据已被换出。该状态下的规约数据不占用任何槽空间。如果需要计算，要首先申请一个槽，然后将该规约数据换入。

4)、data_freed，表示该规约数据已被释放。该规约数据占用的槽空间也已经被释放。

步骤2.3.4、从节点上，初始化槽管理器。槽管理器可以记录所有从节点上空闲槽数量和可用槽数量。空闲槽数量指的是没有被任何规约执行器占用的槽的数量，可用槽数量指的是槽总数减去处于data_using状态的槽数。

步骤2.3.5、主节点上，初始化规约性能计数器。规约性能计数器可以记录所有从节点执行最近几次规约所耗费时间的平均值。该指标可直观的反映各从节点规约性能，可作为规约调度器在决策调度规约任务时的参考指标。而从节点上的规约执行器可定期的将这些性能参数发送给规约性能计数器。

步骤3、从节点上，规约执行器对规约数据进行可靠性存储。

规约执行器在执行规约之前，要首先对进行规约的原始数据进行可靠性存储。可靠性存储的方法是将数据存储在两个不同的非本地从节点上：本地从节点上存储一份，在非本地从节点上存储一份。具体步骤如下：

步骤3.1、在规约数据存储状态映射表可以插入一项，其中，键可以为规约操作标识符，值可以为“尚未存储”。

步骤3.2、异步的向规约数据写线程发出规约数据写请求。

步骤3.3、向主节点的数据可靠性模块请求分配一个非本地从节点。

步骤3.4、异步的向非本地从节点发出数据写请求。

步骤3.5、在得到本地数据写完成或者非本地从节点数据写完成的通知时，将该数据存储状态置为“1副本”。

步骤3.6、在两个通知(本地数据写完成通知和非本地从节点数据写完成通知)都得到之后，可以将数据存储状态置为“2副本”。

步骤3.7、向主节点通知该规约数据的可靠性存储已完成。通知中可以包括规约操作标识符、当前进程号以及存储数据副本的2个进程号。

步骤3.8、主节点将存储信息记录在备份数据映射表中。

步骤4、从节点上，申请规约计算的槽空间。

在进行规约计算之前要首先申请槽空间。槽机制可以实现对大规模高并发分布式规约操作所使用内存的统一管理，确保内存资源不会被过度使用。过度使用的内存一方面可能会导致一些规约操作空间开辟失败，导致规约失败。另一方面，过度使用的内存会让操作系统不断的对数据进行换入换出，频繁的换入换出会大幅降低规约性能，同时会显著的影响其他应用的性能。而槽机制提供了一种将大规模高并发规约操作所占用的内存全部限制在一个用户自定义大小的空间范围内。这样，既不会影响其他应用性能，又可以保证大规模规约操作可靠高效的完成。槽机制的另一个存在的必要性在于，对于异步规约操作，由于数据没有到齐时，规约操作无法进行，而这些规约对应的数据仍然占据着内存空间。通过槽机制可以将这些数据换出到磁盘上，降低对内存空间的占用。申请槽空间的具体步骤如下：

步骤4.1、如果当前空闲槽数等于0，进入步骤4.2。否则，进入步骤4.4。

步骤4.2、在规约执行器-槽映射表中可以插入一项。其中键可以为当前的规约操作标识符，值中的槽编号置可以为-1，槽状态可以设置为data_out。

步骤4.3、将规约数据写出到磁盘上，并释放占用的内存空间。

步骤4.4、搜索所有槽，找到一个可用的槽，可以记其编号为slotid。

步骤4.5、更新槽映射表，可以将槽映射表中编号为slotid的槽对应的规约操作标识符设置为当前规约操作标识符。

步骤4.6、更新规约执行器-槽映射表。在规约执行器-槽映射表中可以插入一项。其中键可以为当前的规约操作标识符，值中的槽编号可以为slotid，槽状态可以设置为data_in。

步骤5、从节点上，规约执行器可以向主节点发送规约操作请求。

在规约数据的可靠性存储完毕之后，规约执行器接着便向主节点上的规约调度器发送数据规约操作请求。本示例性实施例中，数据规约的过程仍然是以树的方式进行的，不过和传统的根据二项树算法静态的确定了树结构不同的是，本示例性实施例采用的基于任务并行模式将动态的构建一棵二叉树。基于任务的计算机制，可以确保优先进入就绪状态的规约数据优先进行规约计算。和预先确定了进程间依赖关系的二项树算法不同的是，在本示例性实施例的规约框架中，进程间的依赖关系可以是根据到达队列的先后顺序动态确定的，从而降低了慢节点对整体性能的影响。这是因为，其余节点不需要等待慢节点，可优先与已就绪节点进行计算。初始的规约数据都是二叉树的叶子节点。具体步骤如下：

步骤5.1、封装规约二叉树叶子节点。

步骤5.2、将该叶子节点发送给主节点的规约调度器。

步骤5.3、返回规约状态对象(即发送规约消息)。规约接口是一个异步调用接口，可以通过查询规约状态对象获得规约的情况。规约状态对象也提供了阻塞查询接口，该接口为get。调用规约状态对象的get方法后，只有当规约计算结束后，get方法才会返回。

步骤6、主节点上，叶子节点规约操作请求放规约树节点队列。

所有规约操作请求都可以放在规约调度器的规约树节点队列中。每个规约操作请求可以对应一个从节点。一个规约树节点可以包含发送该规约操作请求的进程号(表示计算节点)，以及一条规约路径。规约路径可以是一系列规约叶子节点的集合，表示当前的规约中间结果是由哪些原始规约数据计算得到的。将叶子节点对应的规约操作请求放规约树节点队列的步骤如下：

步骤6.1、创建一个新的规约树节点。

步骤6.2、将树节点的进程号可以设置为发送请求的进程号。

步骤6.3、设置该节点的规约路径，规约路径中可以只包含发送请求的进程号。

步骤6.4、将规约树节点放置到规约树节点队列中。

步骤7、主节点上，规约调度器处理规约操作请求。

规约调度器每次可以从规约树节点队列中取出两个从节点，并将这两个从节点调度到与这两个节点对应的两个进程中一个进程上。由该进程负责规约计算。具体步骤如下：

步骤7.1、规约调度器从规约树节点队列中取出一个节点，记作节点1。节点1对应的请求进程，记作进程1。

步骤7.2、判断该节点的规约路径是否包含了所有要规约的原始节点。如果是，进入步骤12.否则，进入步骤7.3。

步骤7.3、规约调度器从规约树节点队列中再取出一个节点，记作节点2。节点2对应的请求进程，记作进程2。

步骤7.4、规约调度器决策将规约任务调度给哪个进程。

规约调度器首先将节点1和节点2封装为一个规约任务，然后决策将该规约任务调度到哪个进程上。规约调度器需要从进程1和进程2中选择一个作为目标进程。分布式规约框架对复杂环境的适应便是在这一步完成的。规约调度器需要选择一个性能高的进程作为目标进程，这样才能降低规约所耗费的时间，从而提高在复杂环境中的规约性能。规约调度器在决策过程中参考的指标可以是各个从节点的槽计数器和各个从节点最近一次的规约性能参数。具体的决策步骤如下：

步骤7.4.1、如果进程1和进程2的空闲槽数都大于0，则选择最近一次规约性能更高的从节点作为目标进程。否则，进入步骤7.4.2。

步骤7.4.2、如果进程1的空闲槽数大于0，进程2的空闲槽数等于0，则可以选择进程1作为目标进程。否则，进入步骤7.4.3。

步骤7.4.3、如果进程1的空闲槽数等于0，进程2的空闲槽数大于0，则可以选择进程2作为目标进程。否则，进入步骤7.4.4。

步骤7.4.4、这种情况下，进程1的空闲槽数和进程2的空闲槽数都为0。进一步对比进程1和进程2的可用槽数。如果进程1和进程2的可用槽数都大于0或者都等于0，则可以选择最近一次规约性能更高的进程作为目标节点。否则，进入步骤7.4.5。

步骤7.4.5、如果进程1的可用槽数大于0，进程2的可用槽数等于0，则可以选择进程1作为目标从节点。否则，进入步骤7.4.6。

步骤7.4.6、如果进程1的可用槽数等于0，进程2的可用槽数大于0，则可以选择进程2作为目标从节点。

步骤8、从节点上，规约执行器执行规约计算。

规约执行器在接收到规约任务之后，便开始执行规约计算。规约计算过程具体可以分为以下几个步骤：

步骤8.1、从槽管理器获取一个槽空间。槽空间的获取具体分为以下几个步骤：

步骤8.1.1、根据规约操作标识符从规约执行器-槽映射表中查找当前规约执行器的槽状态。

步骤8.1.2、如果槽状态为data_in，则将槽状态置为data_using，槽空间获取结束。否则，进入步骤8.1.3。

步骤8.1.3、如果槽状态为data_out，则遍历槽空间，寻找是否有空闲槽。如果找到空闲槽(可以记该空闲槽的编号为slotid)，则更新槽映射表和规约执行器-槽映射表。可以将槽映射表位于slotid的值置为当前规约操作标识符，将当前规约标识福在规约执行器-槽映射表中对应的值的槽编号置为slotid，槽状态置为data_using。槽空间获取结束。如果遍历后没有找到槽空间，则进入步骤8.1.4。

步骤8.1.4、遍历规约执行器-槽映射表，寻找第一个状态为data_in的槽，可以记该槽的编号为slotid。将这个槽对应的规约执行器的数据换出到磁盘上。根据slotid在槽映射表中找到当前槽对应的规约操作标识符，可以记作outreducertag。根据outreducertag更新规约执行器-槽映射表，可以将outreducertag在槽映射表中对应的值的槽编号设置为-1，槽状态设置为data_out。

步骤8.1.5、将当前规约操作标识符对应的规约数据换入到内存中。更新槽映射表和规约执行器-槽映射表。将槽映射表位于slotid的值置为当前规约操作标识符，将当前规约标识福在规约执行器-槽映射表中对应的值的槽编号置为slotid，槽状态置为data_using。

步骤8.2、向兄弟从节点请求规约数据。规约任务中包含了树节点1和树节点2的信息，如果规约任务调度到了进程1上，树节点2便是兄弟节点。同样，如果规约任务调度到进程2上，树节点1便是兄弟节点。

步骤8.3、执行规约计算。

步骤8.4、向规约调度器发送新的规约操作请求。该请求对应的树节点为非叶子节点，进入步骤9。

步骤9、主节点上，非叶子节点规约操作请求放规约树节点队列。

步骤9.1、从规约操作请求中获取节点1的规约路径，可以记作path1。

步骤9.2、从规约操作请求中获取节点2的规约路径，可以记作path2。

步骤9.3、生成一个新的树节点，将树节点的进程号置为发送请求的进程号。

步骤9.4、将树节点的规约路径置为path1与path2的并集。

步骤9.5、将该树节点可以放置到树节点队列中。

步骤10、跳转到步骤7执行。

步骤11、规约过程中故障处理。

在规约过程中，故障的产生是异步的。因此，故障的处理也可以是异步的。故障发生后，影响到的模块有规约调度器，数据可靠性模块以及规约执行器。即使是同一个模块，故障在不同时间点产生时，对其影响也可以是不同的。以下分别具体说明故障产生时，各个模块如何进行故障处理。

步骤11.1、数据可靠性模块的故障处理。

容错模块检测到故障进程后，可将故障进程号传给数据可靠性模块，数据可靠性模块开始恢复故障进程所在的从节点上的数据。具体步骤如下：

步骤11.1.1、主节点上，遍历备份数据映射表找到备份从节点中包括故障从节点的键值对。根据该键值对生成数据拷贝任务。数据拷贝任务中可包含规约标识，规约进程号，有效副本存储的从节点位置。

步骤11.1.2、主节点上，针对每一个拷贝任务，在健康从节点中挑选一个从节点(例如采用随机选取的方式)，将拷贝任务调度给该从节点。

步骤11.1.3、从节点上，目标从节点接收到拷贝任务后，执行拷贝操作，在本地磁盘上也可生成一份数据副本。操作完成后，可将拷贝完成信息通知给数据可靠性模块。

步骤11.1.4、数据可靠性模块接收到完成通知后，更新备份数据映射表。

步骤11.2主节点上，规约调度器模块的故障处理。

规约调度器的故障处理分以下几种情况：

1)、规约调度器给某个进程调度任务时，该进程所在的计算从节点故障。规约调度器需要做故障处理。

2)、规约执行器在执行任务的过程中，其所在的进程出现故障，规约调度器需要重新处理该任务。

3)、规约执行器在执行任务的过程中，兄弟从节点故障，规约调度器需要重新处理该任务。

以上三种情况的具体处理步骤分别在以下的步骤11.2.1，步骤11.2.2，步骤11.2.3中介绍。

步骤11.2.1、调度规约任务到目标进程时，目标进程所在计算从节点故障。

规约任务中包含了树节点1和树节点2的信息。这里以目标进程为进程1(即树节点1对应的规约操作请求进程)为例进行说明。

步骤11.2.1.1、将树节点1按其规约路径拆分为一系列叶子节点，每个叶子节点包含且仅包含一个进程号。

步骤11.2.1.2、将每个叶子节点的置容错标志后，放回到规约树节点队列。

步骤11.2.2、规约执行器所在节点故障，规约调度器重新处理规约任务。

步骤11.2.2.1、规约调度器将任务成功调度给某个进程后，会记录这条调度信息。

步骤11.2.2.2、根据故障进程号和记录的调度信息，找到调度给该进程的规约任务。

步骤11.2.2.3、将故障进程对应的树节点拆分为一系列叶子节点，并置容错标志后，放回到规约树节点队列。

步骤11.2.2.4、将故障进程的兄弟节点对应的树节点放回到规约树节点队列中。

步骤11.2.3、规约执行器执行过程中，所在进程的兄弟节点故障，规约调度器重新处理规约任务。

步骤11.2.3.1、规约执行器发现兄弟节点故障时，可以将规约任务重新发回给规约调度器。

步骤11.2.3.2、规约调度器将故障进程对应的树节点拆分为一系列叶子节点，并置容错标志后，放回到规约树节点队列。

步骤11.2.3.3、将规约执行器所在的从节点对应的树节点放回到规约树节点队列中。

步骤11.2.4、调度故障任务时的处理策略。

规约树节点队列中存在正常的树节点，也存在置了容错标识的树节点。规约调度器每次取出来的两个从节点可能会有三种情况：两个从节点都是正常从节点，其中一个为有容错标志的从节点，两个都是容错标志的从节点。第一种情况，可以按照步骤7处理。第二种情况和第三种情况处理故障处理情况，具体可以按照如下步骤处理：

步骤11.2.4.1、如果两个从节点中有一个节点没有置容错标志，则可以将规约任务调度给健康从节点对应的进程。否则，进入步骤11.2.4.2。

步骤11.2.4.2、如果两个从节点中都置了容错标志，具体可以按照如下步骤处理。

步骤11.2.4.2.1、如果两个从节点对应的进程号都不是故障进程，则可以选择这两个进程中性能较高的从节点作为目标进程。

步骤11.2.4.2.2、如果两个从节点中，有一个从节点对应的进程为故障进程，则可以将健康进程作为目标进程。

步骤11.2.4.2.3、如果两个从节点对应的进程都为故障进程，则可以从剩余的健康且已完成规约任务的进程中，选择性能最高的进程作为目标进程。

步骤11.3、从节点上，规约执行器的故障处理。

规约执行器需要在两个方面进行故障处理：一个是处理包含容错标志从节点的规约任务时；另一个是在处理正常规约任务过程中遇到兄弟从节点故障的情况。这两种情况的处理分别在以下步骤11.3.1和步骤11.3.2中介绍。

步骤11.3.1、规约执行器处理包含容错标志从节点的规约任务。

规约执行器在处理规约任务时，该规约任务包含的两个从节点对应会有三种组合情况：1)两个从节点都是正常节点。2)其中一个从节点置了容错标志。3)两个从节点都置了容错标志。第一种组合情况，可以按照步骤8.2处理。其余两种情况的处理可按照如下步骤进行：

步骤11.3.1.1、如果其中一个从节点置了容错标志，则可以使用数据可靠性模块获取原始规约数据。

步骤11.3.1.2、如果两个从节点都置了容错标志，则这两个从节点的数据获取都可以通过数据可靠性模块得到。

步骤11.3.2、规约执行器在处理正常规约任务过程中遇到兄弟从节点故障。

规约执行器在处理正常规约任务的过程中如果遇到兄弟从节点故障而无法获得需要的规约数据时，可以按如下步骤处理。

步骤11.3.2.1、将规约任务置为task_fault状态。

步骤11.3.2.2、将规约任务重新发送给规约调度器。

步骤12、规约结束。

为了验证本发明的有效性，我们将本发明的运行时系统部署在一个高性能集群上，并使用该集群的100个进行实验。集群中每个节点配备两个intel(r)xeon(r)3.2ghze5-2667v3cpu，128gb的内存，1块1tbsata磁盘。其中，每个处理器包含8个物理核，每个节点共计有16个物理核。节点操作系统的版本为redhatenterpriselinuxserverrelease6.8(santiago)。每次规约测试的数据规模为1gb。

图6中对比了分布式规约和mpi阻塞规约接口的性能，两者性能差距不大。说明尽管分布式规约引入了槽机制，容错机制，可靠性机制等，但并未对系统的性能造成太大的影响。图7中对比了分布式规约和mpi非阻塞规约接口的性能，从该图7中可以看出，随着节点数量的不断增加，mpi非阻塞规约的性能和分布式规约的性能差距越来越大。图8对比了同时运行多个异步规约时mpi规约和分布式规约的性能，异步规约的数量从1增加到6。从图8中可以看出，随着异步规约数量的不断增加，mpi规约的性能和分布式规约的性能差距越来越大，本申请实施例的数据规约方法的性能越来越高。

由此可见，相比于传统的mpi_reduce规约接口，本申请实施例的数据规约方法，在复杂环境中比mpi_reduce具有更高的性能。并且，本申请实施例所提出的数据规约方法能支持容错处理和异步规约，同时，也对大规模、高并发规约操作实现了支持。

虽然上文描述的过程流程包括以特定顺序出现的多个操作，但是，应当清楚了解，这些过程可以包括更多或更少的操作，这些操作可以顺序执行或并行执行(例如使用并行处理器或多线程环境)。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。