CN104915407A - 一种基于Hadoop多作业环境下的资源调度方法 - Google Patents

Abstract

本发明公开了一种基于Hadoop多作业环境下的资源调度方法，包括：(1)实时采集集群负载、Hadoop平台以及硬件三方监控信息，(2)实时采集集群各计算节点上用户的作业执行监控信息，(3)汇总集群三方监控数据，建模评估节点的计算能力，并将集群节点划分为优势计算节点和劣势计算节点，(4)若节点为优势计算节点，则启动基于相似度评估的作业任务资源需求配置策略，(5)若节点为劣势计算节点，则还原为Yarn默认的资源需求配置策略。本发明解决了Yarn现有资源调度器中任务资源需求划分粒度过大导致的资源碎片问题，能够综合考虑集群节点和作业的异构性，通过合理、有效地分配节点资源增加集群执行并发度，从而提高Hadoop集群多作业的执行效率。

Description

一种基于Hadoop多作业环境下的资源调度方法

技术领域

本发明属于大数据技术领域，更具体地，涉及一种基于Hadoop多作业环境下的资源调度方法。

背景技术

随着大数据与互联网时代来临，大数据技术目前已成为学术界和产业界的研究热点，而Hadoop作为开源的大数据处理平台不论在企业还是学术科研领域都已经得到了广泛应用。但是第1代Hadoop在使用中存在单点故障、资源利用率低、无法支持多种计算框架等实际问题。为克服上述缺点，Apache推出了第2代Hadoop，将资源管理模块构建成了一个独立的通用资源管理系统Yarn，统一负责集群的资源分配以及任务调度。Yarn能够让多种计算框架(MapReduce、内存计算框架Spark、流式计算框架Strom和图计算框架等)运行在一个集群中，为不同的并行化计算提供统一的资源分配服务，使得集群具有易于运维、资源弹性可伸缩和数据可共享等优点。其中，资源调度器是Hadoop Yarn中最核心的组件之一，Yarn的资源调度策略会直接影响集群的任务分配，从而影响Hadoop集群整体性能。

目前Yarn主要自带以下三种常用资源调度器：①FIFO调度器(First InFirst Out Scheduler)：先来先服务资源调度器，Hadoop按照作业提交顺序依次运行这些作业；②计算能力调度器(Capacity Scheduler)：是Yarn中默认的资源调度器，适用于多用户共享集群，采用队列的形式分配和调度集群资源，每个队列可设定一定比例的资源最低保证和使用上限，同时，每个用户也可设定一定的资源使用上限以防止资源滥用；③公平调度器(FairScheduler)：以队列为单位划分资源，支持分级队列，允许每个队列单独配置调度策略，包括FIFO、Fair和DRF，即先来先服务、公平调度和主资源公平调度。

Yarn已有的资源调度策略虽然十分多样化，但仍存在明显的缺陷。一方面，在实际运行环境中，Hadoop集群多为异构集群，集群中各计算节点的综合计算能力存在较大差异，而Yarn常规的静态任务资源分配策略无法感知不同节点的异构性，无法根据集群中异构节点的计算能力、作业执行监控状况和资源使用情况动态调整节点上运行的任务数目，间接导致集群所有计算节点上的并发度一样；另一方面，Yarn现有的资源调度算法并未考虑用户提交的作业之间的区别，即未考虑不同类型的作业以及同作业不同执行阶段实际资源需求的异构性，存在大量资源碎片的现象，导致Hadoop平台无法充分利用集群资源，例如很多作业任务可能是io密集型的，消耗的cpu资源非常少，如果此时资源调度器为它分配一整个单位的cpu，剩余的cpu碎片资源无法让其他作业任务使用，是一种严重的资源浪费，会极大程度上地降低系统资源的利用率，减少作业任务执行的并发度，从而直接影响集群作业的执行效率，最终导致Hadoop整体性能下降。

综上所述，Hadoop2.0现有的资源调度策略未考虑集群节点和作业的异构性，无法根据节点的处理能力、作业执行监控状况和资源使用情况动态改变作业的资源需求，无法同时保证作业任务的高效并发和集群资源的充分利用，从而导致系统整体性能下降。

发明内容

针对现有资源调度技术的缺陷，本发明的目的在于提供一种能够根据集群节点异构性、作业执行监控状况和资源使用情况动态调整资源需求的资源调度方法，旨在解决目前已有资源调度策略导致的集群整体资源利用率低、系统性能差的问题。

本发明提供了一种基于Hadoop多作业环境下的资源调度方法，其具体步骤如下：

(1)实时采集集群负载、Hadoop平台以及硬件三方监控信息，并按照数据采集的先后顺序进行存储，生成三方监控输出反馈文件；

(2)实时采集集群各计算节点上用户的作业执行监控信息，生成作业执行监控输出反馈文件；

(3)汇总、解析步骤(1)中得出的三方监控输出反馈文件，建模评估节点的计算能力，并根据计算能力评分的高低将集群计算节点划分为优势计算节点和劣势计算节点；

(4)若节点为优势计算节点，则根据步骤(2)中得出的作业执行监控输出反馈文件启动基于相似度评估的作业任务资源需求配置策略；

(5)若节点为劣势计算节点，则还原为Yarn默认的资源需求配置策略。

其中，所述步骤(1)中，集群负载监控信息和硬件监控信息的采集是通过搭建集群分布式监控系统实现，其中集群负载监控信息为计算节点平均负载信息，硬件监控信息包括监控周期内节点cpu、磁盘、内存和网络平均利用率。

进一步地，所述步骤(1)中，计算节点上自定义的Hadoop平台监控信息项的获取是通过在计算框架源码中植入监控代码实现，具体包括计算节点上多作业任务执行的成功率、投放新任务的平均等待时间以及任务的平均响应时间。

进一步地，所述步骤(1)中，三方监控输出反馈文件中的每一条监控数据记录表示为：

record＝(Host,Monitor_Id,Load_Info,Platform_Info,Hardware_Info)

其中，Host表示计算节点主机名，Monitor_Id表示计算节点所处监控周期的序列号，Load_Info表示当前时刻计算节点的负载信息，Platform_Info表示计算节点在Hadoop平台上的自定义监控信息，包括多作业任务执行的成功率、投放新任务的平均等待时间以及任务的平均响应时间，Hardware_Info表示节点的硬件监控信息，包括cpu、内存、网络和磁盘平均利用率。

进一步地，所述步骤(2)中，用户的作业执行监控信息是通过在计算框架源码中内嵌自定义监控代码实现，作业的执行监控输出反馈文件中的每一条监控记录表示为如下格式：

record＝(Job_Id,Host,Monitor_Id,x₁,x₂,x₃,x₄,x₅,x₆,x₇,x₈,x₉)

其中，Job_Id表示作业序列号，Host表示计算节点主机名，Monitor_Id表示计算节点所处的监控周期序列号，x₁、x₂分别表示该计算节点对应监控周期下作业执行Map任务map子阶段、sort子阶段的平均响应时间，x₃、x₄、x₅分别表示该计算节点对应监控周期下作业执行Reduce任务copy子阶段、sort子阶段和reduce子阶段的平均响应时间，x₆、x₇分别表示该计算节点对应监控周期下作业执行Map任务的平均cpu消耗和平均内存消耗，x₈、x₉分别表示该计算节点对应监控周期下作业执行Reduce任务的平均cpu消耗和平均内存消耗。

进一步地，所述步骤(2)中，包括生成集群上用户作业的历史执行监控信息实例库，实例库中保存集群所有作业在不同计算节点、不同监控周期下的执行状况，即保存有集群历史作业执行监控输出反馈文件中的每一项监控记录。

进一步地，所述步骤(3)具体包括以下子步骤：

(3-1)汇总、解析步骤(1)中得出的三方监控输出反馈文件，在线建模计算节点的计算能力评分，具体采用以下公式：

$t=F_J(\stackrel{\→}{ll},\stackrel{\→}{pw},\stackrel{\→}{hw})$

$\stackrel{\→}{pw}=(suc,wait\_time,response\_time)$

$\stackrel{\→}{hw}=(cpu\_util,io\_util,mem\_util,net\_util)$

其中，t表示计算节点的计算能力评分，表示集群在当前监控周期下负载信息，表示在当前监控周期下自定义的Hadoop平台监控信息，suc表示计算节点执行任务的成功率，wait_time表示在该计算节点投放新任务的平均等待时间，response_time表示节点上任务执行的平均响应时间，表示在当前监控周期下节点的硬件监控信息，cpu_util、io_util、mem_util、net_util分别表示计算节点上cpu、磁盘、内存和网络的平均利用率，F_J则是节点计算能力评分t关于三个变量的一个复杂函数；

(3-2)采用排序函数对节点计算能力评分t按照从高到低的顺序进行重新排列，形成计算节点主机名、监控周期序列号和计算能力评分三者之间的映射关系，具体可以通过以下键值对表示：

(键，值)＝((Host,Monitor_Id),t)

其中，Host表示计算节点主机名，Monitor_Id表示节点所在监控周期的序列号，t表示建模得出的节点计算能力评分；

(3-3)计算集群节点计算能力评分均值at，具体公式如下：

$at=\frac{\underset{z=1}{\overset{N}{\Σ}}{t}_z}{N}$

其中，t_z表示计算节点z的计算能力评分，N表示集群计算节点总个数；

(3-4)将排序后的前K个节点判定为集群的优势计算节点，后(N-K)个节点判定为劣势计算节点，其中，N表示当前集群所有节点个数，K表示集群中计算能力评分高于(β*at)的计算节点个数，β取经验值。

进一步地，所述步骤(4)具体包括以下子步骤：

(4-1)初始对各计算节点上用户提交的作业的Map类型任务和Reduce类型任务均采取Yarn默认的任务资源需求配置策略；

(4-2)假定当前优势计算节点为n，待处理的作业为i，集群所处监控周期为T_x，其历史相邻监控周期为T_y；

(4-3)读取并解析步骤(2)中获取的作业执行监控输出反馈文件，对记录进行抽取、重排，将计算节点n上的作业i在当前监控周期T_x下对应的执行监控信息表示为以下特征向量的形式：

$\stackrel{\→}{r_{ix}}=(x_1,x_2,x_3,x_4,x_5,x_6,x_7,x_8,x_9)$

其中，x₁、x₂分别表示该优势计算节点上作业i在监控周期T_x下执行Map任务map子阶段、sort子阶段的平均响应时间，x₃、x₄、x₅分别表示该优势计算节点上作业i在监控周期T_x下执行Reduce任务copy子阶段、sort子阶段和reduce子阶段的平均响应时间，x₆、x₇分别表示该优势计算节点上作业i在监控周期T_x下执行Map任务的平均cpu消耗和平均内存消耗，x₈、x₉分别表示该优势计算节点上作业i在监控周期T_x下执行Reduce任务的平均cpu消耗和平均内存消耗。

查询集群历史作业执行监控信息实例库，获取作业i在相邻监控周期T_y下的执行监控信息特征向量，具体表示为：

$\stackrel{\→}{r_{iy}}=(x_1\′,x_2\′,x_3\′,x_4\′,x_5\′,x_6\′,x_7\′,x_8\′,x_9\′)$

(4-4)利用余弦相似度公式计算节点n上作业i在当前监控周期T_x与历史相邻监控周期T_y下执行监控信息的相似度，具体公式如下：

$sim\cos \left(\stackrel{\→}{r_{ix}},\stackrel{\→}{r_{iy}}\right)=cos\mathrm{\θ}=\frac{\stackrel{\→}{r_{ix}}\•\stackrel{\→}{r_{iy}}}{||\stackrel{\→}{r_{ix}}||||\stackrel{\→}{r_{iy}}||}=\frac{\underset{j=1}{\overset{5}{\Σ}}(x_j\•{x^{\′}}_j)}{\sqrt{\underset{j=1}{\overset{5}{\Σ}}{x^2}_j\underset{j=1}{\overset{5}{\Σ}}{{x^{\′}}^2}_j}}$

其中，为作业i在计算节点n的监控周期T_x下对应的作业执行监控信息特征向量，为作业i在计算节点n的相邻监控周期T_y下对应的作业执行监控信息特征向量；

(4-5)若说明该计算节点上作业i在当前监控周期T_x与其相邻监控周期T_y下的执行状况类似，可判定上一个监控周期中作业i对应的任务资源需求配置策略合理，作业执行稳定、性能良好，因此选定相邻监控周期T_y作为当前监控周期T_x的基准参考周期，其中取经验值，

(4-6)若说明该计算节点上作业i在当前监控周期T_x与其相邻监控周期T_y下的执行状况不类似(作业任务类型转换、负载过重、节点自身故障等原因)，可判定上一个监控周期下作业i的任务资源需求配置策略不合理或作业执行不稳定，则查找该计算节点上对应的作业历史执行监控信息实例库，遍历获取历史监控周期下作业i的执行监控信息，并计算作业i在当前监控周期T_x和待匹配的历史监控周期下的作业执行监控信息相似度，选取满足如下条件的唯一历史监控周期T_y’：

其中，表示该计算节点上作业i在当前监控周期T_x与第1个监控周期T₁下的作业执行监控信息相似度，表示该计算节点上作业i在当前监控周期T_x与第2个监控周期T₂下的作业执行监控信息相似度…以此类推，表示该计算节点上作业i在当前监控周期T_x与第y’个监控周期T_y’下具有最大的作业执行监控信息相似度，则选定监控周期T_y’作为当前监控周期T_x的基准参考周期；

(4-7)根据作业i在该计算节点上的基准参考监控周期T_y(或T_y’)下对应的cpu资源和内存资源平均使用情况修改下一轮监控间隔内作业i对应的Map任务和Reduce任务的cpu资源需求和内存资源需求，具体可以表示为如下公式：

map_r_d＝(ε*x₆,λ*x₇)

reduce_r_d＝(ε*x₈,λ*x₉)

其中，map_r_d表示作业i在计算节点n下一轮监控周期内Map任务对应的cpu资源需求和内存资源需求，reduce_r_d表示作业i在计算节点n下一轮监控周期内Reduce任务对应的cpu资源需求和内存资源需求，x₆、x₇分别表示作业i在基准参考监控周期T_y(或T_y’)下Map任务的cpu资源和内存资源的平均消耗，x₈、x₉分别表示作业i在基准参考监控周期T_y(或T_y’)下Reduce任务的cpu资源和内存资源的平均消耗，ε、λ分别为cpu资源需求和内存资源需求的弹性调整因子，依据用户经验值设定；

进一步地，在所述步骤(4-6)中，若没有找到符合条件的基准参考监控周期T_y(或T_y’)，则将该计算节点上作业i对应的Map任务和Reduce任务的cpu资源需求和内存资源需求还原为集群初始的资源需求配置策略。

进一步地，所述步骤(5)中，Yarn中作业任务的资源需求均默认为如下配置策略：<”memory:1024MB”,”core:1”>，即作业单个Map任务或者Reduce任务可申请的最少物理内存量是1024MB，最少cpu资源为1。

通过本发明所构思的以上技术方案，与现有技术相比，具有以下显著优点：

(1)本发明在优势计算节点上对执行状况类似、性能稳定的作业基于历史资源消耗水平调整作业资源需求份额，对作业任务类型转换、负载过重、节点自身故障等原因导致的执行状况差异大的作业还原为Yarn默认的资源配置，避免启动过多任务增加延迟，这种基于作业执行监控信息相似度评估的资源需求配置策略能够有效地感知集群节点、作业之间以及同作业不同执行阶段的异构性，充分考虑了作业资源需求随时间的变化，为集群作业的资源调度提供了真实而准确的依据，最大程度上减少了集群计算节点上的资源碎片，在保证集群资源高效利用的同时有利于促进集群作业任务的高效并发，缩短了多作业环境下系统运行时间，从而提高了Hadoop平台整体的执行效率。

(2)本发明通过对集群的全面监控能够准确地识别当前负载环境下异构集群中节点性能的优劣，同时对优势计算节点启动基于相似度评估的资源需求配置策略、对劣势计算节点还原为Yarn默认的资源需求策略；一方面在高水平节点上根据作业实际执行情况动态改变任务的资源需求，在保证较高资源利用率的同时直接控制任务拉取的份额，另一方面避免在低水平节点上频繁切换作业资源需求引起任务执行的延迟，能够有效减少弱势节点因过多失败任务而启动的异地节点备份任务带来的网络传输开销。该系统方案在充分利用集群整体资源的同时保证了作业的高效并发执行，确保了Hadoop异构集群始终具有良好的性能。

(3)本发明对Yarn的三种核心资源调度器(FIFO、Capacity Scheduler以及Fair Scheduler)均适用：本发明能够作为一个子级资源调度方案嫁接在Yarn现有核心资源调度器下，使得整个Hadoop系统在继承Yarn核心资源调度器优点的同时能够综合考虑集群各计算节点、各用户作业以及同作业不同执行阶段的异构性，充分考虑了作业资源需求随时间的变化，能够在保证集群资源利用率的同时促进集群用户作业执行的高效并发。

(4)本发明对Hadoop 2.0支持的多个上层计算框架具有普遍适用性，由于Hadoop Yarn资源框架与上层计算逻辑无关，因此本发明不仅适用于MapReduce类型的计算任务，同样还适用于Spark任务、SparkStreaming任务等其他类型的大数据任务，具有很高的研究和实用价值。

附图说明

图1是本发明基于Hadoop多作业环境下的资源调度系统的架构示意图；

图2是本发明基于Hadoop多作业环境下的资源调度系统工作流程图；

图3是本发明在优势计算节点上启动的基于相似度评估的作业任务资源需求配置策略流程图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

如图1所示，本发明中，基于Hadoop多作业环境下的资源调度系统架构为三方架构：客户端、Hadoop2.0集群平台和监控服务器端，其中Hadoop集群包括一个主节点和多个计算节点，Resource Manager是主节点独立运行的负责管理集群资源到调度的进程，Node Manager是计算节点上独立运行的负责管理并汇报节点状态的进程，Application Master则是运行在计算节点上的组件，客户端提交的每一个应用程序都对应一个App Master。

如图2所示，本发明中，基于Hadoop多作业环境下的资源调度系统工作流程如下：

步骤201，Hadoop集群启动，分布式集群监控系统启动，各作业的Map任务和Reduce任务均采用Yarn默认的cpu资源需求和内存资源需求配置策略，格式为：<”memory:1024MB”,”core:1”>，即表示作业单个Map任务或者Reduce任务可申请的最少物理内存量是1024MB，最少cpu资源为1；

步骤202，集群各计算节点开启后台三方监控线程和作业执行监控线程，按照规定监控时间间隔将所有监控信息发送至监控服务器，本实施例中，监控时间间隔设置为30s；

步骤203，判断一个新的监控周期是否到来，否则循环等待；

步骤204，监控服务器在特定端口接收、汇总集群各计算节点的三方监控输出反馈信息，并表示为如下数据记录的格式：

record＝(Host,Monitor_Id,Load_Info,Platform_Info,Hardware_Info)

其中，Host表示计算节点主机名，Monitor_Id表示计算节点所处监控周期的序列号，Load_Info表示当前时刻计算节点的负载信息，Platform_Info表示计算节点在Hadoop平台上的自定义监控信息，包括多作业任务执行的成功率、投放新任务的平均等待时间以及任务的平均响应时间，Hardware_Info表示节点的硬件监控信息，包括cpu、内存、网络和磁盘平均利用率；

步骤205，监控服务器在特定端口接收、汇总集群各计算节点的作业执行监控输出反馈信息，并表示为如下数据记录的格式：

record＝(Job_Id,Host,Monitor_Id,x₁,x₂,x₃,x₄,x₅,x₆,x₇,x₈,x₉)

其中，Job_Id表示作业序列号，Host表示计算节点主机名，Monitor_Id表示计算节点所处的监控周期序列号，x₁、x₂分别表示该计算节点对应监控周期下作业执行Map任务map子阶段、sort子阶段的平均响应时间，x₃、x₄、x₅分别表示该计算节点对应监控周期下作业执行Reduce任务copy子阶段、sort子阶段和reduce子阶段的平均响应时间，x₆、x₇分别表示该计算节点对应监控周期下作业执行Map任务的平均cpu消耗和平均内存消耗，x₈、x₉分别表示该计算节点对应监控周期下作业执行Reduce任务的平均cpu消耗和平均内存消耗；

步骤206，将步骤205中采集的作业执行监控信息项添加到集群的作业历史执行监控信息实例库；

步骤207，利用步骤204中采集的集群节点三方监控信息，建模评估节点的计算能力，具体公式如下：

$t=F_J(\stackrel{\&RightArrow;}{ll},\stackrel{\&RightArrow;}{pw},\stackrel{\&RightArrow;}{hw})$

$\stackrel{\&RightArrow;}{pw}=(suc,wait\_time,response\_time)$

$\stackrel{\&RightArrow;}{hw}=(cpu\_util,io\_util,mem\_util,net\_util)$

其中，t表示计算节点的计算能力评分，表示集群在当前监控周期下负载信息，表示在当前监控周期下自定义的Hadoop平台监控信息，suc表示计算节点执行任务的成功率，wait_time表示在该计算节点投放新任务的平均等待时间，response_time表示节点上任务执行的平均响应时间，表示在当前监控周期下节点的硬件监控信息，cpu_util、io_util、mem_util、net_util分别表示计算节点上cpu、磁盘、内存和网络的平均利用率，F_J则是节点计算能力评分t关于三个变量的一个复杂函数。

步骤208，采用排序函数对节点计算能力评分t按照从高到低的顺序进行重新排列，形成计算节点主机名、监控周期序列号和计算能力评分三者之间的映射关系，具体可以通过以下键值对表示：

(键，值)＝((Host,Monitor_Id),t)

其中，Host表示计算节点主机名，Monitor_Id表示节点所在监控周期的序列号，t表示建模得出的节点计算能力评分；

步骤209，按照如下公式计算集群节点计算能力评分均值at：

$at=\frac{\underset{z=1}{\overset{N}{\&Sigma;}}{t}_z}{N}$

其中，t_z表示计算节点z的计算能力评分，N表示集群计算节点总个数；

步骤210，将前K个节点判定为集群优势计算节点，启动基于相似度评估的作业任务资源需求配置策略，其中，K表示集群中计算能力评分高于(β*at)的计算节点个数，本实施例中，β取经验值60％；

步骤211，将后(N-K)个节点判定为集群劣势计算节点，则还原为Yarn默认的资源需求配置策略。

如图3所示，本发明在优势计算节点上启动的基于相似度评估的作业任务资源需求配置策略包括以下步骤：

步骤301，假定当前优势计算节点为n，待处理的作业为i，集群所处监控周期为T_x，其历史相邻监控周期为T_y；

步骤302，读取并解析步骤(2)中获取的作业执行监控输出反馈文件，对记录进行抽取、重排，将计算节点n上的作业i在当前监控周期T_x下对应的执行监控信息表示为以下特征向量的形式：

$\stackrel{\&RightArrow;}{r_{ix}}=(x_1,x_2,x_3,x_4,x_5,x_6,x_7,x_8,x_9)$

其中，x₁、x₂分别表示该优势计算节点上作业i在监控周期T_x下执行Map任务map子阶段、sort子阶段的平均响应时间，x₃、x₄、x₅分别表示该优势计算节点上作业i在监控周期T_x下执行Reduce任务copy子阶段、sort子阶段和reduce子阶段的平均响应时间，x₆、x₇分别表示该优势计算节点上作业i在监控周期T_x下执行Map任务的平均cpu消耗和平均内存消耗，x₈、x₉分别表示该优势计算节点上作业i在监控周期T_x下执行Reduce任务的平均cpu消耗和平均内存消耗；

步骤303，查询集群历史作业执行监控信息实例库，获取作业i在相邻监控周期T_y下的执行监控信息特征向量，具体表示为：

$\stackrel{\&RightArrow;}{r_{iy}}=(x_1\&prime;,x_2\&prime;,x_3\&prime;,x_4\&prime;,x_5\&prime;,x_6\&prime;,x_7\&prime;,x_8\&prime;,x_9\&prime;)$

其中，x₁'、x₂'分别表示该优势计算节点上作业i在监控周期T_y下执行Map任务map子阶段、sort子阶段的平均响应时间，x₃'、x₄'、x₅'分别表示该优势计算节点上作业i在监控周期T_y下执行Reduce任务copy子阶段、sort子阶段和reduce子阶段的平均响应时间，x₆'、x₇'分别表示该优势计算节点上作业i在监控周期T_y下执行Map任务的平均cpu消耗和平均内存消耗，x₈'、x₉'分别表示该优势计算节点上作业i在监控周期T_y下执行Reduce任务的平均cpu消耗和平均内存消耗；

步骤304，利用余弦相似度公式计算节点n上作业i在当前监控周期T_x与历史相邻监控周期T_y下执行监控信息的相似度，具体公式如下：

$sim\cos \left(\stackrel{\&RightArrow;}{r_{ix}},\stackrel{\&RightArrow;}{r_{iy}}\right)=cos\mathrm{\&theta;}=\frac{\stackrel{\&RightArrow;}{r_{ix}}\&bull;\stackrel{\&RightArrow;}{r_{iy}}}{||\stackrel{\&RightArrow;}{r_{ix}}||||\stackrel{\&RightArrow;}{r_{iy}}||}=\frac{\underset{j=1}{\overset{5}{\&Sigma;}}(x_j\&bull;{x^{\&prime;}}_j)}{\sqrt{\underset{j=1}{\overset{5}{\&Sigma;}}{x^2}_j\underset{j=1}{\overset{5}{\&Sigma;}}{{x^{\&prime;}}^2}_j}}$

其中，为作业i在计算节点n的监控周期T_x下对应的作业执行监控信息特征向量，为作业i在计算节点n的相邻监控周期T_y下对应的作业执行监控信息特征向量；

步骤305，若(本实施例中，取经验值0.5)，说明该计算节点上作业i在当前监控周期T_x与其相邻监控周期T_y下的执行状况类似，可判定上一个监控周期中作业i对应的任务资源需求配置策略合理，作业执行稳定、性能良好，因此选定相邻监控周期T_y作为当前监控周期T_x的基准参考周期，转步骤308；

步骤306，若说明该计算节点上作业i在当前监控周期T_x与其相邻监控周期T_y下的执行状况不类似(作业任务类型转换、负载过重、节点自身故障等原因)，可判定上一个监控周期下作业i的任务资源需求配置策略不合理或作业执行不稳定，则查找该计算节点上对应的作业历史执行监控信息实例库，遍历获取历史监控周期下作业i的执行监控信息，并计算作业i在当前监控周期T_x和待匹配的历史监控周期下的作业执行监控信息相似度，选取满足如下条件的唯一历史监控周期T_y’：

其中，表示该计算节点上作业i在当前监控周期T_x与第1个监控周期T₁下的作业执行监控信息相似度，表示该计算节点上作业i在当前监控周期T_x与第2个监控周期T₂下的作业执行监控信息相似度…以此类推，表示该计算节点上作业i在当前监控周期T_x与第y’个监控周期T_y’下具有最大的作业执行监控信息相似度，则选定监控周期T_y’作为当前监控周期T_x的基准参考周期，转步骤308；

步骤307，若没有找到符合条件的基准参考监控周期T_y(或T_y’)，则将该计算节点上作业i对应的Map任务和Reduce任务的cpu资源需求和内存资源需求还原为集群初始的配置策略：<”memory:1024MB”,”core:1”>，即作业单个Map任务或者Reduce任务可申请的最少物理内存量是1024MB，最少cpu资源为1，转步骤309；

步骤308，解析步骤(2)中从监控服务器上获取的作业执行监控输出反馈文件(或查询集群历史作业执行监控信息实例库)，获取基准匹配监控周期T_y(或T_y’)下节点n上作业i对应的cpu资源和内存资源的平均消耗，以此修改下一轮监控间隔内对应的Map任务、Reduce任务的cpu资源需求和内存资源需求，具体可表示为如下公式：

map_r_d＝(ε*x₆,λ*x₇)

reduce_r_d＝(ε*x₈,λ*x₉)

其中，map_r_d表示作业i在计算节点n下一轮监控周期内Map任务对应的cpu资源需求和内存资源需求，reduce_r_d表示作业i在计算节点n下一轮监控周期内Reduce任务对应的cpu资源需求和内存资源需求，x₆、x₇分别表示作业i在基准参考监控周期T_y(或T_y’)下Map任务的cpu资源和内存资源的平均消耗，x₈、x₉分别表示作业i在基准参考监控周期T_y(或T_y’)下Reduce任务的cpu资源和内存资源的平均消耗，ε、λ分别为cpu资源需求和内存资源需求的弹性调整因子，依据用户经验值设定；

步骤309，判断当前监控周期下节点n上正运行的作业是否遍历完成，如果未完成，选取节点n的下一个作业作为新的作业i，转步骤301。

本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种基于Hadoop多作业环境下的资源调度方法，其特征在于，包括以下步骤：

(1)实时采集集群负载、Hadoop平台以及硬件三方监控信息，并按照数据采集的先后顺序进行存储，生成三方监控输出反馈文件；

(2)实时采集集群各计算节点上用户的作业执行监控信息，生成作业执行监控输出反馈文件；

(3)汇总、解析步骤(1)中得出的三方监控输出反馈文件，建模评估节点的计算能力，并根据计算能力评分的高低将集群计算节点划分为优势计算节点和劣势计算节点；

(4)若节点为优势计算节点，则根据步骤(2)中得出的作业执行监控输出反馈文件启动基于相似度评估的作业任务资源需求配置策略；

(5)若节点为劣势计算节点，则还原为Yarn默认的资源需求配置策略。

2.根据权利要求1所述的基于Hadoop多作业环境下的资源调度方法，其特征在于，所述步骤(1)中，集群负载监控信息和硬件监控信息的采集通过搭建集群分布式监控系统实现，其中集群负载监控信息为计算节点平均负载信息，硬件监控信息包括监控周期内节点cpu、磁盘、内存和网络平均利用率。

3.根据权利要求1或2所述的基于Hadoop多作业环境下的资源调度方法，其特征在于，所述步骤(1)中，Hadoop平台监控信息项的获取通过在计算框架源码中植入监控代码实现，具体包括计算节点上多作业任务执行的成功率、投放新任务的平均等待时间以及任务的平均响应时间。

4.根据权利要求1或2所述的基于Hadoop多作业环境下的资源调度方法，其特征在于，所述步骤(1)中，三方监控输出反馈文件中的每一条 监控数据记录表示为：

record＝(Host,Monitor_Id,Load_Info,Platform_Info,Hardware_Info) 

其中，Host表示计算节点主机名，Monitor_Id表示计算节点所处监控周期的序列号，Load_Info表示当前时刻计算节点的负载信息，Platform_Info表示计算节点在Hadoop平台上的自定义监控信息，包括多作业任务执行的成功率、投放新任务的平均等待时间以及任务的平均响应时间，Hardware_Info表示节点的硬件监控信息，包括cpu、内存、网络和磁盘平均利用率。

5.根据权利要求1或2所述的基于Hadoop多作业环境下的资源调度方法，其特征在于，所述步骤(2)中，用户的作业执行监控信息通过在计算框架源码中内嵌自定义监控代码实现，作业的执行监控输出反馈文件中的每一条监控记录表示为如下格式：

record＝(Job_Id,Host,Monitor_Id,x₁,x₂,x₃,x₄,x₅,x₆,x₇,x₈,x₉) 

其中，Job_Id表示作业序列号，Host表示计算节点主机名，Monitor_Id表示计算节点所处的监控周期序列号，x₁、x₂分别表示该计算节点对应监控周期下作业执行Map任务map子阶段、sort子阶段的平均响应时间，x₃、x₄、x₅分别表示该计算节点对应监控周期下作业执行Reduce任务copy子阶段、sort子阶段和reduce子阶段的平均响应时间，x₆、x₇分别表示该计算节点对应监控周期下作业Map任务的平均cpu消耗和平均内存消耗，x₈、x₉分别表示该计算节点对应监控周期下作业Reduce任务的平均cpu消耗和平均内存消耗。

6.根据权利要求1或2所述的基于Hadoop多作业环境下的资源调度方法，其特征在于，所述步骤(2)中，还包括生成集群上用户作业的历史执行监控信息实例库，实例库中保存集群所有作业在不同计算节点、不同监控周期下的执行情况，即保存有集群作业执行监控历史输出反馈文件中的每一项监控记录。

7.根据权利要求1或2所述的基于Hadoop多作业环境下的资源调度方法，其特征在于，所述步骤(3)包括以下子步骤：

(3-1)汇总、解析步骤(1)中得出的三方监控输出反馈文件，在线建模计算节点的计算能力评分，具体采用以下公式：

其中，t表示计算节点的计算能力评分，表示集群在当前监控周期下负载信息，表示在当前监控周期下自定义的Hadoop平台监控信息，suc表示计算节点执行任务的成功率，wait_time表示在该计算节点投放新任务的平均等待时间，response_time表示节点上任务执行的平均响应时间，表示在当前监控周期下节点的硬件监控信息，cpu_util、io_util、mem_util、net_util分别表示计算节点上cpu、磁盘、内存和网络的平均利用率，F_J则是节点计算能力评分t关于ll、三个变量的一个复杂函数；

(3-2)采用排序函数对节点计算能力评分t按照从高到低的顺序进行重新排列，形成计算节点主机名、监控周期序列号和计算能力评分三者之间的映射关系，具体通过以下键值对表示：

(键，值)＝((Host,Monitor_Id),t) 

其中，Host表示计算节点主机名，Monitor_Id表示节点所在监控周期的序列号，t表示建模得出的节点计算能力评分；

(3-3)计算集群节点计算能力评分均值at，具体公式如下：

其中，t_z表示计算节点z的计算能力评分，N表示集群计算节点总个数；

(3-4)将排序后的前K个节点判定为集群的优势计算节点，后(N-K) 个节点判定为劣势计算节点，其中，N表示当前集群所有节点个数，K表示集群中计算能力评分高于(β*at)的计算节点个数，β取经验值。

8.根据权利要求1或2所述的基于Hadoop多作业环境下的资源调度方法，其特征在于，所述步骤(4)包括以下子步骤：

(4-1)初始对各计算节点上用户提交的作业的Map类型任务和Reduce类型任务均采取Yarn默认的任务资源需求配置策略；

(4-2)假定当前优势计算节点为n，待处理的作业为i，集群所处监控周期为T_x，其历史相邻监控周期为T_y；

(4-3)读取并解析步骤(2)中获取的作业执行监控输出反馈文件，对记录进行抽取、重排，将计算节点n上的作业i在当前监控周期T_x下对应的执行监控信息表示为以下特征向量的形式：

其中，x₁、x₂分别表示该优势计算节点上作业i在监控周期T_x下执行Map任务map子阶段、sort子阶段的平均响应时间，x₃、x₄、x₅分别表示该优势计算节点上作业i在监控周期T_x下执行Reduce任务copy子阶段、sort子阶段和reduce子阶段的平均响应时间，x₆、x₇分别表示该优势计算节点上作业i在监控周期T_x下执行Map任务的平均cpu消耗和平均内存消耗，x₈、x₉分别表示该优势计算节点上作业i在监控周期T_x下执行Reduce任务的平均cpu消耗和平均内存消耗；

查询集群上用户作业的历史执行监控信息实例库，获取作业i在相邻监控周期T_y下的执行监控信息特征向量，具体表示为：

(4-4)利用余弦相似度公式计算节点n上作业i在当前监控周期T_x与历史相邻监控周期T_y下执行监控信息的相似度，具体公式如下：

其中，为作业i在计算节点n的监控周期T_x下对应的作业执行监控信息特征向量，为作业i在计算节点n的相邻监控周期T_y下对应的作业执行监控信息特征向量；

(4-5)若说明该计算节点上作业i在当前监控周期T_x与其相邻监控周期T_y下的执行状况类似，可判定上一个监控周期中作业i对应的任务资源需求配置策略合理，作业执行稳定、性能良好，因此选定相邻监控周期T_y作为当前监控周期T_x的基准参考周期，其中取经验值， 

(4-6)若说明该计算节点上作业i在当前监控周期T_x与其相邻监控周期T_y下的执行状况不类似(作业任务类型转换、负载过重、节点自身故障等原因)，可判定上一个监控周期下作业i的任务资源需求配置策略不合理或作业执行不稳定，则查找该计算节点上对应的作业历史执行监控信息实例库，遍历获取历史监控周期下作业i的执行监控信息，并计算作业i在当前监控周期T_x和待匹配的历史监控周期下的作业执行监控信息相似度，选取满足如下条件的唯一历史监控周期T_y’：

其中，表示该计算节点上作业i在当前监控周期T_x与第1个监控周期T₁下的作业执行监控信息相似度，表示该计算节点上作业i在当前监控周期T_x与第2个监控周期T₂下的作业执行监控信息相似度…以此类推，表示该计算节点上作业i在当前监控周期T_x与第y’个监控周期T_y’下具有最大的作业执行监控信息相似度，则选定监控周期T_y’作为当前监控周期T_x的基准参考周期；

(4-7)根据作业i在该计算节点上的基准参考监控周期T_y或T_y’下对应的cpu资源和内存资源平均使用情况修改下一轮监控间隔内作业i对应的Map任务和Reduce任务的cpu资源需求和内存资源需求，具体表示为如下公式：

map_r_d＝(ε*x₆,λ*x₇)

reduce_r_d＝(ε*x₈,λ*x₉)

其中，map_r_d表示作业i在计算节点n下一轮监控周期内Map任务对应的cpu资源需求和内存资源需求，reduce_r_d表示作业i在计算节点n下一轮监控周期内Reduce任务对应的cpu资源需求和内存资源需求，x₆、x₇分别表示作业i在基准参考监控周期T_y或T_y’下Map任务的cpu资源和内存资源的平均消耗，x₈、x₉分别表示作业i在基准参考监控周期T_y或T_y’下Reduce任务的cpu资源和内存资源的平均消耗，ε、λ分别为cpu资源需求和内存资源需求的弹性调整因子，依据用户经验值设定。

9.根据权利要求8所述的基于Hadoop多作业环境下的资源调度方法，其特征在于，在所述步骤(4-6)中，若没有找到符合条件的基准参考监控周期T_y或T_y’，则将该计算节点上作业i对应的Map任务和Reduce任务的cpu资源需求和内存资源需求还原为集群初始的资源需求配置策略。

10.根据权利要求1或2所述的一种基于Hadoop多作业环境下的资源调度方法，其特征在于，所述步骤(5)中，Yarn中作业任务的资源需求均默认为如下配置策略：<”memory:1024MB”,”core:1”>，即作业单个任务可申请的最少物理内存量是1024MB，最少cpu资源为1，其中所述作业任务包括Map任务和Reduce任务。