了解mapreduceV1（旧版本的mapreduce）与mapreduceV2（YARN）的区别我们需要先深入理解一下mapreduceV1的工作机制和设计思想。
首先看一下mapreduce V1的运行图解
MapReduce V1的组件及功能分别是：
Client：客户端，负责编写mapreduce代码并配置和提交作业。
JobTracker：是整个mapreduce框架的核心，类似于springMVC中的DispatcherServlet负责初始化作业，分配作业并与TaskTracker进行心跳通信，协调各task节点
TaskTracker：一个mapreduce中可以有很多个TaskTracker，它们负责处理被JobTracker分配到的数据（map和reduce两个阶段的任务）并与JobTracker保持心跳通信。 
图中架构图较为繁琐，概括起来可以认为是如下设计：
1. 首先客户端编写好mapreduce业务代码并提交一个Job给JobTracker，JobTracker负责管理多个TaskTracker节点并给它们分发任务。
2. TaskTracker是mapreduce中每台机器都都具有的，负责监视本机资源状况。
3. TaskTracker负责给JobTracker进行心跳通信随时汇报本机的资源状况，并执行完mapreduce任务后将结果输出放入HDFS
简而言之，mapreduce整个运行体系可以理解为客户端将代码写好，把作业提交给JobTracker这个*管理器，再由JobTracker负责任务的分发与管理给各个Task节点，并由本地的TaskTracker负责监管且将资源与安全状态定时汇报给JobTracker，每个task节点执行完被分配到的任务后将结果输出。
所以，mapreduce V1的性能问题也显而易见。
1. 首先，由于mapreduce V1是由一个master（JobTracker）管理多台分布式的task节点，并且所有客户端的job是通过JobTracker来分发给task节点，还要保持与各节点之间的通信，当客户端提交的Job数量不断增加，JobTracker的内存和带宽消耗也会越来越大，所以性能会急剧下降。JobTracker会成为整个分布式集群的性能瓶颈。
2. TaskTracker端由于作业分配信息过于简单，很可能出现将多个资源消耗多或者运行时间长的Task分配到同一个节点上，这样会造成作业的单点失败或者等待时间过长。
3. 作业延迟过高，在JobTracker分发作业之前需要TaskTracker汇报本机的资源情况和运行情况，JobTracker根据这些信息进行合理分配。这段时间的通信带来的延迟，会极大影响整个mapreduce的运作效率。
YARN的设计思想
谈完了mapreduce V1的缺陷，我们看一看mapreduce V2（YARN）在哪些方面有所改进。 
针对于JobTrack可能会随着客户端提交JOB量大而出现单点瓶颈的问题，YARN的设计思路是将JobTracker的两大任务（集群资源管理和作业管理）进行分离。分离出来的集群资源管理器由全局资源管理器管理，分离出来的作业管理器由针对每个作业的应用主体管理。TaskTracker作为节点管理器。
这样一来，数据计算框架=全局的资源管理器+局部的节点管理器。而针对作业的应用主体旧成为了具体的框架库，负责两个任务：1）与资源管理器通信获取资源 2）与节点服务器配合完成节点的task任务
所以，我们来看一下YARN的具体执行流程 
1. mapreduce框架接收用户提交的作业，并为其分配一个新的用户ID，并将应用的定义打包上传到HDFS上用户的应用缓存目录中，然后提交此应用给应用管理器。
2. 应用管理器同调度器协商获取运行应用主体所需的第一个资源容器。
3. 应用管理器在获取的资源容器上执行应用主体。
4. 应用主体计算应用所需的资源并发送资源请求到调度器。
5. 调度器根据自身统计的可用资源状态和应用主体的资源请求分配合适的资源容器给应用主体。
6. 应用主体与所分配容器的节点管理器通信，提交作业情况和资源使用说明。
7. 节点管理器启用容器并运行任务。
8. 应用主体监控容器上任务的执行情况。
9. 应用主体反馈作业的执行状态信息和完成状态。
YARN相比于mapreduce V1的优势在于：
1. 切分了JobTracker，将资源管理任务交给资源管理器负责，作业启动、运行和检测任务由分布在各个task节点上的应用主体负责。这样一来，单点瓶颈的问题就算得到了解决，而且也提高了集群的扩展性。
2. YARN中的应用主体是一个用户可自定制的部分，因此用户可针对变成模型编写自己的应用主体程序，使得YARN不再像mapreduce V1那么死板。