Apache Hadoop是Apache软件基金会的顶级开源项目之一, 它在分布式计算与存储上具有先天的优势. 随着大数据时代的到来, Hadoop成为了大数据的标签之一, 在很多领域都得到了广泛的应用^[1]. 当前Hadoop已然发展为拥有MapReduce (MR)、HDFS、YARN、Pig、Hive、Hbase等系统的较为完整的大数据生态圈^[2]. YARN (Yet Another Resource Negotiator)资源管理系统是Hadoop生态圈中的核心, 很多计算框架都迁移到YARN上, 借助YARN获得了更好的资源调度、资源隔离、可扩展性以及容灾容错的特性, 比如MR on YARN, Strom on YARN, Spark on YARN等^[3]. 但是, YARN有上百个参数供用户配置, 而且大多数参数间有着密切联系. 对于生产集群来说, 手动调节任何参数都需要用户对集群管理机制有深入的理解以及集群性能长期的观察, 并且调节参数后还需用户花费很多时间来判断集群性能是否达到预期的效果^[4]. 对于开发者来说在面对上百个参数的情况下很难实现YARN的最佳性能, 而YARN性能对于MR作业有很大影响^[5]. 因此, 设计一种自动调节YARN配置参数的方法不仅有助于减少用户在参数调节上所花费的时间, 同时适当的参数配置还可以减少作业的执行时间, 提高作业的吞吐量. 近年来, 研究人员开发了很多种算法来提高Hadoop集群的性能. Bei ZD等^[6]提出了RFHOC模型, 利用随机森林方法为map和reduce阶段构建性能模型集合, 在这些模型的基础上使用遗传算法自动调整Hadoop配置参数. Chen CO等^[7]利用基于树的回归方法对集群的最优参数进行选取. 这类利用机器学习构建性能模型来寻找最优参数的方法需要一个费事的模型训练阶段. 同时, 若作业的类型发生改变或出现集群中节点增加或减少等变化时, 使用这类方法就需要重新训练模型. Zhang B等^[8]发现作业在运行过程中会出现under-allocation和over-allocation两种情况会降低集群性能. Under-allocation表示MR作业数被设置的过少, 导致集群的资源利用率过低. Over-allocation表示MR作业过多, 大部分资源分配给了AppMaster, 导致分配给Container计算任务的资源不足, 甚至会出现AppMaster只占用资源却不进行任何计算的情况, 导致集群性能下降. 为克服以上两种情况, 张博等人提出一种闭环反馈控制方法, 以内存使用状况作为输入, 以最小化资源竞争和最大化资源利用率为目标来调整MR作业数, 但对内存的使用状况考虑不够细腻, 会出现无法跳出over-allocation状态的情况, 例如当集群中计算任务占用总内存的比率小于T2时集群处于over-allocation状态, 此时向集群提交大量MR作业后, 又会将集群认定为under-allocation状态, 导致控制量不发生变化, 这时集群实际上处于MR作业数被设置的过少, 集群的资源利用率过低的over-allocation状态. 本文提出了一种对YARN容量调度器和公平调度器参数调节的闭环反馈控制方法, 该方法采用二分法原则, 逐次缩小被控参数的调节步长, 具有调节速度快, 控制精度高的优点. 相比于文献8本文将公平调度器参数也纳入调节范围, 同时修改了集群状态的判定条件防止无法跳出over-allocation状态. 本文方法有效解决了MR作业运行过程中AppMaster的under-allocation与over-allocation的问题, 相比于现有的参数自整定方法具有如下优点: 1)当集群中有节点增加减少或更换集群时, 无需花费任何时间调整方法模型; 2)不必事先对YARN框架或被提交的MR作业进行修改.

1 相关知识 1.1 YARN体系架构

YARN主要依赖于3个组件ResourceManager、NodeManager和AppMaster来实现所有的功能^[9]. 组件ResourceManager是集群的资源管理器, 整个集群只有一个, 负责集群整个资源的统一管理和调度分配, 包含两个部分: 可插拔的资源调度器和ApplicationManager, 用于管理集群资源和作业. 组件NodeManager位于集群中每个计算节点上, 负责监控节点的本地可用资源, 故障报告以及管理节点上的作业, 它将节点上的资源信息上报给ResourceManager. 组件AppMaster是每个作业的主进程, 用于管理作业的生命周期. 一个作业由一个AppMaster及多个Container组成, 其中Container是节点上的一组资源的组合, 例如(1 GB, 1 core), 用于运行作业中的计算任务. 当客户端有作业提交时, ResourceManager会启动一个AppMaster, 之后再由AppMaster根据当前需要的资源向ApplicationManager请求一定量的Container. ApplicationManager基于调度策略, 尽可能最优的为AppMaster分配Container的资源, 然后将资源请求的应答发给AppMaster^[10]. 上述作业提交流程如图1所示.

1.2 YARN的资源调度器

YARN中自带的可插拔资源调度器有先入先出调度器(FIFO scheduler)、容量调度器(capacity scheduler)和公平调度器(fair scheduler)^[11]. 其中先入先出调度器以“先来先服务”的原则, 按照作业提交的先后时间进行调度, 无需任何配置. 但这种调度策略不考虑作业的优先级, 只适合低负载集群, 当使用大型共享集群时, 大的作业可能会独占集群资源, 导致其他应用阻塞. 在大型共享集群中更适合容量调度器或公平调度器, 这两个调度器都允许大作业和小作业同时运行并都获得一定的系统资源^[12]. 因此本文利用这两种调度器调节MR作业数. 在容量调度器中可设定参数yarn. scheduler. capacity. maximum-am-resource-percent (AMRP), 来调节集群中可分配于AppMaster的资源量, 这个参数影响着集群中MapReduce作业数. 在公平调度器中可设定参数maxAMShare, 调节MapReduce作业数, 它限制了AppMastter可占用队列资源的比例.

2 MapReduce作业数控制方法

本文提出的MR作业数控制方法是基于容量资源调度器和公平资源调度其实现的, 是一种闭环反馈控制, 控制系统的方框图如图2所示. ${y_{sp}}$ 为用户所设定的域值T1、T2、T3, 将监控器得到的内存使用情况与设定值 ${y_{sp}}$ 相比较, 以此调节控制量A, 防止Hadoop集群中MR作业出现under-allocation和over-allocation两种状态, 并使被控变量Hadoop集群中MR作业数保持在最佳值. 阈值T1、T3与集群中所有运行作业的内存使用率相比较, 阈值T2与集群中所有计算任务的内存使用率相比较.

本文提出的闭环反馈控制方法主要分为3个模块: 监控器、控制器和执行器:

(1)监控器: 在集群主节点中运行, 负责周期性监控集群资源使用情况和MR作业运行情况, 并将监控到的数据传输至控制器中. YARN ResourceManager有一个Web端口, 用这个端口可以查看YARN监控页面, 使用户可以方便地了解集群的运行情况和作业的运行情况. 监控器得到的数据是由Python脚本爬取YARN监控页面获得, 而未使用YARN自带的用户命令编写shell脚本. 原因是由YARN自带的用户命令获取数据相较于使用Python爬取较慢, 且受集群运行状况影响较大. 监控器具体获得的指标有: 队列中等待提交的作业数、队列中正在运行的作业数、集群中所有运行作业占用内存、集群中所有从节点总内存.

(2)控制器: 负责根据从监控器接收到的数据对资源调度器的参数进行周期性地修改. 本文调度器参数控制算法以集群内存使用情况和队列中的作业状态作为判断条件, 对集群是否处于over-allocation或under-allocation状态做出判断, 若集群处于上述两种状态则采用二分法原则逐次调节被控参数直至集群从这两种状态中跳出. 参数控制算法的流程描述如算法1.

算法1.　调度器参数控制算法

输入: P: 队列中等待提交的作业数

　　 R: 队列中正在运行的作业数

　　 M_AMs: 集群中所有AppMaster占用内存

　　 M_tasks: 集群中所有计算任务所占用内存

　　 M_used: 集群中所有运行作业占用内存

　　 M_total: 集群中所有从节点总内存

　　 A: 参数AMRP或maxAMShare的值

1.　detect()//检测调度器类型, 读取调度器参数

2.　 If P=0 Then

3.　　　 If $\scriptstyle R(t) < R(t - 1)$ Then

4.　　　　　 decrease_A()

5.　　　　　 If R=0 and $\scriptstyle A = A\_min$ Then

6.　　　　　 n=1

7.　　　　　 End If

8.　　　 End If

9.　 Else

10.　　　 If M_used/M_total<T1 Then

11.　　　　 If $\scriptstyle P(t) > P(t - 1)$ Then

12.　　　　　 increase_A()

13.　　　　 Else If M_used/M_total>T3 and M_tasks/M_total<T2 Then

14.　　　　　 decrease_A()

15.　　　　 End If

16.　　　 Else

17.　　　　 If M_tasks/M_total<T2 Then

18.　　　　　 decrease_A()

19.　　　　 End If

20.　　　 End If

21.　 End If

22.　 n=n+1

算法1中 $P$ 、 $R$ 、 $M\_ used$ 、 $M\_ total$ 的值由监控器传入, $M\_ AMs$ 、 $M\_ tasks$ 由如下公式获得:

$ M\_ AMs = R \times Unit \times 2 $

(1)

$ M\_ tasks = M\_ used - M\_ AMs $

(2)

其中, $Unit$ 为每个Container的内存大小. detect()通过读取YARN配置文件检测调度器类型, 随后读取相应调度器配置文件得到变量A的值. $A\_ min$ 和 $A\_ max$ 是调度器参数AMRP或maxAMShare允许达到的最小值和最大值.

当 $M\_ used/M\_ total < T1$ 且集群中等待提交的作业在增加时(第11行), 可认为没有足够的内存分配给AppMaster, 集群中并行的MR作业数量较少, 导致出现MR作业占用内存小于设定阈值 $T1$ 的情况. 此时集群处于under-allocation状态, 需增加 $A$ 的值, 提升MR作业数, 充分利用集群的资源.

集群处于over-allocation状态可分为如下3种情况:

① 队列中无等待作业且队列中正在运行的作业数比上一时刻少, 即P=0且 $R(t) < R(t - 1)$ , 表示集群中并MR作业数较低或正在降低, 这种状态判断为over-allocation. 此时可减少分配到AppMaster的资源, 使计算任务可使用的资源增多, 以此来减少MR作业总体完成时间.

② $\;T3 < M\_ used/M\_ total < T1$ 且 $M\_ tasks/M\_ total < $ $ T2$ (第13行), 当集群中提交的任务较少时很容易满足 $M\_ used/M\_ total < T1$ 和 $M\_ tasks/M\_ total < T2$ 条件设置阈值 $T3$ 表示当被使用的内存足够多时才会判断集群是否为over-allocation状态. 若集群处于over-allocation状态, 则需减小A的值, 使集群跳出此状态.

③ $M\_ used/M\_ total > T1$ 且 $M\_ tasks/M\_ total <T2 $ (第17行), 表示MR作业占用内存大于设定阈值T1, 但MR作业中的计算任务占用内存小于设定阈值T2. 这种情况下集群MR作业数过高, 集群中计算任务得不到足够的资源, 此时需要减小A的值, 降低MR作业数, 使计算任务获得更多的资源.

算法1中调节变量A的方法increase_A()和decrease_A()分别如算法2和算法3所示. 当增加或减小变量A时, 将确定 $\alpha /{2^n}$ 是否大于用户设置的step, 若大于则以 $\alpha /{2^n}$ 作为此次调节的步长, 若小于则以step作为此次调节的步长.

(3)执行器: 负责将修改对应调度器配置文件的 AMRP 或maxAMShare 参数, 命令 Hadoop 集群重新加载调度器配置.

算法2.　 increase_A()

1.　　 $\scriptstyle \alpha = A\_ max - A$

2.　　 If $\scriptstyle \alpha /{2^n} > step$ Then

3.　　　　 $\scriptstyle A = A + \alpha /{2^n}$

4.　　　 Else

5.　　　　 $\scriptstyle A = A + step$

6.　　　 End If

算法3.　 decrease_A()

1.　 $\scriptstyle \alpha = A - A\_ min$

2.　　　 If $\scriptstyle \alpha /{2^n} > step$ Then

3.　　　　 $\scriptstyle A = A - \alpha /{2^n}$

4.　　 Else

5.　　　 $\scriptstyle A = A - step$

6.　　 End If

3 实验分析 3.1 实验环境

为了验证MR作业数控制方法的效果, 选取了5台普通PC机来搭建测试集群. 其中一台作为主节点, 包含1个NameNode角色和1个ResourceManager角色. 其余4台作为从节点, 每台节点包含1个DataNode角色和1个NodeManager角色. 本文选取Grep, Terasort, Wordcount这3种常见的MR作业用于测试, 其中Terasort为IO密集型作业, Grep为计算密集型作业, Wordcount作业在Map阶段为计算密集型, Reduce阶段为IO密集型, 如表1所示.

3.2 实验结果

本实验分别在将YARN集群资源调度器配置为容量调度器和公平调度器的情况下进行测试, 将四组作业提交到集群中(第一组30个Grep作业、第二组30个Terasort作业、第三组30个Wordcount作业、第四组每种类型作业各10个), 对比在集群使用默认配置、最优配置和本文方法后作业的完成时间. 实验中AMRP和maxAMShare的最优值由穷举法得到, 穷举范围为{0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1}, 一组作业完成时间越短可认为参数AMRP或maxAMShare越优.图3中在使用容量调度器的情况下, 每组作业完成时间最短时, AMRP分别为0.6, 0.5, 0.3, 0.5. 图4中在使用公平调度器的情况下, 每组作业完成时间最短时maxAMShare分别0.8, 0.9, 0.6, 0.8. 实验中T1、T2、T3、step、A_ min、A_ max的值分别为1.0, 0.5, 0.8, 0.05, 0.05, 0.95.

从图3、图4中可以看出使用本文提出的方法调节MR作业数相比于默认的配置, MR作业整体完成时间会明显的减少, 在使用容量调度器和公平调度器的情况下平均减少了53%和14%. 同时在参数最优的情况下, 与使用本文提出的方法在作业完成时间上相差较小. 两者与默认配置相比, 作业完成时间最多有7%的差异. 由于对于不同的作业组合, 都需要做多组实验才能确定最优的参数, 所以在实际使用集群时要达到明确的最优参数并不现实, 因此本文提出的方法与最优参数下的作业完成时间相比略有差异可以接受.

4 结论与展望

本文在现有调度器的基础上提出了一种闭环反馈控制方法对MR作业数进行动态调节. 通过实验证明本文提出的方法能够在省去人工调节参数的情况下有效的降低MR作业完成时间, 提升了集群的性能. 下一步的工作是研究集群虚拟核使用率与集群CPU使用率的关系, 将节点虚拟核数也纳入调节的范畴.