CN115686813A - 一种资源调度方法、装置、电子设备和存储介质 - Google Patents

Abstract

本申请涉及计算机技术领域，提供一种资源调度方法、装置、电子设备和存储介质，用以离线任务资源与在线任务资源冲突的，其中，方法包括：在计算节点中，离线资源管理组件获取流量监测组件实时监测的各个在线任务各自对应的实际使用资源量，然后，根据各个在线任务各自对应的实际使用资源量，计算得到计算节点的当前空闲资源量，进而在计算节点的当前空前资源量发生变化时，将当前空闲资源量发送的资源调度组件。这样，针对容器集群平台，合理进行资源调度，提高资源利用率。

Description

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

技术领域

本申请涉及计算机技术领域，提供一种资源调度方法、装置、电子设备和存储介质。

背景技术

随着大数据的普及，对实时性要求并不高的批量离线作业规模越来越大，为提高资源利用率且不影响在线任务的响应时间，将离线任务和在线任务混合部署在一起逐渐成为趋势。

Kubernetes(k8s)是一种用于容器编排的资源调度管理平台，用户可以在云厂商提供的kubernetes的平台上提交任务，任务在该平台中以容器的形式运行。目标对象提交在线任务时，通常会申请更多的资源，且任务运行过程中会有波峰波谷现象，这就会造成资源得不到充分利用，尤其是在波谷时段在线任务消耗的资源较少，那么在资源空闲时段，则通过填充离线任务来提升资源利用率，这种部署方式称为在线和离线混合部署方式。

但是，离线任务通过复用在线任务的空闲资源，那么则存在与在线任务进行资源竞争，从而产生离线任务资源与在线任务资源冲突的问题，针对该问题，目前还并未提出较好的解决方案。

发明内容

本申请实施例提供一种资源调度方法、装置、电子设备和存储介质，用以解决离线任务资源与在线任务资源冲突的技术问题。

第一方面，本申请实施例提供一种资源调度方法，应用于集群包括的计算节点中，所述计算节点包括流量监测组件和离线资源管理组件，所述集群还包括主节点，所述主节点中包含资源调度组件，该方法包括：

通过所述流量监测组件，实时监测各个在线任务各自对应的实际使用资源量；

通过所述离线资源管理组件，从所述流量监测组件获取所述各个在线任务当前各自对应的实际使用资源量，并基于获得的各个实际使用资源量，确定所述计算节点的当前空闲资源量，以及在确定所述当前空闲资源量与已记录的前一次确定的历史空闲资源量不相同时，将所述当前空闲资源量发往所述资源调度组件，以使所述资源调度组件，基于所述当前空闲资源量，调度相应的空闲资源执行各个离线任务。

第二方面，本申请实施例提供一种资源调度方法，应用于集群包括的主节点中，所述主节点中包含资源调度组件，所述集群还包括计算节点，所述计算节点包括流量监测组件和离线资源管理组件，包括：

通过所述资源调度组件，接收来自所述离线资源管理组件的所述计算节点的当前空闲资源量，其中，所述当前空闲资源量是：所述离线资源管理组件，在确定所述当前空闲资源量与已记录的前一次确定的历史空闲资源量不相同时，发往所述资源调度组件的，所述当前空闲资源量是：所述离线资源管理组件根据所述流量监测组件实时获取的，所述各个在线任务当前各自对应的实际使用资源量确定的；

通过所述资源调度组件，基于所述当前空闲资源量，调度相应的空闲资源执行各个离线任务。

第三方面，本申请实施例提供一种资源调度装置，应用于集群包括的计算节点中，所述计算节点包括流量监测组件和离线资源管理组件，所述集群还包括主节点，所述主节点中包含资源调度组件，包括：

监测单元，用于通过所述流量监测组件，实时监测各个在线任务各自对应的实际使用资源量；

管理单元，用于通过所述离线资源管理组件，从所述流量监测组件获取所述各个在线任务当前各自对应的实际使用资源量，并基于获得的各个实际使用资源量，确定所述计算节点的当前空闲资源量，以及在确定所述当前空闲资源量与已记录的前一次确定的历史空闲资源量不相同时，将所述当前空闲资源量发往所述资源调度组件，以使所述资源调度组件，基于所述当前空闲资源量，调度相应的空闲资源执行各个离线任务。

可选的，所述基于获得的各个实际使用资源量，确定所述计算节点的当前空闲资源量之后，所述将所述当前空闲资源量发往所述资源调度组件之前，监测单元还用于：

将所述当前空闲资源量，记录在所述计算节点的离线资源配置文件中；

将所述当前空闲资源量发往所述资源调度组件之后，还包括：

若确定满足预设的禁止调度条件，则将预设空闲资源量发往所述资源调度组件，以使所述资源调度组件基于所述预设空闲资源量，确定不为所述各个离线任务分配资源；

若确定满足预设的恢复调度条件，则将记录的所述当前空闲资源量发往所述资源调度组件，以使所述资源调度组件基于所述当前空闲资源量，为所述各个离线任务分配资源。

第四方面，本申请实施例提供一种资源调度装置，应用于集群包括的主节点中，所述主节点中包含资源调度组件，所述集群还包括计算节点，所述计算节点包括流量监测组件和离线资源管理组件，包括：

接收单元，用于通过所述资源调度组件，接收来自所述离线资源管理组件的所述计算节点的当前空闲资源量，其中，所述当前空闲资源量是：所述离线资源管理组件，在确定所述当前空闲资源量与已记录的前一次确定的历史空闲资源量不相同时，发往所述资源调度组件的，所述当前空闲资源量是：所述离线资源管理组件根据所述流量监测组件实时获取的，所述各个在线任务当前各自对应的实际使用资源量确定的；

调度单元，用于通过所述资源调度组件，基于所述当前空闲资源量，调度相应的空闲资源执行各个离线任务。

第五方面，本申请实施例提供一种电子设备，包括处理器和存储器，其中，所述存储器存储有计算机程序，当所述计算机程序被所述处理器执行时，使得所述处理器执行上述资源调度方法的步骤。

第六方面，本申请实施例提供一种计算机可读存储介质，其包括计算机程序，当所述计算机程序在电子设备上运行时，所述计算机程序用于使所述电子设备执行上述资源调度方法的步骤。

本申请实施例中，在计算节点中，离线资源管理组件获取流量监测组件实时监测的各个在线任务各自对应的实际使用资源量，然后，根据各个在线任务各自对应的实际使用资源量，计算得到计算节点的当前空闲资源量，继而在计算节点的当前空前资源量发生变化时，将当前空闲资源量发送的资源调度组件。

这样，离线资源管理组件可以实时获取到各个在线任务各自对应的实际使用资源量，当在线任务的实际使用资源量发生变化时，离线资源管理组件可以将当前空闲资源量发送给资源调度组件，使得资源调度组件及时得到当前资源值，资源调度组件可以根据当前空前资源量合理为离线任务分配资源，提高了资源利用率，降低了计算节点的负载。此外，离线资源管理组件获取到当前空闲资源量之后直接将当前空闲资源量发送给资源调度组件，相较于进行组件重启，读取修改后的资源配置文件中写入的当前空闲资源之后，上报资源调度组件，简化了在线离线混合部署的处理流程，且无需离线资源管理组件重启，避免了组件重启带来的成本开销、重启失败等问题。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例中提供的一种可能的应用场景示意图；

图2为本申请实施例中提供的一种可能的计算节点的架构示意图；

图3为本申请实施例中提供的一种资源调度方法的流程示意图；

图4为本申请实施例中提供的一种获取空闲资源量的逻辑示意图；

图5为本申请实施例中提供的一种将空闲资源量发往资源调度组件的逻辑示意图；

图6为本申请实施例中提供的一种获取目标离线任务的逻辑示意图；

图7a为本申请实施例中提供的一种禁止调度流程的逻辑示意图；

图7b为本申请实施例中提供的一种恢复调度流程的逻辑示意图；

图8为本申请实施例中提供的一种资源调度方法的流程示意图；

图9为本申请实施例中提供的一种资源调度的组成结构示意图；

图10为本申请实施例中提供的另一种资源调度的组成结构示意图；

图11为本申请实施例中提供的一种电子设备的硬件组成结构示意图。

具体实施方式

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

下面对本申请实施例中涉及的部分概念进行介绍。

流量监测组件：用户可以在云厂商的基于kubernetes的平台上提交任务，任务以容器的形式运行，kubernetes是一个开源的，用于管理云平台中多个计算节点上的容器化的任务，Kubernetes的目标是让部署容器化的任务简单并且高效，Kubernetes的流量监测组件提供了任务部署、规划、更新以及维护的机制。

离线管理组件：该组件为本申请实施例为了解决在线和离线资源冲突的问题，在流量监测组件基础上，新增的管理组件，用于对离线任务进行资源管理，从而使得离线任务能够脱离流量监测组件的管理，避免离线任务与在线任务竞争资源。

容器(Container)：kubernetes通过部署容器方式实现任务部署，每个容器之间互相隔离，每个容器有自己的文件系统，容器之间进程不会相互影响，能区分计算资源。容器是一组受到资源限制，彼此间相互隔离的进程，每个容器进程都有自己独立的进程空间，看不到其他进程，换句话说，容器就是一种基于操作系统能力的隔离技术，使得不同的任务的进程间相互隔离，无法相互感知。

Hadoop：Hadoop是由Apache基金会发起的分布式系统基础架构，主要用于大规模数据的存储和计算。

ResourceManager：Hadoop中为作业提供的统一资源管理和调度平台的管理端(master)组件。

NodeManager：Hadoop中为作业提供的统一资源管理和调度平台的从属(slave)组件。NodeManager用于接收并运行ResourceManager分配的Hadoop任务。

在线任务在任务运行过程中，会存在资源利用的波峰波谷现象，这就会造成资源浪费，使得资源得不到充分利用，尤其是在波谷时段，会有大量的资源被闲置，那么，通过在资源空闲时段，填充离线任务复用在线任务的空闲资源，提升资源利用率，这种方式即称为在线离线混合部署方式。

为支持Hadoop作业运行在kubernetes上，通常是在kubernetes上，提交Hadoop的NodeManager的容器化的实例，并在NodeManager进程拉起后，注册到Hadoop的ResourceManager中，然后开始接收Hadoop作业。

在基于kubernetes的在线离线混合部署过程中，离线任务复用在线任务的空闲资源，由于资源是有限的，那么离线任务将与在线任务进行资源竞争，产生离线任务与在线任务之间的资源冲突的问题，针对该问题，相关技术中提供了如下解决方式：

方式一、目标对象在kubernetes中提交任务(包括离线任务和在线任务)时，申请固定任务资源，例如，Limit资源，Limit资源用于指示容器能使用的资源上限。kubernetes平台根据固定离线任务资源，为离线任务分配实际使用资源量，在离线任务运行过程中，该实际使用资源量固定不变。

然而，对于在线任务而言，在线任务的资源需求量会随着服务访问流量的变化而变化，对于离线任务而言，当在线任务的资源需求量发生变化时，离线任务的实际使用资源量也需要随之适配。而固定的实际资源使用量会导致资源利用率低，例如，当服务访问流量突增时，在线任务的资源需求量也急剧增加，而服务访问流量降低时，又会出现资源空闲。

方式二：目标对象在kubernetes中提交任务时，申请非固定任务资源，例如，Request资源，Request资源用于指示容器使用的资源下限(也可以称为最小资源需求)。kubernetes平台根据非固定离线任务资源，以及在线任务的实际使用资源量，为离线任务分配离线任务的实际使用资源量。当在线任务的实际使用资源量发生变化时，kubernetes平台修改NodeManager的资源配置文件，并重启NodeManager，以重新加载资源配置，获取当前空闲资源量，然后NodeManager将当前空闲资源量上报ResourceManager，使得ResourceManager根据当前空闲资源量，为离线任务分配资源。

然而，修改资源配置文件，并重新加载资源配置时，需要组件重启存在一定的成本开销，例如，重启过程可能持续几分钟，此外，NodeManager本身存在的资源管理机制，可能会跟新的实际使用资源量冲突，从而导致重启失败，任务异常。

由此可见，相关技术中的解决方案存在资源利用率低、成本开销大、资源更新失败等问题，本申请实施例中，在计算节点中，NodeManager获取流量监测组件实时监测的各个在线任务各自对应的实际使用资源量，然后，根据各个在线任务各自对应的实际使用资源量，计算得到计算节点的当前空闲资源量，继而在计算节点的当前空前资源量发生变化时，将当前空闲资源量发送的ResourceManager。

这样，NodeManager可以实时获取到各个在线任务各自对应的实际使用资源量，当在线任务的实际使用资源量发生变化时，NodeManager可以将当前空闲资源量发送给ResourceManager，使得ResourceManager及时得到当前资源值，ResourceManager可以根据当前空前资源量合理为离线任务分配资源，提高了资源利用率，降低了计算节点的负载。此外，NodeManager获取到当前空闲资源量之后直接将当前空闲资源量发送给ResourceManager，相较于进行组件重启，读取修改后的资源配置文件中写入的当前空闲资源之后，上报ResourceManager，简化了在线离线混合部署的处理流程，且无需NodeManager重启，避免了组件重启带来的成本开销、重启失败等问题。

在介绍完本申请实施例的设计思想之后，下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

本申请实施例提供的方案可以适用于在线离线混合部署的容器集群平台中，例如上述提及的kubernetes平台。参阅图1所示，其为本申请实施例提供的一种应用场景示意图，在该场景中，包括终端设备101、主节点102和计算节点103，一般而言，计算节点103的数量是较多的，参见图1所示的计算节点103～1至计算节点103～n。

终端设备101可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端设备101可以打开主节点102对应的容器集群平台的页面，例如通过浏览器或者客户端等打开相应的页面，用户可以通过在页面中提交自己的计算任务，该计算任务可以是在线任务，也可以是离线任务。

主节点102可以为容器集群平台的管理端，计算节点103则为容器集群平台的任务执行端。主节点102和计算节点103都可以通过服务器来实现，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

示例性的，用户在终端设备101上提交了计算任务后时，主节点102可基于负载均衡策略，为该目标计算任务确定相应的计算节点103，并将目标计算任务下发给计算节点103，从而计算节点103执行计算任务，并通过主节点102将任务结果返回给终端设备101。

在一种可能的应用场景中，本申请实施例中的集群平台一般可以采用云平台的方式，云平台是基于云技术构建的架构平台。云技术(Cloud technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。云技术基于云计算(cloud computing)商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑，技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

云计算是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。

作为云计算的基础能力提供商，会建立云计算资源池(简称云平台，一般称为IaaS(Infrastructure as a Service，基础设施即服务)平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备、网络设备。

按照逻辑功能划分，在IaaS层上可以部署PaaS(Platform as a Service，平台即服务)层，PaaS层之上再部署SaaS(Software as a Service，软件即服务)层，也可以直接将SaaS部署在IaaS上。PaaS为软件运行的平台，如数据库、web容器等。SaaS为各式各样的业务软件，如web门户网站、短信群发器等。一般来说，SaaS和PaaS相对于IaaS是上层。

在一种可能的应用场景中，本申请实施例的容器集群平台可以作为区块链(Blockchain)的实现架构，区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。

区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置(风控审计)；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理(接口适配)，然后通过共识算法将业务信息加密(共识管理)，在加密之后完整一致的传输至共享账本上(网络通信)，并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上(合约注册)，根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控节点设备健康状态等。

平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。

在实际应用中，区块链包括的各层可部署于图1所示的架构中，例如区块链的区块链底层平台、平台产品服务层可部署于各个计算节点103中，主节点102可部署应用服务层，终端设备101则可以部署区块链产品的前端应用，实现与用户层面的交互。

当然，本申请实施例提供的方法并不限用于图1所示的应用场景中，还可以用于其他可能的应用场景，本申请实施例并不进行限制。对于图1所示的应用场景的各个设备所能实现的功能将在后续的方法实施例中一并进行描述，在此先不过多赘述。

在介绍本申请实施例提供的方法之前，首先对本申请实施例的计算节点的结构进行介绍，请参见图2所示，为本申请实施例提供的计算节点的架构示意图，每个计算节点中，包括流量监测组件、离线资源管理组件。

其中，流量监测组件，用于实时监测各个在线任务各自对应的实际使用资源量。

离线资源管理组件，从流量监测组件获取各个在线任务当前各自对应的实际使用资源量，并基于获得的各个实际使用资源量，确定计算节点的当前空闲资源量，以及在确定当前空闲资源量与已记录的前一次确定的历史空闲资源量不相同时，将当前空闲资源量发往资源调度组件，以使资源调度组件，基于当前空闲资源量，调度相应的空闲资源执行各个离线任务。

在基于kubernetes的在线离线混合部署中，离线任务通过复用在线任务的空闲资源进行作业，但是空闲资源是实时变化的，因此，在线离线混合部署中的离线任务通常具备运行时间断、容错性强等特点，而Hadoop生态下的大数据作业恰好具备这些特点，因此，Hadoop适合离线任务作业。因此，在一些可能的应用场景中，kubernetes平台可以支持Hadoop作业机制，当kubernetes平台支持Hadoop作业时，离线资源管理组件可以为Hadoop中的NodeManager，资源调度组件可以为Hadoop中的ResourceManager。

本申请实施例中，通过在kubernetes平台提交Hadoop的NodeManager容器化的实例，来支持Hadoop作业运行在kubernetes上，NodeManager进程拉起后，注册到Hadoop的ResourceManager，开始接收Hadoop作业。也就是说，由Hadoop执行离线任务。

参阅图3所示，其为本申请实施例中提供的一种资源调度方法的流程示意图，该方法可以由图1中的计算节点103来执行，在下面的介绍中，主要是以容器集群平台为kubernetes平台、且kubernetes平台支持Hadoop作业，即由kubernetes执行在线任务、Hadoop执行离线任务为例进行介绍，当然，该方法同样适用于由kubernetes执行在线任务和离线任务，也适用于其他的容器集群平台，本申请对此并不进行限制。具体的，该方法的流程如下：

S301、通过流量监测组件，实时监测各个在线任务各自对应的实际使用资源量。

本申请实施例中，用户可以在容器集群平台提供的页面中提交相应的计算任务，该计算任务可以是在线任务，也可以是离线任务，相应的，容器集群平台的主节点可以基于负载均衡策略，判断执行该计算任务的一个或者多个计算节点，进而将每个计算节点所需执行的任务下发，这样，每个计算节点则可以接收到该节点所需处理的各个目标任务，该目标任务可以是在线任务，也可以是离线任务。

参阅图4所示，计算节点中还包含节点管理组件，节点管理组件用于提供在线任务的实际资源使用量，流量监测组件可预先获取计算节点的总资源量。此外，计算节点中的流量监测组件可以通过节点管理组件，实时获取在线任务的实际资源使用量。本申请实施例中，节点管理组件也可以称为代理(Agent)组件。离线资源管理组件可以调用流量监测组件的资源量获取接口，获取各个在线任务各自对应的实际使用资源量，这样，离线资源管理子组件就可以计算得到该计算节点当前的空闲资源量，进而实时更新计算节点的空闲资源量，即实时更新离线任务的可用资源量。

S302、通过离线资源管理组件，从流量监测组件获取各个在线任务当前各自对应的实际使用资源量，并基于获得的各个实际使用资源量，确定计算节点的当前空闲资源量，以及在确定当前空闲资源量与已记录的前一次确定的历史空闲资源量不相同时，将当前空闲资源量发往资源调度组件，以使资源调度组件，基于当前空闲资源量，调度相应的空闲资源执行各个离线任务。

NodeManager的所有操作都是基于命令行的方式进行的，由于NodeManager是一个单独的容器化的实例，为方便对NodeManager进行操作，提高调度效率，本申请实施例中，可以将NodeManager的命令行方式封装成一个服务(server)组件，外部直接调用应用程序接口(Application Programming Interface，API)即可对NodeManager进行各种操作，例如，启动NodeManager，获取NodeManager当前资源量等。

本申请实施例中，计算节点可以通过流量监测组件实时检测在线任务的实际使用资源量，进而通过离线资源管理组件可以基于在线任务的实际使用资源量，确定计算节点的当前空闲资源量。具体的，离线资源管理组件调用流量监测组件的资源量获取接口，获取各个在线任务当前各自对应的实际使用资源量，基于获取的各个实际使用资源量，以及计算节点的总资源量，确定计算节点的当前空闲资源量。

需要说明的是，本申请实施例中，资源包括但不限于是指内存、中央处理器(Central Processing Unit，CPU)等。计算节点的总资源量中至少包含在线资源、离线资源，还可以包含预留资源。

仅以图4中的在线任务1～在线任务3为例，NodeManager调用Agent组件的资源量获取接口，获取在线任务1～在线任务3当前各自对应的实际使用资源量，以实际使用资源量为CPU为例，其中，在线任务1～在线任务3当前各自对应的实际使用资源量分别为1核(core)、6core、3core，基于获取的各个实际使用资源量，以及计算节点的总资源量100core，其中，预留资源为10core，确定计算节点的当前空闲资源量为80core。

在一些实施例中，当计算节点的空闲资源量变化时，Hadoop离线资源也要随之更新，Hadoop离线资源可以包括ResourceManager端资源和NodeManager端资源，下面，先对ResourceManager端资源更新进行说明。

为避免计算节点调度过多的离线任务，造成离线资源挤占，需要动态更新ResourceManager端资源，考虑到避免重启NodeManage带来的成本开销，以及重启NodeManage时因资源冲突导致的重启失败问题，本申请实施例中，可以采用但不限于以下两种方式将当前空闲资源量发往资源调度组件：

方式一：调用预设的消息通知接口，将空闲资源量发送给资源调度组件。

本申请实施例中，参阅图5所示，针对Hadoop2.8之后的版本，计算节点可以调用updateNodeResource功能，将空闲资源量发送给资源调度组件，以实现ResourceManager端的资源更新，其中，updateNodeResource功能用于在ResourceManager端更新NodeManager的资源信息，资源信息包括但不限于空闲资源量。

方式二：若离线资源管理组件中还包括代理组件，则通过代理组件，在发往资源调度组件的心跳数据中，携带空闲资源量，其中，心跳数据用于表征计算节点处于运行中状态。

考虑到Hadoop2.8之前的版本不支持updateNodeResource功能，本申请实施例中，针对Hadoop2.8之前的版本，计算节点可以在离线资源管理组件发往资源调度组件的心跳数据包中，携带当前空闲资源。具体而言，计算节点采用hook NodeManager发往ResourceManager心跳的方式，仍参阅图5所示，计算节点中还包含代理组件，该转发组件也可以称为ResourceManager proxy组件。NodeManager定时向ResourceManager发送心跳数据，本申请实施例中，计算节点通过增加iptables规则，将心跳数据先发往ResourceManager Proxy组件，ResourceManager Proxy组件可以将心跳数据中携带的资源数据，修改为当前空闲资源量，再转发送给ResourceManager组件。

需要说明的是，本申请实施例中，为防止NodeManager异常重启，而读取旧的资源数据，可以在将当前空闲资源量发往ResourceManager之间，将当前空闲资源量，记录在计算节点的离线资源配置文件中。

下面，对ResourceManager端资源更新进行说明。

在一些实施例中，更新的Hadoop离线资源还包括离线资源管理组件端的离线任务的空闲资源量，若当前空闲资源量，小于各个离线任务当前的实际使用资源总量，则计算节点中的离线资源管理组件可以结束部分离线任务，以回收超过当前空闲资源量的资源，这样，通过物理隔离，降低离线任务对在线任务的干扰。

具体的，若当前空闲资源量，大于各个离线任务当前的实际使用资源总量，则通过离线资源管理组件，基于各个离线任务当前各自对应的执行状态，从各个离线任务中，筛选出执行状态为运行中状态的离线任务，作为各个候选离线任务，并基于各个候选离线任务当前各自对应的任务信息，从各个候选离线任务中，确定至少一个目标离线任务，以及结束至少一个目标离线任务。

例如，参阅图6所示，假设，离线任务包括：离线任务1～离线任务x，其中，至少离线任务2、离线任务3、离线任务4当前对应的任务状态为运行中状态，NodeManager基于离线任务1～离线任务x当前各自对应的执行状态，从各个离线任务中，至少筛选出离线任务2、离线任务3、离线任务4，作为候选离线任务，然后，基于离线任务2、离线任务3、离线任务4当前各自对应的任务信息，从离线任务2、离线任务3、离线任务4中，确定目标离线任务为离线任务2，以及结束离线任务4。

在一些实施例中，考虑到结束的离线任务到计算节点的影响，本申请实施例中，可以采用以下方式确定目标离线任务：

A1、计算节点通过离线资源管理组件，分别获取各个候选离线任务当前各自对应的任务信息；其中，每个任务信息中包含：对应的候选离线任务的实际使用资源量和任务运行时长；

A2、计算节点通过离线资源管理组件，基于获取到的各个任务信息中，包含的实际使用资源量和任务运行时长，以及基于预设的使用资源权重和运行时长权重，分别计算各个候选离线任务各自对应的任务评估值；

A3、计算节点通过离线资源管理组件，基于计算得到各个任务评估值，从各个候选离线任务中，确定至少一个目标离线任务。

需要说明的是，本申请实施例中，使用资源权重和运行时长权重，可以根据实际应用场景设定。若任务信息中还包含离线任务的资源申请量，则可以根据资源申请量和实际使用资源量，在一个离线任务的实际使用资源量大于资源申请量时，计算该离线任务的实际使用资源量与资源申请量之间的差值，并基于差值和运行时长，以及基于预设的差值权重和运行时长权重，计算得到该离线任务的任务评估值，例如，可以按照离线任务的实际使用资源量是否超出申请值、任务运行时长排序，优先结束超出申请量最大、任务运行时长最短的离线任务。

示例性的，计算节点可以通过离线资源管理组件，从各个候选离线任务中，确定至少一个目标离线任务的过程中，可以按照任务评估值的取值，对各个候选离线任务进行排序，进而从各个候选离线任务中，依次确定预设数目的目标离线任务，本申请对此不作限定。

仍以候选离线任务为离线任务2、离线任务3、离线任务4为例，假设，离线任务2、离线任务3、离线任务4的实际使用资源量，从大到小依次为：离线任务2、离线任务3、离线任务4，离线任务2、离线任务3、离线任务4的实际使用资源量，从小到大依次为：离线任务2、离线任务3、离线任务4，使用资源权重取正数，运行时长权重取负数，那么，NodeManager分别获取各个候选离线任务当前各自对应的任务信息之后，计算得到各个候选离线任务各自对应的任务评估值，按照从大到小依次为离线任务2、离线任务3、离线任务4，然后，基于计算得到各个任务评估值，从离线任务2、离线任务3、离线任务4中，确定目标离线任务为任务评估值的取值最大的离线任务2。

在一些实施例中，离线资源管理组件中还可以包含离线任务作业进行组，该离线任务作业进行组用于执行各个离线任务。计算节点可以通过将离线作业进程组发送结束(kill)的方式，结束上述目标离线任务。

在一些实施例中，kubernetes在线作业可能会出现流量突增，急需大量资源，或节点负载压力较大的时候，此时，针对离线任务可以采取禁止调度的方式，避免ResourceManager再给计算节点调度离线任务，减少离线任务对在线任务的干扰。由于NodeManager本身没有禁止调度功能，在一些实施例中，可以调用Decomission功能禁止计算节点作业，但Decomission功能位于ResourceManager端，需要增加额外组件开销。因此，本申请实施例中，将ResourceManager中NodeManager的空闲可用资源修改为0的方式，这样，到当ResourceManager发现没有可用资源，便不会继续调度离线作业。相应的，在线任务流量恢复或节点压力恢复的时候，需要从NodeManager的离线资源配置文件中读取变更之前的资源量，并更新到ResourceManager端来恢复调度。借助热更新资源功能，无需重启NodeManager，提高了调度效率。

具体的，计算节点通过离线资源管理组件，将当前空闲资源量发往资源调度组件之前，将当前空闲资源量，记录在计算节点的离线资源配置文件中，防止NodeManager异常重启，而读取旧的资源数据。

进而，将当前空闲资源量发往资源调度组件之后，存在但不限于以下两种情况：

情况一：若确定满足预设的禁止调度条件，则将预设空闲资源量发往资源调度组件，以使资源调度组件基于预设空闲资源量，确定不为各个离线任务分配资源。

需要说明的是，本申请实施例中，预设的禁止调度条件包括但不限于是：各个在线任务的实际使用资源总量在预设时长内高于预设资源总量阈值、计算节点的负载大于预设负载阈值等。

例如，参阅图7a所示，若NodeManager确定计算节点的负载大于预设阈值，则将预设空闲资源量发往ResourceManager，以使ResourceManager基于预设空闲资源量，确定不为各个离线任务分配资源，其中，预设空闲资源量为0。

情况二：若确定满足预设的恢复调度条件，则将记录的当前空闲资源量发往资源调度组件，以使资源调度组件基于当前空闲资源量，为各个离线任务分配资源。

需要说明的是，本申请实施例中，预设的恢复调度条件包括但不限于是：各个在线任务的实际使用资源总量在预设时长内不大于预设资源总量阈值、计算节点的负载不大于预设负载阈值。

例如，参阅图7b所示，若NodeManager确定计算节点的负载不大于预设阈值，则将记录的当前空闲资源量发往ResourceManager，以使ResourceManager基于当前空闲资源量为各个离线任务分配资源。

参阅图8所示，其为本申请实施例中提供的一种资源调度方法的流程示意图，该方法可以由图1中的主节点来执行，该主节点也可以称为主节点，在下面的介绍中，仍以容器集群平台为kubernetes平台、kubernetes平台支持Hadoop作业为例进行介绍，当然，该方法同样适用于其他的容器集群平台，本申请对此并不进行限制。具体的，该方法的流程如下：

S801、通过资源调度组件，接收来自离线资源管理组件的计算节点的当前空闲资源量，其中，当前空闲资源量是：离线资源管理组件，在确定当前空闲资源量与已记录的前一次确定的历史空闲资源量不相同时，发往资源调度组件的，当前空闲资源量是：离线资源管理组件根据流量监测组件实时获取的，各个在线任务当前各自对应的实际使用资源量确定的。

S802、通过资源调度组件，基于当前空闲资源量，调度相应的空闲资源执行各个离线任务。

基于相同的发明构思，本申请实施例提供一种资源调度装置。如图9所示，其为资源调度装置900的结构示意图，可以包括：

监测单元901，用于通过所述流量监测组件，实时监测各个在线任务各自对应的实际使用资源量；

管理单元902，用于通过所述离线资源管理组件，从所述流量监测组件获取所述各个在线任务当前各自对应的实际使用资源量，并基于获得的各个实际使用资源量，确定所述计算节点的当前空闲资源量，以及在确定所述当前空闲资源量与已记录的前一次确定的历史空闲资源量不相同时，将所述当前空闲资源量发往所述资源调度组件，以使所述资源调度组件，基于所述当前空闲资源量，调度相应的空闲资源执行各个离线任务。

可选的，所述从所述流量监测组件获取所述各个在线任务当前各自对应的实际使用资源量，并基于获得的各个实际使用资源量，确定所述计算节点的当前空闲资源量时，所述管理单元902具体用于：

调用所述流量监测组件的资源量获取接口，获取所述各个在线任务当前各自对应的实际使用资源量；

基于获取的各个实际使用资源量，以及所述计算节点的总资源量，确定所述计算节点的当前空闲资源量。

可选的，所述将所述当前空闲资源量发往所述资源调度组件时，所述管理单元902具体用于：

调用预设的消息通知接口，将所述空闲资源量发送给所述资源调度组件；或者，

若所述离线资源管理组件中还包括代理组件，则通过所述代理组件，在发往所述资源调度组件的心跳数据中，携带所述当前空闲资源量，其中，所述心跳数据用于表征所述计算节点处于运行中状态。

可选的，所述管理单元902还用于：

若所述当前空闲资源量，小于所述各个离线任务当前的实际使用资源总量，则基于所述各个离线任务当前各自对应的执行状态，从所述各个离线任务中，筛选出执行状态为运行中状态的离线任务，作为各个候选离线任务；

基于所述各个候选离线任务当前各自对应的任务信息，从所述各个候选离线任务中，确定至少一个目标离线任务；

结束所述至少一个目标离线任务。

可选的，每个任务信息中包含：对应的候选离线任务的实际使用资源量和任务运行时长；

则所述基于所述各个候选离线任务当前各自对应的任务信息，从所述各个候选离线任务中，确定至少一个目标离线任务时，所述管理单元902具体用于：

分别获取所述各个候选离线任务当前各自对应的任务信息；

基于获取到的各个任务信息中，包含的实际使用资源量和任务运行时长，以及基于预设的使用资源权重和运行时长权重，分别计算各个候选离线任务各自对应的任务评估值；

基于计算得到各个任务评估值，从所述各个候选离线任务中，确定所述至少一个目标离线任务。

可选的，所述基于获得的各个实际使用资源量，确定所述计算节点的当前空闲资源量之后，所述将所述当前空闲资源量发往所述资源调度组件之前，还包括：

将所述当前空闲资源量，记录在所述计算节点的离线资源配置文件中；

将所述当前空闲资源量发往所述资源调度组件之后，检测单元902还包括：

若确定满足预设的禁止调度条件，则将预设空闲资源量发往所述资源调度组件，以使所述资源调度组件基于所述预设空闲资源量，确定不为所述各个离线任务分配资源；

若确定满足预设的恢复调度条件，则将记录的所述当前空闲资源量发往所述资源调度组件，以使所述资源调度组件基于所述当前空闲资源量，为所述各个离线任务分配资源。

基于相同的发明构思，本申请实施例提供一种资源调度装置。如图10所示，其为资源调度装置1000的结构示意图，应用于集群包括的主节点中，所述主节点中包含资源调度组件，所述集群还包括计算节点，所述计算节点包括流量监测组件和离线资源管理组件，可以包括：

接收单元1001，用于通过所述资源调度组件，接收来自所述离线资源管理组件的所述计算节点的当前空闲资源量，其中，所述当前空闲资源量是：所述离线资源管理组件，在确定所述当前空闲资源量与已记录的前一次确定的历史空闲资源量不相同时，发往所述资源调度组件的，所述当前空闲资源量是：所述离线资源管理组件根据所述流量监测组件实时获取的，所述各个在线任务当前各自对应的实际使用资源量确定的；

调度单元1002，用于通过所述资源调度组件，基于所述当前空闲资源量，调度相应的空闲资源执行各个离线任务。

为了描述的方便，以上各部分按照功能划分为各模块(或单元)分别描述。当然，在实施本申请时可以把各模块(或单元)的功能在同一个或多个软件或硬件中实现。

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

所属技术领域的技术人员能够理解，本申请的各个方面可以实现为系统、方法或程序产品。因此，本申请的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

在介绍了本申请示例性实施方式的资源调度方法和装置之后，接下来，介绍根据本申请的另一示例性实施方式的电子设备。

图11是根据一示例性实施例示出的一种电子设备1200的框图，该装置包括：

处理器1110；

用于存储处理器1110可执行指令的存储器1120；

其中，处理器1110被配置为执行指令，以实现本公开实施例中的资源调度方法，例如图3或图8中所示的步骤。

在示例性实施例中，还提供了一种包括操作的存储介质，例如包括操作的存储器1120，上述操作可由电子设备1100的处理器1110执行以完成上述方法。可选地，存储介质可以是非临时性计算机可读存储介质，例如，非临时性计算机可读存储介质可以是只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、便携式紧凑盘只读存储器(Compact Disk Read Only Memory，CD-ROM)、磁带、软盘和光数据存储设备等。

基于同一发明构思，本申请还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述实施例中各种可选实现方式中提供的资源调度方法。

在一些可能的实施方式中，本申请提供的资源调度方法的各个方面还可以实现为一种程序产品的形式，其包括计算机程序，当程序产品在计算机设备上运行时，计算机程序用于使计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的资源调度方法中的步骤，例如，计算机设备可以执行如图3或图8中所示的步骤。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、RAM、ROM、可擦式可编程只读存储器(EPROM或闪存)、光纤、CD-ROM、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请的实施方式的程序产品可以采用CD-ROM并包括程序代码，并可以在计算装置上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被命令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由命令执行系统、装置或者器件使用或者与其结合使用的程序。尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

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

Claims (15)

1.一种资源调度方法，其特征在于，应用于集群包括的计算节点中，所述计算节点包括流量监测组件和离线资源管理组件，所述集群还包括主节点，所述主节点中包含资源调度组件，该方法包括：

通过所述流量监测组件，实时监测各个在线任务各自对应的实际使用资源量；

通过所述离线资源管理组件，从所述流量监测组件获取所述各个在线任务当前各自对应的实际使用资源量，并基于获得的各个实际使用资源量，确定所述计算节点的当前空闲资源量，以及在确定所述当前空闲资源量与已记录的前一次确定的历史空闲资源量不相同时，将所述当前空闲资源量发往所述资源调度组件，以使所述资源调度组件，基于所述当前空闲资源量，调度相应的空闲资源执行各个离线任务。

2.如权利要求1所述的方法，其特征在于，所述从所述流量监测组件获取所述各个在线任务当前各自对应的实际使用资源量，并基于获得的各个实际使用资源量，确定所述计算节点的当前空闲资源量，包括：

调用所述流量监测组件的资源量获取接口，获取所述各个在线任务当前各自对应的实际使用资源量；

基于获取的各个实际使用资源量，以及所述计算节点的总资源量，确定所述计算节点的当前空闲资源量。

3.如权利要求1或2所述的方法，其特征在于，所述将所述当前空闲资源量发往所述资源调度组件，包括：

调用预设的消息通知接口，将所述空闲资源量发送给所述资源调度组件；或者，

若所述离线资源管理组件中还包括代理组件，则通过所述代理组件，在发往所述资源调度组件的心跳数据中，携带所述当前空闲资源量，其中，所述心跳数据用于表征所述计算节点处于运行中状态。

4.如权利要求1或2所述的方法，其特征在于，还包括：

若所述当前空闲资源量，小于所述各个离线任务当前的实际使用资源总量，则基于所述各个离线任务当前各自对应的执行状态，从所述各个离线任务中，筛选出执行状态为运行中状态的离线任务，作为各个候选离线任务；

基于所述各个候选离线任务当前各自对应的任务信息，从所述各个候选离线任务中，确定至少一个目标离线任务；

结束所述至少一个目标离线任务。

5.如权利要求4所述的方法，其特征在于，每个任务信息中包含：对应的候选离线任务的实际使用资源量和任务运行时长；

则所述基于所述各个候选离线任务当前各自对应的任务信息，从所述各个候选离线任务中，确定至少一个目标离线任务，包括：

分别获取所述各个候选离线任务当前各自对应的任务信息；

基于获取到的各个任务信息中，包含的实际使用资源量和任务运行时长，以及基于预设的使用资源权重和运行时长权重，分别计算各个候选离线任务各自对应的任务评估值；

基于计算得到各个任务评估值，从所述各个候选离线任务中，确定所述至少一个目标离线任务。

6.如权利要求1或2所述的方法，其特征在于，所述基于获得的各个实际使用资源量，确定所述计算节点的当前空闲资源量之后，所述将所述当前空闲资源量发往所述资源调度组件之前，还包括：

将所述当前空闲资源量，记录在所述计算节点的离线资源配置文件中；

将所述当前空闲资源量发往所述资源调度组件之后，还包括：

若确定满足预设的禁止调度条件，则将预设空闲资源量发往所述资源调度组件，以使所述资源调度组件基于所述预设空闲资源量，确定不为所述各个离线任务分配资源；

若确定满足预设的恢复调度条件，则将记录的所述当前空闲资源量发往所述资源调度组件，以使所述资源调度组件基于所述当前空闲资源量，为所述各个离线任务分配资源。

7.一种资源调度方法，其特征在于，应用于集群包括的主节点中，所述主节点中包含资源调度组件，所述集群还包括计算节点，所述计算节点包括流量监测组件和离线资源管理组件，包括：

通过所述资源调度组件，接收来自所述离线资源管理组件的所述计算节点的当前空闲资源量，其中，所述当前空闲资源量是：所述离线资源管理组件，在确定所述当前空闲资源量与已记录的前一次确定的历史空闲资源量不相同时，发往所述资源调度组件的，所述当前空闲资源量是：所述离线资源管理组件根据所述流量监测组件实时获取的，所述各个在线任务当前各自对应的实际使用资源量确定的；

通过所述资源调度组件，基于所述当前空闲资源量，调度相应的空闲资源执行各个离线任务。

8.一种资源调度装置，应用于集群包括的计算节点中，所述计算节点包括流量监测组件和离线资源管理组件，所述集群还包括主节点，所述主节点中包含资源调度组件，其特征在于，包括：

监测单元，用于通过所述流量监测组件，实时监测各个在线任务各自对应的实际使用资源量；

管理单元，用于通过所述离线资源管理组件，从所述流量监测组件获取所述各个在线任务当前各自对应的实际使用资源量，并基于获得的各个实际使用资源量，确定所述计算节点的当前空闲资源量，以及在确定所述当前空闲资源量与已记录的前一次确定的历史空闲资源量不相同时，将所述当前空闲资源量发往所述资源调度组件，以使所述资源调度组件，基于所述当前空闲资源量，调度相应的空闲资源执行各个离线任务。

9.如权利要求8所述的装置，其特征在于，所述从所述流量监测组件获取所述各个在线任务当前各自对应的实际使用资源量，并基于获得的各个实际使用资源量，确定所述计算节点的当前空闲资源量时，所述管理单元具体用于：

调用所述流量监测组件的资源量获取接口，获取所述各个在线任务当前各自对应的实际使用资源量；

基于获取的各个实际使用资源量，以及所述计算节点的总资源量，确定所述计算节点的当前空闲资源量。

10.如权利要求8或9所述的装置，其特征在于，所述将所述当前空闲资源量发往所述资源调度组件时，所述管理单元具体用于：

调用预设的消息通知接口，将所述空闲资源量发送给所述资源调度组件；或者，

若所述离线资源管理组件中还包括代理组件，则通过所述代理组件，在发往所述资源调度组件的心跳数据中，携带所述当前空闲资源量，其中，所述心跳数据用于表征所述计算节点处于运行中状态。

11.如权利要求8或9所述的装置，其特征在于，所述管理单元还用于：

若所述当前空闲资源量，小于所述各个离线任务当前的实际使用资源总量，则基于所述各个离线任务当前各自对应的执行状态，从所述各个离线任务中，筛选出执行状态为运行中状态的离线任务，作为各个候选离线任务；

基于所述各个候选离线任务当前各自对应的任务信息，从所述各个候选离线任务中，确定至少一个目标离线任务；

结束所述至少一个目标离线任务。

12.如权利要求11所述的装置，其特征在于，每个任务信息中包含：对应的候选离线任务的实际使用资源量和任务运行时长；

则所述基于所述各个候选离线任务当前各自对应的任务信息，从所述各个候选离线任务中，确定至少一个目标离线任务时，所述管理单元具体用于：

分别获取所述各个候选离线任务当前各自对应的任务信息；

基于获取到的各个任务信息中，包含的实际使用资源量和任务运行时长，以及基于预设的使用资源权重和运行时长权重，分别计算各个候选离线任务各自对应的任务评估值；

基于计算得到各个任务评估值，从所述各个候选离线任务中，确定所述至少一个目标离线任务。

13.一种资源调度装置，其特征在于，应用于集群包括的主节点中，所述主节点中包含资源调度组件，所述集群还包括计算节点，所述计算节点包括流量监测组件和离线资源管理组件，包括：

接收单元，用于通过所述资源调度组件，接收来自所述离线资源管理组件的所述计算节点的当前空闲资源量，其中，所述当前空闲资源量是：所述离线资源管理组件，在确定所述当前空闲资源量与已记录的前一次确定的历史空闲资源量不相同时，发往所述资源调度组件的，所述当前空闲资源量是：所述离线资源管理组件根据所述流量监测组件实时获取的，所述各个在线任务当前各自对应的实际使用资源量确定的；

调度单元，用于通过所述资源调度组件，基于所述当前空闲资源量，调度相应的空闲资源执行各个离线任务。

14.一种电子设备，其特征在于，其包括处理器和存储器，其中，所述存储器存储有计算机程序，当所述计算机程序被所述处理器执行时，使得所述处理器执行权利要求1～6中任一所述方法的步骤，或者执行权利要求7所述方法的步骤。

15.一种计算机可读存储介质，其特征在于，其包括计算机程序，当所述计算机程序在电子设备上运行时，所述计算机程序用于使所述电子设备执行权利要求1～6中任一所述方法的步骤，或者执行权利要求7所述方法的步骤。

Images