CN104317658B - 一种基于MapReduce的负载自适应任务调度方法 - Google Patents

Abstract

本发明公开了一种基于MapReduce的负载自适应的任务调度方法，包括：(1)动态监测Hadoop集群负载状态，(2)动态监测集群各执行节点在执行任务过程中产生的软件信息，(3)动态监测集群各执行节点在执行任务过程中的硬件信息，(4)汇总步骤(1)、步骤(2)及步骤(3)中采集的集群各执行节点的负载监控信息、软件监控信息以及硬件监控信息三方监控信息，建模计算集群各执行节点的计算能力，(5)执行集群负载预警功能，并根据集群各执行节点计算能力进行智能任务调度。本发明解决了Hadoop现有调度器对集群资源感知度低、任务分配不合理的问题，提供了一种能够负载自适应的、更科学有效的任务调度方案。

Description

一种基于MapReduce的负载自适应任务调度方法

技术领域

本发明属于分布式并行计算领域，具体而言是一种基于MapReduce的负载自适应的任务调度方法。

背景技术

随着大数据与互联网时代来临，数据呈几何级爆炸式增长，给传统的分布式存储和计算系统带来了极大挑战，一种更简化的分布式并行计算模型—Hadoop MapReduce应运而生。MapReduce是一种分布式的用于处理海量数据集的并行编程系统，其框架是由一个主控节点和多个执行节点共同组成，主控节点通常会把输入的数据集切分为若干独立的数据块，即将作业划分为固定粒度大小的子任务，分配给多个执行节点并发执行，以提高集群吞吐率。因此，MapReduce的任务调度策略直接影响Hadoop集群的资源利用率、系统执行效率。

现有的Hadoop调度技术主要有以下四种：①FIFO调度器(First In First Out)：FIFO为Hadoop默认的调度器，其按照作业的优先级高低以及到达时间的先后选择被执行的作业；②公平调度器：支持多队列多用户，每个队列中的资源量可以配置，同一队列中的作业公平共享队列中所有资源；③计算能力调度器：支持多队列，每个队列可配置一定的资源量，每个队列采用FIFO调度策略，为了防止同一个用户的作业独占队列中的资源，该调度器会对同一用户提交的作业所占资源量进行限定；④HOD调度器(Hadoop On Demand)：HOD调度器在一个共享物理集群上管理若干个Hadoop集群，以满足不同用途。

已有的Hadoop任务调度策略虽然十分多样化，但在集群实际运行中仍存在很明显的缺陷。一方面，Hadoop集群中各执行节点的综合计算能力存在较大差异，此处计算能力不仅指各节点的硬件环境差异，还包括节点在执行任务过程中表现出的执行能力的不同(软件信息)，因此常规的静态任务分配方案无法感知不同节点的异构性，会降低系统计算资源的利用率、影响作业的执行效率。

另一方面，在当前互联网环境下，互联网服务层出不穷，同一个数据中心同时可能运行着不同类型的负载，不同负载对系统资源的需求量也是不同的：如统计值计算、垃圾数据分析等CPU密集型作业对CPU资源需求高，而数据挖掘、机器学习等I/O密集型作业则对磁盘资源需求高。然而，现有的任务调度算法没有考虑针对不同类型负载采取不同的调度方法，这样的做法存在一定弊端：大量CPU密集型的任务调度到集群同一个工作节点，则该节点的I/O资源就没有得到充分利用。在这种忽略负载具体类型的统一调度方式下，任务分配的不合理性、各节点资源的不均衡使用均有可能导致系统执行效率低下。

综上所述，Hadoop目前已有的大部分任务调度策略对系统的监控不全面，缺乏对集群运行过程中实时负载类型以及软件信息的监测，无法准确识别节点计算能力的异构性，从而导致集群资源感知度低、任务分配不合理、系统整体性能下降。

发明内容

针对现有MapReduce任务调度技术的缺陷，本发明的目的在于提供一种基于集群节点计算能力评估体系、负载自适应的任务调度方案，旨在解决目前已有任务策略导致的集群资源感知度低、系统性能差的问题。本发明提供了一种基于MapReduce的负载自适应任务调度方案，其具体步骤如下：

(1)动态监测Hadoop集群负载状态；

(2)动态监测集群各执行节点在执行任务过程中产生的软件信息，包括任务执行成功率、任务推测执行失败次数、投放任务平均等待时间以及执行任务平均响应时间；

(3)动态监测集群各执行节点在执行任务过程中产生的硬件信息，包括节点CPU、内存、I/O以及网络使用情况；

(4)汇总步骤(1)、步骤(2)以及步骤(3)中采集到的集群各执行节点的负载监控信息、软件监控信息以及硬件监控信息三方监控信息，建模计算集群各执行节点的计算能力；

(5)执行集群负载预警功能，并根据集群各执行节点计算能力进行智能任务调度。

其中，所述步骤(1)具体包括以下子步骤：

(1-1)集群负载类型监听：动态提取集群各执行节点在监控时间间隔内平均cpu使用率以及io操作比，利用朴素贝叶斯分类器，判定当前集群负载类型；

(1-2)集群负载压力状态监听：集群负载压力状态分为三种：超负荷扩容型、轻负荷收缩型以及自适应调度型。其中，超负荷扩容型表示集群各执行节点满负荷运行、负载压力大、系统执行效率低，需紧急扩容以缓解集群压力；轻负荷收缩型表示集群节点过剩、系统资源浪费，为使系统节能运行，移除之前为紧急扩容加入的节点；自适应调度型表示当前系统运行健康、稳定，无需扩容或者收缩。

在集群运行过程中，动态提取集群节点平均负载(load_average)以及一秒内io操作平均所占比(io_util)，根据步骤(1-1)得出的当前集群负载类型选择系统变量(load_average或者io_util)判定集群负载压力状态，具体分为，当集群类型为CPU密集型时，集群负载压力状态判定方法为:

其中，Hadoop_Feature代表集群负载压力状态，γ、δ为设定阈值的上、下限，load_average代表集群平均系统负载；如果load_average高于设定的阈值上限γ，则判定当前集群负载属于超负荷扩容型；如果load_average低于设定的阈值下限δ，则判定当前集群负载属于轻负荷收缩型；如果load_average在设定阈值的上、下限之间，则判定当前集群负载属于自适应调度型。一般而言，阈值上、下限根据集群机器平均cpu核数而定。假定集群机器平均CPU核数为n，一般而言，阈值下限δ取0.2*n，阈值上限γ取n；

当集群负载为I/O密集型时，集群负载压力状态判定方法为：

其中，Hadoop_Feature代表集群负载压力状态，β、α为设定阈值的上、下限，io_util代表集群一秒内平均io操作所占比；如果io_util高于设定的阈值上限β，则判定当前集群负载属于超负荷扩容型；如果io_util低于设定的阈值下限α，则判定当前集群负载属于轻负荷收缩型；如果io_util在设定阈值的上、下限之间，则判定当前集群负载属于自适应调度型；

当集群负载为混合型时，集群负载压力状态判定需同时考虑系统平均负载load_average以及io操作平均所占比io_util。

进一步地，所述步骤(1-1)中还具体包括如下子步骤：

(1-1-1)离线分类器训练：

设类别集合C＝{cpu密集型负载，io密集型负载，混合型负载}，待分类负载x＝{cpu利用率cpuUtil，io操作比ioUtil}。

运行多种类型的负载训练样本，动态采集集群监控时间段内负载特征属性cpuutil、ioutil，计算每个类别在训练样本中的出现频率：P(cpu密集型)、P(io密集型)和P(混合型)，以及每个特征属性划分对每个类别的条件概率估计：P(cpuutil|cpu密集型负载)、P(ioutil|cpu密集型负载)、P(cpuutil|io密集型负载)、P(ioutil|io密集型负载)、P(cpuutil|混合型负载)和P(ioutil|混合型负载)，并将结果记录。

(1-1-2)负载在线分类：Hadoop集群启动后，对于一个运行中的待分类负载x，监控服务器端动态获取集群各执行节点平均cpu利用率以及io操作比，得到负载特征向量x＝{cpuutil，ioutil}，并按如下贝叶斯公式计算该负载后验概率P(C_i|x)：

P(Ci|x)＝P(x|C_i)P(C_i)/P(x)＝P(C_i)∏P(x_i|C_i)/P(x)，i∈[1,3]；

以上公式中，由于分母对所有类别均为常数，因此有max{P(Ci|x)}＝max{P(C_i)P(x_i|C_i)}，i∈[1,3]，计算比较后，具有最大后验概率的类即为该待分类负载所属的类。

进一步地，所述步骤(2)中，在Hadoop可编译源码中植入监控代码，自定义软件监控信息，包括获取执行节点在监控时间间隔内执行任务的成功率、任务推测执行的失败次数、投放任务平均等待时间以及执行任务的平均响应时间四项。

进一步地，在所述步骤(3)中所述的分布式监控系统监测的内容包括集群执行节点上CPU、内存、磁盘以及网络使用情况。

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

(4-1)离线训练模型：综合考虑节点在监控时间间隔内三方监控信息，即负载信息、软件信息以及硬件信息，按照以下评估模型公式确定集群执行节点的综合计算能力:

Node_ResTime＝β₀+β₁F₁(TaskSucRate)+β₂F₂(TaskSpekilledTimes)

+β₃F₃(WaitTime)+β₄F₄(Cpuutil)

+β₅F₅(Memutil)+β₆F₆(Diskutil)

+β₇F₇(Netutil)+C

式中，Node_ResTime代表监控时间间隔内执行节点执行任务的平均响应时间，TaskSucRate代表监控时间间隔内执行节点执行任务的成功率，TaskSpekilledTimes代表推测执行失败的任务数，WaitTime代表投放新任务的平均等待时间，Cpuutil代表监控时间间隔内CPU的利用率，Memutil代表内存利用率，Diskutil代表磁盘利用率，Netutil代表网络利用率；C为预先需要考虑的其他因素对节点计算能力优先级的影响的函数；β₁、β₂、β₃、β₄、β₅、β₆、β₇分别为函数F₁(TaskSucRate)、F₂(TaskSpekilledTimes)、F₃(WaitTime)、F₄(Cpuutil)、F₅(Memutil)、F₆(Diskutil)以及F₇(Netutil)对应的权重；

针对不同类型的代表性负载，利用RRDTool从Ganglia监控的环形数据库中进行顺序采集，离线收集集群运行过程中提取出的各执行节点的负载、软件以及硬件三方监测历史信息，采用多元线性回归模型进行训练、建模，从而得出在CPU密集型、I/O密集型以及混合型负载状态下对应的计算能力模型参数β₁、β₂、β₃、β₄、β₅、β₆、β₇。

(4-2)在线模型计算：根据步骤(1)中得出的集群负载类型，选择对应的计算能力评估模型进行建模，计算得出各执行节点计算能力。如果当前集群负载状态为CPU密集型，则调用CPU密集型负载对应的模型参数建模；如果集群负载状态为I/O密集型，则调用I/O密集型负载对应的模型参数进行建模；否则，调用混合型负载对应的模型参数进行建模。

进一步地，步骤(5)包括，首先根据当前时刻集群负载状态执行负载预警，如果探测到集群处于负载超负荷扩容状态，则自动增加执行节点，进行集群扩容；如果探测到集群处于负载轻负荷收缩阶段，则自动移除节点，减小集群能耗；如果集群正常、稳定运行，即既不处于负载超负荷状态，也不处于负载轻负荷状态，则执行负载自适应的任务调度策略：根据当前集群各执行节点的优先级大小进行动态任务拉取，计算能力越优越的节点拉取更多的任务，计算能力相对较弱的节点则适当拉取少量任务。如集群有5个节点，1个Master节点，4个Slave节点，则优先级最高的执行节点拉取5个任务，优先级最低的执行节点则按照默认拉取2个任务，以此类推。

通过本发明所构思的以上技术方案，与现有技术相比，本发明具有以下的有益效果：

(1)增强Hadoop平台对不同负载的适用性；本发明采取基于集群节点计算能力评估体系、负载自适应的个性化调度方案：根据当前时刻集群负载状态确定节点计算能力评估模型(不同负载状态对应不同模型)，从而确定任务调度策略并反馈给集群主控节点，这种调度方案可以根据集群负载状态的不同，准确衡量出集群各执行节点计算能力，从而更合理地进行任务分配。

(2)采取的实时监控更为全面、新颖；相比于Hadoop已有的任务调度策略，本发明不仅包括对常规硬件信息，如CPU、内存、I/O以及网络等信息进行实时监控，同时也通过植入的监控代码在集群运行过程中获取各执行节点的负载信息、软件信息，使得监控更为全面、个性化，也使得后续节点计算能力的建模更为合理，从而有利于科学、有效地进行任务分配。

(3)面向异构集群，智能建模反馈；监控服务器定期收集集群所有执行节点的负载、软件、硬件三方监控信息，调用离线收集、线性回归模式处理得出的不同负载模型进行建模，以此量化集群各执行节点的计算能力，从而控制后续阶段节点的任务拉取。在这种方式下，通过感知当前时刻集群各执行节点计算能力的异构性，根据节点计算能力的大小智能控制任务调度，从而进一步提高集群资源利用率、保证任务分发合理性、增加集群吞吐率。

(4)能够动态感知负载，具有较好的过载预警功能；本发明在集群负载过高的情况下，能够通过加入新的执行节点分担当前集群承担的任务来提高集群的执行速率；若集群当前执行的任务量较小，节点数供过于求，为避免集群资源消耗，对集群采取节点收缩的处理方式，移除之前为扩容加入的新增节点，从而使集群紧凑、高效、节能地完成所有任务。

附图说明

下面结合附图及实施例对本发明进行进一步描述：

图1是本发明基于Hadoop的负载自适应任务调度系统的架构示意图；

图2是本发明基于Hadoop的负载自适应任务调度系统的工作流程图；

图3是本发明基于Hadoop的负载自适应的任务调度系统的负载、软件以及硬件信息三方监控流程图；

图4是本发明中系统负载压力状况监听的工作流程图；

图5是本发明中节点计算能力评估模型的离线训练工作流程图；

图6是本发明中负载自适应的任务调度方案的工作流程图。

具体实施方式

上述说明仅是本发明技术方案的概括，为了能够更清楚了解本发明的技术手段，并可依照说明书的内容予以实施，以下结合附图以及具体实施例对上述方案做进一步说明。应理解，这些实施例是用于说明本发明而不限于限制本发明的范围。

为了清楚地理解本发明，以下对本发明中使用的术语进行解释：

异构集群：集群中，由于节点硬件、软件运行环境不同导致节点之间具有性能差异。

MapReduce：是Google提出的一个软件架构，用于大规模数据集(大于1TB)的并行计算，通过把数据集的大规模操作分发给网络上的每个节点实现可靠性，每个节点会周期性的把完成的工作和状态的更新报告回来。

Ganglia：Ganglia监控平台是UC Berkeley发起的一个开源集群监控项目，用以监测数以千计的节点，主要是用来监控系统性能，如CPU、内存、磁盘利用率、I/O、网络等。

RRD：Round Robin Database，即环形数据库，使用固定大小的空间来存储数据，并有一个指针指向最新的数据的位置。

Master/Slave节点:Hadoop集群是Master/Slave模式。Master节点包括JobTracker和NameNode，Slave节点包括TaskTracker和DataNode。一个Hadoop集群中Master节点只能有一个，Slave节点可以有多个。

朴素贝叶斯模型(Naive Bayesian Model，NBM)：通过某对象的先验概率，利用贝叶斯公式计算出其后验概率，即该对象属于某一类的概率，选择具有最大后验概率的类作为该对象所属的类。设x＝{a₁,a₂…a_m}为一个待分类项，而每个a为x的一个特征属性，有类别集合C＝{y₁,y₂…y_n}，利用贝叶斯公式计算得出各后验概率值：P(y₁|x),P(y₂|x),…,P(y_n|x)，如果P(y_k|x)＝max{P(y₁|x),P(y₂|x),…,P(y_n|x)}，则x∈y_k，即待分类样本x属于类别y_k。

贝叶斯公式：用于描述两个条件概率之间的关系，如P(A|B)和P(B|A)。按照乘法法则：P(A∩B)＝P(A)*P(B|A)＝P(B)*P(A|B)，也可变形为：P(B|A)＝P(A|B)*P(B)/P(A)。

如图1所示，本发明中，基于Hadoop的负载自适应任务调度系统的架构主要包括三方：Hadoop客户端、Hadoop服务器端以及监控服务器端。其中，Hadoop服务器端包括一个Master节点以及多个Slave节点。

如图2所示，本发明中，基于Hadoop的负载自适应的任务调度系统工作流程如下：

步骤201，集群启动，各节点后台负载、软件以及硬件三方监控开启；

步骤202，节点按规定监控时间间隔将三方监控信息发送至监控服务器，本实施例中，监控时间间隔为30s；

步骤203，监控服务器汇总集群各节点负载监控信息，计算得出集群负载特征均值：x＝{io_util，cpu_util}；

步骤204，利用朴素贝叶斯分类器进行在线负载类型判定；

步骤205，监控服务器根据集群负载类型选择特征量load_average或者io_util，判定集群负载压力状况；

步骤206，监控服务器根据当前集群所属负载类型选择计算能力评估模型，如果集群当前负载为CPU密集型，转步骤207；如果集群当前负载为I/O密集型，转步骤208；否则，执行步骤209；

步骤207，选择CPU密集型负载对应的计算能力评估模型，代入软件、硬件监控信息值，计算得出集群执行节点计算能力大小，执行步骤210；

步骤208，选择I/O密集型负载对应的计算能力评估模型，代入软件、硬件监控信息值，计算得出集群执行节点计算能力大小，执行步骤210；

步骤209，选择混合型负载对应的计算能力评估模型，代入软件、硬件监控信息值，计算得出集群执行节点计算能力大小，执行步骤210；

步骤210，监控服务器将集群负载压力状况文件以及执行节点优先级列表传送给主节点；

步骤211，主节点读取文件，判断是否需要执行集群负载预警，如果是，转步骤212，否则，执行步骤215；

步骤212，进行集群负载预警，如果集群负载超负荷，转步骤213；如果集群负载轻负荷，转步骤214；

步骤213，增加集群执行节点，转步骤202；

步骤214，减少集群执行节点，转步骤202；

步骤215，执行负载自适应的动态任务调度方案，根据节点优先级大小进行任务分配，转步骤202。

图3为本发明中负载、软件以及硬件三方监控的处理流程，包括：

步骤301，集群启动，各执行节点开启负载监测代理、软件监测代理以及硬件监测代理；

步骤302，判断距离上次监控信息发送是否有一个监控时间间隔，若有，执行步骤303，否则循环等待；

步骤303，将监控时间间隔内产生的节点负载、软件以及硬件三方监控信息写入磁盘；

步骤304，将负载、软件监控信息用插件Ganglia自带插件gmetric发送给监控服务器；

步骤305，将硬件监控信息文件用gmond标准发送给监控服务器，转步骤302。

其中，步骤301中的负载、软件以及硬件三方监测代理实现方法如下：

1、负载监测代理：利用系统命令top、iostat获取规定监控时间间隔内平均系统负载load_average、平均cpu利用率cpu_util以及平均io操作所占比io_util。为减少单次采集数据的不准确性，本实施例中，系统每隔1秒采集一次io操作所占比，连续执行30次后求取均值，作为该执行节点当前监控时间间隔内io操作频度的特征量，并写入文件。

2、硬件监测代理：本实施例中，分布式监控系统采用Ganglia监控系统，监控需要配置gmond.conf文件中的metric name、time_threshold以及cluster name。具体包括对CPU利用率、磁盘利用率、内存利用率存以及网络利用率四项内容的配置；本实施例中，监控时间间隔设定为30s；节点所属集群名称设置为Hadoop_SlaveMonitor。

3、软件监测代理：本实施例中，软件监测内容包括监控间隔内节点上任务执行成功率、任务推测执行失败次数、投放任务平均等待时间以及执行任务平均响应时间四项，主要通过植入监控代码实现，具体方案如下：

(1)TaskSucRate信息提取

Hadoop集群开启后，执行节点上的TaskTracker进入主循环线程，同时启动自定义添加的后台监测线程SlaveMonitor，整个节点任务执行成功率的监控流程包括对TaskTracker主循环线程的修改，以及后台监测线程SlaveMonitor的修改，具体实现如下：

①线程1：Hadoop集群Slave节点的主线程

一旦节点上有任务对象执行成功，则进行标记。

②线程2：后台监控线程SlaveMonitor

SlaveMonitor会循环检测节点本地监控文件距离上次更新是否已经有一个监控间隔的时间。如果线程监测到距离上次更新监控文件时间间隔已有30s，则更新节点本地监控文件中TaskSucRate变量值，计算公式为：

TaskSucRate＝success/totalTIPs；

式中，success为当前监控时间段内执行任务成功次数；totalTIPs为执行节点当前任务列表长度。同时记录下当前系统的unix时间戳，此时一轮监控完成。

(2)TaskSpekilledTimes信息提取

该指标为执行节点上开启的推测执行任务被中途终止的次数。Hadoop集群开启后，执行节点上的TaskTracker进入主线程，同时启动自定义添加的后台监测线程SlaveMonitor，整个节点任务失败次数的监控流程包括对TaskTracker主循环线程的修改，以及后台监测线程SlaveMonitor的修改，具体实现如下：

①线程1：Hadoop集群Slave节点的主线程

一旦节点上有任务对象被杀死，则进行标记。

②线程2：后台监控线程SlaveMonitor

SlaveMonitor会循环检测节点本地监控文件距离上次更新是否已经有一个监控间隔的时间。如果线程监测到距离上次更新监控文件时间间隔已有30s，则更新节点本地监控文件中TaskSpekilledTimes变量值，用当前系统全局变量killedtasks的值替换，同时记录下当前系统的unix时间戳，此时一轮监控完成。

(3)averageWaitForSlot信息提取

该指标用于预测当新任务分配到该节点上时，为获取空任务槽所需要的平均等待时间。Hadoop集群开启后，启动自定义添加的后台监测线程SlaveMonitor，整个节点空闲任务槽的平均等待时间的监控流程如下：

①后台监测线程休眠一个小监测时间间隔后执行，在本实施例中，将一个监测时间段划分为5个小监测时间段后求取各段空闲任务槽平均等待时间的平均值。

②遍历Slave节点上正在运行的任务管理对象TaskInProgress(TIP)，对各TIP剩余执行时间求取平均值。对于单个正在运行的TIP而言，剩余的任务执行时间WaitTime求取公式如下：

式中，progress为Hadoop提供的当前任务的执行进度；currentTime为系统当前时间，dispatchTime为该任务被分配时刻；progressRate为Slave节点上该任务的执行速率；则节点单个槽的平均等待时间averageWaitTime求取公式如下：

式中，slotNumbers为该Slave节点上所有任务槽个数；n为当前时刻该执行节点上正在运行的总任务数目。

③如果当前系统时间距离上一次更新已达到监测间隔30s，则转步骤④；否则，转步骤①；

④将此次30s监测间隔内的5个小监测时段获取到的单个任务槽的平均等待时间averageWaitTime进行平均值求取，从而获得最终软件监测量averageWaitForSlot，即当前节点在监测间隔内单个任务槽的平均等待时间，其求取公式如下：

式中，averageWaitTime为步骤②所得值；同时，对执行节点本地的监测文件进行更新，具体为执行覆盖写的操作；

⑤一轮监控完成，同时记录下系统当前unix时间戳，返回步骤①进行下一轮软件监控信息的提取。

(4)ResponseTime信息提取

该变量为执行节点在规定监控间隔内执行任务的平均响应时间。Hadoop集群开启后，执行节点上的TaskTracker进入主线程，同时启动自定义添加的后台监测线程SlaveMonitor，整个节点任务失败次数的监控流程包括对TaskTracker主循环线程的修改，以及后台监测线程SlaveMonitor的修改，具体实现如下：

①线程1：Hadoop集群Slave节点的主线程

一旦节点上有任务对象完成，则计算其响应时间responseTime，并加入到全局队列中，任务响应时间的计算公式为：

responseTime＝finishTime–startTime

式中，finishTime为任务执行完成的时间；startTime为该任务初始被分配的时间。

②线程2：后台监控线程SlaveMonitor

SlaveMonitor会循环检测节点本地监控文件距离上次更新是否已经有一个监控间隔的时间。如果线程监测到距离上次更新监控文件时间间隔已有30s，则计算出当前节点在规定监测间隔内执行任务的平均响应时间averageResponseTime，其求取公式如下：

式中，respnseTime为监测间隔内节点上成功执行完成的任务的响应时间；N为当前监测间隔内该节点上成功执行完成的任务数量。

同时，对执行节点本地的监测文件进行更新，记录当前系统的unix时间戳，此时一轮监控完成。

各执行节点将本地三方监控信息发送给集群监控服务器，同时监控服务器启动负载、软件以及硬件信息监测代理，在端口8651进行监听，按照<机器节点名，节点监测信息>形式将集群所有节点的三方监控信息分类写入磁盘。其中，负载监控信息和软件监控信息可以直接从RRD数据库实时获取，而各硬件监测变量由于存在单位和量级的差异，本实施例中统一对硬件监测量进行归一化处理，通过在RRD数据库中读取剩余量和总量，利用公式Util＝剩余量/总量得到实时计算值。各硬件监测量：内存、CPU、网络以及磁盘利用率计算公式依次为：

MemUtil＝MemFree/MemTotal

CpuUtil＝CpuFree/CpuTotal

NetUtil＝NetFree/NetTotal

DiskUtil＝DiskFree/DiskTotal

其中，NetTotal根据实际使用的网卡而定，IB网络或IP网络，单工或双工网络计算方法均有一定区别。

如上所述，监控服务器收集集群所有节点的负载、软件以及硬件三方监测信息后，会结合集群负载特征向量判定当前集群所属负载类型，处理流程具体包括朴素贝叶斯分类器的离线训练和在线计算判定两部分，具体描述如下：

(1)分类器离线训练：设类别集合C＝{cpu密集型负载，io密集型负载，混合型负载}，待分类负载x＝{cpu利用率cpuutil，io操作比ioutil}。

运行多种类型的负载训练样本，动态采集集群监控时间段内负载特征属性cpuutil、ioutil，计算每个类别在训练样本中的出现频率：P(cpu密集型)、P(io密集型)和P(混合型)，以及每个特征属性划分对每个类别的条件概率估计：P(cpuutil|cpu密集型负载)、P(ioutil|cpu密集型负载)、P(cpuutil|io密集型负载)、P(ioutil|io密集型负载)、P(cpuutil|混合型负载)和P(ioutil|混合型负载)，并将结果记录。

(2)负载在线分类：对于一个运行中的待分类负载x，监控服务器端动态获取集群各执行节点平均cpu利用率以及io操作比，得到负载特征向量x＝{cpuutil，ioutil}，并按如下贝叶斯公式计算该负载后验概率P(C_i|x)：

P(Ci|x)＝P(x|C_i)P(C_i)/P(x)＝P(C_i)∏P(x_i|C_i)/P(x)，i∈[1,3]；

以上公式中，由于分母对所有类别均为常数，因此有max{P(Ci|x)}＝max{P(C_i)P(x_i|C_i)}，i∈[1,3]，计算比较后，具有最大后验概率的类即为该待分类负载所属的类。

图4为系统负载压力状况监听的处理流程图，包括：

步骤401，监控服务器读取集群各执行节点系统平均负载以及io操作所占比，汇总后求取平均值，得出集群平均系统负载load_average以及集群平均一秒io操作所占比io_util；

步骤402，根据集群负载类型选择评判量进行负载压力的判定。如果当前集群负载为CPU密集型，转步骤403；如果集群负载为I/O密集型，转步骤404；否则，转步骤405；

步骤403，按如下公式判定集群负载压力状况：

其中，Hadoop_Feature代表集群负载压力状态，γ、δ为设定阈值的上、下限，load_average代表集群平均系统负载；如果load_average高于设定的阈值上限γ，则判定当前集群负载属于超负荷扩容型；如果load_average低于设定的阈值下限δ，则判定当前集群负载属于轻负荷收缩型；如果load_average在设定阈值的上、下限之间，则判定当前集群负载属于自适应调度型。一般而言，阈值上、下限根据集群机器平均cpu核数而定。假定集群机器平均CPU核数为n，一般而言，阈值下限δ取0.2*n，阈值上限γ取n；

步骤404，按如下公式判定集群负载压力状况：

其中，Hadoop_Feature代表集群负载压力状态，β、α为设定阈值的上、下限，io_util代表集群一秒内平均io操作所占比；如果io_util高于设定的阈值上限β，则判定当前集群负载属于超负荷扩容型；如果io_util低于设定的阈值下限α，则判定当前集群负载属于轻负荷收缩型；如果io_util在设定阈值的上、下限之间，则判定当前集群负载属于自适应调度型；

步骤405，当集群负载为混合型时，集群负载压力状态判定需同时考虑系统平均负载load_average以及io操作平均所占比io_util。

下面结合图5所示流程，对集群节点计算能力评估过程进行详细描述。如图5所示，节点计算能力评估模型的离线训练处理流程包括以下几个步骤：

首先基于集群运行不同类型的代表性负载，由用户指定数据采集的时间段，并通过rrdtool从监控服务器rrd数据库进行顺序采集；

然后根据获取到的集群运行数据，绘制出各自变量和因变量的相关关系图，根据图形特征选择策略，代入采集的监测量进行学习建模，同时利用SPSS软件计算得出模型策略参数和拟合度；

最后根据得出的拟合度对模型进行评估，若评估通过，则可得出在CPU密集型、I/O密集型以及混合型负载状态下对应的模型参数，致此，模型离线训练完成。

其中，可按照以下评估模型公式确定集群执行节点的综合计算能力：

Node_ResTime＝β₀+β₁F₁(TaskSucRate)+β₂F₂(TaskSpekilledTimes)

+β₃F₃(WaitTime)+β₄F₄(Cpuutil)

+β₅F₅(Memutil)+β₆F₆(Diskutil)

+β₇F₇(Netutil)+C

式中，Node_ResTime为因变量，代表监控时间间隔内执行节点执行任务的平均响应时间，TaskSucRate代表监控时间间隔内执行节点执行任务的成功率，TaskSpekilledTimes代表推测执行失败的任务数，WaitTime代表投放新任务的平均等待时间，Cpuutil代表监控时间间隔内CPU的利用率，Memutil代表内存利用率，Diskutil代表磁盘利用率，Netutil代表网络利用率；C为预先需要考虑的其他因素对节点计算能力优先级的影响的函数；β₁、β₂、β₃、β₄、β₅、β₆、β₇分别为函数F₁(TaskSucRate)、F₂(TaskSpekilledTimes)、F₃(WaitTime)、F₄(Cpuutil)、F₅(Memutil)、F₆(Diskutil)以及F₇(Netutil)对应的权重。

在Hadoop集群运行过程中，监控服务器会根据探测到的集群负载类型，选择对应的计算能力评估模型进行建模。如果当前集群负载状态为CPU密集型，则调用CPU密集型负载对应的模型参数进行建模；如果集群负载状态为I/O密集型，则调用I/O密集型负载对应的模型参数进行建模；否则，调用混合型负载对应的模型参数进行建模。其中，Node_ResTime值越低，则节点综合计算能力较强，赋予更高的调度优先级priority；Node_ResTime值越高，节点综合计算能力较弱，适当给予低的调度优先级priority。本实施例中，priority＝0代表节点优先级最高。遍历得出集群所有节点综合计算能力优先级列表，写入本地文件，并传送给集群Master节点。

图6是集群执行负载自适应的任务调度策略的工作流程，包括：

步骤601，后台控制集群规模的线程启动，读取主节点本地扩容/收缩跟踪文件中集群负载状态值。如果当前集群负载状态为负载自适应，转步骤602；若集群负载状态为超负荷，转步骤603；若集群负载状态为轻负荷，转步骤604；

步骤602，当前集群负载状态良好，进行负载自适应的任务调度，包括：解析请求任务的节点名称，从全局的<节点，计算能力优先级>映射表中获取当前请求节点对应的计算能力优先级，计算能力优先级每增加一级，则主节点多给该节点分配一个任务，后转步骤601；

步骤603，当前集群负载压力过大，需紧急扩容，立刻加入新的Slave节点，转步骤601；

步骤604，当前集群节点过剩，迅速将集群规模收缩，移除之前为紧急扩容加入的应急节点，转步骤601。

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

Claims (6)

1.一种基于MapReduce的负载自适应的任务调度方法，其特征在于，包括以下步骤：

(1)动态监测Hadoop集群负载状态；

(2)动态监测集群各执行节点在执行任务过程中产生的软件信息，包括任务执行成功率、任务推测执行失败次数、投放任务平均等待时间以及执行任务平均响应时间四项；

(3)动态监测集群各执行节点在执行任务过程中产生的硬件信息，包括节点CPU、内存、I/O以及网络使用情况；

(4)汇总步骤(1)、步骤(2)以及步骤(3)中采集到的集群各执行节点的负载监控信息、软件监控信息以及硬件监控信息三方监控信息，建模计算集群各执行节点的计算能力；具体包括如下子步骤：

(4-1)离线训练模型：综合考虑节点在监控时间间隔内的负载、软件以及硬件监控信息，按如下评估模型公式确定集群执行节点的综合计算能力:

Node_ResTime＝β₀+β₁F₁(TaskSucRate)+β₂F₂(TaskSpekilledTimes)

+β₃F₃(WaitTime)+β₄F₄(Cpuutil)

+β₅F₅(Memutil)+β₆F₆(Diskutil)

+β₇F₇(Netutil)+C

式中，Node_ResTime代表监控时间间隔内执行节点执行任务的平均响应时间，TaskSucRate代表监控时间间隔内执行节点执行任务的成功率，TaskSpekilledTimes代表推测执行失败的任务数，WaitTime代表投放新任务的平均等待时间，Cpuutil代表监控时间间隔内CPU的利用率，Memutil代表内存利用率，Diskutil代表磁盘利用率，Netutil代表网络利用率；C为预先需要考虑的其他因素对节点计算能力优先级的影响的函数；β₁、β₂、β₃、β₄、β₅、β₆、β₇分别为函数F₁(TaskSucRate)、F₂(TaskSpekilledTimes)、F₃(WaitTime)、F₄(Cpuutil)、F₅(Memutil)、F₆(Diskutil)以及F₇(Netutil)对应的权重；

针对不同类型的代表性负载，离线收集集群运行过程中提取出的各执行节点三方监测历史信息，采用多元线性回归模型进行训练、建模，从而得出在CPU密集型、I/O密集型以及混合型负载状态下对应的计算能力模型参数；

(4-2)在线模型计算：根据步骤(1)中得出的集群负载类型选择对应的计算能力评估模型进行建模；如果当前集群负载状态为CPU密集型，则调用CPU密集型负载对应的模型参数代入计算；如果当前集群负载状态为I/O密集型，则调用I/O密集型负载对应的模型参数代入计算；否则，调用混合型负载对应的模型参数进行代入计算；

(5)执行集群负载预警功能，并根据集群各执行节点计算能力进行智能任务调度。

2.根据权利要求1所述的基于MapReduce的负载自适应的任务调度方法，其特征在于，所述步骤(3)中动态监测集群硬件信息方法，是通过集群分布式监控系统实现。

3.根据权利要求1或2所述的基于MapReduce的负载自适应的任务调度方法，其特征在于，所述步骤(1)中，具体包括如下子步骤：

(1-1)集群负载类型监听：动态提取集群各执行节点在监控时间间隔内平均cpu使用率及io操作比，利用贝叶斯分类器，判定当前集群负载类型；

(1-2)集群负载压力状态监听：动态提取集群运行过程中集群节点平均负载即load_average以及一秒内io操作平均所占比即io_util，根据当前集群所属负载类型选择系统变量，load_average或者io_util，来判定集群负载压力状态，具体包括：当集群负载为CPU密集型时，集群负载压力状态判定方法为:

其中，Hadoop_Feature代表集群负载压力状态，γ、δ为设定阈值的上、下限，load_average代表集群平均系统负载；如果load_average高于设定的阈值上限γ，则判定当前集群负载属于超负荷扩容型；如果load_average低于设定的阈值下限δ，则判定当前集群负载属于轻负荷收缩型；如果load_average在设定阈值的上、下限之间，则判定当前集群属于负载自适应调度型；阈值上、下限根据集群机器平均cpu核数而定，阈值下限δ取0.2*n，阈值上限γ取n，其中n为集群机器平均CPU核数；

当集群负载为I/O密集型时，集群负载压力状态判定方法为：

其中，Hadoop_Feature代表集群负载压力状态，β、α为设定阈值的上、下限，io_util代表集群一秒内平均io操作所占比；如果io_util高于设定的阈值上限β，则判定当前集群负载属于超负荷扩容型；如果io_util低于设定的阈值下限α，则判定当前集群负载属于轻负荷收缩型；如果io_util在设定阈值的上、下限之间，则判定当前集群负载属于自适应调度型；

当集群负载为混合型时，集群负载压力状态判定需同时考虑系统平均负载load_average以及io操作平均所占比io_util。

4.根据权利要求3所述的基于MapReduce的负载自适应的任务调度方法，其特征在于，所述步骤(1-1)中使用朴素贝叶斯分类器，所述步骤(1-1)具体包括以下步骤：

(1-1-1)离线分类器训练：

设类别集合C＝{cpu密集型负载，io密集型负载，混合型负载}，待分类负载x＝{cpu利用率cpuutil，io操作比ioutil}；

运行多种类型的负载训练样本，动态采集集群监控时间段内负载特征属性cpuutil、ioutil，计算每个类别在训练样本中的出现频率：P(cpu密集型)、P(io密集型)和P(混合型)，以及每个特征属性划分对每个类别的条件概率估计：P(cpuutil|cpu密集型负载)、P(ioutil|cpu密集型负载)、P(cpuutil|io密集型负载)、P(ioutil|io密集型负载)、P(cpuutil|混合型负载)和P(ioutil|混合型负载)，并将结果记录；

(1-1-2)负载在线分类：Hadoop集群启动后，对于一个运行中的待分类负载x，监控服务器端动态获取集群各执行节点平均cpu利用率以及io操作比，得到负载特征向量x＝{cpuutil，ioutil}，并按如下贝叶斯公式计算该负载后验概率P(C_i|x)：

P(Ci|x)＝P(x|C_i)P(C_i)/P(x)＝P(C_i)∏P(x_i|C_i)/P(x)，i∈[1,3]；

以上公式中，由于分母对所有类别均为常数，因此有max{P(Ci|x)}＝max{P(C_i)P(x_i|C_i)}，i∈[1,3]，计算比较后，具有最大后验概率的类C_i即为该待分类负载所属的类。

5.根据权利要求1或2所述的基于MapReduce的负载自适应的任务调度方法，其特征在于，所述步骤(2)中动态监测集群软件信息方法，是通过在Hadoop中植入自定义监控代码实现，包括在监控时间间隔内获取节点执行任务的成功率、任务推测执行的失败次数、投放任务平均等待时间以及执行任务的平均响应时间四项。

6.根据权利要求1或2所述的基于MapReduce的负载自适应的任务调度方法，其特征在于，所述步骤(5)具体包括；当集群负载状态处于超负荷扩容型，立刻增加节点；当集群负载处于轻负荷收缩型，移除之前扩容新增的节点；当集群正常、稳定运行，开始负载自适应调度，根据当前集群各执行节点的计算能力大小进行动态任务拉取，计算能力越优异的节点拉取更多的任务，计算能力相对弱的执行节点则适当拉取少量任务。