YARN并不是下一代MapReduce（MRv2）
下一代MapReduce与第一代MapReduce（MRv1）在编程接口、数据处理引擎（MapTask和ReduceTask）是完全一样的， 可认为MRv2重用了MRv1的这些模块，不同的是资源管理和作业管理系统，MRv1中资源管理和作业管理均是由JobTracker实现的，集两个功能于一身，而在MRv2中，将这两部分分开了， 其中，作业管理由ApplicationMaster实现，而资源管理由新增系统YARN完成，由于YARN具有通用性，因此YARN也可以作为其他计算框架的资源管理系统，不仅限于MapReduce，也是其他计算框架，比如Spark等， 通常而言，我们一般将运行在YARN上的计算框架称为“X on YARN”，比如“MapReduce On YARN”, "Spark On YARN"，“Storm On YARN”等
总结：
mapreduce v1 与 v2 都是hadoop的计算框架
而yarn 是 分离开来的资源管理框架
下面可以看到 v2 与 YARN的关系：
原 Hadoop MapReduce 框架的问题
原来的 map-reduce V1 架构是简单明了的，在最初推出的几年，也得到了众多的成功案例，获得业界广泛的支持和肯定，但随着分布式系统集群的规模和其工作负荷的增长，原框架的问题逐渐浮出水面，主要的问题集中如下：
- JobTracker 是 Map-reduce 的集中处理点，存在单点故障。
- JobTracker 完成了太多的任务，造成了过多的资源消耗，当 map-reduce job 非常多的时候，会造成很大的内存开销，潜在来说，也增加了 JobTracker fail 的风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。
- 在 TaskTracker 端，以 map/reduce task 的数目作为资源的表示过于简单，没有考虑到 cpu/ 内存的占用情况，如果两个大内存消耗的 task 被调度到了一块，很容易出现 问题。
新 Hadoop Yarn 框架原理及运作机制
从业界使用分布式系统的变化趋势和 hadoop 框架的长远发展来看，MapReduce 的 JobTracker/TaskTracker 机制需要大规模的调整来修复它在可扩展性，内存消耗，线程模型，可靠性和性能上的缺陷。在过去的几年中，hadoop 开发团队做了一些 bug 的修复，但是最近这些修复的成本越来越高，这表明对原框架做出改变的难度越来越大。
为从根本上解决旧 MapReduce 框架的性能瓶颈，促进 Hadoop 框架的更长远发展，从 0.23.0 版本开始，Hadoop 的 MapReduce 框架完全重构，发生了根本的变化。新的 Hadoop MapReduce 框架命名为 MapReduceV2，其架构图如下图所示：
重构根本的思想是将 JobTracker 两个主要的功能分离成单独的组件，这两个功能是资源管理和任务调度 / 监控。新的资源管理器（ResourceManager ）全局管理所有应用程序计算资源的分配。
每一个应用（原来叫做一个mapreduce作业）都会有一个ApplicationMaster 负责相应的调度和协调
Resourcemanager:
Mapreducev1版本只有一个jobtracker，jobtracker用来跟踪和分配诸如cpu和内存之类的资源，并处理mapreduce相关的作业跟踪
在YARN里jobtracker的资源管理部分由一个被称为资源管理的后台程序来负责（resource manager）
application master
每个应用是一个单独的mapreduce作业，但不同于以前所有的作业都由一个单独的jobtracker来负责，
现在每个作业都有一个被称为应用管理者的进程（application master），它运行在集群中某个工作节点上，功能相等于jobtracker。
这与一个集中式的jobtracker有很大不同，因为一个作业的应用管理者现在已经完全与其他作业分离，这意味着即使jobtracker发生了灾难性的错误，其他作业也不会受到影响。
更进一步说，因为jobtracker已经被完全指定到了某个作业，所以多个jobtracker能在集群上同时运行
container
容器我们可以简单的理解为单独为这个容器做了一个虚拟资源
ResourceManager 是基于应用程序对资源的需求进行调度的 ; 每一个应用程序需要不同类型的资源因此就需要不同的容器。
每一个应用的 ApplicationMaster 的职责有：向调度器索要适当的资源容器，运行任务，跟踪应用程序的状态和监控它们的进程，处理任务的失败原因。
NodeManager
NodeManager 监控数据节点的应用程序的资源使用情况 (CPU，内存，硬盘，网络 ) 并且向resource manager 汇报
NodeManager 功能比较专一，就是负责 Container 状态的维护，并向 RM 保持心跳。
NodeManager 并不完全等同于tasktracker，因为tasktracker需要运行任务并保持心跳，在V2版本里运行任务的功能分配给了Application Master
