Hadoop中的Yarn的整体讲解

Hadoop中的Yarn的整体讲解

MapReduce2.0（ YARN）工作流程详解

MapReduce 系统获得成功的原因之一是它为编写需要大规模并行处理的代码提供了简单的编程模式。它受到了 Lisp 的函数编程特性和其他函数式语言的启发。 MapReduce 和云计算非常相配。 MapReduce 的关键特点是它能够对开发人员隐藏操作并行语义 — 并行编程的具体工作方式。

 

但是我们同样也知道， MapReduce 的诞生于 2004 年，距今已经有 10 年左右了，其缺陷与限制也日益暴露出来，目前的 MapReduce 缺陷如下：

   集群规模最多容纳 4000 节点，最大并发数 40000.

   无法对所有队列和运行中的任务进行人工终止。

   节点资源利用效率较低。

   迭代算法实现较差。

基于此上原因， 2010 年新一代的 MapReduce 开始进入设计规划，也就是我们看到的 YARN。

 

YARN概述

YARN 是“ Yet Another ResourceNegotiator”的简称。在进一步了解 YARN 框架之前我们需要知道，相比较而言， MapReduce 则是 YARN 的一个特例。 YARN 则是 MapReduce 的一个更加通用和高级的框架形式，并在其上增加了更多的功能。例如通过加载分布式执行脚本可以在集群节点上执行独立的脚本任务，并且更多功能正在被追加中。所以我们可以看到，YARN 可以直接运行在 MapReduce 运行的框架上而不会造成更多的干扰，并且会为集群的运算带来更多的好处。更一步的开发显示了 YARN 会允许开发者根据自己的需求运行不同版本的 MapReduce 在集群中，这将为开发者提供更为便捷的服务。

 

相比较 MapReduce1.0， JobTracker 在 YARN 中被拆分成了两个：

   功能资源管理（ ResourceManager）

   任务的调度与监视（ Task progress monitoring）。

 

功能资源管理器是管理集群中对资源的利用和调度，并且通过一个内置的任务的调度器去管理集群应用的生命周期。ResourceManager 和每个节点内的 NodeManager 构成一个资源估算框架。其主要行为是在当前节点中生成一系列的容器，而对于大多数的任务来说要在容

器中运行，而容器又是有着所被分配的资源，因此 ResourceManager 可以通过任务的调度器对在系统中所有应用的资源分配拥有最终的最高级别仲裁权。具体见图所示

 

 

从图中我们可以看到相对于 MapReduce 而言，其主体运行范围发生了变化，主要为：

   客户端：用来提交 MapReduce 任务(Job)

   YARN ResourcesManager：用来管理协调分配集群中的资源

   YARN NodeManager：用来启动和监控本地计算机资源单位 Container 的利用情况

   MapReduce ApplicationMaster：用来协调 MapReduce Job 下的 Task 的运行。它和MapReduce Task 都运行在 Container 中，这个 Container 由 RM(ResourcesManager)调度并有NM(NodeManager)管理

  
HDFS：用来在其他实体之间共享作业文件

 

YARN 的工作流程如图所示：

 

 

YARN任务过程分析

步骤一：首先是任务的提交。对于任务的提交，与 MapReduce 相类似，客户端向 MapReduce 提交任务。在提交任务后，返回一个新的可供运行的应用管理器对其进行管理。

 

步骤二：ResourcesManager返回一个新的Job ID。

 

步骤三：Job 客户端计算输入分片，拷贝资源(包括 Job JAR文件、配置文件，分片信息)到 HDFS。

 

步骤四：用SubmitApplication 方法提交Job 给 MapReduce 进行处理。

 

步骤五：任务提交申请资源调用，将其请求给ResourcesManager处理，ResourcesManager在NoeManager上分配Container，同时在管理节点上上启动一个 Application Master 进程。 Application Master 主要执行者 MRAppMatser 会初始化一定数量的记录对象(bookkeeping)来跟踪 Job 的运行进度，并收集 task 的进度和完成情况

 

之后步骤与经典 MapReduce 仍然有所不同，此时 Application Master 会决定如何组织运行 MapReduce Job，如果 Job 很小，能在同一个 JVM，同一个 Node 运行的话，则用 uber 模式运行。

 

对于运行任务的分配，如果不在 uber 模式下运行，则 Application Master 会为所有的Map 和 Reducer task 向 RM 请求 Container，所有的请求都通过 heartbeat(心跳)传递，心跳也传递其他信息，例如关于 Map 数据本地化的信息，分片所在的主机和机架地址信息，这信息帮主调度器来做出调度的决策，调度器尽可能遵循数据本地化或者机架本地化的原则分配Container。

 

在 YARN 中，不像经典 MapReduce 中那样限制 Map 或者 Reduce 的任务槽个数，这样就限制了资源是利用率， YARN 中非配资源更具有灵活性，可以在配置文件中设置最大分配资源和最小分配资源，例如，用“yarn.scheduler.capacity.minimum-allocation-mb”设置最小申请资源 1G，用“yarn.scheduler.capacity.maximum-allocation-mb”设置最大可申请资源 10G 这样一个 Task 申请的资源内存可以灵活的在 1G~10G 范围内。

 

而对于任务的执行来说，分配给 Task 任务给Container 后，Nonde Manager 上的 Application Master 就进行 Container 的启动， Task 最后被一个叫 YarnChild 的 main 类执行，不过在此之前各个资源文件已经从分布式缓存拷贝下来，这样才能开始运行 Map Task或者 Reduce Task。

对于进程和状态的更新，当 Yarn 运行同时， Task 和 Container 会报告它的进度和状态给Application Master，客户端会每秒轮询检测 Application Master，这样就随时收到更新信息，这些信息也要通过 Web UI 来查看。过程如图所示：

 

 

最后对于任务的结束客户端每 5 秒轮询检查 Job 是否完成，期间需要调用函数 Job 类下waitForCompletion()方法,Job 结束后该方法返回。轮询时间间隔可以用配置文件的属性MapReduce.client.completion.pollinterval来设置。

 

YARN的异常处理

对于 YARN 的异常处理来说，需要对运行过程中所有的过程对象进行处理，这其中包括当前任务发生的异常,对任务调度器，节点管理器和资源管理器的处理等。

 

首先对于任务失败，与 MapReduce 任务失败相类似，直接报出运行异常并且从所运行的 JVM 中退出，其中 Task Attempt 失败这个消息会通知 Application Master，由 Application Master 标记其为失败。

 

当 Task 失败的比例大于

MapReduce.Map.failures.maxpercent(Map)或者MapReduce.Reduce.failures.maxpercent(reduece)时候， Job 失败。

 

而对于 Application Master 失败来说，当 Application Master 失败，会被标记为失败，这时候 Resource Manager 会立刻探寻到 Application Master 的失败，并新实例化一个Application Mast 和借助 NodeManager 建造新的相应的 Container ，并且在设置yarn.app.MapReduce.am.job.recovery.enable为true 情况下失败情况下尝试将

Application Master 恢复，并且恢复后并不返回。默认情况下，失败 Application Master会让所有的 Task 返回

 

如果客户端轮询得知 Application Master 失败后，经过一段时间失败状态仍然没有改变，则重新向 ResourceManager 申请相应的资源。

 

当 Node Manager 的失败，会停止向 Resource Manager 发送心跳，则 Resource Manager会将这个 Node Manager 从可用的 Node Manager 池中移出，心态间隔时间可由yarn.resourcemanager.nm.liveness-monitor.expiry-interval-ms设置，默认是10 分钟

 

同样的与经典 MapReduce 类似，如果 Node Manager 上 Application Manager 失败次数过高，此 Node Manager 会被列入黑名单， Application Manager 会在不同 Node 上重新运行Task。

 

所有的错误中 Resources Manager 失败是最为严重的，因为没有 Resources Manager则没有任何一个任务或任务容器能够被配置和调度。为了解决一旦 Resources Manager 发生异常则整个集群陷入瘫痪， YARN 采用了 checkpointing 尝试去重建 Resources Manager。这个功能目前为止还在开发中。