YARN与MRv1的对比

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来记录集群内的资源使用状况，这些使用状况都是共享的数据，以此来达到与全局资源管理器相同的效果。
• 全部任务访问共享数据时，采用乐观并发控制方法。

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