YARN与MRv1的对比

转载请注明出处：http://www.cnblogs.com/BYRans/

Hadoop 1.0存在的问题

由于Hadoop 1.0的良好特性，Hadoop 1.0被应用到了各行各业。但是Hadoop的最初设计是为了用于搜索引擎业务（如Yahoo、Google等公司），其最初的设计中存在的一些问题逐渐凸现出来。主要存在以下几个方面：

存在单点故障，影响可扩展性和稳定性
Hadoop 1.0中HDFS的NameNode和MapReduce的JobTracker设计为单一节点，这将是整个系统的单点故障源（SPOF）。单点故障主要由以下两个原因导致：
- NameNode内存消耗过大
  DataNode会定期向NameNode发送Block Report，这些数据是占用内存空间的，随着Hadoop集群存储空间的增多，这些Block Report会越来越多，因此NameNode的内存容量成为制约Hadoop集群的一个重要因素。
- JobTracker内存消耗过大
  随着JobTracker处理的job数量的增长，任务数量也随着增长，从而导致JobTracker的内存消耗过大，同时任务失败的概率也随着增加。
资源管理方案不灵活
- slot数目无法动态修改。Hadoop 1.0采用了静态slot资源设置策略，即每个节点实现配置好可用的slot总数，这些slot数目一旦启动后无法再动态修改。
- 资源无法共享。Hadoop 1.0将slot分为Map slot和Reduce slot两种，且不允许共享。对于一个作业，刚开始运行时，Map slot资源紧缺而Reduce slot空闲，当Map Task全部运行完成后，Reduce slot紧缺而Map slot空闲。很明显，这种区分slot类别的资源管理方案在一定程度上降低了slot的利用率。
- 资源划分粒度粗糙。这种基于slot的资源划分方法的划分粒度仍过于粗糙，往往会造成节点资源利用率过高或者过低。比如，Hadoop默认为每个slot分配2G内存和1个CPU，如果一个应用程序的任务只需要1GB内存，则会产生“资源碎片”，从而降低集群资源的利用率；同样，如果一个应用程序的任务需要3GB内存，则会隐式地抢占其他任务的资源，从而产生资源抢占现象，可能导致集群利用率过高。另外，slot只是从内存和CPU的角度对资源进行分配，在实际系统中，资源本身是多维度的，例如：CPU、内存、网络I/O和磁盘I/O等。
- 没引入有效的资源隔离机制。Hadoop 1.0仅采用了基于jvm的资源隔离机制，这种方式仍过于粗糙，很多资源，比如CPU，无法进行隔离，这会造成同一个节点上的任务之间干扰严重。
计算模式单一。只支持MapReduce模式，不能有效的支持Storm、Spark等计算框架。

举个栗子，假设Hadoop 1.0同时运行10个job，每个job有100个task，假设每个task运行在不同的机器上，那么，就有10000个几点在同时运行。如果每个节点（即每个task）每个5分钟向JobTracker发送心跳，那么JobTracker节点的压力会特别大，所以正常情况下Hadoop 1.0的集群规模只能达到4000台左右。JobTracker压力过重也是造成Hadoop 1.0单点故障和可扩展性差的重要原因。

YARN的改进

在Hadoop 1.0中JobTracker主要完成两项功能：资源的管理和作业控制。在集群规模过大的场景下，JobTracker压力过重，因此在YARN的设计中，资源的管理和作业控制是分离开的。取代JobTracker的是ResourceManager、ApplicationMaster、NodeManager三个部分。如下图所示：

Resource Manager是一个全局的资源管理器，它做的事情是调度、启动每一个Job所属的ApplicationMaster、另外监控ApplicationMaster的存在情况。注：RM只负责监控AM，在AM运行失败时候启动它，RM并不负责AM内部任务的容错，这由AM来完成。
ApplicationMaster是每一个Job（不是每一种）都有的一个部分，ApplicationMaster可以运行在ResourceManager以外的机器上。
NodeManager是ResourceManager的在每个节点的代理，负责 Container 状态的维护，并向RM保持心跳。
另外，YARN使用Container对资源进行抽象，它封装了某个节点上一定量的资源（现在YARN仅支持CPU和内存两种资源）。当AM向RM申请资源时，RM为AM返回的资源使用Container表示。YARN会为每个任务分配一个或多个Container，且该任务只能使用该Container中描述的资源。注：AM也是运行在一个Container中。

YARN设计的优点

将资源管理和作业控制分离，减小JobTracker压力
- YARN的设计大大减小了 JobTracker（也就是现在的 ResourceManager）的资源消耗，并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。
- 老的框架中，JobTracker一个很大的负担就是监控job下的tasks的运行状况，现在，这个部分就扔给ApplicationMaster做了而ResourceManager中有一个模块叫做ApplicationsManager(ASM)，它负责监测ApplicationMaster的运行状况。
能够支持不同的计算框架
将计算框架和底层存储调度分开，以支持更多的计算框架。在YARN中ApplicationMaster是一个可变更的部分，用户可以对不同的计算框架写自己的 AppMst，让更多类型的计算框架能够跑在Hadoop集群中，可以参考YARN官方配置模板中的mapred-site.xml配置。
资源管理更加合理
- 使用Container对资源进行抽象，Container不同于MRv1中的slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的，比之前以slot数目更合理。
- 且使用了轻量级资源隔离机制Cgroups进行资源隔离。
- Container的设计避免了之前的map slot/reduce slot分开造成集群资源闲置的尴尬情况。

YARN与Mesos的对比

	Mesos	YARN
框架担任的角色	各个计算框架需在Mesos中部署后才能使用，完全融入到Mesos中	计算框架只是作为客户端的库使用，不在YARN中部署即可使用
调度机制	双层调度；第一层由Mesos Master将空闲资源分配给框架，第二层由各个框架自带的调度器对资源的使用进行分配	双层调度，第一层由RM分配资源，第二层再对框架的任务进行调度
资源分配	先粗粒度分配，再细粒度分配	细粒度分配
资源隔离性	采用Linux Container对内存和CPU两种资源进行隔离	当前采用OS进程级别隔离
扩展性	支持6,000 ~ 50,000个节点	目标是支持6,000 ~ 100,000个节点

YARN的不足与展望

YARN是一个双层调度器（Two-level scheduler），解决了中央调度器（Monolithic scheduler）的不足（中央调度器典型的代表就是JobTracker)，双层调度架构看上去为调度增加了灵活性和并发性，但实际上它保守的资源可见性和上锁算法（使用悲观并发）也限制了灵活性和并发性。第一，保守的资源可见性导致各框架无法感知整个集群的资源使用情况，有空闲资源无法通知排队的进程，容易造成资源的浪费；第二，上锁算法降低了并发性，调度器会将资源分配给一个架构，只有该架构返回资源后，调度器才回将该部分资源分配给其他架构，在第一个分配过程中，资源相当于被锁住，从而降低了并发性。总结来说，YARN同其他双层架构的调度器（例如：Mesos）都有的不足为：

各个应用无法感知集群整体资源的使用情况，只能等待上层调度推送信息。
资源分配采用轮询、ResourceOffer机制（mesos)，在分配过程中使用悲观锁，并发粒度小。
缺乏一种有效的竞争或优先抢占的机制。

为了改善双层调度系统的的不足，尤其是各个应用无法感知集群整体资源的使用情况和悲观加锁控制导致的并发性不高这两个不足，共享状态调度器（Shared State Scheduler）被越来越多的人所重视，其中最具代表性的就是Google的Omega。共享状态调度器在双层调度器的基础上做了改进：

简化了双层调度器中的全局资源管理器，改为由一个Cell State来记录集群内的资源使用情况，这些使用情况都是共享的数据，以此来达到与全局资源管理器相同的效果。
所有任务访问共享数据时，采用乐观并发控制方法。

共享调度器也存在不足。例如，当某一资源被不同任务同时访问时容易产生冲突，访问的任务越多时，冲突次数就会越多，冲突次数越高调度器的性能下降越快，这将影响调度器的工作效率和工作性能。