YARN

介绍

Apache Hadoop YARN作为hadoop的子项目加入到Hadoop Common (core libraries), Hadoop HDFS (storage) and Hadoop MapReduce (the MapReduce implementation) ，它也是apache的顶级工程。

在Hadoop 2.0中，各个客户端会向运行在YARN上的MapReduce v2框架提交种种MapReduce应用。而在Hadoop 1.0中，各个客户端则向MapReduce v1框架提交MapRecude应用。

这两类API都引用开发者可用的MapRecude框架来创建MapReduce应用。org.apache.hadoop.mapred API是最早的API，最广泛地使用在MapReduce应用的创建中。任何使用mapred API开发的MapReduce v1应用都可以提交至运行在YARN上的MapReduce v2框架，并在该框架中运行。在这种情况下，无须修改该MapReduce应用。

hadoop1.0和2.0的区别

直接看图会看的比较清晰：

作为hadoop2.0的一部分，YARN有资源管理的能力，所以它能够使用多个新的引擎。使用YARN，你能运行多个应用在hadoop上，如下图：

MapReduce2.0——YARN的基本架构

MapReduce在Hadoop 0.23时已经经历了一次大规模更新，新版本的MapReduce2.0被称为YARN或MRv2。

YARN 的基本思想是将JobTracker的两个主要功能（资源管理和作业调度/监控）分离，主要方法是创建一个全局的ResourceManager（RM）和若干个针对应用程序的ApplicationMaster（AM）。这里的应用程序是指传统的MapReduce作业或作业的DAG（有向无环图）。

ResourceManager 和每个slave结点的NodeManager（NM）构成了数据计算框架。ResourceManager负责最终将资源分配到各个应用程序。 NodeManager是每台机器的框架代理，负责管理容器，监控它们的资源使用情况（CPU，内存，硬盘，网络），同时向 ResourceManager/Scheduler汇报。
针对各个应用程序的ApplicationMaster实际上是一个详细的框架库，它结合从 ResourceManager 获得的资源和 NodeManager 协同工作来运行和监控任务。ApplicationMaster同时负责向Scheduler请求适当的资源容器，跟踪它们的使用状态并监控其进展。

ResourceManager中有两个主要组件：Scheduler和ApplicationsManager。

Scheduler 负责给应用程序分配资源。Scheduler从某种意义上说是一种纯粹的调度，它不监控和跟踪应用程序的状态，另外它也不负责重启应用程序或者硬件故障造成的失败。Scheduler根据应用程序的资源需求执行调度，这些需求基于一个抽象的资源概念Container，包括内存、CPU、硬盘和网络等。
ApplicationsManager负责接收作业提交，将应用程序分配给具体的ApplicationMaster，并负责重启失败的ApplicationMaster。

YARN在接口上兼容于此前的稳定版本（Hadoop 0.20.205），这意味着以前的MapReduce作业重新编译后就可以在YARN下运行。

MapReduce

MapReduce的数据流程图：

MapReduce的问题：

在最初推出的几年，也得到了众多的成功案例，获得业界广泛的支持和肯定，但随着分布式系统集群的规模和其工作负荷的增长，原框架的问题逐渐浮出水面，主要的问题集中如下：

JobTracker 是 Map-reduce 的集中处理点，存在单点故障。
JobTracker 完成了太多的任务，造成了过多的资源消耗，当 map-reduce job 非常多的时候，会造成很大的内存开销，潜在来说，也增加了 JobTracker fail 的风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。
在 TaskTracker 端，以 map/reduce task 的数目作为资源的表示过于简单，没有考虑到 cpu/ 内存的占用情况，如果两个大内存消耗的 task 被调度到了一块，很容易出现 OOM。
在 TaskTracker 端，把资源强制划分为 map task slot 和 reduce task slot, 如果当系统中只有 map task 或者只有 reduce task 的时候，会造成资源的浪费，也就是前面提过的集群资源利用的问题。
源代码层面分析的时候，会发现代码非常的难读，常常因为一个 class 做了太多的事情，代码量达 3000 多行，，造成 class 的任务不清晰，增加 bug 修复和版本维护的难度。
从操作的角度来看，现在的 Hadoop MapReduce 框架在有任何重要的或者不重要的变化 ( 例如 bug 修复，性能提升和特性化 ) 时，都会强制进行系统级别的升级更新。更糟的是，它不管用户的喜好，强制让分布式集群系统的每一个用户端同时更新。这些更新会让用户为了验证他们之前的应用程序是不是适用新的 Hadoop 版本而浪费大量时间。

YARN的安装

可参考：

http://blog.csdn.net/shenshouer/article/details/7613234

YARN的demo

示例可参考：

http://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-yarn/

YARN框架用到的一些设计模式

可以参考：

http://blog.csdn.net/bxyz1203/article/details/8128989

YARN总结

个人总结了一下，其实主要是以下两点：

1、整合其它应用，比如和storm的整合，可以使用strom-yarn等。

2、将原来JobTracker的工作进一步细分，提高性能。