CN109408229B

CN109408229B - 一种调度方法及装置

Info

Publication number: CN109408229B
Application number: CN201811161060.6A
Authority: CN
Inventors: 凌晓
Original assignee: Huawei Technologies Co Ltd
Current assignee: Shenzhen Huawei Cloud Computing Technology Co ltd
Priority date: 2018-09-30
Filing date: 2018-09-30
Publication date: 2021-06-04
Anticipated expiration: 2038-09-30
Also published as: CN109408229A

Abstract

一种调度方法及装置，用以解决现有技术中作业等待时延较大，效率较低的问题。方法为，资源管理设备接收至少一个调度器的资源调度请求，任一个资源调度请求用于为所述调度器对应的一个作业请求资源调度；然后所述资源管理设备判断服务器集群负载是否大于设定负载阈值，所述服务器集群用于执行作业；若是，则所述资源管理设备开启缓存时间窗口，并缓存所述缓存窗口对应的时间内接收到的多个资源调度请求所对应的多个作业；所述资源管理设备在所述缓存时间窗口关闭时，按照预设规则对缓存的所述多个作业进行资源调度；否则，所述资源管理设备将接收到的资源调度请求对应的作业的资源调度结果发送给所述资源调度请求对应的调度器。

Description

一种调度方法及装置

技术领域

本申请涉及大数据分析领域，尤其涉及一种调度方法及装置。

背景技术

随着云计算的发展，数据中心需要处理的数据量与日俱增，而且面向各种各样的服务，其中，大数据分析是企业或科研机构所用到的最广泛的业务，例如基于分布式系统(如Hadoop、Spark、Storm等)进行机器学习或数据挖掘(如搜索引擎、日志分析、实时检测等)等。大数据应用通常以作业(如WordCount、Sort、PageRank等)为调度单元，由于作业通常是异构性的(应用类型不同、数据量大小不一)，而且源源不断地到达，这无疑给数据中心的资源管理和调度带来很大的挑战。

传统的集中式调度方法(如Hadoop 1.x、Borg、Kubernetes等)由于只有一个中央调度器，当数据量大的时候，效率低下；两级调度架构(如Mesos、Yarn等)虽然把资源调度与作业调度分离开，但是每个调度器却没有全局的资源视角，无法识别作业可以被放到哪些机器上执行；全分布式调度方法(如Sparrow等)虽然提升了调度速度，但是却很难实现作业合理的放置(placement)，不协调的调度方式通常导致资源利用不均；共享状态的调度架构(如Omega、Apollo等)虽然可以使得每个调度器都拥有一份集群状态的副本，但是却容易产生较大作业“饥饿”等待的问题。发展至今，混合调度方式(如Hawk、Mercury等)逐渐成为学术界与工业界的前沿研究方向。

目前，混合式调度方式为最常用的调度方法，以Hawk调度器架构为例，它是把中心化和分布式的调度策略进行了融合，也即架构中包括一个中心调度器和多个分布式调度器。首先中心调度器根据历史运行时间对作业进行估计，把作业分成“大作业”和“小作业”两大类，其中“大作业”为运行时间较长的作业，“小作业”为运行时间较短的作业；然后针对“小作业”利用分布式调度器调度，针对“大作业”利用中心调度器进行调度。

但是，上述调度方法需要对所有作业都进行时间估计，又由于作业应用类型繁多，可能会导致所需估计时间较长或出现误差，这样会产生较大作业等待时延，效率较低；并且就算能够准确划分出“大作业”和“小作业”，依然可能存在“大作业”有很多的情况，这样仍会导致作业等待时延较大。

综上，现有的调度方法存在作业时延较大，效率较低的问题。

发明内容

本申请提供一种调度方法及装置，用以解决现有技术中作业等待时延较大，效率较低的问题。

第一方面，本申请提供了一种调度方法，该方法包括：资源管理设备接收至少一个调度器的资源调度请求，任一个资源调度请求用于为所述调度器对应的一个作业请求资源调度；之后，所述资源管理设备判断服务器集群负载是否大于设定负载阈值，所述服务器集群用于执行作业；若是，则所述资源管理设备开启缓存时间窗口，并缓存所述缓存窗口对应的时长内接收到的多个资源调度请求所对应的多个作业；所述资源管理设备在所述缓存时间窗口关闭时，按照预设规则对缓存的所述多个作业进行资源调度；否则，所述资源管理设备将接收到的资源调度请求对应的作业的资源调度结果发送给发送所述资源调度请求的调度器。

通过上述方法，所述资源管理设备无需预先对作业进行划分“大作业”和“小作业”，直接根据服务器集群的负载情况灵活对作业进行资源调度，这样可以减小作业时延，提高效率。并且，当服务器集群负载超过设定负载阈值时，作业只需在一个小的缓存时间窗口内等待较短时间，在短时间内当前服务器集群的资源余量会相应增加，这样可以满足较大作业的资源需求，也就是可以避免较大作业无限等待的恶性循环。

在一个可能的设计中，所述资源管理设备按照预设规则对缓存的所述多个作业进行资源调度，具体方法可以为：所述资源管理设备按照预设评分规则，对所述多个作业分别进行评分，根据所述多个作业分别对应的评分，对所述多个作业按照评分由高到低进行排序；并按照所述多个作业的排序顺序依次进行资源调度。

通过上述方法，所述资源管理设备可以在集群服务器负载较高时成功实现对作业的资源调度。

在一个可能的设计中，所述资源管理设备可以针对所述多个作业中的任一个作业，基于所述作业的等待时延、所述作业的CPU需求大小和所述作业的内存资源需求大小确定所述作业的评分。通过上述方法，所述资源管理设备可以较为准确得到每个作业的评分，进而可以针对评分高低依次合理调度。

在一个可能的设计中，任一个作业的评分可以符合以下公式：

其中，Score_j即代表作业j的评分，N为所述多个作业的个数，N为大于1的正整数，

作业j的等待时延，

表示作业j的CPU需求大小，

表示作业j的内存资源需求大小；ω表示作业时延的权重，0.5≤ω≤1。

通过上述方法，所述资源管理设备可以得到每个作业的评分，进而可以针对评分高低依次合理调度。

在一个可能的设计中，ω可以符合以下公式：

其中，θ表示所述服务器集群负载的所述设定负载阈值，μ表示最大的资源利用率，μ＝max{μ_cpu,μ_mem}，μ_cpu表示所述服务器集群当前的CPU利用率，μ_mem表示所述服务器集群当前的内存利用率。

在一个可能的设计中，所述资源管理设备判断服务器集群负载是否大于设定负载阈值，具体方法可以为：所述资源管理设备判断所述服务器集群的资源利用率是否大于设定资源利用率阈值。

通过上述方法，所述资源管理设备可以准确判断所述服务器集群负载是否大于设定负载阈值，以使后续根据判断结果执行相应操作。

在一个可能的设计中，所述缓存时间窗口对应的时长可以是由单个作业的调度时间、所述服务器集群当前的CPU利用率和所述服务器集群当前的内存利用率确定的。

通过上述方法，所述资源管理设备可以准确确定需要缓存作业的时长，以使实现在所述缓存时间窗口对应的时长内缓存相应的作业。

在一个可能的设计中，所述缓存时间窗口对应的时长可以符合以下公式：

其中，t_job为单个作业的调度时间，t_job(short)表示小作业的调度时间，μ_cpu表示所述服务器集群当前的CPU利用率，μ_mem表示所述服务器集群当前的内存利用率。

在一种可选的实施方式中，所述资源管理设备还可以清除缓存的所述多个作业。这样可以节省资源占用，并在后续需要重新开启所述缓存时间窗口时可以成功将需要缓存的作业进行缓存。

第二方面，本申请还提供了一种资源管理设备，该资源管理设备具有实现上述第一方面方法的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。

在一个可能的设计中，所述资源管理设备的结构中包括接收单元、判断单元、中央调度单元和发送单元，这些单元可以执行上述方法示例中的相应功能，具体参见第一方面方法示例中的详细描述，此处不做赘述。

在一个可能的设计中，所述资源管理设备的结构中包括通信模块和处理器，可选的还可以包括存储器，所述通信模块用于收发数据，以及与其他设备进行通信交互，所述处理器被配置为执行上述第一方面提及的方法。所述存储器与所述处理器耦合，其保存所述资源管理设备必要的程序指令和数据。

第三方面，本申请还提供了一种计算机存储介质，所述计算机存储介质中存储有计算机可执行指令，所述计算机可执行指令在被所述计算机调用时用于使所述计算机执行上述第一方面提及的任一种方法。

第四方面，本申请还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面提及的任一种方法。

第五方面，本申请还提供了一种芯片，所述芯片与存储器相连，用于读取并执行存储器中存储的程序指令，以实现上述第一方面提及的任一种方法。

附图说明

图1为本申请提供的一种调度系统的架构示意图；

图2为本申请提供的一种调度方法的流程图；

图3为本申请提供的一种资源管理设备的结构示意图；

图4为本申请提供的一种资源管理设备的结构图。

具体实施方式

下面将结合附图对本申请作进一步地详细描述。

本申请实施例提供一种调度方法及装置，用以解决现有技术中作业等待时延较大，效率较低的问题。其中，本申请所述方法和装置基于同一发明构思，由于方法及装置解决问题的原理相似，因此装置与方法的实施可以相互参见，重复之处不再赘述。

在本申请的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。

在本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。为了更加清晰地描述本申请实施例的技术方案，下面结合附图，对本申请实施例提供的调度方法及装置进行详细说明。

图1示出了本申请实施例提供的调度方法适用的一种可能的调度系统的架构，所述调度系统的架构中包括多个调度器、资源管理设备、服务器集群。其中：

所述多个调度器可以如图1中所示的多个调度器A和多个调度器B等等所示。应理解，图1中示出调度器A(或调度器B)所示的三层可以表示三个调度器A(或调度器B)，当然也可以比三个多，这里仅以三个示例。其中，所述多个调度器可以包括多种针对不同业务(可以理解为不同作业类型等)的调度器，例如，所述调度器A可以是分布式离线作业调度器(如Hadoop scheduler)，所述调度器B可以是在线流式数据处理调度器(如streamingscheduler)。当然，调度器A和调度B还可以是其他调度器，本申请不再一一列举。

所述多个调度器中每个调度器可以接收来自客户端的作业请求，然后基于与所述资源管理设备同步的服务器集群的状态信息(也即全局资源副本，也即所述集群服务器的资源利用情况)，确定可分配给该作业的空闲资源块(也即可用的服务器中的空闲资源)后，向所述资源管理设备发起针对所述作业请求的资源调度请求。也就说，所述资源管理设备决定空闲的资源块中是否可以调度，或者哪块资源块可以调度。

所述资源管理设备也可以称为主节点(master node)，所述资源管理设备接收到调度器的资源调度请求后，确定针对该资源调度请求的调度结果并返回，也即所述资源管理设备确定可以分配给该资源调度请求针对的作业的资源分配给请求资源成功的调度器，以使调度器为针对的作业调度资源。

所述服务器集群用于被调度执行相应的作业。

在本申请中，所述资源管理设备中的验证中心(validation center)中可以增加中央调度器插件(central scheduler)，来实现服务器集群负载较高时灵活确定调度结果，而实现满足较大作业的资源需求，也就是可以避免较大作业无限等待的恶性循环。具体的，增加中央调度器插件，可以理解为所述资源管理设备中集成了中央调度器的功能。也就说本申请中的调度系统可以认为是相对于现有的共享状态调度架构(如Omega等)中的资源管理设备在功能上的进步。基于此本申请中的调度系统可以理解为是基于负载感知的协同资源调度架构，例如可以称为支持负载的协作资源调度器(load-aware cooperativeresource scheduler，LaCrs)。

本申请实施例提供的一种调度方法，适用于如图1所示的调度系统。参阅图2所示，该方法的具体流程包括：

步骤201、资源管理设备接收至少一个调度器的资源调度请求，任一个资源调度请求用于为所述调度器对应的一个作业请求资源调度。

在一种可选的实施方式中，所述至少一个调度器中任一个调度器在接收到来自客户端的作业请求后，选择了可以分配给当前作业的空闲资源块时，向所述资源管理设备发送针对所述作业的资源调度请求，以使所述资源管理设备确定所述资源调度请求对应的资源是否可以成功调度，也即确定资源调度结果。

在一种实现方式中，同一个资源可能会被多个调度器分别为不同的作业请求，也就是说所述资源管理设备会根据多个调度器的资源调度请求确定出一个调度器可以成功调度请求的资源，而给其他调度器返回调度失败的调度结果。

步骤202、所述资源管理设备判断服务器集群负载是否大于设定负载阈值，若是，则执行步骤203，否则执行步骤204。其中，所述服务器集群用于执行作业。

在一种可选的实施方式中，所述资源管理设备判断所述服务器集群负载是否大于所述设定负载阈值，具体方法可以为：所述资源管理设备判断所述服务器集群的资源利用率是否大于设定资源利用率阈值。当然，除此方法之外，还可以通过其他方法判断所述服务器集群负载是否大于所述设定负载阈值，此处不再一一列举。

例如，所述设定资源利用率的值可以设置为95％，当所述服务器集群的资源利用率大于95％时，则判定服务器集群负载是大于设定负载阈值；当所述服务器集群的资源利用率小于或者等于95％时，则判定服务器集群负载是不大于设定负载阈值。需要说明的是，95％只是一种可能的示例，还可以为其他设定值，本申请对比不做限定。

在一种可选的实施方式中，所述资源管理设备可以通过所述资源管理设备中的验证中心实现步骤202中的判断过程，所述验证中心可以被看做是判断单元，所述判断单元可以集成在所述资源管理设备的处理单元或者处理器中。

步骤203、所述资源管理设备开启缓存时间窗口，并缓存所述缓存窗口对应的时长内接收到的多个资源调度请求所对应的多个作业；所述资源管理设备在所述缓存时间窗口关闭时，按照预设规则对缓存的所述多个作业进行资源调度。

在一种示例性的方式中，所述缓存时间窗口可以被称为Cache时间窗口，所述缓存时间窗口对应的时长可以看作是一个cache周期。

在一种可选的实施方式中，所述缓存时间窗口对应的时长是可以由单个作业的调度时间、所述服务器集群当前的CPU利用率和所述服务器集群当前的内存利用率所确定的。例如，所述缓存时间窗口对应的时长可以符合以下公式一：

上述公式一中选择小作业的调度时间作为基数，是因为大作业调度时间相对较长，而本申请的优化目标即是最小化作业(尤其是大作业)的时延，Cache时间长度(即所述缓存时间窗口对应的时长t_cache)如果过长会增加无谓的等待时间开销。因此，选择小作业的调度时间可以节省等待时间开销，减小作业时延。

此外，从公式一中还可以看出，Cache时间长度与服务器集群负载高低成负相关关系：即服务器集群负载越高，Cache时间长度越短，这样所述缓存时间窗口内作业不至于积累过多，以避免一旦作业积压不能完全调度，返回调度失败的结果。

在一种可选的实施方式中，所述资源管理设备缓存所述缓存窗口对应的时长内接收到的多个资源调度请求所对应的多个作业时，可以将所述多个作业缓存至队列(Queuing)中，例如，所述队列可以记为队列Q。

在一种可选的实施方式中，所述资源管理设备按照预设规则对缓存的所述多个作业进行资源调度，具体方法可以为：所述资源管理设备按照预设评分规则，对所述多个作业(例如，队列Q中的多个作业)分别进行评分后，根据所述多个作业分别对应的评分，对所述多个作业按照评分由高到低进行排序，并按照所述多个作业的排序顺序依次进行资源调度。

在一种可选的实施方式中，所述资源管理设备可以针对所述多个作业中的任一个作业，基于所述作业的等待时延、所述作业的CPU需求大小和所述作业的内存资源需求大小来确定所述作业的评分。

示例性的，对队列Q中的多个作业进行合理的评分及排序，这里主要考虑两个关键因素：一是作业等待时延，因为在传统共享状态架构中大作业通常等待时间较长，甚至可能无限等待，所以这是本申请首要考虑的因子；二是作业所占资源的比重，为了便于对比，并且考虑到加权问题，这里对队列Q中所有作业的多维资源进行归一化的处理，最终给出的作业评分规则。例如，任一个作业的评分可以符合以下公式二：

作业j的等待时延，

表示作业j的CPU需求大小，

其中，ω可以与所述服务器集群负载的所述设定负载阈值和所述服务器集群负载的资源利用率相关。例如，ω可以符合以下公式三：

其中，上述公式三中θ表示所述服务器集群负载的所述设定负载阈值，μ表示最大的资源利用率，μ＝max{μ_cpu,μ_mem}，μ_cpu表示所述服务器集群当前的CPU利用率，μ_mem表示所述服务器集群当前的内存利用率。

从公式二和的公式三可以看出，作业时延的权重略大于资源占比的权重(1-ω)，并且服务器集群负载越高，权重差距越大，因为等待时间较长的作业优先调度，而不是单纯地把较大(资源占比较大)作业优先调度，这样对于所有等待的作业来讲更加公平。可以设想一种极端的情况，当集群到达满负载的时候，其实再考虑资源维度已经意义不大(因为都放不下了)，这时候作业时延则占了全部的比重。所以，作业时延的权重略大于资源占比的权重会使调度更加合理。

需要说明的是，上述公式二和公式三仅仅作为一种实现方法的示例，其他能满足需求的方法均可以应用，本申请对此不作限定。

在一种可选的实施方式中，所述资源管理设备清除缓存的所述多个作业，也可以理解为所述资源管理设备清空所述队列Q。

在一种可选的实施方式中，所述资源管理设备对缓存的所述多个作业进行资源调度具体为：所述资源管理设备针对每个作业的资源调度结果返回给发送针对该作业的资源调度请求的调度器。

通常情况下，所述多个作业均会被成功分配资源，即调度成功。但是，在实际中，也不排除评分较低的几个作业(即排序在后面的几个作业)不能调度(例如所需资源被占用产生资源冲突的情况)时，所述资源管理设备会返回调度失败的结果。之后，由于所述几个作业等待时间相对其他后请求的作业时间较长，因此通过评分规则在下一个Cache周期内所述几个作业可以被优先排到队列Q的头部，也即优先针对所述几个作业进行资源调度，从而可以减少等待时延。

在一种可选的实施方式中，所述资源管理设备可以通过所述资源管理设备中的中央调度器插件实现步骤203中的执行过程，所述中央调度器插件可以被看做是中央调度单元，所述中央调度单元可以集成在所述资源管理设备的处理单元或者处理器中。

步骤204、所述资源管理设备将接收到的资源调度请求对应的作业的资源调度结果发送给发送所述资源调度请求的调度器。

在步骤204中，服务器集群负载不大于设定负载阈值时，即表示当前服务器集群可以满足作业对资源需求，因此，所述资源管理设备可以通过传统的分布式调度方法完成资源调度结果的反馈。

采用本申请实施例提供的调度方法，资源管理设备接收至少一个调度器的资源调度请求，任一个资源调度请求用于为所述调度器对应的一个作业请求资源调度；然后所述资源管理设备判断服务器集群负载是否大于设定负载阈值，所述服务器集群用于执行作业；若是，则所述资源管理设备开启缓存时间窗口，并缓存所述缓存窗口对应的时间内接收到的多个资源调度请求所对应的多个作业；所述资源管理设备在所述缓存时间窗口关闭时，按照预设规则对缓存的所述多个作业进行资源调度；否则，所述资源管理设备将接收到的资源调度请求对应的作业的资源调度结果发送给所述资源调度请求对应的调度器。通过上述方法，所述资源管理设备无需预先对作业进行划分“大作业”和“小作业”，直接根据服务器集群的负载情况灵活对作业进行资源调度，这样可以减小作业时延，提高效率。并且，当服务器集群负载超过设定负载阈值时，作业只需在一个小的缓存时间窗口内等待较短时间，在短时间内当前服务器集群的资源余量会相应增加，这样可以满足较大作业的资源需求，也就是可以避免较大作业无限等待的恶性循环。

基于以上实施例，可以通过一个具体的示例对本申请提供的调度方法(也可以理解为通过LaCrs调度器的算法实现)的进行详细说明。在该示例中，所述资源管理设备以master节点为例。例如，LaCrs调度器的算法的伪代码可以为如下所示：

初始化：服务器集群负载的设定负载阈值，θ；

服务器集群负载大于设定负载阈值的标志符，heavy_load＝false；

资源操作是否被锁定，lock＝false；

当前系统时间，t_current；

被接收作业及相应调度器的二元组集合，

Cache作业及相应调度器的二元组集合，

失败作业及相应调度器的二元组集合，

返回资源调度结果集合，re＝[S_success,S_wait,S_fail]；

开始：当一个调度器S_i对应的作业请求j_i到达时：

1)如果heavy_load＝false：

a)如果lock＝true；

b)否则，如果μ≥θ：heavy_load＝true：t_stop＝t_current+t_cache；go 2)c)；

否则，如果资源冲突：

否则，给作业j_i分配资源：

2)否则：

c)如果t_current<t_stop：把二元组(S_i，j_i)添加到中央调度器(插件)的

cache中：

d)否则：

e)heavy_load＝false；lock＝true；把cache中的作业根据评分高低进行降幂排序得到队列Q；

f)遍历Q，当alloc_resource(j_i)且i<length(Q)；i++；

g)把所有元组(S_k，j_k)，0≤k<i加入集合S_success；把所有元组(S_k，j_k)，0≤k<length(Q)加入集合S_fail；

lock＝false；

返回：资源调度结果集合re。

通过上述伪代码示例介绍本申请调度方法的实现过程可以如下：

首先初始化系统参数，设定服务器集群高负载的阈值为θ(如95％)；由于开始状态服务器集群处于空载，于是服务器集群负载大于设定负载阈值的标志符heavy_load初始化为false；由于在Cache时间窗口结束以后，需要清空中央队列(即清除缓存的作业)并进行作业评分、排序及调度，在这个微小的时间片内需要对服务器集群资源操作进行临时锁定，这里采用lock来表示服务器集群资源的锁定状态，初始化为false；用t_current记录当前系统的时间；S_success表示被成功接收作业j_i及相应调度器S_i的二元组集合，初始化为空集；S_wait表示Cache时间窗口内的作业及相应调度器的二元组集合，初始化为空集；同样地，S_fail表示调度失败的作业及相应调度器的二元组集合，初始化为空集；re＝[S_success,S_wait,S_fail]即表示最终返回资源调度结果的集合；

当任意一个调度器S_i对应的作业请求j_i到达的时候，向master节点请求资源，如果当前放服务器集群处于低负载状态(即服务器集群负载不大于设定负载阈值)，即heavy_load＝false，那么a)：如果服务器集群资源操作被锁定了(即lock＝true)，则返回

即反馈资源调度失败的结果(实际中，这种情况的发生概率较低，因为只有服务器集群刚好从高负载状态转到低负载状态的时候，并且处于清空中央队列的时刻才有可能发生)；b)：否则，判断当前服务器集群资源利用率μ是否大于系统设置的设定负载阈值θ，那么，如果大于设定负载阈值，即把heavy_load修改为true，开启Cache时间窗口，并根据上述公式一计算Cache时间t_cache，把Cache截止时间设定为t_stop＝t_current+t_cache，并且跳转到步骤2)；而如果小于或等于设定负载阈值，即判断是否产生资源请求冲突的情况，如果当前请求的资源块被其他调度器抢先占用了，则返回调度失败结果

否则给作业分配资源，返回调度成功结果

如果当前服务器集群处于高负载状态(即服务器集群负载大于设定负载阈值)，即heavy_load＝true，那么c)如果当前处于Cache时间窗口内，即t_current<t_stop，则把二元组(S_i，j_i)添加到中央调度器中的Cache中(即缓存所述缓存窗口对应的时长内接收到的资源调度请求所对应的作业)，返回

d)否则，即Cache时间窗口结束(关闭)以后，则执行以下三个步骤：e)把服务器集群负载状态(即标识符)heavy_load设为false，并且把资源操作进行锁定(即lock＝true)，同时把Cache时间内的作业根据评分规则公式二进行降幂排序得到队列Q；f)遍历队列Q，如果当前服务器集群空闲资源足够，则把剩余队列中优先级最高(即排序在前边)的作业调度出列；g)把所有成功调度的作业加入集合S_success，而调度失败的作业则添加到集合S_fail中，最后返回Cache窗口内的资源调度结果

并且把资源操作锁定解除(即lock＝false)。

通过上述过程即可以实现合理资源调度，并且基于上述示例不需要预先知道作业信息(事实上获取需要预训练)或者进行复杂的分类识别(机器学习手段)，只需要跟踪当前服务器集群的负载情况(而这是很容易实现的)，根据负载状态高低判断是否要开启Cache时间窗口缓存作业。因为哪怕缓存一小段时间，当前服务器集群的资源余量即会相应增加，这样很可能可以满足较大作业的资源需求，避免了较大作业无限等待的恶性循环。而较小作业虽然在Cache窗口中可能被降低调度优先级，但是由于资源请求量小在将来的时刻内被成功调度的概率较大。另一方面，在清空中央队列的时候，采用了权衡作业时延和资源请求的评分策略，使得对于所有等待的作业更加公平。此外，Cache时间通常较小，所以中央等待队列较短，不致于造成作业积压而带来不必要的时延。也就是说可以理解本申请提出了一个新的低时延协同集中调度与分布式调度的资源管理模式，其中提出基于服务器集群负载的cache机制，并权衡时延和资源需求定义了作业评分规则，最后通过本申请的资源调度算法实现整个流程。本申请可以使得在系统处理大量异构性作业的时候，能够有效地降低平均作业时延，避免了较大作业“饥饿”等待问题，同时提高了作业吞吐量以及服务器集群资源利用率。

需要说明的是，本申请实施例提供的调度方法不限于应用于分布式的大数据处理场景，只要是关于资源分配与作业处理平台，尤其作业大量到达并且是异构性的，当有多个资源请求，而资源不能在同一时刻被共享的时候，那么本申请提供的方法均可参考移植，例如施工工地或车间作业的调度问题等等，本申请不做具体限定。

基于以上实施例，本申请实施例还提供了一种资源管理设备，用于实现图2所示的实施例提供的调度方法。参阅图3所示，所述资源管理设备300中可以包括：接收单元301、判断单元302、中央调度单元303、发送单元304。其中：接收单元301用于接收至少一个调度器的资源调度请求，任一个资源调度请求用于为所述调度器对应的一个作业请求资源调度；判断单元302用于判断服务器集群负载是否大于设定负载阈值，所述服务器集群用于执行作业；中央调度单元303用于在所述判断单元302判断结果为是的情况下则执行：开启缓存时间窗口，并缓存所述缓存窗口对应的时长内接收到的多个资源调度请求所对应的多个作业；在所述缓存时间窗口关闭时，按照预设规则对缓存的所述多个作业进行资源调度；发送单元304用于在所述判断单元302判断结果为否的情况下则执行：将接收到的资源调度请求对应的作业的资源调度结果发送给发送所述资源调度请求的调度器。

在一种可选的实施方式中，所述中央调度单元303在按照预设规则对缓存的所述多个作业进行资源调度时具体用于：按照预设评分规则，对所述多个作业分别进行评分，并根据所述多个作业分别对应的评分，对所述多个作业按照评分由高到低进行排序，并按照所述多个作业的排序顺序依次进行资源调度。

一种可选的实施方式中，所述中央调度单元303针对所述多个作业中的任一个作业，可以基于所述作业的等待时延、所述作业的CPU需求大小和所述作业的内存资源需求大小来确定所述作业的评分。一种可选的实施方式中，任一个作业的评分可以符合以下公式：

作业j的等待时延，

表示作业j的CPU需求大小，

示例性的，ω可以符合以下公式：

一种可选的实施方式中，所述判断单元302在判断服务器集群负载是否大于设定负载阈值时可以通过判断所述服务器集群的资源利用率是否大于设定资源利用率阈值来实现。

一种可选的实施方式中，所述缓存时间窗口对应的时长是由单个作业的调度时间、所述服务器集群当前的CPU利用率和所述服务器集群当前的内存利用率确定的。例如，所述缓存时间窗口对应的时长可以符合以下公式：

一种可选的实施方式中，所述中央调度单元303，还可以用于：清除缓存的所述多个作业。

采用本申请实施例提供资源管理设备，无需预先对作业进行划分“大作业”和“小作业”，直接根据服务器集群的负载情况灵活对作业进行资源调度，这样可以减小作业时延，提高效率。并且，当服务器集群负载超过设定负载阈值时，作业只需在一个小的缓存时间窗口内等待较短时间，在短时间内当前服务器集群的资源余量会相应增加，这样可以满足较大作业的资源需求，也就是可以避免较大作业无限等待的恶性循环。

需要说明的是，上述所述判断单元和所述中央调度单元可以集成与处理单元中，也就是说可以通过处理单元实现所述判断单元和所述中央调度单元的操作。

需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。在本申请的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

基于以上实施例，本申请实施例还提供了一种资源管理设备，用于实现如图2所示的调度方法。参阅图4所示，所述资源管理设备400可以包括：通信模块401、处理器402，可选的还可以包括存储器403，其中，其中，处理器402可以是中央处理器(central processingunit，CPU)，网络处理器(network processor，NP)或者CPU和NP的组合等等。处理器402还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(application-specificintegrated circuit，ASIC)，可编程逻辑器件(programmable logic device，PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device，CPLD)，现场可编程逻辑门阵列(field-programmable gate array，FPGA)，通用阵列逻辑(genericarray logic，GAL)或其任意组合。处理器402在实现上述功能时，可以通过硬件实现，当然也可以通过硬件执行相应的软件实现。

所述通信模块401、所述处理器402以及所述存储器403之间相互连接。可选的，所述通信模块401、所述处理402以及所述存储器403通过总线404相互连接；所述总线404可以是外设部件互连标准(Peripheral Component Interconnect，PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture，EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

所述通信模块401，用于与其他设备进行通信交互，即收发数据。在一种可选的实施方式中，所述通信模块401可以通过无线连接与其他设备进行通信，例如，所述通信模块401可以为RF电路、WiFi模块等。所述通信模块401也可以通过物理连接与其他设备进行通信，例如，所述通信模块401可以为通信接口或收发器。

所述处理器402，用于实现如图2所示的调度方法，具体过程可以参照以上实施例中的具体描述，此处不再赘述。

所述存储器403，用于存放程序和数据等。具体地，程序可以包括程序代码，该程序代码包括计算机操作的指令。存储器403可能包含随机存取存储器(random accessmemory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。处理器402执行存储器402所存放的程序，实现上述功能，从而实现如图2所示的调度方法。

综上所述，通过本申请实施例提供一种调度方法及装置，在该方法中，所述资源管理设备无需预先对作业进行划分“大作业”和“小作业”，直接根据服务器集群的负载情况灵活对作业进行资源调度，这样可以减小作业时延，提高效率。并且，当服务器集群负载超过设定负载阈值时，作业只需在一个小的缓存时间窗口内等待较短时间，在短时间内当前服务器集群的资源余量会相应增加，这样可以满足较大作业的资源需求，也就是可以避免较大作业无限等待的恶性循环。

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

显然，本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的精神和范围。这样，倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包括这些改动和变型在内。

Claims

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

资源管理设备接收至少一个调度器的资源调度请求，任一个资源调度请求用于为所述调度器对应的一个作业请求资源调度；

所述资源管理设备判断服务器集群负载是否大于设定负载阈值，所述服务器集群用于执行作业；

若是，则所述资源管理设备开启缓存时间窗口，并缓存所述缓存时间窗口对应的时长内接收到的多个资源调度请求所对应的多个作业；所述资源管理设备在所述缓存时间窗口关闭时，按照预设规则对缓存的所述多个作业进行资源调度；

否则，所述资源管理设备将接收到的资源调度请求对应的作业的资源调度结果发送给发送所述资源调度请求的调度器。

2.如权利要求1所述的方法，其特征在于，所述资源管理设备按照预设规则对缓存的所述多个作业进行资源调度，包括：

所述资源管理设备按照预设评分规则，对所述多个作业分别进行评分；

所述资源管理设备根据所述多个作业分别对应的评分，对所述多个作业按照评分由高到低进行排序；

所述资源管理设备按照所述多个作业的排序顺序依次进行资源调度。

3.如权利要求2所述的方法，其特征在于，所述资源管理设备按照预设评分规则，对所述多个作业分别进行评分，包括：

针对所述多个作业中的任一个作业，所述资源管理设备基于所述作业的等待时延、所述作业的CPU需求大小和所述作业的内存资源需求大小确定所述作业的评分。

4.如权利要求2或3所述的方法，其特征在于，任一个作业的评分符合以下公式：

作业j的等待时延，

表示作业j的CPU需求大小，

5.如权利要求1-3任一项所述的方法，其特征在于，所述资源管理设备判断服务器集群负载是否大于设定负载阈值，包括：

所述资源管理设备判断所述服务器集群的资源利用率是否大于设定资源利用率阈值。

6.如权利要求1-3任一项所述的方法，其特征在于，所述缓存时间窗口对应的时长是由单个作业的调度时间、所述服务器集群当前的CPU利用率和所述服务器集群当前的内存利用率确定的。

7.如权利要求1-3任一项所述的方法，其特征在于，所述缓存时间窗口对应的时长符合以下公式：

8.如权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

所述资源管理设备清除缓存的所述多个作业。

9.一种资源管理设备，其特征在于，包括：

接收单元，用于接收至少一个调度器的资源调度请求，任一个资源调度请求用于为所述调度器对应的一个作业请求资源调度；

判断单元，用于判断服务器集群负载是否大于设定负载阈值，所述服务器集群用于执行作业；

中央调度单元，用于若所述判断单元判断结果为是，则开启缓存时间窗口，并缓存所述缓存时间窗口对应的时长内接收到的多个资源调度请求所对应的多个作业；在所述缓存时间窗口关闭时，按照预设规则对缓存的所述多个作业进行资源调度；

发送单元，用于若所述判断单元判断结果为否，则将接收到的资源调度请求对应的作业的资源调度结果发送给发送所述资源调度请求的调度器。

10.如权利要求9所述的资源管理设备，其特征在于，所述中央调度单元，在按照预设规则对缓存的所述多个作业进行资源调度时，具体用于：

按照预设评分规则，对所述多个作业分别进行评分；

根据所述多个作业分别对应的评分，对所述多个作业按照评分由高到低进行排序；

按照所述多个作业的排序顺序依次进行资源调度。

11.如权利要求10所述的资源管理设备，其特征在于，所述中央调度单元，在按照预设评分规则，对所述多个作业分别进行评分时，具体用于：

针对所述多个作业中的任一个作业，基于所述作业的等待时延、所述作业的CPU需求大小和所述作业的内存资源需求大小确定所述作业的评分。

12.如权利要求10或11所述的资源管理设备，其特征在于，任一个作业的评分符合以下公式：

作业j的等待时延，

表示作业j的CPU需求大小，

13.如权利要求9-11任一项所述的资源管理设备，其特征在于，所述判断单元，在判断服务器集群负载是否大于设定负载阈值时，具体用于：

判断所述服务器集群的资源利用率是否大于设定资源利用率阈值。

14.如权利要求9-11任一项所述的资源管理设备，其特征在于，所述缓存时间窗口对应的时长是由单个作业的调度时间、所述服务器集群当前的CPU利用率和所述服务器集群当前的内存利用率确定的。

15.如权利要求9-11任一项所述的资源管理设备，其特征在于，所述缓存时间窗口对应的时长符合以下公式：

16.如权利要求9-11任一项所述的资源管理设备，其特征在于，所述中央调度单元，还用于：

清除缓存的所述多个作业。

17.一种计算机存储介质，其特征在于，所述计算机存储介质中存储有计算机可执行指令，所述计算机可执行指令在被所述计算机调用时用于使所述计算机执行上述权利要求1-8中任一项所述的方法。