汪健

摘要：Hadoop2使用YARN平台进行资源管理，支持更多的计算框架和可插拔的资源调度器。现有的资源调度机制中并不支持时间因素，而新的应用方向需要YARN对预分配、实时性、截止期限等与时间密切相关的资源调度提供支持。本文对YARN进行扩展，以支持各种与时间相关的调度策略。

关键词：Hadoop YARN；资源请求与分配；时间因素

中图分类号：TP3 文献标识码：A 文章编号：1009-3044（2016）17-0272-03

作为Apache顶级项目之一，Hadoop可以使数据分析工作分布在成千上万台普通计算机组成的集群上同时运行，同时具备良好的扩展性和容错性。随着信息技术越来越广泛的使用，人们需要处理的数据量呈爆发式增长，为充分利用Hadoop集群处理能力，集群中的资源分配是一个关键环节。Hadoop从 2.0版本开始使用YARN通用资源管理平台，从而使得资源管理工作从MapReduce v1计算框架中分离出来，并支持Storm、Spark等其他计算框架在其上运行。

YARN中目前集成了Capacity Scheduler和Fair Scheduler两种资源调度器，支持在多用户、多任务环境下平衡资源分配，达到共享Hadoop集群的目的，并提供了诸如优先级、标签管理等措施来帮助集群资源的管理。然而，YARN中现有的调度几乎没有考虑时间，而在实际的资源调度需求中，时间也是一个重要的因素，特别是在支持资源预留的调度中。文献[1]指出基于资源预留的调度对集群的利用率几乎可达到100%，而Capacity Scheduler不超过80%；文献[2，3]基于Hadoop来实现高实时需求的软件系统；基于截止时间的调度策略[4]和可同时启动多个Container的Gang调度策略[5]也在研究中。因此，需要扩充YARN现有资源请求和调度框架，增加时间因素，各种调度策略从其中获得资源和时间需求并进行资源调度，从而弹性地满足作业对时间上的需求和更充分地利用资源。本文通过对YARN中的资源调度环节进行分析研究，定义了可自定义的时间标记定义，扩充了现有的资源请求方式，从而将时间因素与现有的资源分配结合起来。

1 YARN资源管理平台简述

RM（ResourceManager）是YARN中的核心模块，负责整个集群所有资源的统一管理和分配；集群中每个提供资源服务的结点由其内部的NM（NodeManager）进行管理； NM中的资源以Container的形式进行分配，每个Container封装了一定的资源量。

客户端可以向RM提交作业（Job），每个作业将被分为多个子任务（Task），并分布到Hadoop集群中的多个结点并行地运算。作业提交到RM后不会马上被运行，而是由RM先分配一个合适的Container，以容纳该作业的AM（ApplicationMaster）。AM是该作业申请资源及内部管理的必要部件。AM向RM注册成功后，便可持续地申请资源来运行子任务。RM通过内部的调度机制为请求分配资源，AM通过周期性的心跳来获取这些以Container形式表示的资源。AM得到Container后，与Container所在的NM通信以真正获得资源，并在Container中运行子任务。

NM用心跳机制定期向RM汇报结点信息以及Container信息。

2 资源分配中引入时间因素

Hadoop集群在实际应用中，由于其上运行的作业不同，数据的多样性，集群本身的异构性等，从而对资源分配有不同的需求，进而产生各种调度策略。这里我们并不对具体调度策略做讨论，仅关注如何在申请资源时引入时间因素。

2.1 扩展ResourceRequest

AM申请资源时，用ResourceRequest对象描述所需资源。为引入时间因素，我们扩展现有的资源请求环节，采用新的ResourceDescription类封装原有的ResourceRequst，并在类中引入对时间需求的描述。增加时间因素并不会改变YARN的原有流程，仅是对其中的操作有部分扩展。资源申请流程分析如下（图1）：

1）AM通过RPC函数与RM中的ApplicationMasterService通信，并传递ResouceDescription对象，该对象中包含了原有的ResourceRequest对象，并增加了时间或其他资源相关条件。由于该通信是周期性调用，因此也称为心跳。

2）ApplicationMasterService调用ResourceScheduler.allocate（）函数，将资源需求汇报给ResouceScheduler。

3）ResourceScheduler根据调度策略分配资源，并以Container形式更新到相应的数据结构中。现有调度只能在收到资源请求时立即分配，增加了时间因素后，可在将来的某个时间才进行资源分配。

4）每次心跳会返回AllocateResponse应答对象，包含分配的Container及集群规模等信息，AM获取信息后与对应的NM通信以真正启动Container并运行子任务。

图1 ApplicationMaster申请资源流程

2.2 时间需求格式

在分配和占用资源时，可能涉及的时间需求可能包含起始时间、截止时间、占用时长等等。在具体实现中，如果用对象来传递各种时间条件，那么当时间条件需求发生任何变化，都需要修改对象类型，且难以满足复杂的条件组合例如与、并、非逻辑。因此在传递时间条件时，采用独立于语言平台的JSON格式数据以避免上述的缺陷。通信双方可通过预定义字段和取值类型，并相应实现解释器，从而达到交换数据的目的。

在支持时间条件的资源分配机制中，可能的字段及解释如下：

1）DemandID：

客户端向RM发送资源请求时生成的流水号。在引入时间条件后，该流水号对应的资源可能在将来某时刻被分配。

2）Start： {， ， …}

资源分配时间。代表客户端希望在此时间得到所请求的资源，若RM接受此请求，应在此时间之前就预留足够的资源。

3）Duration： {， ， …}

资源已分配后，预计占用时间。该字段便于RM掌握资源的预期使用时长，从而合理进行调度。

4）DeadLine： {， ， …}

资源上的任务截止完成期限。该字段可用于实时性要求较高的作业，RM可选择能够满足截止期限的结点来运行该任务。

5）OrderBy： < DemandID expression>

次序字段隐性地与时间相关。这里并不指定具体时间，而是指本次资源请求是在其他资源上的任务完成之后进行分配，非常适合于类似Oozie[6]的工作流任务的资源预分配。

每个字段对应的值对象可包含多个内容，常用的内容为：

1）

时间表达式格式为Time： [T1， T2]。当T1、T2均有明确指定时，代表一段时间间隔；当T1未指定而T2指定时，表示到T2截止；当T2未指定而T1指定时，表示从T1开始；当T1、T2均未指定时，表示不对时间做任何要求，从而兼容现有的无时间条件调度机制。

T1为绝对时间，以“YY-MM-DD hh：mm：ss”表示，并支持特定标识，如以NOW代表当前时间；T2可为绝对时间、相对时间或延迟调度次数，相对时间以“+数字及单位”来表示，单位可为小时h、分钟m和秒s，延迟调度次数以“^数字”表示可放弃多次调度机会。

2）

策略表达式格式为Strategy： strict | loose。策略可取值strict表示严格遵从条件，或loose表示宽松遵从。例如对于资源分配，可用strict指明资源必须在指定时间分配，否则应拒绝该请求；也可用loose指明尽量在指定时间分配资源，如未能保证，可拒绝也可延期。

3）逻辑运算

数值中可包含逻辑运算，即AND（与）、OR（并）、NOT（非）。例如，可以用Time： { OR： [ [NOW， +5m]， [NOW， ^3] ] }表示时间间隔为当前时间起5分钟内，或是当前时间起延迟调度次数在3次以内。

下面是一个时间需求的例子，其请求ID为1234，所需资源在ID号为1200的子任务运行完后分配，分配后其上的子任务尽量在20分钟以内完成。

2.3 资源请求状态机

在资源分配过程中引入时间因素后，AM请求的资源并非立即返回，而将经历多个阶段，为追踪这些阶段状态，我们引入RMDemand状态机，每个请求对应一个状态机对象，状态之间的转换基于事件机制。RM通过访问状态机列表来掌控请求对应资源的分配情况。状态的说明以及它们之间的转换关系如下。

图2 资源请求状态转换

1）NEW：初识状态。当RM接收到一个资源请求时，若请求合法（权限校验通过、格式正确），则生成该请求对应的RMDemand对象，并通知调度器进行调度。

2）ACCEPTED：若调度器接受该资源请求，进入此状态。

3）ALLOCATING：开始实际分配资源时状态。RM应尽量保证在用户指定的时刻T1可得到资源，因此在T1之前就应通知调度器开始调度，并进入此状态。

4）FAILED：若调度器拒绝该资源请求，或是调度器未能按预计分配足够的资源时，进入此状态。另外，除FINISHED状态，其他状态都可因该请求被杀死而进入FAILED状态，为清晰起见未画出这些状态的转换。

5）ALLOCATED：资源分配完成后状态。AM可根据请求ID，自行到RM来获取这些资源信息（位置、实际大小等），并与相应结点的NM通信以启动Container。需要指出的是，若一段时间之后用户不来取这些资源，RM可释放这些资源并置状态为FAILED。

6）MONITORING：若资源请求中需要对已分配的资源进行监控，进入此状态。RM可管理处于该状态的资源请求时长、截止期限，或是资源请求的依次处理等。

7）FINISHED：结束状态。资源分配结束、或Container上的子任务运行完成后进入此状态，完成资源回收等工作。

3 小结

作业的运行先要分配一个Container来容纳AM，这个工作是由ApplicationMasterLauncher完成。仿照前述的思路，可对AM的启动加入时间条件，以预定作业的开始时间。虽然可以通过修改客户端接口，在提交作业时通知RM预先分配一定数量的资源来运行子任务，但是更简便的办法是避免修改现有由AM申请资源的方式，提前一定时间启动AM。例如要求作业在早晨3点准时运行一批子任务，那么可以预定AM提前半小时启动，然后申请所需资源，当然，这就需要用户手动估算提前量。

增加时间因素后，调度器分配资源时需要更多考虑，这也是当前的研究热点。在我们给出的扩展方案中，RM通过RMDemand状态机来监控资源分配情况，因此不需要对调度器接口作出改变。

对YARN平台的主要改变是将原来的ResourceRequest资源对象请求扩展为ResourceDescription对象，以及增加资源请求状态的管理。对YARN的运行机制没有重大修改，可兼容现有调度器并支持将来的调度器。除了时间因素，ResourceDescription中也可加入其他调度因素，满足调度器的其他特性，对未来的调度策略提供良好的支撑。

参考文献：

[1] C Curino， DE Difallah， C Douglas， S Krishnan， R Ramakrishnan. Reservation-based Scheduling： If You're Late Don't Blame Us！[C]. ACM Symposium on Cloud Computing，2014.

[2] Ciprian Barbieru， Florin Pop. Soft Real-Time Hadoop Scheduler for BigData Processing in Smart Cities[C]. 2016 IEEE 30th International Conference on Advanced Information Networking and Applications（AINA）， 2016.

[3] M. Mazhar Rathore， Awais Ahmad， Anand Paul， Alfred Daniel. Hadoop based real-time Big Data Architecture for remote sensing Earth Observatory System[C]. 2015 6th International Conference on Computing， Communication and Networking Technologies （ICCCNT）， 2015.

[4] Quentin Perret， Gabriel Charlemagne， Stelios Sotiriadis， Nik Bessis. A Deadline Scheduler for Jobs in Distributed Systems[C]. Advanced Information Networking and Applications Workshops （WAINA）， 2013 27th International Conference on，2013.

[5] Support gang scheduling in the AM RM protocol [EB/OL]. https：//issues.apache.org/jira/browse/YARN-624，2015-8-12

[6] Apache Oozie Workflow Scheduler for Hadoop[EB/OL]. http：//oozie.apache.org/，2016-4-12