hadoop yarn

简介： 本文介绍了 Hadoop 自 0.23.0 版本后新的 map-reduce 框架（Yarn) 原理，优点，运做机制和配置方法等；着重介绍新的 yarn 框架相对于原框架的差别及改进；并经过 Demo 示例详细描述了在新的 yarn 框架下搭建和开发 hadoop 程序的方法。 读者经过本文中新旧 hadoop map-reduce 框架的对比，更能深入理解新的 yarn 框架的技术原理和设计思想，文中的 Demo 代码通过微小修改便可用于用户基于 hadoop 新框架的实际生产环境。java

发布日期： 2013 年 1 月 17 日 node

级别： 初级 web

访问状况 ： 22455 次浏览 编程

评论： 2 (查看 | 添加评论 - 登陆)安全

平均分 5 星 共 332 个评分 平均分 (332个评分)bash

为本文评分服务器

 

Hadoop MapReduceV2(Yarn) 框架简介网络

原 Hadoop MapReduce 框架的问题架构

对于业界的大数据存储及分布式处理系统来讲，Hadoop 是耳熟能详的卓越开源分布式文件存储及处理框架，对于 Hadoop 框架的介绍在此再也不累述，读者可参考 Hadoop 官方简介。使用和学习过老 Hadoop 框架（0.20.0 及以前版本）的同仁应该很熟悉以下的原 MapReduce 框架图：app

 

图 1.Hadoop 原 MapReduce 架构

图 1.Hadoop 原 MapReduce 架构 

从上图中能够清楚的看出原 MapReduce 程序的流程及设计思路：

首先用户程序 (JobClient) 提交了一个 job，job 的信息会发送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他须要与集群中的机器定时通讯 (heartbeat), 须要管理哪些程序应该跑在哪些机器上，须要管理全部 job 失败、重启等操做。

TaskTracker 是 Map-reduce 集群中每台机器都有的一个部分，他作的事情主要是监视本身所在机器的资源状况。

TaskTracker 同时监视当前机器的 tasks 运行情况。TaskTracker 须要把这些信息经过 heartbeat 发送给 JobTracker，JobTracker 会搜集这些信息以给新提交的 job 分配运行在哪些机器上。上图虚线箭头就是表示消息的发送 - 接收的过程。

能够看得出原来的 map-reduce 架构是简单明了的，在最初推出的几年，也获得了众多的成功案例，得到业界普遍的支持和确定，但随着分布式系统集群的规模和其工做负荷的增加，原框架的问题逐渐浮出水面，主要的问题集中以下：

JobTracker 是 Map-reduce 的集中处理点，存在单点故障。

JobTracker 完成了太多的任务，形成了过多的资源消耗，当 map-reduce job 很是多的时候，会形成很大的内存开销，潜在来讲，也增长了 JobTracker fail 的风险，这也是业界广泛总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。

在 TaskTracker 端，以 map/reduce task 的数目做为资源的表示过于简单，没有考虑到 cpu/ 内存的占用状况，若是两个大内存消耗的 task 被调度到了一块，很容易出现 OOM。

在 TaskTracker 端，把资源强制划分为 map task slot 和 reduce task slot, 若是当系统中只有 map task 或者只有 reduce task 的时候，会形成资源的浪费，也就是前面提过的集群资源利用的问题。

源代码层面分析的时候，会发现代码很是的难读，经常由于一个 class 作了太多的事情，代码量达 3000 多行，，形成 class 的任务不清晰，增长 bug 修复和版本维护的难度。

从操做的角度来看，如今的 Hadoop MapReduce 框架在有任何重要的或者不重要的变化 ( 例如 bug 修复，性能提高和特性化 ) 时，都会强制进行系统级别的升级更新。更糟的是，它无论用户的喜爱，强制让分布式集群系统的每个用户端同时更新。这些更新会让用户为了验证他们以前的应用程序是否是适用新的 Hadoop 版本而浪费大量时间。

新 Hadoop Yarn 框架原理及运做机制

从业界使用分布式系统的变化趋势和 hadoop 框架的长远发展来看，MapReduce 的 JobTracker/TaskTracker 机制须要大规模的调整来修复它在可扩展性，内存消耗，线程模型，可靠性和性能上的缺陷。在过去的几年中，hadoop 开发团队作了一些 bug 的修复，可是最近这些修复的成本愈来愈高，这代表对原框架作出改变的难度愈来愈大。

为从根本上解决旧 MapReduce 框架的性能瓶颈，促进 Hadoop 框架的更长远发展，从 0.23.0 版本开始，Hadoop 的 MapReduce 框架彻底重构，发生了根本的变化。新的 Hadoop MapReduce 框架命名为 MapReduceV2 或者叫 Yarn，其架构图以下图所示：

 

图 2. 新的 Hadoop MapReduce 框架（Yarn）架构

图 2. 新的 Hadoop MapReduce 框架（Yarn）架构 

重构根本的思想是将 JobTracker 两个主要的功能分离成单独的组件，这两个功能是资源管理和任务调度 / 监控。新的资源管理器全局管理全部应用程序计算资源的分配，每个应用的 ApplicationMaster 负责相应的调度和协调。一个应用程序无非是一个单独的传统的 MapReduce 任务或者是一个 DAG( 有向无环图 ) 任务。ResourceManager 和每一台机器的节点管理服务器可以管理用户在那台机器上的进程并能对计算进行组织。

事实上，每个应用的 ApplicationMaster 是一个详细的框架库，它结合从 ResourceManager 得到的资源和 NodeManager 协同工做来运行和监控任务。

上图中 ResourceManager 支持分层级的应用队列，这些队列享有集群必定比例的资源。从某种意义上讲它就是一个纯粹的调度器，它在执行过程当中不对应用进行监控和状态跟踪。一样，它也不能重启因应用失败或者硬件错误而运行失败的任务。

ResourceManager 是基于应用程序对资源的需求进行调度的 ; 每个应用程序须要不一样类型的资源所以就须要不一样的容器。资源包括：内存，CPU，磁盘，网络等等。能够看出，这同现 Mapreduce 固定类型的资源使用模型有显著区别，它给集群的使用带来负面的影响。资源管理器提供一个调度策略的插件，它负责将集群资源分配给多个队列和应用程序。调度插件能够基于现有的能力调度和公平调度模型。

上图中 NodeManager 是每一台机器框架的代理，是执行应用程序的容器，监控应用程序的资源使用状况 (CPU，内存，硬盘，网络 ) 而且向调度器汇报。

每个应用的 ApplicationMaster 的职责有：向调度器索要适当的资源容器，运行任务，跟踪应用程序的状态和监控它们的进程，处理任务的失败缘由。

新旧 Hadoop MapReduce 框架比对

让咱们来对新旧 MapReduce 框架作详细的分析和对比，能够看到有如下几点显著变化：

首先客户端不变，其调用 API 及接口大部分保持兼容，这也是为了对开发使用者透明化，使其没必要对原有代码作大的改变 ( 详见 2.3 Demo 代码开发及详解)，可是原框架中核心的 JobTracker 和 TaskTracker 不见了，取而代之的是 ResourceManager, ApplicationMaster 与 NodeManager 三个部分。

咱们来详细解释这三个部分，首先 ResourceManager 是一个中心的服务，它作的事情是调度、启动每个 Job 所属的 ApplicationMaster、另外监控 ApplicationMaster 的存在状况。细心的读者会发现：Job 里面所在的 task 的监控、重启等等内容不见了。这就是 AppMst 存在的缘由。ResourceManager 负责做业与资源的调度。接收 JobSubmitter 提交的做业，按照做业的上下文 (Context) 信息，以及从 NodeManager 收集来的状态信息，启动调度过程，分配一个 Container 做为 App Mstr

NodeManager 功能比较专注，就是负责 Container 状态的维护，并向 RM 保持心跳。

ApplicationMaster 负责一个 Job 生命周期内的全部工做，相似老的框架中 JobTracker。但注意每个 Job（不是每一种）都有一个 ApplicationMaster，它能够运行在 ResourceManager 之外的机器上。

Yarn 框架相对于老的 MapReduce 框架什么优点呢？咱们能够看到：

这个设计大大减少了 JobTracker（也就是如今的 ResourceManager）的资源消耗，而且让监测每个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。

在新的 Yarn 中，ApplicationMaster 是一个可变动的部分，用户能够对不一样的编程模型写本身的 AppMst，让更多类型的编程模型可以跑在 Hadoop 集群中，能够参考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。

对于资源的表示之内存为单位 ( 在目前版本的 Yarn 中，没有考虑 cpu 的占用 )，比以前以剩余 slot 数目更合理。

老的框架中，JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行情况，如今，这个部分就扔给 ApplicationMaster 作了，而 ResourceManager 中有一个模块叫作 ApplicationsMasters( 注意不是 ApplicationMaster)，它是监测 ApplicationMaster 的运行情况，若是出问题，会将其在其余机器上重启。

Container 是 Yarn 为了未来做资源隔离而提出的一个框架。这一点应该借鉴了 Mesos 的工做，目前是一个框架，仅仅提供 java 虚拟机内存的隔离 ,hadoop 团队的设计思路应该后续能支持更多的资源调度和控制 , 既然资源表示成内存量，那就没有了以前的 map slot/reduce slot 分开形成集群资源闲置的尴尬状况。

新的 Yarn 框架相对旧 MapRduce 框架而言，其配置文件 , 启停脚本及全局变量等也发生了一些变化，主要的改变以下：

 

表 1. 新旧 Hadoop 脚本 / 变量 / 位置变化表

改变项原框架中新框架中（Yarn）备注

配置文件位置${hadoop_home_dir}/conf${hadoop_home_dir}/etc/hadoop/Yarn 框架也兼容老的 ${hadoop_home_dir}/conf 位置配置，启动时会检测是否存在老的 conf 目录，若是存在将加载 conf 目录下的配置，不然加载 etc 下配置

启停脚本${hadoop_home_dir}/bin/start（stop）-all.sh${hadoop_home_dir}/sbin/start（stop）-dfs.sh

${hadoop_home_dir}/bin/start(stop)-all.sh新的 Yarn 框架中启动分布式文件系统和启动 Yarn 分离，启动 / 中止分布式文件系统的命令位于 ${hadoop_home_dir}/sbin 目录下，启动 / 中止 Yarn 框架位于 ${hadoop_home_dir}/bin/ 目录下

JAVA_HOME 全局变量${hadoop_home_dir}/bin/start-all.sh 中${hadoop_home_dir}/etc/hadoop/hadoop-env.sh

${hadoop_home_dir}/etc/hadoop/Yarn-env.shYarn 框架中因为启动 hdfs 分布式文件系统和启动 MapReduce 框架分离，JAVA_HOME 须要在 hadoop-env.sh 和 Yarn-env.sh 中分别配置

HADOOP_LOG_DIR 全局变量不须要配置${hadoop_home_dir}/etc/hadoop/hadoop-env.sh老框架在 LOG，conf，tmp 目录等均默认为脚本启动的当前目录下的 log,conf，tmp 子目录 

Yarn 新框架中 Log 默认建立在 Hadoop 用户的 home 目录下的 log 子目录，所以最好在 ${hadoop_home_dir}/etc/hadoop/hadoop-env.sh 配置 HADOOP_LOG_DIR，不然有可能会由于你启动 hadoop 的用户的 .bashrc 或者 .bash_profile 中指定了其余的 PATH 变量而形成日志位置混乱，而该位置没有访问权限的话启动过程当中会报错

 

因为新的 Yarn 框架与原 Hadoop MapReduce 框架相比变化较大，核心的配置文件中不少项在新框架中已经废弃，而新框架中新增了不少其余配置项，看下表所示会更加清晰：

 

表 2. 新旧 Hadoop 框架配置项变化表

配置文件配置项Hadoop 0.20.X 配置Hadoop 0.23.X 配置说明

core-site.xml系统默认分布式文件 URIfs.default.namefs.defaultFS

hdfs-site.xmlDFS name node 存放 name table 的目录dfs.name.dirdfs.namenode.name.dir新框架中 name node 分红 dfs.namenode.name.dir( 存放 naname table 和 dfs.namenode.edits.dir（存放 edit 文件），默认是同一个目录

DFS data node 存放数据 block 的目录dfs.data.dirdfs.datanode.data.dir新框架中 DataNode 增长更多细节配置，位于 dfs.datanode. 配置项下，如 dfs.datanode.data.dir.perm（datanode local 目录默认权限）；dfs.datanode.address（datanode 节点监听端口）；等

分布式文件系统数据块复制数dfs.replicationdfs.replication新框架与老框架一致，值建议配置为与分布式 cluster 中实际的 DataNode 主机数一致

mapred-site.xmlJob 监控地址及端口mapred.job.tracker无新框架中已改成 Yarn-site.xml 中的 resouceManager 及 nodeManager 具体配置项，新框架中历史 job 的查询已从 Job tracker 剥离，纳入单独的 mapreduce.jobtracker.jobhistory 相关配置，

第三方 MapReduce 框架无mapreduce.framework.name新框架支持第三方 MapReduce 开发框架以支持如 SmartTalk/DGSG 等非 Yarn 架构，注意一般状况下这个配置的值都设置为 Yarn，若是没有配置这项，那么提交的 Yarn job 只会运行在 locale 模式，而不是分布式模式。

Yarn-site.xmlThe address of the applications manager interface in the RM无Yarn.resourcemanager.address新框架中 NodeManager 与 RM 通讯的接口地址

The address of the scheduler interface无Yarn.resourcemanager.scheduler.address同上，NodeManger 须要知道 RM 主机的 scheduler 调度服务接口地址

The address of the RM web application无Yarn.resourcemanager.webapp.address新框架中各个 task 的资源调度及运行情况经过经过该 web 界面访问

The address of the resource tracker interface无Yarn.resourcemanager.resource-tracker.address新框架中 NodeManager 须要向 RM 报告任务运行状态供 Resouce 跟踪，所以 NodeManager 节点主机须要知道 RM 主机的 tracker 接口地址