配置：

　　conf/core-site.xml

　　<configuration>
　　<property>
　　<name>fs.default.name</name>
　　<value>hdfs://localhost:9000</value>
　　</property>
　　</configuration>

　　conf/hdfs-site.xml

　　<configuration>
　　<property>
　　<name>dfs.replication</name>
　　<value>1</value>
　　</property>
　　</configuration>

　　mapred-site.xml

　　<configuration>
　　<property>
　　<name>mapred.job.tracker</name>
　　<value>localhost:9001</value>
　　</property>
　　</configuration>

　　运行：

　　格式化分布式文件系统：$bin/hadoopnamenode–format
　　启动hadoop进程：$bin/start-all.sh
　　检查是否启动成功，可访问以下url
　　NameNode–http://localhost:50070/
　　JobTracker–http://localhost:50030/
　　如果不能访问，检查logs目录下的日志分析原因。
　　将输入文件复制到分布式文件系统：$bin/hadoopfs-putlocalinput
　　运行作业：$bin/hadoopjarpath/xx.jarWordCountinputoutput
　　检查输出：$bin/hadoopfs-catoutput/*
　　停止hadoop进程：$bin/stop-all.sh

　　完全分布式运行测试

　　完全分布式运行需要利用多台机器，实现hadoop的分布式集群，通过高仿真环境进行集成测试。关于完全分布式运行测试环境搭建可见ClusterSetup。

　　集成测试总结

　　在掌握了如何运行hadoop作业后，测试要做的事是通过脚本/代码将这个过程自动化起来，一般流程是：预设置（准备输入文件、启动hadoop进程等）->运行作业->输出结果跟预期结果的对比->报告导致失败的原因。

　　在运行集成测试时需要考虑几个问题：

　　集成环境的搭建：需要考虑机器资源，维护成本。

　　输入构造：在单元测试时我们可以很容易的构造一些小的键值对，其输出结果可以很好的预期，但在集成测试时小文件意义已经不大了，我们需要仿真的大批量的数据来发现程序的问题，仿真度越高，发现问题的可能性越大。

　　输出分析：我们面对的输入是仿真的海量数据，不可能做输出结果的精确预期，需要借助日志或对输出进行二次分析。在开发时需要考虑这些情况，将有用信息通过日志或输出的方式存储。在完全分布式模式运行，日志散落在各台机器上，如何有效获取这些日志集中起来做分析?这个我们可以借助Scribe工具。同样，输出结果也可能为海量数据，如何高效对此进行分析，这可能需要针对输出数据编写测试的MapReduce任务来分析结果。