CN114237891A - 资源调度方法、装置、电子设备及存储介质 - Google Patents

Abstract

本公开关于一种资源调度方法、装置、电子设备及存储介质。所述方法包括：通过全局管理组件接收混洗处理节点发送的资源信息，全局管理组件和所述混洗处理节点分别独立封装于计算引擎之外；通过全局管理组件从第一调度队列中获取任务的资源请求，第一调度队列用于存储任务的资源请求，资源请求是在计算引擎启动任务时发送至全局管理组件，并通过全局管理组件添加至第一调度队列中的；通过全局管理组件处理资源请求，根据混洗处理节点的资源信息，确定用于处理任务的目标混洗处理节点。根据本公开的方案，通过全局管理组件实现对混洗处理节点和任务的资源请求的全局管理，将流量均匀打散到各个混洗处理节点上，实现全局资源负载均衡。

Description

资源调度方法、装置、电子设备及存储介质

技术领域

本公开涉及计算机技术领域，尤其涉及一种资源调度方法、装置、电子设备、计算机可读存储介质、计算机程序产品。

背景技术

随着计算机技术的发展，企业内部的计算引擎，如Mapreduce(一种映射归约模型)、Spark(一种计算引擎)等任务存在shuffle(混洗)机制。混洗机制承担任务中MapTask(映射任务)、ReduceTask(归约任务)之间的数据传输。

目前，混洗机制按照局部视图模式为每个任务分配相应的节点，以对任务进行处理。在局部视图模式下，所有的节点会将自身的负载、CPU(Central Processing Unit，中央处理器)、内存等资源信息上报至远端的状态存储服务。当一个任务启动时，计算引擎中的任务管理器从状态存储服务获取全量的、已上报资源信息的混洗管理节点的资源快照。每个任务内部根据该资源快照，优先选择资源剩余较多的节点进行调度。

但是，若出现任务数量较多的情况时，各个任务获取的资源快照存在偏差，存在有多个任务同时被调度到同一个节点的情况，造成节点负载飙升，进而影响混洗处理的稳定性。

发明内容

本公开提供一种资源调度方法、装置、电子设备、计算机可读存储介质、计算机程序产品，以至少解决相关技术中存在的多个任务同时被调度到同一个混洗处理节点的情况，从而影响混洗服务稳定性的问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种资源调度方法，所述方法包括：

通过全局管理组件接收混洗处理节点发送的资源信息，所述全局管理组件和所述混洗处理节点分别独立封装于计算引擎之外；

通过所述全局管理组件从第一调度队列中获取任务的资源请求，所述第一调度队列用于存储所述任务的资源请求，所述资源请求是在所述计算引擎启动任务时发送至所述全局管理组件，并通过所述全局管理组件添加至所述第一调度队列中的；

通过所述全局管理组件处理所述资源请求，根据所述混洗处理节点的资源信息，确定用于处理所述任务的目标混洗处理节点。

在其中一个实施例中，所述全局管理组件包括任务状态服务；

所述方法还包括：

当所述计算引擎启动所述任务时，通过任务管理组件向所述全局管理组件中的所述任务状态服务发送所述任务的资源请求，所述任务管理组件为独立封装于所述计算引擎之外的组件；

通过所述任务状态服务将所述资源请求添加至所述第一调度队列。

在其中一个实施例中，用于处理所述任务的目标混洗处理节点包括与所述任务的各个分区相对应的目标混洗处理节点；

在所述确定用于处理所述任务的目标混洗处理节点之后，还包括：

通过所述全局管理组件建立所述任务的分区与所述目标混洗处理节点之间的映射关系，通过所述任务状态服务将所述映射关系发送至所述任务管理组件；

通过混洗写入节点从所述任务管理组件处获取所述映射关系，所述混洗写入节点为独立封装于所述计算引擎之外的节点，用于接收所述计算引擎中的映射任务对所述任务进行处理得到的键值数据；

当所述混洗写入节点获取对所述任务进行映射处理得到的键值数据后，按照所述映射关系，将各个所述分区的键值数据发送至与各个所述分区对应的目标混洗处理节点。

在其中一个实施例中，所述全局管理组件包括节点状态服务；所述通过全局管理组件接收混洗处理节点发送的资源信息，包括：

通过所述全局管理组件中的节点状态服务接收所述混洗处理节点发送的资源信息。

在其中一个实施例中，所述方法还包括：

当所述全局管理组件处理所述资源请求失败时，将所述资源请求添加至第二调度队列；

在满足预设的请求调度条件时，从所述第二调度队列获取所述资源请求，并重新将所述资源请求添加至所述第一调度队列。

在其中一个实施例中，所述方法还包括：

当所述全局管理组件确定所述目标混洗处理节点发生异常时，获取所述目标混洗处理节点的异常类型；

采用与所述异常类型相对应的异常处理方式，重新确定用于处理所述任务的新的目标混洗处理节点。

在其中一个实施例中，所述采用与所述异常类型相对应的异常处理方式，重新确定用于处理所述任务的新的目标混洗处理节点，包括：

当所述异常类型为第一类型时，等待预设时长后重新检测所述目标混洗处理节点的节点状态，当获取所述节点状态为正常时，继续使用所述目标混洗处理节点，所述第一类型为***能够修复的异常类型；

当所述异常类型为第二类型时，重新确定与所述任务相对应的新的目标混洗处理节点，所述第二类型为所述***不能够修复的异常类型。

根据本公开实施例的第二方面，提供一种资源调度装置，所述装置包括：

接收模块，被配置为执行通过全局管理组件接收混洗处理节点发送的资源信息，所述全局管理组件和所述混洗处理节点分别独立封装于计算引擎之外；

请求获取模块，被配置为执行通过所述全局管理组件从第一调度队列中获取任务的资源请求，所述第一调度队列用于存储所述任务的资源请求，所述资源请求是在所述计算引擎启动所述任务时发送至所述全局管理组件，并通过所述全局管理组件添加至所述第一调度队列中的；

第一资源调度模块，被配置为执行通过所述全局管理组件处理所述资源请求，根据所述混洗处理节点的资源信息，确定用于处理所述任务的目标混洗处理节点。

在其中一个实施例中，所述全局管理组件包括任务状态服务；

所述装置还包括：

请求发送模块，被配置为执行当所述计算引擎启动所述任务时，通过任务管理组件向所述全局管理组件中的所述任务状态服务发送所述任务的资源请求，所述任务管理组件为独立封装于所述计算引擎之外的组件；

第一队列更新模块，被配置为执行通过所述任务状态服务将所述资源请求添加至所述第一调度队列。

在其中一个实施例中，用于处理所述任务的目标混洗处理节点包括与所述任务的各个分区相对应的目标混洗处理节点；

所述装置还包括：

关系生成模块，被配置为执行通过所述全局管理组件建立所述任务的分区与所述目标混洗处理节点之间的映射关系，通过所述任务状态服务将所述映射关系发送至所述任务管理组件；

关系获取模块，被配置为执行通过混洗写入节点从所述任务管理组件处获取所述映射关系，所述混洗写入节点为独立封装于所述计算引擎之外的节点，用于接收所述计算引擎中的映射任务对所述任务进行处理得到的键值数据；

数据发送模块，被配置为执行当所述混洗写入节点获取对所述任务进行映射处理得到的键值数据后，按照所述映射关系，将各个所述分区的键值数据发送至与各个所述分区对应的目标混洗处理节点。

在其中一个实施例中，所述全局管理组件包括节点状态服务；所述接收模块，被配置为执行通过所述全局管理组件中的节点状态服务接收所述混洗处理节点发送的资源信息。

在其中一个实施例中，所述装置还包括：

第二队列更新模块，被配置为执行当所述全局管理组件处理所述资源请求失败时，将所述资源请求添加至第二调度队列；

第三队列更新模块，被配置为执行在满足预设的请求调度条件时，从所述第二调度队列获取所述资源请求，并重新将所述资源请求添加至所述第一调度队列。

在其中一个实施例中，所述装置还包括：

类型确定模块，被配置为执行当所述全局管理组件确定所述目标混洗处理节点发生异常时，获取所述目标混洗处理节点的异常类型；

第二资源调度模块，被配置为执行采用与所述异常类型相对应的异常处理方式，重新确定用于处理所述任务的新的目标混洗处理节点。

在其中一个实施例中，所述第二资源调度模块，被配置为执行：

当所述异常类型为第一类型时，等待预设时长后重新检测所述目标混洗处理节点的节点状态，当获取所述节点状态为正常时，继续使用所述目标混洗处理节点，所述第一类型为***能够修复的异常类型；

当所述异常类型为第二类型时，重新确定与所述任务相对应的新的目标混洗处理节点，所述第二类型为所述***不能够修复的异常类型。

根据本公开实施例的第三方面，提供一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现上述第一方面任一项所述的资源调度方法。

根据本公开实施例的第四方面，提供一种计算机可读存储介质，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行上述第一方面任一项所述的资源调度方法。

根据本公开实施例的第五方面，提供一种计算机程序产品，所述计算机程序产品中包括指令，所述指令被电子设备的处理器执行时，使得所述电子设备能够执行上述第一方面任一项所述的资源调度方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

通过在计算引擎之外部署独立封装的全局管理组件和混洗处理节点。该全局管理组件接收任务的资源请求，将资源请求存储至第一调度队列。该全局管理组件接收混洗处理节点发送的资源信息，根据混洗处理节点的资源信息，对第一调度队列中任务的资源请求进行处理，确定用于处理任务的目标混洗处理节点，从而通过全局管理组件实现对混洗处理节点和任务的资源请求的全局管理，将流量均匀打散到各个混洗处理节点上，实现全局资源负载均衡。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种资源调度方法的应用环境图。

图2是根据一示例性实施例示出的一种资源调度方法的流程图。

图3是根据一示例性实施例示出的一种对异常情况进行处理的流程图。

图4是根据一示例性实施例示出的一种对异常情况进行处理的流程示意图。

图5是根据一示例性实施例示出的一种对任务进行混洗处理的流程示意图。

图6是根据一示例性实施例示出的一种资源调度方法的流程示意图。

图7是根据一示例性实施例示出的一种资源调度装置的框图。

图8是根据一示例性实施例示出的一种电子设备的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

还需要说明的是，本公开所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于展示的数据、分析的数据等)，均为经用户授权或者经过各方充分授权的信息和数据。

本公开提供一种资源调度方法，可以应用于如图1所示的应用环境中。其中，终端110通过网络与服务器120进行交互。服务器120中部署有至少一种计算引擎，以及部署在至少一种计算引擎之外的分别独立封装的全局管理组件和混洗处理节点。服务器120通过全局管理组件实时或者定时接收混洗处理节点发送的资源信息。服务器120每获取终端110上传的任务，将任务的资源请求发送至全局管理组件，并通过全局管理组件将资源请求添加至第一调度队列。在全局管理组件对第一调度队列中任务的资源请求进行处理时，根据混洗处理节点最新上报的资源信息，确定用于处理任务的目标混洗处理节点。

其中，终端110可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑、便携式可穿戴设备。便携式可穿戴设备可为智能手表、智能手环等。服务器120可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

图2是根据一示例性实施例示出的一种资源调度方法的流程图，如图2所示，包括以下步骤。

在步骤S210中，通过全局管理组件接收混洗处理节点发送的资源信息。

其中，全局管理组件为独立封装于计算引擎之外的组件，可以有自己的属性和方法，可以但不限于用于负责全局资源调度、全局任务管理、混洗处理节点的生命周期管理、混洗处理节点的心跳请求、管理所有任务的生命周期等。

混洗处理节点为独立封装于计算引擎之外的节点，可以有自己的属性和方法，可以但不限于负责按照任务的分区对任务的数据进行聚合、排序，并溢写到远端文件***(可以为HDFS)。混洗处理节点的数量可以为多个。

具体地，每个混洗处理节点与全局管理组件连接，实时或者定时(例如，每隔S秒)地将当前自身的负载信息和剩余的资源信息上报至全局管理组件。通过全局管理组件将每个混洗处理节点的负载信息和资源信息缓存至内存中。

在步骤S220中，通过全局管理组件从第一调度队列中获取任务的资源请求，第一调度队列用于存储任务的资源请求，资源请求是在计算引擎启动任务时发送至全局管理组件，并通过全局管理组件添加至第一调度队列中的。

其中，任务可以是用户在一次算题过程中或一个事务处理中要求计算引擎所做的工作的集合。任务可以是用户通过终端设备上传至计算引擎中的，也可以通过任务调度器调度至计算引擎中。

具体地，每当计算引擎侧启动任务时，可以通过计算引擎侧的任务管理器向全局管理组件发送该任务的资源请求。通过全局管理组件将资源请求添加至第一调度队列。全局管理组件调用第一调度线程定期执行调度流程，从第一调度队列中获取待分配资源的资源请求，启动新一轮的调度流程。

一个示例中，第一调度队列可以采用顺序队列。顺序队列基于先进先出原则，先存储至第一调度队列中的资源请求会被优先处理。第一调度线程在定期执行调度流程时，则按照资源请求的存储先后顺序获取最先存储至第一调度队列的资源请求。另一个示例中，第一调度队列可以采用优先级队列。优先级基于优先级最高原则，优先处理优先级最高的资源请求。优先级可以根据任务的任务类型等确定。第一调度线程在定期执行调度流程时，则按照资源请求的优先级高低从第一调度队列中获取优先级最高的资源请求。

步骤S230中，通过全局管理组件处理资源请求，根据混洗处理节点的资源信息，确定用于处理任务的目标混洗处理节点。

具体地，全局管理组件通过第一调度线程从内存中获取各个混洗处理节点的最新上报的资源信息。按照资源信息从高到低的顺序对多个混洗处理节点进行排序，从排序后的混洗处理节点中选择排序最高(即资源最多)的混洗处理节点，作为处理任务的目标混洗处理节点。

一个实施例中，资源请求中还可以携带任务的资源需求。第一调度线程可以将资源需求与各个混洗处理节点的最新上报的资源信息进行比较，确定满足资源需求的混洗处理节点，作为目标混洗处理节点。

上述资源调度方法中，通过在计算引擎之外部署分别独立封装的全局管理组件和混洗处理节点。该全局管理组件接收任务的资源请求，将资源请求存储至第一调度队列。该全局管理组件接收混洗处理节点发送的资源信息，根据混洗处理节点的资源信息，对第一调度队列中任务的资源请求进行处理，确定用于处理任务的目标混洗处理节点，从而通过全局管理组件实现对混洗处理节点和任务的资源请求的全局管理，将流量均匀打散到各个混洗处理节点上，实现全局资源负载均衡。

在一示例性实施例中，所述方法还包括：当全局管理组件处理资源请求失败时，将资源请求添加至第二调度队列；在满足预设的请求调度条件时，从第二调度队列获取资源请求，并重新将资源请求添加至第一调度队列。

具体地，当全局管理组件确定当前没有空余的混洗处理节点，或者，当前各个混洗处理节点的资源信息不满足任务的资源需求等情况时，确定资源请求处理失败。全局管理组件可以将处理失败的资源请求添加至第二调度队列。在满足请求调度条件时，调用第二调度线程将第二调度队列中的资源请求添加至第一调度队列，以使全局管理组件能够对处理失败的资源请求进行重试。

本实施例中，通过部署资源处理请求的重试机制，以支持对处理失败的资源处理请求进行重试处理，从而能够确保任务的资源请求都能够得到有效处理，提升了资源调度的稳定性。

在一示例性实施例中，全局管理组件包括RpcService(远程过程调用服务)，该RpcService可以但不限于包括任务状态服务(SessionStateService)。当计算引擎侧的任务管理器(ApplicationMaster)启动任务时，任务管理组件随之启动。其中，任务管理组件可以与计算引擎中的任务管理器对应部署，与任务引擎中的任务管理器属于同一个进程，共享同一个JVM(Java Virtual Machine，Java虚拟机)。一个示例中，任务管理组件可以作为SDK(Software Development Kit，软件开发工具包)嵌入在计算引擎侧的任务管理器中。任务管理组件向全局管理组件中的任务状态服务发送任务的资源请求，以通过任务状态服务将资源请求添加至第一调度队列。

本实施例中，通过在全局管理组件中部署任务状态服务，使任务的资源请求能够与其他数据隔离处理，从而避免其他数据之间互相影响，确保资源请求的处理准确性。

在一示例性实施例中，全局管理组件中的远程过程调用服务还包括节点状态服务(WorkerStateService)。在步骤S210中，全局管理组件接收混洗处理节点发送的资源信息，具体可以通过以下方式实现。

具体地，各个混洗处理节点实时或者定时地将自身的负载信息和资源信息发送至全局管理组件中的节点状态服务。通过节点状态服务将接收到的负载信息以及资源信息缓存至内存中，以便第一调度线程调度时使用。

本实施例中，通过在全局管理组件中部署节点状态服务，使混洗处理节点的资源信息能够与其他数据隔离处理，从而避免与其他数据之间互相影响，确保资源信息的准确性。

在一示例性实施例中，用于处理任务的目标混洗处理节点包括与任务的各个分区相对应的目标混洗处理节点。如图3所示，在步骤S230，确定用于处理任务的目标混洗处理节点之后，还包括以下步骤：

在步骤S310中，通过全局管理组件建立任务的分区与目标混洗处理节点之间的映射关系，通过任务状态服务将映射关系发送至任务管理组件。

具体地，全局管理组件调用第一调度线程从第一调度队列中获取任务的资源请求，并获取该任务的分区。从内存中获取各个混洗处理节点最新上报的资源信息。按照资源信息从高到低的顺序对多个混洗处理节点进行排序。第一调度线程按照排序从高到低的顺序，为每个分区分配对应的目标混洗处理节点，进而建立分区和目标混洗处理节点之间的映射关系。第一调度线程将该映射关系发送至任务状态服务，以通过任务状态服务将该映射关系发送至任务管理组件。

一个示例中，任务包括A个分区，全局管理组件可以通过第一调度线程从混洗处理节点中确定出资源最多的A个混洗处理节点，将这A个混洗处理节点作为目标混洗处理节点，进而生成分区与目标混洗处理节点之间的一一对应关系。

另一个示例中，当满足分区的资源需求的混洗处理节点数量少于分区数量时，全局管理组件可以对分区进行合并处理，使同一个混洗处理节点能够处理多个分区下的数据，进而生成分区与目标混洗处理节点之间的映射关系。

在步骤S320中，通过混洗写入节点从任务管理组件处获取映射关系。

一个实施例中，混洗写入节点可以为部署在计算引擎之外的独立封装的节点。另一个实施例汇中，混洗写入节点可以与计算引擎侧的映射任务对应部署，两者可以共享同一进程。一个示例中，混洗写入节点可以作为SDK嵌入在计算引擎侧的映射任务中。

另一个实施例中，混洗写入节点和计算引擎侧的映射任务可以具备一一对应关系。一个示例中，计算引擎侧包括M个映射任务，则可以部署至少M个混洗写入节点，且存在M个混洗写入节点与映射任务一一对应，每个混洗写入节点用于对与自身对应的映射任务处理得到的键值数据进行进一步处理。

具体地，在计算引擎侧的任务管理器启动任务时，任务管理组件随之启动。计算引擎侧的任务管理器启动映射任务，与映射任务对应设置的混洗写入节点随之启动。混洗写入节点在启动后，向任务管理组件请求分区与目标混洗写入节点之间的映射关系。

在步骤S330中，当混洗写入节点获取对任务进行映射处理得到的键值数据后，按照映射关系，将各个分区的键值数据发送至与各个分区对应的目标混洗处理节点。

具体地，每个映射任务对任务进行处理，产生一系列的键值数据。对于每个映射任务输出的每个键值数据，可以通过计算每个键值的哈希值，然后采用归约任务的数量对哈希值进行取模得到每个键值数据的分区。每个映射任务将相同分区下的键值数据进行聚合，将聚合后的键值数据写入对应的混洗写入节点的本地缓冲寄存器中。当本地缓冲寄存器中键值数据的数量达到阈值时，通过与各个映射任务对应的混洗写入节点按照分区与目标混洗处理节点之间的映射关系，将各个分区对应的键值数据发送至与分区对应的目标混洗处理节点。

一个实施例中，目标混洗处理节点在接收到与各个分区对应的键值数据后，还可以按照预先部署的排序逻辑对各个分区对应的键值数据进行排序。将与各个分区相对应的排序后的键值数据存储至文件***(例如，Hadoop分布式文件***)。

本实施例中，通过部署分别独立封装的混洗写入节点和多个混洗处理节点，建立分区和混洗处理节点之间的映射关系，能够从分区维度对多个映射任务输出数据进行聚合处理，使归约任务无需从各个映射任务对应的本地文件中的拉取数据，从而可以减少数据IO(输入输出)的次数，提升混洗的输入输出效率。

在一示例性实施例中，所述方法还包括：当全局管理组件确定目标混洗处理节点发生异常时，获取目标混洗处理节点的异常类型；采用与异常类型相对应的异常处理方式，重新确定用于处理任务的新的目标混洗处理节点。

其中，异常类型可以但不限于包括连接异常(如连接超时)、混洗处理节点的缓存空间已满、CRC(Cyclic Redundancy Check，循环冗余校验)异常、宕机等，异常类型可以通过错误代码等标识。全局管理组件中部署有与异常类型相对应的异常处理方式。全局管理组件在检测到目标混洗处理节点发生异常时，根据与异常类型相对应的异常处理方式，对发生异常的目标混洗处理节点进行处理，确定用于处理任务的新的目标混洗处理节点。

本实施例中，通过对混洗处理节点进行高可用、高容错建设，部署与异常类型相对应的异常处理方式，在混洗处理节点发生异常时，能够及时地确定新的混洗处理节点，从而能够保障任务的正常处理。

在一示例性实施例中，可以按照异常是否能被***自行修复，对异常进行分类得到第一类型和第二类型。其中，第一类型为***能够修复的异常类型，例如，连接异常(如连接超时)、混洗处理节点的缓存空间已满。第二类型为***不能够修复的异常类型，例如，CRC(Cyclic Redundancy Check，循环冗余校验)异常、chunk(数据块)不符合预期、宕机等。在本实施例中，采用与异常类型相对应的异常处理方式，重新确定用于处理任务的新的目标混洗处理节点，具体可以通过以下过程实现：

具体地，当全局管理组件确定目标混洗处理节点的异常类型为第一类型时，等待预设时长，使目标混洗处理节点能够执行重启操作。在预设时长后，全局管理组件可以通过心跳请求等方式检测目标混洗处理节点的节点状态，当确定目标混洗处理节点的状态正常时，继续使用目标混洗处理节点。

一个实施例中，若全局管理组件确定目标混洗处理节点的重启次数达到预设次数，但是，检测目标混洗处理节点的状态仍然为异常，则可以将目标混洗处理节点的异常类型更新为第二类型，并执行与第二类型对应的异常处理方式。

当全局管理组件确定目标混洗处理节点的异常类型为第二类型时，重新确定与任务对应的新的目标混洗处理节点。一个实施例中，可以重新生成该任务对应的新的资源请求，将该新的资源请求加入至第一调度队列。全局管理组件对第一调度队列中新的资源请求的处理方式可以参照上述资源请求的处理方式，在此不作具体阐述。一个实施例中，第一调度队列可以采用优先级队列。新的资源请求的优先级可以高于其他资源请求，从而使全局管理组件能够优先处理新的资源请求，加快当前任务的处理效率。

本实施例中，按照***的修复能力对异常类型进行划分，针对不同的类型采用不同的异常处理方式，能够减轻***处理异常节点的压力，进而有助于优化混洗服务的整体性能。

图4示例性示出了一种混洗处理节点的异常处理方式，具体可以通过以下步骤实现。

在步骤S402中，混洗写入节点获取与自身对应的映射任务处理得到的键值数据，将键值数据发送至目标混洗处理节点中的数据块远程调用服务。

在步骤S404中，若目标混洗处理节点对键值数据处理失败，则向混洗写入节点发送异常通知。异常通知中携带异常类型。

在步骤S406中，混洗写入节点将目标混洗处理节点的异常类型上报至任务管理组件。

在步骤S408中，任务管理组件向全局管理组件发送任务的新的资源请求，当异常类型为第一类型时，尝试重新启动目标混洗处理节点。当异常类型为第二类型时，全局管理组件确定新的目标混洗处理节点，并继续执行步骤S410～步骤S414。

在步骤S410中，全局管理组件将任务与新的目标混洗处理节点之间的映射关系发送至任务管理组件。

在步骤S412中，任务管理组件将任务与新的目标混洗处理节点之间的映射关系发送至混洗写入节点。

在步骤S414中，混洗写入节点根据该映射关系，将数据流切换至新的目标混洗处理节点。

图5是根据一示例性实施例示出的一种对任务进行处理的流程示意图，如图5所示，该方法应用于在计算引擎之外独立部署的混洗服务。混洗服务包括分别独立封装的任务管理组件(App Shuffle Master，ASM)、全局管理组件(Shuffle Master)、混洗写入节点(Shuffle Writer)、混洗处理节点(Shuffle Worker)、混洗读取节点(Shuffle Reader)。以下对各个组件/节点的功能进行说明。

全局管理组件：负责全局资源调度、全局任务管理、混洗处理节点的生命周期管理、混洗处理节点的心跳请求等。

任务管理组件：可以与计算引擎中的任务管理器(ApplicationMaster)对应部署，与任务管理器属于同一个进程，共享同一个JVM。一个示例中，任务管理组件可以作为SDK嵌入在任务管理器中。任务管理组件负责单个任务的资源管理、处理混洗写入节点和混洗读取节点的RPC(Remote Procedure Call，远程过程调用)请求、管理混洗写入节点和混洗读取节点的生命周期。

混洗写入节点：可以作为SDK嵌入在计算引擎侧的映射任务(Map)中，负责将映射任务处理得到的键值数据按照分区维度发送到对应的混洗处理节点上。在混洗处理节点将排序后的键值数据完全持久化之后再安全退出。

混洗处理节点：负责将键值数据按照分区维度聚合、排序，并溢写到远端HDFS中。在溢写完成后，通知任务管理组件和混洗写入节点持久化的结果。

混洗读取节点，可以与计算引擎中的归约任务(Reduce)对应部署，与归约任务属于同一个进程，共享同一个JVM。一个实施例中，混洗读取节点可以作为SDK嵌入在归约任务中。另一个实施例中，混洗读取节点和归约任务可以具备一一对应关系。混洗读取节点负责从HDFS拉取待处理的混洗文件集合，根据一致性元数据在本地做去重后返回给计算引擎侧的归约任务。

如图5所示，以任务为Mapreduce Job为例，任务的数据处理可以通过以下步骤实现。

在步骤S502中，一个Mapreduce Job(即Mapreduce中的任务管理器)启动，随之启动任务管理组件。

在步骤S504中，任务管理组件向全局管理组件申请资源，请求全局管理组件进行资源调度，确定任务的分区与目标混洗处理节点之间的映射关系。在申请成功之后开始混洗服务模式。

图6示例性示出了资源调度的流程示意图。如图6所示，可以通过以下步骤实现。

在步骤S6042中，各个混洗处理节点向全局管理组件中的节点状态服务发送当前的负载信息和资源信息。

在步骤S6044中，任务管理组件向全局管理组件中的任务状态服务发送任务的资源请求。

在步骤S6046中，通过任务状态服务将资源请求添加至第一调度队列。

在步骤S6048中，全局管理组件调用第一调度线程，通过第一调度线程从第一调度队列中获取任务的资源请求。

在步骤S6050中，第一调度线程根据各个混洗处理节点最新上报的资源信息，确定与任务的各个分区对应的目标混洗处理节点。

具体地，第一调度线程获取状态为可用的混洗处理节点。将这些混洗处理节点加入至优先级队列中。按照资源信息(例如，CPU、内存)对多个混洗处理节点进行排序。并将剩余资源最多的混洗处理节点分配给任务的各个分区，建立分区与目标混洗处理节点之间的映射关系。

在步骤S6052中，若分配成功，第一调度线程将分区与目标混洗处理节点之间的映射关系发送至任务状态服务，以通过任务状态服务将该映射关系发送至任务管理组件。

在步骤S6054中，若分配失败，第一调度线程将该任务的资源请求发送至第二调度队列。

在步骤S6056中，调用第二调度线程调度第二调度队列中的资源请求。

在步骤S6058中，调用第二调度线程将第二调度队列中的资源请求重新添加至第一调度队列，重复步骤S6048～S6054。

在步骤S506中，任务管理器启动映射任务。混洗写入节点随映射任务启动，两者共享同一进程。混洗写入节点启动后向任务管理组件获取分区与目标混洗处理节点之间的映射关系。

在步骤S508中，各个映射任务将处理得到的键值数据通过接口写入到对应的混洗写入节点的本地缓冲寄存器。再由混洗写入节点按照分区与目标混洗处理节点之间的映射关系，将缓冲寄存器中的键值数据主动发送到与分区对应的目标混洗处理节点上。

在步骤S510中，各个目标混洗处理节点按照分区维度对键值数据进行排序，并将排序后的键值数据持久化到HDFS中。

在步骤S512中，各个目标混洗处理节点将排序后的键值数据在HDFS的存储路径发送至任务管理组件。

在步骤S514中，当映射阶段完成之后，任务管理器启动归约任务，混洗读取节点随归约任务启动。启动后的混洗读取节点从任务管理组件处获取各个分区对应的存储路径。

在步骤S516中，混洗读取节点根据各个分区对应的存储路径从HDFS读取键值数据。在本地去重后将读取到的键值数据返回给计算引擎侧的归约任务。

应该理解的是，虽然上述流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，上述流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

可以理解的是，本说明书中上述方法的各个实施例之间相同/相似的部分可互相参见，每个实施例重点说明的是与其他实施例的不同之处，相关之处参见其他方法实施例的说明即可。

图7是根据一示例性实施例示出的一种资源调度装置X00框图。参照图7，该装置包括接收模块X02、请求获取模块X04、第一资源调度模块X06。

接收模块X02，被配置为执行通过全局管理组件接收混洗处理节点发送的资源信息，全局管理组件和混洗处理节点分别独立封装于计算引擎之外；请求获取模块X04，被配置为执行通过全局管理组件从第一调度队列中获取任务的资源请求，第一调度队列用于存储任务的资源请求，资源请求是在计算引擎启动任务时发送至全局管理组件，并通过全局管理组件添加至第一调度队列中的；第一资源调度模块X06，被配置为执行通过全局管理组件处理资源请求，根据混洗处理节点的资源信息，确定用于处理任务的目标混洗处理节点。

在一示例性实施例中，全局管理组件包括任务状态服务；装置X00还包括：请求发送模块，被配置为执行当计算引擎启动所述任务时，通过任务管理组件向全局管理组件中的任务状态服务发送任务的资源请求，任务管理组件为独立封装于计算引擎之外的组件；第一队列更新模块，被配置为执行通过任务状态服务将资源请求添加至第一调度队列。

在一示例性实施例中，用于处理任务的目标混洗处理节点包括与任务的各个分区相对应的目标混洗处理节点；装置X00还包括：关系生成模块，被配置为执行通过全局管理组件建立任务的分区与目标混洗处理节点之间的映射关系，通过任务状态服务将映射关系发送至任务管理组件；关系获取模块，被配置为执行通过混洗写入节点从任务管理组件处获取映射关系，混洗写入节点为独立封装于计算引擎之外的节点，用于接收计算引擎中的映射任务对任务进行处理得到的键值数据；数据发送模块，被配置为执行当混洗写入节点获取对任务进行映射处理得到的键值数据后，按照映射关系，将各个分区的键值数据发送至与各个分区对应的目标混洗处理节点。

在一示例性实施例中，全局管理组件包括节点状态服务；接收模块X02，被配置为执行通过全局管理组件中的节点状态服务接收混洗处理节点发送的资源信息。

在一示例性实施例中，装置X00还包括：第二队列更新模块，被配置为执行当全局管理组件处理资源请求失败时，将资源请求添加至第二调度队列；第三队列更新模块，被配置为执行在满足预设的请求调度条件时，从第二调度队列获取资源请求，并重新将资源请求添加至第一调度队列。

在一示例性实施例中，装置X00还包括：类型确定模块，被配置为执行当全局管理组件确定目标混洗处理节点发生异常时，获取目标混洗处理节点的异常类型；第二资源调度模块，被配置为执行采用与异常类型相对应的异常处理方式，重新确定用于处理任务的新的目标混洗处理节点。

在一示例性实施例中，第二资源调度模块，被配置为执行：当异常类型为第一类型时，等待预设时长后重新检测目标混洗处理节点的节点状态，当获取节点状态为正常时，继续使用目标混洗处理节点，第一类型为***能够修复的异常类型；当异常类型为第二类型时，重新确定与任务相对应的新的目标混洗处理节点，第二类型为***不能够修复的异常类型。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图8是根据一示例性实施例示出的一种用于资源调度的电子设备S00的框图。例如，电子设备S00可以为服务器。参照图8，电子设备S00包括处理组件S20，其进一步包括一个或多个处理器，以及由存储器S22所代表的存储器资源，用于存储可由处理组件S20的执行的指令，例如应用程序。存储器S22中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件S20被配置为执行指令，以执行上述方法。

电子设备S00还可以包括：电源组件S24被配置为执行电子设备S00的电源管理，有线或无线网络接口S26被配置为将电子设备S00连接到网络，和输入输出(I/O)接口S28。电子设备S00可以操作基于存储在存储器S22的操作***，例如Windows Server，Mac OS X，Unix，Linux，FreeBSD或类似。

在示例性实施例中，还提供了一种包括指令的计算机可读存储介质，例如包括指令的存储器S22，上述指令可由电子设备S00的处理器执行以完成上述方法。存储介质可以是计算机可读存储介质，例如，所述计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供一种计算机程序产品，所述计算机程序产品中包括指令，上述指令可由电子设备S00的处理器执行以完成上述方法。

需要说明的，上述的装置、电子设备、计算机可读存储介质、计算机程序产品等根据方法实施例的描述还可以包括其他的实施方式，具体的实现方式可以参照相关方法实施例的描述，在此不作一一赘述。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种资源调度方法，其特征在于，所述方法包括：

通过全局管理组件接收混洗处理节点发送的资源信息，所述全局管理组件和所述混洗处理节点分别独立封装于计算引擎之外；

通过所述全局管理组件从第一调度队列中获取任务的资源请求，所述第一调度队列用于存储所述任务的资源请求，所述资源请求是在所述计算引擎启动任务时发送至所述全局管理组件，并通过所述全局管理组件添加至所述第一调度队列中的；

通过所述全局管理组件处理所述资源请求，根据所述混洗处理节点的资源信息，确定用于处理所述任务的目标混洗处理节点。

2.根据权利要求1所述的资源调度方法，其特征在于，所述全局管理组件包括任务状态服务；

所述方法还包括：

当所述计算引擎启动所述任务时，通过任务管理组件向所述全局管理组件中的所述任务状态服务发送所述任务的资源请求，所述任务管理组件为独立封装于所述计算引擎之外的组件；

通过所述任务状态服务将所述资源请求添加至所述第一调度队列。

3.根据权利要求2所述的资源调度方法，其特征在于，用于处理所述任务的目标混洗处理节点包括与所述任务的各个分区相对应的目标混洗处理节点；

在所述确定用于处理所述任务的目标混洗处理节点之后，还包括：

通过所述全局管理组件建立所述任务的分区与所述目标混洗处理节点之间的映射关系，通过所述任务状态服务将所述映射关系发送至所述任务管理组件；

通过混洗写入节点从所述任务管理组件处获取所述映射关系，所述混洗写入节点为独立封装于所述计算引擎之外的节点，用于接收所述计算引擎中的映射任务对所述任务进行处理得到的键值数据；

当所述混洗写入节点获取对所述任务进行映射处理得到的键值数据后，按照所述映射关系，将各个所述分区的键值数据发送至与各个所述分区对应的目标混洗处理节点。

4.根据权利要求1～3任一项所述的资源调度方法，其特征在于，所述全局管理组件包括节点状态服务；所述通过全局管理组件接收混洗处理节点发送的资源信息，包括：

通过所述全局管理组件中的节点状态服务接收所述混洗处理节点发送的资源信息。

5.根据权利要求1～3任一项所述的资源调度方法，其特征在于，所述方法还包括：

当所述全局管理组件处理所述资源请求失败时，将所述资源请求添加至第二调度队列；

在满足预设的请求调度条件时，从所述第二调度队列获取所述资源请求，并重新将所述资源请求添加至所述第一调度队列。

6.根据权利要求1～3任一项所述的资源调度方法，其特征在于，所述方法还包括：

当所述全局管理组件确定所述目标混洗处理节点发生异常时，获取所述目标混洗处理节点的异常类型；

采用与所述异常类型相对应的异常处理方式，重新确定用于处理所述任务的新的目标混洗处理节点。

7.一种资源调度装置，其特征在于，所述装置包括：

接收模块，被配置为执行通过全局管理组件接收混洗处理节点发送的资源信息，所述全局管理组件和所述混洗处理节点分别独立封装于计算引擎之外；

请求获取模块，被配置为执行通过所述全局管理组件从第一调度队列中获取任务的资源请求，所述第一调度队列用于存储所述任务的资源请求，所述资源请求是在所述计算引擎启动任务时发送至所述全局管理组件，并通过所述全局管理组件添加至所述第一调度队列中的；

第一资源调度模块，被配置为执行通过所述全局管理组件处理所述资源请求，根据所述混洗处理节点的资源信息，确定用于处理所述任务的目标混洗处理节点。

8.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至6中任一项所述的资源调度方法。

9.一种计算机可读存储介质，其特征在于，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如权利要求1至6中任一项所述的资源调度方法。

10.一种计算机程序产品，所述计算机程序产品中包括指令，其特征在于，所述指令被电子设备的处理器执行时，使得所述电子设备能够执行如权利要求1至6任一项所述的资源调度方法。

Images