CN104298550A - 一种面向Hadoop的动态调度方法 - Google Patents

Abstract

本发明提供一种面向Hadoop的动态调度方法，包括以下步骤:S1：设置每个节点的计算能力是一致的；且每个作业的执行时间随着执行次数的增加而线性减少；S2：判断作业是否为同类作业，且获取并统计同类作业的执行情况；S3：解析每个作业提交时所制定的期望执行时间；S4：若判定作业为同类作业，则会建立代价模型得到作业权重值；S5：若判断作业不为同类作业，则分配最低权重值；S6：根据作业权重值调整作业实际资源量，提高实时作业的响应度。本发明可以有效地解决现有调度算法在调度实时作业上的不足，并对实时作业进行资源控制，以此提高实时作业效率的能力，从而达到用户精细控制作业执行速度的功能。

Description

一种面向Hadoop的动态调度方法

技术领域

本发明涉及电子技术应用领域，具体涉及对Hadoop平台的FairScheduler算法的改进的一种面向Hadoop的动态调度方法。

背景技术

随着网络信息技术的迅猛发展，每天数十亿的请求访问量造成了PB级别的数据库存储量，Hadoop作为一个开源的大型数据处理平台，成为了云计算的最佳选择。Hadoop是一个能够对大量数据进行分布式处理的软件框架，因为它可以部署在异构集群的基础设施和普通的硬件中，从而使得云计算具有易于扩展的特性。Hadoop是目前主流的云计算解决方案，通过实现简单的两个函数来解决大数据集的分析问题。

在Hadoop框架中作业调度是关乎作业执行效率与用户响应的关键。现有的算法无论是Fair Scheduler(公平调度)或者Capacity Scheduler(计算能力调度)都不能很好的处理用户实时提交的作业；在Fair Scheduler调度算法中当集群空闲时作业能够得到资源执行，但是当集群满载时，针对实时的作业Fair Scheduler不能很好的调度合适的资源给予实时作业执行，常见的状况是实时作业需要等待Fair Scheduler重新进行公平共享量的计算,同时需要对资源池的资源进行抢占时才能获得与新设置的公平共享量相适应的资源；而Capacity Scheduler调度算法仅仅是FIFO(先入先出)调度算法的多队列的实现。因此，如何针对作业调度进行优化从而提高Hadoop的性能势在必行。

发明内容

针对上述现有调度算法中的问题，本发明的目的是提供一种面向Hadoop的动态调度方法，以解决现有技术中高实时性作业无法得到响应、作业执行速度难以控制、Fair Scheduler基于缺额的资源抢占方法使大作业的占用的资源巨大导致小作业迟迟得不到资源，从而导致小作业难以得到及时的调度的问题。

为解决上述问题，根据本发明的一种面向Hadoop的动态调度方法，包括以下步骤:

S1：设置每个节点的计算能力是一致的，且每个作业的执行时间随着执行次数的增加而线性减少；

S2：判断作业是否为同类作业，且获取并统计同类作业的执行情况；

S3：解析出每个作业提交时的期望执行时间；

S4：若判断作业为同类作业，则建立代价模型以得到作业权重值；

S5：若判断作业不为同类作业，则给该作业分配最低权重值；

S6：根据作业权重值调整作业实际资源量，提高实时作业的响应度。

在一些实施方式中，步骤S2进一步包括：

创建监听事件执行中的作业进行监听，在监听事件中激活抓取方法对运算完成或者失败的作业进行信息回收，

作业的运行记录数据通过计数器记录，

用正则表达式解析计数器记录的运行记录数据，生成对应的实例，再从实例中进行提取并解析用户在提交作业时自定义的数据，

使用数据库存储作业信息，通过所述数据库存储一个作业中的多个运行参数键值对；

为防止所述数据库中存储所述作业信息数据丢失，设定每隔一个预设的储存时间将数据库中的作业信息数据持久化到存储设备中；

其中，

同类作业的判断是根据作业名的相似程度判定的。

在一些实施方式中，步骤S3进一步包括：

用户在Hadoop集群中期望提交的作业的工作时间即用户期望执行时间，最高阀值为作业占用用户资源池所有资源，最低阀值为占用1个单位的资源(slot)；

采取推测执行机制获得用户期望执行时间；

在推测执行机制的基础上，建立作业代价模型来制定实际期望执行时间。

在一些实施方式中，步骤S4中，若判定作业同类作业，则建立代价模型的步骤如下：

根据Map作业和Reduce作业所产生的历史数据来决定代价模型；

对Map作业和Reduce作业各个阶段进行分析，对作业持续时间进行更改，更改的作业持续时间为：

$D+A\≥\frac{\mathrm{\σ}}{n_m\×C_m}+\frac{\mathrm{f\σ}}{n_r\×C_r}+\frac{\mathrm{f\σ}}{C_d}+\mathrm{f\σ}/C_s$

其中，D表示用户设定的期望工作时间、A表示查询到来的时间、σ表示输入数据大小、n_m是map任务的资源槽数目、C_m表示Map任务处理单元数据的速率、fσ表示Map任务输出端的数据量、n_r表示Reduce任务的资源槽数目、C_r表示Reduce任务处理单元数据的速率、C_d表示单元数据网络传输的速率、C_s表示单元数据排序的速率；

根据以上步骤，得到使作业在期望工作时间内完成的最低占用的资源数，根据这个资源数获取作业在集群中的权重值，根据作业权重值来动态地调整资源数。

在一些实施方式中，对作业分配权重的步骤包括：

若提交的作业在数据库中无同类作业，则分配最低权值；

若提交的作业在数据库中有同类作业且为用户提交的实时作业，读取数据库中的同类作业信息，排除作业执行效率最高的作业集与执行效率最低的作业集，对剩余的作业运行参数信息进行平均计算；

对进行平均计算后的作业运行参数信息进行建模，得到用户提交的同类作业的预计执行时间，根据Hadoop集群的实时运行状况与用户的期望作业执行时间来动态分配该作业的权重值，根据作业权重值来动态地调整资源数。

在一些实施方式中，根据作业权重来动态分配调整资源数的步骤如下：

设置实时作业资源池；

对实时作业资源池设置最小资源共享量抢占检测时间，实时作业资源池会每隔若干秒检测当前实时作业资源池的占用资源的数目，当发现占用数没有达到最小公平共享量，会从其他资源池中抢占资源。

在一些实施方式中，还包括对Fair Scheduler的可插拔模块WeightAdjuster接口中的AdjustWeight方法来控制并调整权重，其步骤包括：

更新作业的线程每隔一个预设的更新时间进行一次作业更新的操作，更新的信息包括作业的公平共享量，调度算法日志，WeightAdjuster每隔一个调用阀值被每个作业调用一次；

通过外接接口编写权重调整器来动态调整运行作业的权重；

通过参数Mapred.fairscheduler.weightadjuster使权重调整器生效，作业权重即为WeightAdjuster中方法AdjustWeight的返回值。

通过上述技术方案与现有技术相比具有以下优点：本发明针对应用广泛的高性能平台Hadoop调度算法进行改进，旨在解决现有调度算法无法针对用户实时提交的交互作业进行高响应，提出了一种基于Fair Scheduler的实时作业调度优化方法，能够有效地解决实时作业得不到响应的问题，并且保证其他作业的正常运行，是当前一种较为有效地解决方案。

附图说明

图1为本发明一种实施方式中一种面向Hadoop的动态调度方法中从作业提交到执行过程示意图；

图2为本发明一种实施方式中一种面向Hadoop的动态调度方法中作业调度模型示意图；

图3为本发明一种实施方式中一种面向Hadoop的动态调度方法总体流程示意图；

图4为本发明一种实施方式中一种面向Hadoop的动态调度方法中代价模型工作流程示意图；

图5为本发明一种实施方式中一种面向Hadoop的动态调度方法中任务日志分析工作流程示意图；

图6为本发明一种实施方式中一种面向Hadoop的动态调度方法中集群环境网络拓扑图。

具体实施方式

下面结合附图对本发明作进一步详细的说明。

本发明一种面向Hadoop的动态调度方法以现有Fair Scheduler(公平调度)算法基础上进行优化为例，进行具体说明，但不限于此。整个方法思想是：针对用户提交的实时作业,建立读取历史执行数据,并生成代价模型预估作业执行时间，并通过分析用户提交作业时加入的作业期望执行时间计算作业的实际作业数量，从而使得作业能够在用户定义的期望执行时间计算完成。本发明针对应用广泛的高性能平台Hadoop调度算法进行改进，旨在解决现有调度算法无法针对用户实时提交的交互作业进行及时响应的问题，提出了一种基于Fair Scheduler的实时作业调度优化方法，能够有效地解决实时作业得不到响应的问题，并且保证其他作业的正常运行，是当前一种较为有效的解决方案。

本发明是对Hadoop平台Fair Scheduler算法的改进，设置每个节点的计算能力是一致的(即同构集群)，并且作业的执行时间随着执行次数的增加而线性减少。首先判断作业在执行之前是否为同类作业，判断的同时获取同类作业的执行情况并进行统计，若判定作业为同类作业，则会建立代价模型进行分析，作业通过代价模型会计算作业权重值，根据作业权重值调整作业实际资源量，通过使用Fair Scheduler中WeightAdjuster(权重调整器)接口中的AdjustWeight方法来控制并调整权重值，用户在提交实时作业时需要制定一个期望执行时间。

在作业执行时首先判断该作业是否为同类作业，获取同类作业的执行情况并进行统计，步骤包括：

在JobListener(作业监听)中创建事件JobAdd(作业添加)、JobUpdate(作业更新)和JobRemove(作业删除)，对JobTracker(作业追踪)进行监听。

JobTracker是一个后台服务进程，启动之后，会一直监听并接收来自各个TaskTracker发送的心跳信息，包括资源使用情况和任务运行情况等信息。TaskTracker是JobTracker和Task之间的桥梁：一方面，从JobTracker接收并执行各种命令：运行任务、提交任务、收回任务等；另一方面，将本地节点上各个任务的状态通过心跳周期性汇报给JobTracker。TaskTracker与JobTracker和Task之间采用了RPC协议进行通信。

在JobRemoved事件中激活抓取方法对运算完成或者失败的作业进行信息回收，作业的运行记录通过计数器(Counter)记录。对应每个作业有两种类型的Counter，一种是系统记录型，另外一种是用户自定义型。系统记录型的格式为简单的键值对，用户自定义的格式类似Json格式。针对两种不同的格式，本方法使用了两种解析办法，对于系统定义的记录是用正则表达式(与所需的数据进行匹配)提取所有的键值对，而类似Json格式的内容是用序列化的技术(序列化是将对象的状态信息转换为可以存储或传输的形式的过程)生成对应的实例再从实例进行提取，序列化技术为现有技术，在此不做详细说明。解析后的数据使用非关系型数据库Redis来进行存储。由于每天都有很多的作业产生，针对大量的同类的作业的历史数据不能依靠每次遍历日志文件夹来实现，考虑到读取的历史信息都是基于Key/Value的格式，所以本发明采用了NOSQL数据库中应用广泛并且高效的Redis数据库。每次解析到的字符串都将加入Redis中，同时为了防止Redis所在机器的某些异常导致的内存丢失，为防止所述数据库中存储所述作业信息数据丢失，设定每隔一个预设的储存时间将数据库中的作业信息数据持久化到存储设备中，本发明设定了每一个小时将内存中的信息持久化到磁盘中，确保数据不会丢失。通过Hashmap存储一个作业中的多个运行参数键值对；同类作业的判断是根据作业名的相似程度判定的，相似程度依靠作业名分词项的匹配个数决定，匹配的个数越多，则相似程度越高。

用户提交的实时作业需要制定一个期望执行时间，步骤如下：

设定用户期望提交的作业在Hadoop集群中工作的时间，最高阀值为作业占用用户资源池所有资源，最低阀值为占用1个单位的Slot。

采取推测执行机制来估算期望执行时间，推测执行机制是指在估算期望执行时间的过程中为了采集该类作业的执行数据，对该类作业进行推测执行，即不对该类作业的权重值进行更改，保证作业的最低资源1个Slot，设置该类作业的优先级为最低优选级；采用现有技术计算出该类作业的执行数据。在推测执行机制的基础上，建立作业代价模型来制定期望执行时间。建立代价模型的过程如下：

(1)变量定义：

q＝(A，σ，D)：一个查询q,A是查询的到来时间，σ是输入数据大小，D表示用户设定的用户期望执行时间；

J＝(t_m1，t_m2，t_m3，....，t_mu，t_r1，t_r2，...，t_rv：查询q所对应的Hadoop的一个作业。t_mi是第i个Map任务，t_mj是第J个Reduce任务，其中1<＝i<＝u,1<＝j<＝v。

n：集群中分配给该工作的所有Slot数目。n=n_m+n_r,其中n_m是Map任务的Slot数目，n_r是Reduce任务的Slot数目；

a＝(a₁+a₂,…,a_u):Map数据分布向量，其中u是作业J的Map任务的总数。A_j是分配给第j个Map任务的数据的比例。由于Map数据是平均分配给每个Map节点上的，所以a_j＝1/u.

f:过滤比，即Map输出端数据和输入端数据的比值，一般情况下0<＝f<＝1；

fσ：Map任务输出端的数据量；

C_m：Map任务处理单元数据的时间；

C_r：Reduce任务处理单元数据的时间；

C_d：转换单元数据的通信时间(拷贝时间)；

S_m：作业第一个Map任务开始的时间；

S_r：作业第一个Reduce任务的开始时间；

作业能被调度的Map任务需被满足的最小数；

作业能被调度的Reduce任务需被满足的最小数。

(2)计算过程

为了计算作业的持续时间，考虑Map阶段的计算时间，Reduce阶段的计算时间和Reduce的拷贝阶段数据转换时间。因此，作业的持续时间可以表述如下：

$\frac{\mathrm{\&sigma;}{C}_m}{n_m}+\frac{\mathrm{f\&sigma;}{C}_r}{n_r}+\mathrm{f\&sigma;}{C}_d$

由于作业有一个到达时间A和最后期限D，因此需要满足作业开始运行后在作业的运行时间要小于等于用户设置的执行时间。

$s_m+\frac{\mathrm{\&sigma;}{C}_m}{n_m}+\frac{\mathrm{f\&sigma;}{C}_r}{n_r}+\mathrm{f\&sigma;}{C}_d\&le;A+D$

设Reduce任务开始的最大时间则Map任务执行时间要小于等于Reduce作业最大的开始时间。

$S_m+\mathrm{\&sigma;}{C}_m/n_m\&le;S_r^{\max }$

所以， $n_m\&GreaterEqual;\frac{\mathrm{\&sigma;}{C}_m}{S_r^{\max }}-S_m,$ 得出， $n_m\&GreaterEqual;\frac{\mathrm{\&sigma;}{C}_m}{(S_r^{\max }-S_m)}$

因此，Map任务达到预定执行时间的最低资源量为：

$n_m^{\min }=[\mathrm{\&sigma;}{C}_m/(S_r^{\max }-S_m)]$

对应的Reduce任务最低资源量为：

$n_r^{\min }=[\mathrm{f\&sigma;}{C}_r/(A+D-\mathrm{f\&sigma;}{C}_d-S_r)]$

以上是代价模型的建立。而在实际的作业提交过程中发现，作业的ReduceTask的个数是远小于MapTask的，同时集群的Reduce Slot的空闲率较高。也就是说，在作业的Map工作执行完毕，作业基本上都能获得ReduceTask所有的资源以运行用户编写的Reduce函数，于是代价模型的重点转向了如何预估Map阶段的执行时间。故更改的作业持续时间为：

$D+A\&GreaterEqual;\frac{\mathrm{\&sigma;}}{n_m\&times;C_m}+\frac{\mathrm{f\&sigma;}}{n_r\&times;C_r}+\frac{\mathrm{f\&sigma;}}{C_d}+\mathrm{f\&sigma;}/C_s$

其中，C_s为Reduce中的Sort的速度；n_r是一个可知的值(用户提交作业时可以指定，默认是3)。式子中仅有一个未知变量即Map端的资源量n_m，通过分析历史的执行数据并将历史数据带入式中可以得到一个要求作业在期望工作时间内完成的最低满足Slot。之后调度器根据这个Slot获取作业在集群中应该设置的权值。

若判定作业同类作业，则会建立代价模型的步骤包括：

代价模型是根据Map作业的5个阶段Read(读入)、Map(Map函数)、Collect(收集)、Spill(溢写)、Combine(合并)和Reduce作业的5个阶段Shuffle(拷贝)、Merge(整合)、Sort(排序)、Reduce(Reduce函数)，Write(写入)，这十个阶段所产生的历史数据来决定，对于Map作业和Reduce作业各个阶段的分析，本发明对作业持续时间进行了更改，则可以得到使作业在期望工作时间内完成的最低Slot(资源)数，根据这个Slot数获取作业在集群中的权重值。代价模型是根据已有作业历史执行信息，针对Map/ReduceTask每个运行阶段，采取对每个阶段的运行时间或者运行速度进行线性的累加。本发明从作业开始执行时调度上述算法计算出作业的运行时间从而更改作业提交时的权重值。由此考虑，本算法对现有的代价模型进行了改进。

对作业分配权重值的步骤包括：

若提交的作业在Redis中无同类作业，则分配最低权值；若提交的作业在Redis中有同类作业且为用户提交的实时作业，读取Redis中的同类作业信息，排除作业执行效率最高的作业集与执行效率最低的作业集，对剩余的作业运行信息进行平均计算；对平均后的该类作业运行参数信息建立代价模型，得到用户提交的同类作业的预计执行时间，从而可以根据集群的实时运行状况与用户的期望作业执行时间来动态分配该作业的权重值。

根据作业权重值来动态地调整资源数的步骤包括：

在Fair Scheduler的配置文件中人为地设置了一个具有较高资源池权重值的Real-time(实时作业资源池)，对Real-time资源池设置最小资源共享量抢占检测时间30s，资源池会每隔30秒检测当前资源池的占用Slot数目，当发现占用数没有达到最小公平共享量(MinShare配置)，会从其他资源池中抢占资源；在常规操作中，当提交了一个新作业时，Hadoop中的公平调度器会等待已运行作业中的任务完成以释放时间片给新的作业。但公平调度器也支持在可配置的超时时间后对运行中的作业进行抢占。如果新的作业在一定时间内还获取不到最小的共享资源，这个作业被允许去终结已运行作业中的任务以获取运行所需要的资源。因此抢占可以用来保证“生产”作业在指定时间内运行的同时也让Hadoop集群能被实验或研究作业使用。另外，作业的资源在可配置的超时时间内拥有不到其公平共享资源(fairshare)的一半的时候也允许对任务进行抢占。一般设置超时时间大于最小共享资源超时时间，在选择需要结束的任务时，公平调度器会在所有作业中选择近期运行的任务，以最小化浪费的资源。抢占不会导致被抢占的作业失败，因为Hadoop作业不能容忍丢失任务，这只是会让它们的运行时间更长。对于资源池的抢占选取了对占有超过自己最高公平共享量的资源池(MaxShare),当所有的资源池都没有达到最高公平共享量时会调用资源池管理器PoolManager对所有资源池的资源进行重计算，选取公平共享量比重高的资源池进行抢占。

同类作业的判定与同类作业的平均计算的步骤包括：

对于已经处理完毕的作业，对作业名进行分词，利用朴素贝叶斯分类方法(基于人工训练的样本)对作业进行分类，新提交的作业会通过分类器从而判断新提交的作业属于哪一类历史作业；作业在Redis中匹配到多个同类作业的执行信息时会对匹配到的作业信息进行归类及合并，根据作业代价模型的公式，针对其中的每个参数求平均值。

对Fair Scheduler的可插拔模块WeightAdjuster接口中的AdjustWeight方法来控制并调整权重值步骤包括：

预设的更新时间为500ms，通常更新作业的线程每隔500ms进行一次作业更新的操作(可设置)，更新的信息包括作业的公平共享量，调度算法日志等信息。在此线程本发明中编写的WeightAdjuster的调用阀值为500ms被每个作业调用一次；通过实现WeightAdjuster接口编写一个权重值调整器，来动态调整运行作业的权重值；通过参数Mapred.fairscheduler.weightadjuster(公平调度算法权重调整器)来动态地调整权重使之生效，作业权重值即为WeightAdjuster中方法AdjustWeight的返回值。同时，本发明的设计主要利用了Fair Scheduler的可插拔模块WeightAdjuster。Fair Scheduler调度算法中设置了更新作业的线程。为避免已经被调度的作业重复建立代价模型，本发明在内存数据库中设置了作业调度标号，对于不存在标号的作业才可以生成代价模型从而预估执行时间。

如图1为所示为本发明中面向Hadoop的动态调度方法中作业提交到执行过程示意图。在Hadoop中由于Map Task和Reduce Task运行时使用了不同种类的资源(不同的Slot)，且这两种资源之间不能混用，因此任务调度器分别对Map Task和Reduce Task单独进行调度。而对于同一作业而言，ReduceTask和Map Task之间存在的数据依赖关系，默认情况下，当Map Task完成数目达到总数的5％后，才开始启动Reduce Task即Reduce Task开始调度。图1所表示的是一个作业从提交到开始执行的启动过程，整个过程大约需7个步骤，客户端调用作业提交函数将程序提交到JobTracker端(S201)；JobTracker收到新作业后，通知任务调度算法(TaskScheduler)对作业进行初始化(S202)；某个TaskTracker想JobTracker汇报心跳，其中包含剩余的Slot数目和能否接受新任务等信息(S203)；如果该TaskTracker能够接受新任务，则JobTracker调用TaskTracker对外函数AssignTasks为该TaskTracker分配新任务(S204)；TaskScheduler按照一定的调度方法为该TaskTracker选择最合适的任务列表，并将该列表返回给JobTracker(S205)；JobTracker将任务列表以心跳应答的形式返回给对应的TaskTracker；TaskTracker收到心跳应答后，有需要启动的新任务(S206)，则直接启动该任务(S207)。在图1中根据调度器反馈信息判断是否为历史作业，本发明设计了历史分析模块，将在图5中进行详述。判定是历史作业时则会建立代价模型，将在图4中进行详述。

图2为本发明一种实施方式中面向Hadoop的动态调度方法中作业调度模型示意图。在Hadoop中任务调度器和JobTracker之间存在函数相互调用的关系，他们彼此都拥有对方需要的信息或者功能。对于JobTracker而言,它需要调用任务调度器中的分配任务函数AssignTasks函数为TaskTracker分配新的任务，同时，JobTracker内部保存了整个集群中的节点、作业和任务的运行时状态信息，这些信息是任务调度器进行调度决定时需要用到。如图2所示，当一个TaskTracker出现空闲资源时，调度器会依次选择一个队列、队列中的作业和作业中的任务，并最终将这个任务分配给TaskTracker。

本发明与其他调度方法主要区别在于队列选择方法和作业选择方法不同，而任务选择方法通常是相同的，也就是说，给定一个节点，从一个作业中选择一个任务需考虑的因素是一样的，均主要是数据本地性(Data-locality)由于不同调度器采用的任务选择方法相同，因此Hadoop将之封装成一个通用的模块供各个调度器使用，具体存放在JobInProgress类(用来记录job所有信息)中的ObtainNewMapTask(分配Map Task)和ObtainNewReduceTask(分配Reduce Task)方法中。

图3为本发明一种实施方式中面向Hadoop的动态调度方法总体流程示意图。在算法的开始首先根据本发明调度器判断是否为历史作业(S101)，历史作业为已经处理完成了的作业，若为历史作业则建立模型(S102)，计算权重值(S103)，分配相应的Slot(S104)，若不为历史作业，则进行判断是否有空闲Slot(105)，若有则返回当前权值(S106)，若没有则分配最小权值(S107)。分配结束。

本发明的目标旨在复杂的集群作业运行状况中，针对用户提交的实时作业根据同类作业的历史运行状况，指导调度算法合理的调度资源给予实时作业。在既满足实时作业的高响应特性又要保证其他作业依然能够正常执行。不会因为抢占其他作业资源，使得被抢占资源的作业无法正常执行。

图4为本发明一种实施方式中面向Hadoop的动态调度方法代价模型工作流程示意图。本发明的关键模块是作业代价模型的建立，核心则是基于FairScheduler的可插拔模块权重值调整器。该权重值调整期是根据作业的历史执行数据，通过对作业进行代价模型建模从而能够预估作业的执行时间。如何建立作业代价模型来预估作业的执行时间则是需要解决的关键性问题。本发明建立的代价模型是根据Map Task和Reduce Task运行阶段所产生的历史数据所决定的。同时本发明是基于同构集群与负载均衡的条件下进行的。

图5为本发明一种实施方式中面向Hadoop的动态调度方法中任务日志分析工作流程示意图。作为对上层决策做数据支持的模块，历史数据分析模块需要对JobTracker进行监听。在FairScheduler中已经创建了JobListener对JobTracker的几个事件进行了监听，这些事件分别是JobAdd,JobUpdate和JobRemove。本发明的分析模块已经在JobRemove事件中加入了相关的处理方法来对即将运行完成的任务进行数据分析从而避免了多次操作JobTracker的本地磁盘。历史数据分析模块主要负责分析已经完成的任务，这些任务存放在JobTracker的本地磁盘中，需要程序对本地历史文件夹进行遍历并且对所有的任务日志文件进行分析。

在设计分析日志文件时本发明在Hadoop中保存日志文件的格式进行了区分。在Hadoop中，作业的运行记录是通过计数器(Counter)记录的。对应每个作业有两种类型的Counter，一种是系统记录型，另外一种是用户自定义型。针对两种不同的格式本发明使用了两种解析办法，对于系统定义的记录是用正则表达式提取所有的键值对，而类似Json格式的内容是用序列化的技术生成对应的实例再从实例进行提取。

图6为本发明一种实施方式中面向Hadoop的动态调度方法中集群环境网络拓扑图。如图6所示，Hadoop集群采用了三层网络拓扑结构，其中，根节点表示整个集群，第一层代表数据中心601，第二层代表机架或者交换机602，第三层代表实际用于计算和存储的物理节点603。对于目前的Hadoop各个版本而言，默认均采用了二层网络拓扑结构，即数据中心一层暂时未被考虑。为了对本发明进行测试，来验证是否达到预期的效果，搭建了Hadoop集群环境，本发明的所有测试都是在Hadoop集群下运行的，集群由1个Master节点和8个Slave节点共9台机器组成，Master节点604为3核6线程2.2GHz酷睿至强处理器，16G内存和160G存储，Slave机器为4核8线程2.2GHz酷睿至强处理器，18G内存以及150G存储。所有节点运行在Centos6.4系统和Hadoop1.2版本上。集群总共配置了31个可用的MapSlots和31个ReduceSlots。本发明的机器采用虚拟机虚拟化产生，内部网络为千兆，磁盘组成了RAID5。在本发明的测试中，使用了在CPU与IO都有较高要求的WordCount作业作为基准测试标准，集群的网络拓扑如图6所示。

本发明在Hadoop集群下分别进行了算法决策能力实验、权重值与作业实际资源关系测试、作业资源量与作业运行时间测试以及实时作业提交测试。从测试结果可以看出，本发明设计的优化算法不仅提高了作业的决策成功率，也满足了用户实时作业的交互特性与集群正常作业的运行。至此，本发明优化的调度算法已经达到预期目标。

以上表述仅为本发明的优选方式，应当指出，对本领域的普通技术人员来说，在不脱离本发明创造构思的前提下，还可以做出若干变形和改进，这些也应视为本发明的保护范围之内。

Claims (7)

1.一种面向Hadoop的动态调度方法，其特征在于，包括以下步骤:

S1：设置每个节点的计算能力为一致，且每个作业的执行时间随着执行次数的增加而线性减少；

S2：判断作业是否为同类作业，且获取并统计同类作业的执行情况；

S3：解析出每个作业提交时的期望执行时间；

S4：若判断作业为同类作业，则建立代价模型以得到作业权重值；

S5：若判断作业不为同类作业，则给该作业分配最低权重值；

S6：根据作业权重值调整作业实际资源量，提高实时作业的响应度。

2.根据权利要求1所述的一种面向Hadoop的动态调度方法，其特征在于，所述步骤S2进一步包括：

创建监听事件执行中的作业进行监听，在所述监听事件中激活抓取方法对运算完成或者失败的作业进行信息回收，

作业的运行记录数据通过计数器记录，

用正则表达式解析所述计数器记录的运行记录数据，生成对应的实例，再从实例中进行提取并解析用户在提交作业时自定义的数据，

使用数据库存储作业信息，通过所述数据库存储一个作业中的多个运行参数键值对；

为防止所述数据库中存储所述作业信息数据丢失，设定每隔一个预设的储存时间将数据库中的作业信息数据持久化到存储设备中；

其中，

同类作业的判断是根据作业名的相似程度判定的。

3.根据权利要求1所述的一种面向Hadoop的动态调度方法，其特征在于，所述步骤S3进一步包括：

用户在Hadoop集群中期望提交的作业的工作时间即用户期望执行时间，最高阀值为作业占用用户资源池所有资源，最低阀值为占用1个单位的资源；

采取推测执行机制获得用户期望执行时间；

在推测执行机制的基础上，建立作业代价模型来制定实际期望执行时间。

4.根据权利要求1所述的一种面向Hadoop的动态调度方法，其特征在于，所述步骤S4中，若判定作业同类作业，则建立代价模型的步骤如下：

根据Map作业和Reduce作业所产生的历史数据来决定代价模型；

对Map作业和Reduce作业各个阶段进行分析，对作业持续时间进行更改，更改的作业持续时间为：

$D+A\&GreaterEqual;\frac{\mathrm{\&sigma;}}{n_m\&times;C_m}+\frac{\mathrm{f\&sigma;}}{n_r\&times;C_r}+\frac{\mathrm{f\&sigma;}}{C_d}+\mathrm{f\&sigma;}/C_s$

其中，D表示用户设定的期望工作时间、A表示查询到来的时间、σ表示输入数据大小、n_m是Map任务的资源槽数目、C_m表示Map任务处理单元数据的速率、fσ表示Map任务输出端的数据量、n_r表示Reduce任务的资源槽数目、C_r表示Reduce任务处理单元数据的速率、C_d表示单元数据网络传输的速率、C_s表示单元数据排序的速率；

根据以上步骤，得到使作业在期望工作时间内完成的最低占用的资源数，根据这个资源数获取作业在集群中的权重值，根据作业权重值来动态地调整资源数。

5.根据权利要求4所述的一种面向Hadoop的动态调度方法，其特征在于，所述对作业分配权重的步骤包括：

若提交的作业在数据库中无同类作业，则分配最低权值；

若提交的作业在数据库中有同类作业且为用户提交的实时作业，读取数据库中的同类作业信息，排除作业执行效率最高的作业集与执行效率最低的作业集，对剩余的作业运行参数信息进行平均计算；

对所述进行平均计算后的作业运行参数信息进行建模，得到用户提交的同类作业的预计执行时间，根据Hadoop集群的实时运行状况与用户的期望作业执行时间来动态分配该作业的权重值，根据作业权重值来动态地调整资源数。

6.根据权利要求4或5所述的一种面向Hadoop的动态调度方法，其特征在于，所述的根据作业权重来动态分配调整资源数的步骤如下：

设置实时作业资源池；

对实时作业资源池设置最小资源共享量抢占检测时间，所述实时作业资源池会每隔若干秒检测当前所述实时作业资源池的占用资源的数目，当发现占用数没有达到最小公平共享量，会从其他资源池中抢占资源。

7.根据权利要求1所述的一种面向Hadoop的动态调度方法，其特征在于，还包括对Fair Scheduler的可插拔模块WeightAdjuster接口中的adjustWeight方法来控制并调整权重，其步骤包括：

更新作业的线程每隔一个预设的更新时间进行一次作业更新的操作，更新的信息包括作业的公平共享量，调度算法日志，WeightAdjuster每隔一个调用阀值被每个作业调用一次；

通过外接接口编写权重调整器来动态调整运行作业的权重；

通过参数Mapred.fairscheduler.weightadjuster使所述权重调整器生效，作业权重即为WeightAdjuster中方法AdjustWeight的返回值。