论文阅读笔记 - YARN : Architecture of Next Generation Apache Hadoop MapReduceFramework

做者：刘旭晖 Raymond 转载请注明出处

Email：colorant at 163.com

BLOG：http://blog.csdn.net/colorant/

更多论文阅读笔记 http://blog.csdn.net/colorant/article/details/8256145

 

== 目标问题 ==

 

下一代的Hadoop框架，支持10,000+节点规模的Hadoop集群，支持更灵活的编程模型

 

== 核心思想 ==

 

固定的编程模型，单点的资源调度和任务管理方式，使得Hadoop 1.0的应用在模式上和规模上都日益表现出它的局限性。

 

YARN的核心思想是采用两级分布式的资源调度和任务管理框架，支持模块化的任务调度组件和自定义的任务管理模块，以适应多样化的编程模式和日益增大的集群规模。

 

YARN以container为单位调度资源和任务，可调度的资源类型为Memory（长期目标包括CPU/DISK/IO等），经过在各个任务管理框架间分配和共享资源来提升集群利用率，总体思想和Mesos十分接近。

 

== 实现 ==

 

YARN的主要组成部分包括：

 

一个全局的RM(ResourceManager)，每一个Job一个的AM(ApplicationMaster) 和每一个节点一个的NM(NodeManager)

 

 

RM内部又进一步分为调度模块(scheduler)和应用管理模块(Applications Manager)，调度模块负责在各个Job间调度分配资源，而应用管理模块则负责监听客户端建立Job的请求和启动Per Job的AM

 

在应用管理模块启动AM之后，AM就接管了自身Job以后的管理工做，AM负责与调度模块协商获取任务运行所需的资源，经过NM建立获得所需资源的任务进程，并监控任务的完成状况。

 

从AM和RM的通信协议上看，对资源的调度接口已经简化为一个AM所需Container的配置，数量和位置的列表，所以具备很大的通用性，固然，因为调度模块只是简单的根据Job的需求和优先级等调度资源，而不考虑任何任务具体细节和执行状况的相关信息，也就会损失一些能够做为调度依据的信息。以MapReduce为例，MapSplit相关的信息是调度模块所没法得知的。Locality等要求就须要由AM来保证。

 

== 相关研究，项目等 ==

 

Mesos所要解决的问题和总体思路和YARN十分类似。一样的两级资源调度，可模块化的调度策略，由具体的运算框架负责第二级资源调度，隔离的资源管理方式和类似的任务执行方式。不过在资源的一级调度方式上，Mesos采用Push的方式，而YARN采用Pull的方式，Mesos号称是为了使接口更加简单和通用化，YARN采用Pull的方式看起来则彷佛更灵活一些。可是光从API上看，我的理解AM在作调度请求前还须要获取全局资源的状态，可能须要付出更大的通信代价？

 

Facebook的Corona一样是为Hadoop开发的，基本上也是将MapReduce1.0中的Job tracker以Job为单位进行拆分。一样采用Pull的方式向中央调度模块Cluster manager请求资源。不过Scope大概比YARN要小，目测纯粹是经过分布是调度的方是解决集群规模问题，而YARN同时还但愿能灵活适配不一样的运算框架。