hdoop2总结.docx

Hadoop2.0 federation介绍
1 概述
在Hadoop1.0的架构中，HDFS的所有的元数据都放在一个namenode中，只有一个namespace(名字空间)。这样随着HDFS的数据越来越多，单个namenode的资源使用必然会达到上限，而且namenode的负载也会越来越高，限制了HDFS的性能。
在hadoop2.0架构中，namenode federation（联合）通过多个namenode/namespace把元数据的存储和管理分散到多个节点中，使到namenode/namespace可以通过增加机器来进行水平扩展，并且能把单个namenode的负载分散到多个节点中，在HDFS数据规模较大的时候不会也降低HDFS的性能。还有可以通过多个namespace来隔离不同类型的应用，把不同类型应用的HDFS元数据的存储和管理分派到不同的namenode中。

2 架构
如果上图所示，一个block pool由属于同一个namespace的数据块组成，每个namenode管理一个namespace，即每个namenode负责存储和管理一个block pool的元数据。而每个datanode是会连接所有的namenode的，为所有的block pools所共享，即每个datanode都会存储所有的block pools的数据块。每个block pool通过namespace隔离开来，对一个block pool的操作不会影响另外一个block pool。
从配置和使用的角度来看，整个HDFS有一个唯一的clusterid，如“hellokitty”，它可以配置多个block pool/namespace（也叫name service），如“mycluster”和“yourcluster”。为了方便访问不同名字空间的目录和文件，federation还提供了一个类似linux的Client Side Mount Table的挂载机制，提供了一个统一的全局的文件系统视图（viewfs）。用户可以根据自己的需要把各个namespace挂载到一个叫做viewFS的文件系统视图的不同目录下。例如namespace/name service “mycluster”和“yourcluster”分别挂载到viewfs的“/my”和“/your”目录下，如下图所示：

3 federation和HA
上面提到的每个namespace/name service配置一个namenode，这样这个namespace/name service的单点问题还是存在，因此可以给每个namespace/name service配置成HA。
假设我们有4台namenode，分别是namenode1，namenode2，namenode3，namenode4。其中namenode1和namenode2是namespace/name service“mycluster”的两个主备namenode节点，NN_ID分别是“mycluster”的“nn1”和“nn2”；而namenode3和namenode4是namespace/name service“yourcluster”的两个主备namenode节点，NN_ID分别是“yourcluster”的“nn1”和“nn2”。
“mycluster”和“yourcluster”分别挂载在viewfs的“/my”和“/your”目录下。
结构如下图所示：

4 实战tips
一般1000台机器一下的中小规模的hadoop集群，一个namespace/name service就足够了，不需要考虑federation，以免增加不必要的复杂性。
hadoop2.0 yarn 总结 基于hadoop2.2.0 
为什么使用hadoop？

在单机程序设计中，为了快速处理一个大的数据集，通常采用多线程并行编程，如图所示，大体流程如下：先由操作系统启动一个主线程，由它负责数据切分、任务分
配、子线程启动和销毁等工作，而各个子线程只负责计算自己的数据，当所有子线程处理完数据后，主线程再退出。这种方式依然受限于一台计算机的处理能力，另外某些数据集的增长会超出一台计算机的处理能力。这时可以将大数据切分成多部分使用多台计算机来处理数据，当使用多台计算机时，整个大环境中的其他因素将对其产生影响，其中最主要是协调性和可靠性两大因素。哪个进程负责运行整个作业？我们如何处理失败的进程？因此，尽管可以实现并行处理，但是实际上非常复杂，使用hadoop框架来实现并行数据处理将很有帮助。

hadoop 2.0

hadoop2.0的组成：

1：计算框架：MRv2:（与mrv1有相同的编程模型和数据处理引擎（优化过），唯一不同的是运行时环境。），dag，spark等。

     mapreduce计算框架结构如下：
·           编程模型：新旧api，新api兼容旧api方面还存在一点问题。
·           数据处理引擎：map（）和reduce（）
·           运行时环境：yarn（资源管理：内存，cpu，磁盘等）+applicationMaster（与应用程序相关的模块）组成

2:yarn通用资源管理框架（主要由resourcemanager,nodemanager,applicationMaster,Container等组成）

yarn
说明：
      随着互联网的高速发展，基于数据密集型应用的计算框架不断出现，从支持离线处理
的MapReduce，到支持在线处理的Storm，从迭代式计算框架Spark 到流式处理框架S4，
各种框架诞生于不同的公司或者实验室，它们各有所长，各自解决了某一类应用问题。而
在大部分互联网公司中，这几种框架可能同时被采用。比如在搜索引擎公司中，一种可能
的技术方案如下：网页建立索引采用MapReduce 框架，自然语言处理/ 数据挖掘采用 Spark
（如网页 PageRank 计算、聚类分类算法等），对性能要求很高的数据挖掘算法用MPI 等。
考虑到资源利用率、运维成本、数据共享等因素，公司一般希望将所有这些框架都部署到
一个公共的集群中，让它们共享集群的资源，并对资源进行统一使用，同时采用某种资源
隔离方案（如轻量级 cgroups）对各个任务进行隔离，这样便诞生了轻量级弹性计算平台。

资源利用率高：如果每个框架一个集群，则往往由于应用程序数量
和资源需求的不均衡性，使得在某段时间内，有些计算框架的集群资源紧张，而另
外一些集群资源空闲。共享集群模式则通过多种框架共享资源，使得集群中的资源
得到更加充分的利用。
运维成本低：如果采用“一个框架一个集群”的模式，则可能需要多个管理员管理
这些集群，进而增加运维成本，而共享模式通常需要少数管理员即可完成多个框架
的统一管理
数据共享：。随着数据量的暴增，跨集群间的数据移动不仅需花费更长的时间，且硬
件成本也会大大增加，而共享集群模式可让多种框架共享数据和硬件资源，将大大
减小数据移动带来的成本。

组成结构：

resourcemanager（scheduler调度器，application manager（asm）应用程序管理器 2个 组件组成）

     应用程序管理器:

applicationmaster
     1:用户提交的每个应用程序均包含一个am。
          与rm调度器协商以获取资源（container）
          将得到的任务进一步分配给内部任务
          与nm通信以启动/停止任务
          监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以启动任务
     当前默认的2个applicationmaster（演示am用的distributedshell,和MRAppMaster）
Nodemanager
     1：NM是每个二姐店上的资源和任务管理器
          定时地向rm汇报本节点上的资源使用情况和各个container的运行状态；
          接受并处理来自am的container启动/停止等请求。
Container
     1：container是yarn资源的抽象，它封装了某个节点上的多维度资源（内存，cpu，磁盘，网络等），当am想rm申请资源时，rm为am返回的资源便是用container表示的。yarn会为每个任务分配一个container，且该任务只能使用该container描述的资源，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。（目前yarn只支持cpu和内存2种资源）

yarn 工作流程

步骤 1　用户向YARN 中提交应用程序， 其中包括 ApplicationMaster 程序、启动
ApplicationMaster 的命令、用户程序等。
步骤 2　ResourceManager 为该应用程序分配第一个 Container， 并与对应的Node-
Manager 通信，要求它在这个Container 中启动应用程序的 ApplicationMaster。
步骤 3　ApplicationMaster 首先向ResourceManager 注册， 这样用户可以直接通过
ResourceManage 查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运
行状态，直到运行结束，即重复步骤 4~7。
步骤 4　ApplicationMaster 采用轮询的方式通过 RPC 协议向ResourceManager 申请和
领取资源。
步骤 5　一旦ApplicationMaster 申请到资源后，便与对应的 NodeManager 通信，要求
它启动任务。
步骤 6　NodeManager 为任务设置好运行环境（包括环境变量、 JAR 包、二进制程序
等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
步骤 7　各个任务通过某个RPC 协议向 ApplicationMaster 汇报自己的状态和进度，以
让ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。
在应用程序运行过程中，用户可随时通过 RPC 向ApplicationMaster 查询应用程序的当
前运行状态。
步骤 8　应用程序运行完成后， ApplicationMaster 向ResourceManager 注销并关闭自己。

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

图 1.Hadoop 原 MapReduce 架构

从上图中可以清楚的看出原 MapReduce 程序的流程及设计思路：
1. 首先用户程序 (JobClient) 提交了一个 job，job 的信息会发送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他需要与集群中的机器定时通信 (heartbeat), 需要管理哪些程序应该跑在哪些机器上，需要管理所有 job 失败、重启等操作。
2. TaskTracker 是 Map-reduce 集群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况。
3. TaskTracker 同时监视当前机器的 tasks 运行状况。TaskTracker 需要把这些信息通过 heartbeat 发送给 JobTracker，JobTracker 会搜集这些信息以给新提交的 job 分配运行在哪些机器上。上图虚线箭头就是表示消息的发送 - 接收的过程。
可以看得出原来的 map-reduce 架构是简单明了的，在最初推出的几年，也得到了众多的成功案例，获得业界广泛的支持和肯定，但随着分布式系统集群的规模和其工作负荷的增长，原框架的问题逐渐浮出水面，主要的问题集中如下：
1. JobTracker 是 Map-reduce 的集中处理点，存在单点故障。
2. JobTracker 完成了太多的任务，造成了过多的资源消耗，当 map-reduce job 非常多的时候，会造成很大的内存开销，潜在来说，也增加了 JobTracker fail 的风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。
3. 在 TaskTracker 端，以 map/reduce task 的数目作为资源的表示过于简单，没有考虑到 cpu/ 内存的占用情况，如果两个大内存消耗的 task 被调度到了一块，很容易出现 OOM。
4. 在 TaskTracker 端，把资源强制划分为 map task slot 和 reduce task slot, 如果当系统中只有 map task 或者只有 reduce task 的时候，会造成资源的浪费，也就是前面提过的集群资源利用的问题。
5. 源代码层面分析的时候，会发现代码非常的难读，常常因为一个 class 做了太多的事情，代码量达 3000 多行，，造成 class 的任务不清晰，增加 bug 修复和版本维护的难度。
6. 从操作的角度来看，现在的 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）架构

重构根本的思想是将 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 框架什么优势呢？我们可以看到：
1. 这个设计大大减小了 JobTracker（也就是现在的 ResourceManager）的资源消耗，并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。
2. 在新的 Yarn 中，ApplicationMaster 是一个可变更的部分，用户可以对不同的编程模型写自己的 AppMst，让更多类型的编程模型能够跑在 Hadoop 集群中，可以参考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。
3. 对于资源的表示以内存为单位 ( 在目前版本的 Yarn 中，没有考虑 cpu 的占用 )，比之前以剩余 slot 数目更合理。
4. 老的框架中，JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状况，现在，这个部分就扔给 ApplicationMaster 做了，而 ResourceManager 中有一个模块叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是监测 ApplicationMaster 的运行状况，如果出问题，会将其在其他机器上重启。
5. 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.sh
Yarn 框架中由于启动 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
系统默认分布式文件 URI
fs.default.name
fs.defaultFS

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

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

分布式文件系统数据块复制数
dfs.replication
dfs.replication
新框架与老框架一致，值建议配置为与分布式 cluster 中实际的 DataNode 主机数一致
mapred-site.xml
Job 监控地址及端口
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.xml
The 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 接口地址

回页首
Hadoop Yarn 框架 Demo 示例
Demo 场景介绍：Weblogic 应用服务器日志分析
了解了 hadoop 新的 Yarn 框架的架构和思路后，我们用一个 Demo 示例来检验新 Yarn 框架下 Map-Reduce 程序的开发部署。
我们考虑如下应用场景：用户的生产系统由多台 Weblogic 应用服务器组成，每天需要每台对应用服务器的日志内容进行检查，统计其日志级别和日志模块的总数。
WebLogic 的日志范例如下图所示：

图 3.Weblogic 日志示例

如上图所示，<Info> 为 weblogic 的日志级别，<Security>，<Management> 为 Weblogic 的日志模块，我们主要分析 loglevel 和 logmodule 这两个维度分别在 WebLogic 日志中出现的次数，每天需要统计出 loglevel 和 logmodule 分别出现的次数总数。
Demo 测试环境 Yarn 框架搭建
由于 Weblogic 应用服务器分布于不同的主机，且日志数据量巨大，我们采用 hadoop 框架将 WebLogic 各个应用服务器主机上建立分布式目录，每天将 WebLogic 日志装载进 hadoop 分布式文件系统，并且编写基于 Yarn 框架的 MapReduce 程序对日志进行处理，分别统计出 LogLevel 和 Logmodule 在日志中出现的次数并计算总量，然后输出到分布式文件系统中，输出目录命名精确到小时为后缀以便区分每次 Demo 程序运行的处理结果。
我们搭建一个 Demo 测试环境以验证 Yarn 框架下分布式程序处理该案例的功能，以两台虚拟机作为该 Demo 的运行平台，两机均为 Linux 操作系统，机器 hostname 为 OEL 和 Stephen，OEL 作为 NameNode 和 ResouceManager 节点主机，64 位，Stephen 作为 DataNode 和 NodeManager 节点主机，32 位（Hadoop 支持异构性）, 具体如下：

表 3.Demo 测试环境表
主机名
角色
备注
OEL(192.168.137.8)
NameNode 节点主机 
ResourceManager 主机
linux 操作系统 
32bit
Stephen(192.168.l37.2)
DataNode 节点主机 
NodeManager 主机
linux 操作系统 
64bit

我们把 hadoop 安装在两台测试机的 /hadoop 文件系统目录下，安装后的 hadoop 根目录为：/hadoop/hadoop-0.23.0，规划分布式文件系统存放于 /hadoop/dfs 的本地目录，对应分布式系统中的目录为 /user/oracle/dfs
我们根据 Yarn 框架要求，分别在 core-site.xml 中配置分布式文件系统的 URL，详细如下：

清单 1.core-site.xml 配置

<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://192.168.137.8:9100</value>
</property>
</configuration>

在 hdfs-site.xml 中配置 nameNode，dataNode 的本地目录信息，详细如下：

清单 2.hdfs-site.xml 配置

<configuration>
<property>
<name>dfs.namenode.name.dir</name>
<value>/hadoop/dfs/name</value>
<description> </description>
</property>

<property>
<name>dfs.datanode.data.dir</name>
<value>/hadoop/dfs/data</value>
<description> </description>
</property>

<property>
<name>dfs.replication</name>
<value>2</value>
</property>

</configuration>

在 mapred-site.xml 中配置其使用 Yarn 框架执行 map-reduce 处理程序，详细如下：

清单 3.mapred-site.xml 配置

<configuration>
<property>
<name>mapreduce.framework.name</name>
<value>Yarn</value>
</property>
</configuration>

最后在 Yarn-site.xml 中配置 ResourceManager，NodeManager 的通信端口，web 监控端口等，详细如下：

清单 4.Yarn-site.xml 配置

<?xml version="1.0"?>
<configuration>

<!-- Site specific YARN configuration properties -->
<property>
<name>Yarn.nodemanager.aux-services</name>
<value>mapreduce.shuffle</value>
</property>
<property>
<description>The address of the applications manager interface in the RM.</description>
<name>Yarn.resourcemanager.address</name>
<value>192.168.137.8:18040</value>
</property>

<property>
<description>The address of the scheduler interface.</description>
<name>Yarn.resourcemanager.scheduler.address</name>
<value>192.168.137.8:18030</value>
</property>

<property>
<description>The address of the RM web application.</description>
<name>Yarn.resourcemanager.webapp.address</name>
<value>192.168.137.8:18088</value>
</property>

<property>
<description>The address of the resource tracker interface.</description>
<name>Yarn.resourcemanager.resource-tracker.address</name>
<value>192.168.137.8:8025</value>
</property>
</configuration>

具体配置项的含义，在 hadoop 官方网站有详细的说明，读者可以参见 hadoop 0.23.0 官方配置模板。
Demo 代码开发及详解
以下我们详细介绍一下新的 Yarn 框架下针对该应用场景的 Demo 代码的开发， 在 Demo 程序的每个类都有详细的注释和说明，Yarn 开发为了兼容老版本，API 变化不大，可以参考 官方 Hadoop Yarn 框架 API。
在 M