Hadoop平台下动态标签匹配DLMS调度方法与流程
本发明属于计算机软件领域，涉及一种基于hadoop平台下动态标签匹配dlms调度方法的设计与实现。
背景技术：
早期hadoop版本由于将资源调度管理和mapreduce框架整合在一个模块中，导致代码的解耦性较差，不能很好的进行扩展，不支持多种框架。hadoop开源社区设计实现了一种全新架构的新一代hadoop系统，该系统为hadoop2.0版本，将资源调度抽取出来构建了一个新的资源调度框架，即新一代的hadoop系统yarn。众所周知在某一确定的环境下合适的调度算法能够在满足用户作业请求的同时，有效的提升hadoop作业平台的整体性能和系统的资源利用率。在yarn中默认自带三种调度器：先入先出(fifo)、公平调度器(fairscheduler)和计算能力调度器(capacityscheduler)。hadoop默认采用的是fifo调度器，该算法采用先进先出的调度策略，简单易实现，但是不利于短作业的执行，不支持共享集群和多用户管理；由facebook提出的公平调度算法考虑不同用户与作业资源配置需求的差异，支持用户公平共享集群的资源，但是作业资源的配置策略不够灵活，容易造成资源的浪费，并且不支持作业抢占；雅虎提出的计算能力调度算法支持多用户共享多队列，计算能力灵活，但是不支持作业抢占易陷入局部最优。
然而在实际的企业生产中，随着企业的数据量加大，每年集群都会加入一些新节点，但是集群节点的性能差异是显著的，这种异构集群在企业生产环境中很普遍。设想如果将一个计算量很大的机器学习的任务分配在cpu计算能力很差的机器节点上，显然会影响作业的整体执行时间。hadoop自带的三种资源调度器并没有很好地解决这个问题，本发明提出了一种节点性能和作业类别标签动态匹配的资源调度方法(dlms)，将cpu性能比较好的机器贴上cpu标签，在磁盘io性能比较好的机器上面贴上io标签或者是两者都一般的普通标签，作业根据分类可以贴上cpu标签、io标签任务或者普通标签，然后进入不同的标签队列，调度器尽可能将相应的标签节点的资源分配给相应的标签作业，从而可以减少作业的运行时间，提高系统资源利用率，提高系统整体效率。
技术实现要素：
本发明提出的调度方法将集群节点进行初始分类并赋予相应的标签。nodemanager发送心跳前进行自我检测并对原始标签进行动态调整，并使用机器学习分类算法对作业进行分类赋予相应的标签，并根据用户设定的作业优先级，作业等待时间等属性动态实现作业的排序，并将相应标签的资源分配给相应的标签队列中的作业。
本发明所提出的调度方法主要包括以下模块：
(1)集群节点原始分类及其动态分类标签
集群节点首先需要进行初始分类，根据节点的cpu和磁盘io性能进行分类。集群中每个节点都需要单独运行一个指定类型的任务并记录下该节点运行该类作业的时间，根据节点运行单个任务的时间与集群中所有节点运行时间平均值的大小关系将节点分成cpu型节点，磁盘io型节点，普通型节点。
在集群节点运行的过程中，如果一个节点运行部分作业导致负载过大，会对这个节点的标签进行降级处理，直接降级为普通节点。一个节点初始标签是cpu型标签，节点中运行cpu型任务，虽然此节点还有部分资源未使用，但是此时环境中节点cpu性能优势已经失去，为避免这种情况出现，采取动态标签方法，在nodemanager向resourcemanager发送心跳的时候动态检测该节点机器的cpu和io使用率，如果超过阈值，就将此节点标签贴上普通标签，每次发送心跳时都需要进行检测一次，由此实现节点动态标签。此阈值可以在配置文件中自行配置，如果用户未配置会参照系统默认值。
(2)map执行信息的获取与回传
hadoop作业通常分成map阶段和reduce阶段，通常大作业map数量在上百个甚至更多，一个作业主要时间是花费在map阶段的计算上，但是每个map又是完全相同的执行逻辑，所以会收集作业运行的第一个map进程的运行信息，这些信息在nodemanager向resourcemanager发送心跳时传递到调度器中，调度器根据传回的信息进行作业的分类。
企业生产环境中，每天都会运行一些相同内容逻辑的作业，即用户已知作业应所属的标签，在命令行或者代码中为作业设置作业类型标签，在调度的时候调度器会进行检查，如果用户已经对作业贴上标签，就省去作业分类的环节，直接进行调度。
(3)多优先级队列
为满足不同用户的需求，防止小作业出现“饥饿”现象，采用作业优先级方案。在调度器中新建5个队列即：原始队列、等待优先级队列、cpu优先级队列、io优先级队列和普通优先级队列。用户提交作业首先是进入原始队列中，先运行作业部分map并收集这部分map运行信息，然后作业进入等待优先级队列中等待map的运行信息回传并进行分类，最后根据作业的分类类别标签进入到对应标签的队列中。
(3)作业分类
在分类之前需要对数据进行预处理，数据预处理是指在前期对数据进行一些处理。为提高数据挖掘的质量产生了数据预处理技术。数据预处理技术有多种方法：数据清理、数据集成、数据变换和数据规约。这些数据处理技术在数据挖掘之前使用，大大提高数据挖掘模式的质量，降低实际挖掘所需时间。本文数据预处理主要是在数据归一化方面。数据归一化就是把各个变量数据都线性地变换到一个新标尺上，变换后变量最小值为0，最大值为1，这样就保证所有的变量数据都小于等于1。
在作业分类方面选择了简单、使用比较普遍而且分类效果较好的朴素贝叶斯分类器进行分类。如果用户在命令行和任务代码中已经添加作业的类型的话，这个步骤会省掉，直接进入相应的队列中等待分配资源。
(4)数据本地性
hadoop中遵循一个原则是“移动计算比移动数据更好”，移动到放置数据的计算节点要比把数据移动到一个计算节点更加节省成本，性能更好。关于数据本地性本发明采取了延时降级调度策略。
有益效果如下：
1.本发明针对异构集群环境提出一种动态标签匹配的调度方法，通过对节点和作业进行分类，结合作业本身特性以及提交用户的属性共同组计算作业优先级，在分配资源时将相同类型资源和节点进行匹配，考虑到节点的性能跟现阶段运行的任务量的关系，采用自检测方法动态调整节点标签。最后通过实验来对算法性能进行对比分析。
2.本发明针对数据本地性问题，提出了延时降级的算法，降级分为当前本节点、本机架节点和随机节点三种，通过在一定的延时时间降低本地性等级来提高数据本地性。
3.本发明采用动态标签的方法，首先预先运行不同类型作业，根据单节点运行的时间和集群所有节点的平均时间对比对节点进行分类，然后根据集群节点运行任务的负载情况对节点性能进行自检测并生成相应的新标签。
4.本发明提出对作业进行分类，由于mapreduce作业map部分都是相同的处理逻辑，所以可以根据作业预先执行的部分信息对作业进行分类。
附图说明
图1作业调度整体框架流程图；
图2调度算法流程图；
图3不同调度算法下三种作业总运行时间对比图；
图4dlms下500m数据量下container分布数量图；
图5dlms下1g数据量下container分布数量图；
图6dlms下1.5g数据量下container分布数量图；
图7作业组在不同调度算法下运行时间对比图；
具体实施方式
为使本发明的目的、技术方案和特点更加清楚明白，以下结合具体实施例子，并参照附图，对本发明进行进一步的细化说明。yarn调度框架如图1所示。
各个步骤解释如下：
(1)用户向yarn提交应用程序，其中包括用户程序、启动applicationmaster命令。
(2)resourcemanager为该应用程序分配第一个container，并与对应的nodemanager通信，要求它启动应用程序的applicationmaster。
(3)applicationmaster向resourcemanager注册后，为各个任务申请资源，并监控它们的运行状态，直到运行结束
(4)nodemanager发送心跳前进行自我检测生成动态的节点标签，并向resourcemanager汇报资源。
(5)任务分类进入不同的标签队列中，进行优先级排序等待分配资源。
(6)applicationmaster通过rpc协议向resourcemanager申请和领取资源。
(7)根据nodemanager汇报的节点标签和资源，调度器将此节点的资源分配给对应标签队列的作业。
(8)applicationmaster申请到资源后，便与对应的nodemanager通信，要求它启动任务。
(9)nodemanager为任务设置好运行环境(环境变量、jar包、二进制程序等)后，将任务启动命令写到脚本中，并通过运行该脚本启动任务。
(10)各个任务通过某个rpc协议向applicationmaster汇报自己的状态和进度，可以在任务失败时重新启动任务。
(11)应用程序运行完成后，applicationmaster向resourcemanager注销并关闭自己。
首先对集群物理节点进行初始分类，分类的方法过程如下：
(1)设集群机器节点集为n＝{ni|i∈[1,n]}n为节点总数量，i为从1开始n的正整数，ni表示集群中第i个物理机器。
(2)在每台节点上都执行一个相同的任务量的cpu、io和普通型作业并记录作业执行时间；tcpu(i)表示在第ni个节点上执行cpu作业的花费时间；tio(i)表示在第ni个节点上执行io作业的花费时间,tcom(i)表示在第ni个节点上执行普通作业的花费时间。
(3)计算每种作业的集群平均时间，集群平均时间的计算公式如下：
设map的运行信息为m，它包括以下需要收集的信息m＝{min,mout,rate,acpu,mcpu,zcpu,mrate}min表示map输入数据量，mout表示map输出数据量，rate表示输入数据量/输出数据量，acpu表示cpu平均使用率，mcpu表示cpu中位数，zcpu表示cpu使用率超过90％的平均数，mrate表示内存使用量，这些数据将成为以后这个作业分类的特征属性。在实验的过程中发现单纯的计算cpu的平均时间不能很好反应作业的特征，通过实验发现cpu型作业的cpu使用率大于90％的次数比较多，其他类型的作业cpu使用率大于90％的次数相对较少，所以把这个信息也加入到map回传的信息中。
在队列优先级方面采取用户自定义双层权重的设计方法，设作业的大小属性所占的权重为worthnum，该属性分成三个等级num∈{long,mid,short}，作业的拥有者属性所占权重为worthuser，该属性分成两个等级user∈{root,others}，作业的紧急程度所占权重为worthemogence，该属性可分成三个等级prority∈{highprority,midprority,lowprority},作业的等待时间所占的权重为worthwait，等待的计算公式为waittime＝nowtime-submittime,赋予相应的权重，最后计算出每个任务的优先级数，然后在相应的队列中进行排序。上述五种任务属性权重相加和为100％，具体公式如下。
worthnum+worthuser+worthemogence+worthwtait＝100％；
最后权重计算公式：
finalwort＝worthnum*num+worthuser*user+worthemogence*prority+worthwait*waittime
在作业分类方面，采用朴素贝叶斯分类器，具体分类步骤如下：
(1)分别计算一个作业在某些条件下是cpu、io还是普通型作业下的条件概率：
p(job＝labcpu|v1,v2,…,vn)
p(job＝labio|v1,v2,…,vn)
p(job＝labcom|v1,v2,…,vn)
其中job∈{cpu,io,com}表示作业类别标签；vi为作业的属性特征。
(2)根据贝叶斯公式p(b|a)＝p(ab)/p(a)得:
假设vi之间相对独立，根据独立假设其中
(3)实际计算中p(v1,v2,…,vn)与作业无关可忽略不计，因此最终可得
同理有
作业是cpu型作业、io型作业还是普通型作业取决于哪个概率值更大。
本地性本文采取了延时降级调度策略。该策略具体思想如下：
为每个作业增加一个延时时间属性，设ti为第i个作业当前的延时时间，i∈[1,n],n为集群的节点数目，tlocal表示本地节点延时时间阈值，track表示机架节点延时时间阈值。当调度器分配资源给作业时，如果作业的执行节点和数据输入节点不在一个节点上，此时ti自增1，表示该作业有一次延时调度，此时将此资源分配给其它合适的作业，直到当ti>tlocal时，作业的本地性就会降低为机架本地性，此时只要是本机架内的节点都可以将资源分配给该作业；当ti>track时，作业的本地性降低为随机节点。其中的tlocal和track都采用配置文件的方式由用户根据集群情况自行配置。采用延时的调度策略可以保证在一定的延时时间内获得较好的本地性。
dlms调度方法的基本思想是预先分配部分作业执行，根据作业回传的信息对作业进行分类，然后将节点标签的资源分配给相应的队列中的任务，基本流程：
步骤1当节点通过心跳向资源管理汇报资源的时候，如果原始队列不为空，则遍历原始队列中作业，将已经在命令行或者程序中指定了作业类型标签的作业分配到相应的标签优先级队列中，原始队列移除此作业。
步骤2如果原始队列不为空，则将此节点上的资源分配给原始队列，作业进入等待队列中等待下次分配资源，原始队列移除此作业，此轮分配结束。
步骤3如果等待优先级队列不为空，则对等待优先级队列中的作业进行分类进入相应的标签优先级队列。
步骤4如果如节点性能标签相应的作业类别队列不为空，则将此节点的资源分配给此队列，此轮分配结束。
步骤5设置查看资源访问次数变量，如果超过集群的数量，则将节点的资源按cpu、io、普通、等待优先级顺序将资源分配给相应的队列，此轮调度结束。本步骤可以防止出现类似以下情况，cpu队列作业过多，导致cpu型节点资源已经耗尽，其他标签的节点还有资源，但是作业无法分配资源的情况。
算法的流程图如图2所示。
实验环境
本节将通过实验来验证本文提出的dlms调度器的实际效果。实验环境为5台pc机搭建而成的hadoop完全分布式集群，集群的节点机器配置统一为操作系统ubuntu-12.04.1,jdk1.6，hadoop2.5.1，内存2g，硬盘50g。其中namenode的cpu的核数为2，datanode1的cpu核数为2，datanode2的cpu核数为4，datanode3的cpu核数为2，datanode4的cpu核数为4.
实验结果与说明
首先准备数据量为128m的wordcount(io型)，kmeans(cpu型)作业各一个，分别在4台节点上面运行6次，记录下作业运行的时间。表1中s表示时间单位秒，avg表示该节点运行相应标签任务的平均时间，allavg表示所有节点运行相应标签任务的总平均时间，rate的计算公式如下：
负号表示平均时间相对于总平均时间的减少，正号表示平均时间相对于总平均时间的增加。
由表1可以看出datanode1在运行两个任务的时间都是节省时间的，我们采取节省最多的cpu作业作为机器的原始标签，datanode2为io标签，datanode3、datanode4为普通机器。
表1原始分类实验表
实验结果及其分析
使用可以明显区分作业类型的几种作业，wordcount在map阶段需要大量的读取数据和写入中间数据，map阶段和reduce阶段基本上没有算数计算，所以将此种作业定性为io型作业，kmeans在map阶段和reduce阶段都需要大量的计算点和点之间的距离，并没有太多的中间数据的写入，所以将此种作业定性为cpu型作业，topk在reduce阶段没有大量的数据写入磁盘，也没有大量的计算，只涉及到简单的比较，所以人为的认为这个是普通型的任务。
通过两组实验来进行验证，第一组实验设置调度器为fifo，在500m、1g和1.5g的数据量下分别运行wordcount，kmeans，topk作业各3次，记录每个作业3次的平均时间作为最终时间，切换调度器为capacity和dlms调度器做同样的实验操作，实验中记录下dlms调度器下每种作业的container在集群的分布，container是表示集群资源的划分单位，记录了作业分片在集群中运行的分布情况，yarn中每个map和reduce进程都是以一个container来进行表示的。container在集群中每个节点分布比例表明节点执行作业任务量的比例。图2的横坐标是作业的数据量，纵坐标是wordcount，kmeans，topk这3种作业共同运行的总时间。在数据量增大的情况下，dlms调度器相比于其他的调度器节省大约10％-20％的时间。
因为dlms会将相应节点标签的资源分配给相应标签的作业。作业的map和reduce是以一个container的形式在节点上运行的，图3至图5是在dmls调度器下不同数据量作业的container数量。根据上节的原始分类node1是cpu型的标签节点，node2和node3是普通标签节点，node4是io标签节点。wordcount是io型作业，topk是普通型作业，kmeans是cpu型作业。从图中可以看出container的分布规律为wordcount作业在node4上分配的container比较多，tokp在普通节点node2和node3上面分布的比较多，kmeans作业在node1节点上面分布的比较多。以上不同作业的container在集群节点上的分布表明dlms调度器提高了相应节点标签的资源分配给对应标签作业的概率。
第二组实验，准备了5个作业，分别是128m和500m数据量的wordcount作业，128m和500m数据量的kmeans作业，500m的topk作业组成一个作业组。5个作业同时提交运行。在不同调度器的集群中模拟连续作业执行情况，记录作业组执行完的总时间。作业组在不同的调度器下运行3次，记录下作业组运行完的总时间。具体结果见图6，从图6中可以看出本文提出的dlms调度器相比于hadoop自带调度器执行相同作业组节省的时间是显而易见的，本文提出的dmls调度器相比hadoop自带的fifo调度器节省了大约20％的时间，比capacity调度器节省了大约10％的运行时间。
- 还没有人留言评论。精彩留言会获得点赞！