(1)扩展性对比。

    在MRv1中，JobTracker是个重量级组件，集中了资源管理分配、作业控制两大核心功能，随着集群规模的增大，JobTracker处理各种RPC请求负载过重，这也是系统的最大瓶颈，严重制约了Hadoop集群的扩展性。相比之下，Yarn将JobTracker功能进行了拆分，拆分为全局组件ResourceManager、应用组件ApplicationMaster和JobHistoryServer。其中，ResourceManager负载整个系统资源的管理和分配，ApplicationMaster负载单个应用程序的相关管理(job的管理),JobHistoryServer负载日志的展示和收集工作。Yarn的这种功能拆分，将减轻了master节点的负载，其处理的RPC请求的压力得到减少。其实换句话Yarn是将这种负载进行了横向转移到子节点，这个可以通过ApplicationMaster(简称APP Mstr)的机制体现，APP Mstr是运行在其中一个子节点，运行在其他各个子节点的Task只需要向App Mstr发送相关的RPC请求来汇报task运行情况就ok，而不需要直接和master节点的相关进行进行RPC通讯。这个就将MRv1的Master/slave转化为了Master/slave混杂slave/slave的这种结构。

    另外，Hadoop1.x扩展性差问题不仅仅体现在MRv1框架中，提体现在HDSF中。Yarn为了解决这个问题，提出了HDFS Federation,它可以允许集群中启动多个NameNode来分管不同目录的元数据进而实现了访问隔离和横向扩展问题，同时HDFS Federation的提出也彻底解决了hadoop1.x的NameNode单点故障问题。

(2)资源利用率对比。

    MRv1的资源管理分配模型是基于槽位的，槽位是一个相当粗粒度的系统资源单位，一个槽位是系统一定cpu、内存、网络、IO等资源的抽象。一个Slot只能启动一个Task，关键的是一个Task未必用完一个Slot所对应的系统资源，但是它又占着不给别的Task使用，这就造成了浪费。另外，在MRv1中Slot还被分为了Reduce Solt和Map Slot，Reudce solt只能启动Reduce Task，Map Slot只能启动Map Task，这两种Slot不允许共享，因此常常会导致一种Slot资源相当紧张而另外一种Slot资源却是空闲的。例如，当一个Job刚刚被提交的时候，只有当Map Task完成数据为总数量的5%（默认）时，Reduce Task才会启动，那么此时的Reudce Slot就是被闲置浪费了。另外，如果想了解更多关于MRv1的资源管理方案的话，请看看我之前写的blog：http://zengzhaozheng.blog.51cto.com/8219051/1362100 。相比之下，Yarn就克服了上面的问题，Yarn的资源抽象单位container是细粒度的，而且是动态的（目前Yarn版本中只支持cpu和内存的动态分配），他可以为不同的Task需求进行分配，而且container是部分种类的，在MRv框架中可以同时被Map Task和Reduce Task使用。

(3)安全稳定性对比。

    Hadoop1.x对应的HDFS版本中NameNode是存在单点故障的，但是Yarn通过HFDS Federation的提出完美地解决了这个棘手问题。

(4)基本架构特性对比。

    MRv1是单纯地为离线框架Map Reduce打造的，而这种离线计算机框架不能满足现在需求了，一些更有针对性的框架被开发出来，如Spark、storm、DAG计算机框架Tez。这些新的框架无法运行在MRv1上。相比之下，Yarn是一个独立的资源管理系统，其资源和计算机框架是被分离开来的，你可以在Yarn上同时运行MR APP、Spark APP、MPI APP等等。

转: http://zengzhaozheng.blog.51cto.com/8219051/1433986