Hadoop 新 MapReduce 框架 Yarn 详解
Hadoop新MapReduce框架Yarn详解
简介：本文介绍了Hadoop自0.23.0版本后新的map-reduce框架（Yarn)原理，优势，运作机制和配置方法等；着重介绍新的yarn框架相对于原框架的差异及改进；并通过Demo示例详细描述了在新的yarn框架下搭建和开发hadoop程序的方法。读者通过本文中新旧hadoop map-reduce框架的对比，更能深刻理解新的yarn框架的技术原理和设计思想，文中的Demo代码经过微小修改即可用于用户基于hadoop新框架的实际生产环境。
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.3Demo代码开发及详解)，但是原框架中核心的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(st
op)-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/h
adoop-env.sh
${hadoop_home_dir}/etc/hadoop/Y
arn-env.sh
Yarn框架中由于启动hdfs分布式文件系统和启
动MapReduce框架分离，JAVA_HOME需要在
hadoop-env.sh和Yarn-env.sh中分别配置
HADOOP_LOG_D IR全局变量不需要配置${hadoop_home_dir}/etc/hadoop/h
adoop-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框架配置项变化表
配置文件配置项Hadoop0.20.X
配置
Hadoop0.23.X配置说明
core-site.xml系统默认分布式文件URI https://www.sodocs.net/doc/5c8398857.html, fs.defaultFS
hdfs-site.xml DFS name node存放name
table的目录https://www.sodocs.net/doc/5c8398857.html,.dir https://www.sodocs.net/doc/5c8398857.html,.dir新框架中name node分成
https://www.sodocs.net/doc/5c8398857.html,.dir(存放
naname table和
https://www.sodocs.net/doc/5c8398857.html,node.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.tracke
r 无新框架中已改为Yarn-site.xml中的
resouceManager及nodeManager具
体配置项，新框架中历史job的查询
已从Job tracker剥离，归入单独的
mapreduce.jobtracker.jobhistory
相关配置，
第三方MapReduce框架无https://www.sodocs.net/doc/5c8398857.html,新框架支持第三方MapReduce开发框
架以支持如SmartTalk/DGSG等非
Yarn架构，注意通常情况下这个配置
的值都设置为Yarn，如果没有配置这
项，那么提交的Yarn job只会运行在
locale模式，而不是分布式模式。
Yarn-site.xml The address of the
applications manager
interface in the RM 无Yarn.resourcemanager.add
ress
新框架中NodeManager与RM通信的
接口地址
The address of the scheduler interface 无Yarn.resourcemanager.sch
eduler.address
同上，NodeManger需要知道RM主机
的scheduler调度服务接口地址
The address of the RM web application 无Yarn.resourcemanager.web
app.address
新框架中各个task的资源调度及运
行状况通过通过该web界面访问
The address of the无Yarn.resourcemanager.res新框架中NodeManager需要向RM报
resource tracker interface ource-tracker.address告任务运行状态供Resouce跟踪，因
此NodeManager节点主机需要知道
RM主机的tracker接口地址
Hadoop Yarn框架Demo示例
Demo场景介绍：Weblogic应用服务器日志分析
了解了hadoop新的Yarn框架的架构和思路后，我们用一个Demo示例来检验新Yarn框架下Map-Reduce程序的开发部署。
我们考虑如下应用场景：用户的生产系统由多台Weblogic应用服务器组成，每天需要每台对应用服务器的日志内容进行检查，统计其日志级别和日志模块的总数。
WebLogic的日志范例如下图所示：
图 3.Weblogic日志示例
如上图所示，
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配置
在hdfs-site.xml中配置nameNode，dataNode的本地目录信息，详细如下：
清单 2.hdfs-site.xml配置
在mapred-site.xml中配置其使用Yarn框架执行map-reduce处理程序，详细如下：
清单 3.mapred-site.xml配置
最后在Yarn-site.xml中配置ResourceManager，NodeManager的通信端口，web监控端口等，详细如下：
清单 4.Yarn-site.xml配置
interface.
具体配置项的含义，在hadoop官方网站有详细的说明，读者可以参见hadoop 0.23.0官方配置模板。
Demo代码开发及详解
以下我们详细介绍一下新的Yarn框架下针对该应用场景的Demo代码的开发，在Demo程序的每个类都有详细的注释和说明，Yarn开发为了兼容老版本，API 变化不大，可以参考官方Hadoop Yarn框架API。
在Map程序中，我们以行号为key，行文本为value读取每一行WebLogic日志输入，将loglevel和logmodule的值读出作为Map处理后的新的key值，由于一行中loglevel和logmodule的出现次数应该唯一，所以经Map程序处理后的新的record记录的value应该都为1：
清单 5.Map业务逻辑
public static class MapClass extends Mapper
{
private Text record=new Text();
private static final IntWritable recbytes=new IntWritable(1);
public void map(Object key,Text value,Context context) throws IOException,InterruptedException{
String line=value.toString();
//没有配置RecordReader，所以默认采用line的实现，
//key就是行号，value就是行内容，
//按行key-value存放每行loglevel和logmodule内容
if(line==null||line.equals(""))
return;
String[]words=line.split("><");
if(words==null||words.length<2)
return;
String logLevel=words[1];
String moduleName=words[2];
record.clear();
record.set(new
StringBuffer("logLevel::").append(logLevel).toString());
context.write(record,recbytes);
//输出日志级别统计结果，通过logLevel::作为前缀来标示。
record.clear();
record.set(new
StringBuffer("moduleName::").append(moduleName).toString());
context.write(record,recbytes);
//输出模块名的统计结果，通过moduleName::作为前缀来标示
}
}
由于有loglevel和logmodule两部分的分析工作，我们设定两个Reduce来分别处理这两部分，loglevel的交给reduce1，logmodule交给reduce2。因此我们编写Patitioner类，根据Map传过来的Key中包含的logLevel和moduleName的前缀，来分配到不同的Reduce：
清单 6.Partition业务逻辑
public static class PartitionerClass extends Partitioner
{
public int getPartition(Text key,IntWritable value,int numPartitions) {
if(numPartitions>=2)//Reduce个数，判断loglevel还是logmodule的统计，分配到不同的Reduce
if(key.toString().startsWith("logLevel::"))
return0;
else if(key.toString().startsWith("moduleName::"))
return1;
else return0;
else
return0;
}
}
在Reduce程序中，累加并合并loglevel和logmodule的出现次数
清单7.Reduce业务逻辑
public static class ReduceClass extends Reducer IntWritable,Text,IntWritable> { private IntWritable result=new IntWritable(); public void reduce(Text key,Iterable Context context)throws IOException, InterruptedException{ int tmp=0; for(IntWritable val:values){ tmp=tmp+val.get(); } result.set(tmp); context.write(key,result);//输出最后的汇总结果 } } 以上完成了MapReduce的主要处理逻辑，对于程序入口，我们使用Hadoop提供的Tools工具包方便的进行May-Reduce程序的启动和Map/Reduce对应处理class的配置。 清单8.Main执行类 import java.io.File; import java.io.IOException; import java.text.SimpleDateFormat; import java.util.Date; import java.util.Iterator; import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.conf.Configured; import org.apache.hadoop.fs.Path; import org.apache.hadoop.io.IntWritable; import org.apache.hadoop.io.Text; import org.apache.hadoop.mapreduce.Job; import org.apache.hadoop.mapreduce.Reducer; import org.apache.hadoop.mapreduce.Mapper; import org.apache.hadoop.mapreduce.Partitioner; import org.apache.hadoop.mapreduce.lib.input.FileInputFormat; import org.apache.hadoop.mapreduce.lib.output.FileOutputFormat; import org.apache.hadoop.util.Tool; import org.apache.hadoop.util.ToolRunner; public class LogAnalysiser extends Configured implements Tool{ public static void main(String[]args) { try { int res; res=ToolRunner.run(new Configuration(),new LogAnalysiser(),args); System.exit(res); }catch(Exception e) { e.printStackTrace(); } } public int run(String[]args)throws Exception { if(args==null||args.length<2) { System.out.println("need inputpath and outputpath"); return1; } String inputpath=args[0]; String outputpath=args[1]; String shortin=args[0]; String shortout=args[1]; if(shortin.indexOf(File.separator)>=0) shortin=shortin.substring(https://www.sodocs.net/doc/5c8398857.html,stIndexOf(File.separator)); if(shortout.indexOf(File.separator)>=0) shortout=shortout.substring(https://www.sodocs.net/doc/5c8398857.html,stIndexOf(File.separator)); SimpleDateFormat formater=new SimpleDateFormat("yyyy.MM.dd.HH.mm"); shortout=new StringBuffer(shortout).append("-") .append(formater.format(new Date())).toString(); if(!shortin.startsWith("/")) shortin="/"+shortin; if(!shortout.startsWith("/")) shortout="/"+shortout; shortin="/user/oracle/dfs/"+shortin; shortout="/user/oracle/dfs/"+shortout; File inputdir=new File(inputpath); File outputdir=new File(outputpath); if(!inputdir.exists()||!inputdir.isDirectory()) { System.out.println("inputpath not exist or isn't dir!"); return0; } if(!outputdir.exists()) { new File(outputpath).mkdirs(); } //以下注释的是hadoop0.20.X老版本的Job代码，在hadoop0.23.X新框架中已经大大简化 //Configuration conf=getConf(); //JobConf job=new JobConf(conf,LogAnalysiser.class); //JobConf conf=new JobConf(getConf(),LogAnalysiser.class);//构建Config //conf.setJarByClass(MapClass.class); //conf.setJarByClass(ReduceClass.class); //conf.setJarByClass(PartitionerClass.class); //conf.setJar("hadoopTest.jar"); //job.setJar("hadoopTest.jar"); //以下是新的hadoop0.23.X Yarn的Job代码 job job=new Job(new Configuration()); job.setJarByClass(LogAnalysiser.class); job.setJobName("analysisjob"); job.setOutputKeyClass(Text.class);//输出的key类型，在OutputFormat会检查 job.setOutputValueClass(IntWritable.class);//输出的value类型，在OutputFormat会检查 job.setJarByClass(LogAnalysiser.class); job.setMapperClass(MapClass.class); job.setCombinerClass(ReduceClass.class); job.setReducerClass(ReduceClass.class); job.setPartitionerClass(PartitionerClass.class); job.setNumReduceTasks(2);//强制需要有两个Reduce来分别处理流量和次数的统计 FileInputFormat.setInputPaths(job,new Path(shortin));//hdfs中的输入路径 FileOutputFormat.setOutputPath(job,new Path(shortout));//hdfs中输出路径 Date startTime=new Date(); System.out.println("Job started:"+startTime); job.waitForCompletion(true); Date end_time=new Date(); System.out.println("Job ended:"+end_time); System.out.println("The job took"+ (end_time.getTime()-startTime.getTime())/1000+"seconds."); //删除输入和输出的临时文件 //fileSys.copyToLocalFile(new Path(shortout),new Path(outputpath)); //fileSys.delete(new Path(shortin),true); //fileSys.delete(new Path(shortout),true); return0; } } Demo部署及运行 Demo输入输出的控制 本demo中我们将从Weblogic日志目录中拷贝原始待处理日志文件作为Yarn 程序的输入，使用hadoop dfs命令将其放入分布式目录的input目录，处理完后将生成以时间戳为文件目录后缀的输出目录 Weblogic日志存放的原始目录位于： /u01/app/Oracle/Middleware/user_projects/domains/test_domain/AdminSer ver/logs 分布式文件系统中的输入目录：/user/oracle/dfs/input 分布式文件系统中的输出目录：/user/oracle/dfs/output_%YYYY-MM-DD-hh-mm% Demo打包和部署 可以使用JDeveloper或者Eclipse等IDE工具将开发的Hadoop Demo代码打包为jar，并指定Main类为LoyAnalyze，本文中我们采用JDeveloper打包Demo代码，如下图示例： 图 4.Yarn Demo程序打包示例 Demo执行与跟踪 我们在OEL主机（NameNode&ResourceManager主机，192.168.137.8）上启动dfs分布式文件系统： 图 5.启动Demo dfs文件系统 从上图可以看出dfs分布式文件系统已经在OEL和Stephen主机上成功启动，我们通过默认的分布式文件系统Web监控端口 http://192.168.137.8:50070（也可以在上文中core-site.xml中配置https://www.sodocs.net/doc/5c8398857.html,node.http-address项指定其他端口)来验证其文件系统情况： 图 6.hadoop文件系统web监控页面 从上图中我们可以看到/user/oracle/dfs分布式文件系统已成功建立。 接下来我们在NameNode主机（OEL，192.168.137.8）上启动Yarn框架： 图7.启动Demo Yarn框架 从上图我们可以看到ResouceManager在OEL主机上成功启动，NodeManager 进程在Stephen节点主机上也已经启动，至此整个新的Hadoop Yarn框架已经成功启动。 我们将打好的testHadoop.jar包上传至NameNode主机（OEL）的 /hadoop/hadoop-0.23.0/根目录下，我们使用Hadoop自带的hadoop命令行工具执行Demo的jar包，具体步骤为，先使用hadoop dfs命令将输入文件（weblogic原始日志）拷贝至dfs分布式目录的input输入目录，清理dfs 分布式目录下的output输出子目录。然后使用hadoop jar命令执行testHadoop的jar包。 执行Demo的shell脚本示例如下： ./bin/hadoop dfs-rmr/user/oracle/dfs/output* ./bin/hadoop dfs-rmr/user/oracle/dfs/input ./bin/hadoop dfs-mkdir/user/oracle/dfs/input ./bin/hadoop dfs-copyFromLocal./input/*.log/user/oracle/dfs/input/ ./bin/hadoop jar./hadoopTest.jar/hadoop/hadoop-0.23.0/input /hadoop/hadoop-0.23.0/output 清单9.Demo执行脚本 然后我们使用上文中的脚本启动demo并执行： 图8.Demo程序运行