Hortonworks公司的人写了篇关于YARN的paper，投到SOCC'13，然后一不小心就成了BestPaper。文章名为《ApacheHadoop YARN: Yet Another Resource Negotiator》，重点介绍了YARN的产生驱动、基本架构等，这里与大家分享一下。如有不当之处，敬请指正。
一、介绍
1、驱动
初始的Hadoop专注于大规模的索引web抓取，属于数据密集型计算。由于单一典型的应用场景，Hadoop采用了紧耦合的资源管理方式，仅支持MapReduce。但是，随着大数据的兴起，Hadoop逐渐成为了数据存储和处理的通用系统。面对各式各样的数据类型和应用场景，MapReduce编程模型实际上限制了开发者。另一方面，集群规模越来越大，作业数量和作业到达率也显著增高，对Hadoop的可拓展性提出了更高的要求。
总体来说，初始的Hadoop存在以下问题：1、MR编程模型和资源管理的紧耦合，迫使开发者滥用了MR编程模型；2、中心化的作业控制流影响了系统的可拓展性。
2、贡献
本文介绍了下一代Hadoop计算平台YARN。这种新的架构解耦了编程模型和资源管理，分离了部分“调度功能”到AppMaster。
二、历史与指标
1、历史
Hadoop初始的调度逻辑比较简单，不过由于Yahoo!在实际生产需要解决多租户（Multi-tenancy）问题，Hadoop为此研发了Hadoopon Demand(HoD)，它采用Torque和Maui在共享物理集群上部署多个Hadoop集群（这里的Hadoop集群可以理解为“虚拟集群”）。
HoD的一些特性已经比较类似现在的Mesos了，但仍然存在一些问题：
1）Torque分配节点时不考虑本地性；
2）资源调整粒度过粗，job之间无法共享资源。（一个极端例子是一个简单地reduce任务可能独占一个节点）
3）调度延迟过高，利用率过低。
因此，在HoD之后，Hadoop还需要新的集群调度机制。
2、指标
在回顾Hadoop历史的同时，本文列举了Hadoop设计需要考虑的10条标准，分别如下：
1）Scalability
2）Multi-tenancy
3）Serviceability
4）Locality awareness
5）High Cluster Utilization
6）Reliability/Availability
7）Secure and auditable operation
8）Support for Programming Model Diversity
9）Flexible Resource Model
10）Backward compatibility
根据这10条标准优化Hadoop，有些可以通过局部修改便可以完成，真正驱动Hadoop大改其系统架构、促使YARN诞生的我认为是其中的两条：
1）Scalability（可扩展性），由于第一代Hadoop将业务逻辑和资源管理集中在JobTracker一点上，容易性能单点性能瓶颈，影响系统可扩展性。
2）Support for Programming Model Diversity（支持编程模型多样性）。正如前文所说，由于数据类型和应用场景的多样性，目前出现了越来越多的编程模型，第一代Hadoop紧耦合的架构显然无法支持更多的编程模型，因此促使了YARN的诞生，图1也可以表明YARN的产生驱动。
图1Hadoop YARN产生驱动示意图
三、基本架构
YARN解耦了资源管理和业务逻辑，YARN专门负责资源分配，剥离业务逻辑到计算框架（Framework）中。YARN仍采用Master-Slave架构，主要包括3个组件。
Resource Manager，简称RM，是YARN的Master，具有中心化的全局资源视图，负责系统的任务调度、资源管理和状态监控。RM根据应用需求、调度优先级和资源情况等，动态调整资源。
Application Master，简称AM，管理某种应用，具体负责申请资源、监控任务运行和容错等。
Node Manager，简称NM，是YARN的Slave，负责相应节点的资源管理、任务执行、心跳上报等。
图2为YARN的架构图，其中蓝色部分为YARN自身的组件，粉红色部分、***部分分别为为运行在YARN上的MapReduce和MPI。
图2Hadoop YARN架构图
四、实验
论文对比了两代Hadoop的稳定版本，Hadoop1.2.1和Hadoop2.1.0。实验表明，在大部分指标上，YARN更优。
其实这样的实验结果不难预见，这里我个人更希望某个组织可以在大型集群上实验对比一下YARN、Mesos、Omega的优劣。虽然三者具体应用场景具有一定差异，比如说Mesos更适用于短作业场景，Omega则主要面向终止型作业和服务性作业的混合负载，但总体来说它们都在解决集群复用这类问题，benchmark丰富一些，还是具有可比性的。
五、对比
论文对比了YARN和Mesos、Omega、Corona、Cosmos四个系统的区别。这些系统虽实现方法不同，但是目标大体一致，包括兼容多种编程模型、提高可扩展性、提高集群利用率、降低调度延迟。后两个系统不太熟悉，简要分析下YARN与Mesos、Omega的区别。
Mesos是基于resource offer的资源管理器，定期向Framework推送resource offer。YARN的基于请求的资源管理器，通过响应AM的资源请求来进行资源分配。Omega是一个分布式多级调度系统，其调度过程也是并发的，这种机制提高了系统的可扩展性，但是可能引入调度冲突。本文认为Omega可能适合Google内部使用，但对于Hadoop这种开源平台，YARN的模式更具优势。
这里特别说明一点，YARN属于两级调度系统还是单一调度系统。虽然YARN看上去很像两级调度系统，而且本文自己也说YARN属于两级调度系统，但是Google却不这么认为，在《Omega:flexible, scalable schedulers for large compute cluster》如此评价YARN：“It might appear that YARN is a two-level scheduler, too. …But the application masters provide job-management services, not scheduling, so YARN is effectively a monolithic scheduler architecture.”我个人同意Google的观点，认为YARN属于单一调度系统，而非两级调度系统。要判断YARN属于哪类调度系统，首先要明确“调度”的概念，典型的调度是指为任务分配资源、为任务选择合适的机器，所以负责为任务选择机器的组件才是调度器。就YARN来看，YARN虽然具有ResourceManager和AppMaster，但是AppMaster只负责作业管理，完成调度的是单一组件ResourceManager，因此YARN是中央单一调度系统。
六、总结
YARN解耦了资源管理与编程模型，主要有3中优势：
1）提高可扩展性；
2）提高效率，提高集群利用率；
3）兼容不同编程模型，共享集群。
参考
[1] Malte Schwarzkopf, AndyKonwinskiz, Michael Abd-El-Malekx. Omega: flexible, scalable schedulers forlarge compute clusters. EuroSys’13 April 15-17, 2013.
[2] Benjamin Hindman, AndyKonwinski, Matei Zaharia. Mesos: A Platform for Fine-Grained Resource Sharingin the Data Center. In Proceedings of NSDI, 2011.
[3] Apache Hadoop. http://hadoop.apache.org.
[4] 董的博客. http://dongxicheng.org/