Yarn脱胎于MRv1,并克服了MRv1的种种不足。先来看看MRv1让人诟病的地方，主要是可靠性差、扩展性差、资源利用率低、无法支持异构的计算框架：

1.可靠性差： MRv1是主从架构，主节点的JobTracker一旦出现问题就会导致整个集群不可用。

2.扩展性差： MRv1的主节点JobTracker承担集群的资源管理和作业调度功能，一旦同时提交的作业较多，JobTracker将不堪重负，成为整个集群的瓶颈，制约集群的线性扩展。

3.资源利用率低： 正如前面所提到的，MRv1的资源表示模型是“槽”，这种资源表示模型将资源划分为Map槽和Reduce槽，也就是Map槽只能运行Map任务，而Reduce槽只能运行Reduce任务，两者不能混用。那么在运行Mapreduce任务时就一定存在资源浪费的情况，比如Map槽非常紧张，而Reduce槽还很充裕。

4.无法支持异构的计算框架： 在一个组织中，可能并不只有离线批处理的需求，也许还有流处理的需求、大规模并行处理的需求等，这些需求催生了一些新的计算框架，如Strom、Spark、Impala等。目前，MRv1并不支持多种计算框架并存。

为了解决上面这些不足，社区开始着手开发下一代Hadoop，并提出了一种通用的架构—–统一资源管理和调度平台

统一资源管理平台有哪些？

1. 集中式调度器 
集中式调度器最大的特点是全局只运行一个中央调度器，整合的计算框架的资源请求全部交给中央调度器来满足，所有的调度逻辑都由中央调度器来实现，所以调度器在遇到高并发的情况下很容易遇到瓶颈。 
所有的调度逻辑都集中在中央调度器里，这对并发影响很大，所以在分配资源时，是完全顺序执行的，类似的调度框架有MRv1的JobTracker，目前已经淘汰。

2. 双层调度器 
顾名思义，双层调度器（two-level scheduler）将整个调度工作划分为两层：中央调度器和框架调度器。中央调度器管理集群中所有资源的状态，它拥有集群所有的资源信息，它按照一定的策略（如FIFO、Fair、Capacity、Delay、Dominant Resource Fair）将资源粗粒度地分配给框架调度器，各个框架收到资源后再根据作业特性细粒度地将资源分配给容器执行具体的计算任务。在这种双层架构中，每个计算框架看不到整个集群的资源，只能看到中央调度器给自己的资源。 
二级调度器的存在大大减轻了中央调度器的负载，这对并发来说有很大提升，资源利用率也得到了提升。但由于中央调度器的存在，这种并发还是一种悲观并发。当中央调度器做出将某些资源分配给哪个计算框架的决策的时候，还是必须顺序执行，属于悲观锁。值得注意的是中央调度器还是保存在整个集群的资源信息，但每个二级调度器只能看到部分的集群资源信息。 
这种双调度的实现有Apache YARN 和 Apache Mesos。

3. 状态共享调度器 
状态共享调度器是由Google公司的Omega调度系统提出的一种新范型。它大大弱化了中央调度器，只需要保存一份集群使用信息，取而代之的是各个框架调度器，每个调度器都能获取集群的全部信息，并采取了乐观锁控制并发。 
Omega与双层调度器的不同在于严重弱化了中央调度器，每个框架内部会不断地从主调度器更新集群信息并保存一份，而框架对资源的申请则会在该份信息上进行，一旦框架做出决策，就会将该信息同步到主调度，资源竞争过程是通过事务进行的，从而保证了操作的原子性。由于决策是在自己的私有数据上做出的，并通过原子事务提交，系统保证只有一个胜出者，这是一种类似于MVCC的乐观并发机制，可以增加系统的整体并发性能。