引言
通过本系列的前篇文章 用MRUnit做单元测试 介绍可以很容易对MapReduce进行单元测试，这很必要，可以较早的发现一些代码逻辑的问题。只有单元测试是不够的，我们需要对MapReduce任务进行集成测试，要进行集成测试，得先懂得如何将MapReduce 作业在hadoop集群中运行起来。
准备工作
以windows环境为例：
 安装jdk，设置环境变量JAVA_HOME为jdk安装目录
 安装Cygwin，安装时注意选择安装软件包openssh - Net 类，安装完成将cygwin/bin加入环境变量path。
 确认ssh。打开cygwin命令行，分别执行以下命令
  安装sshd:$ ssh-host-config
  启动sshd服务：$ net start sshd
  配置免密码登录用户：$ ssh-user-config
  检查可登录localhost：$ ssh localhost
 下载稳定的hadoop版本，点此选择 下载 ，我选择的是0.20.2版本。
 下载后解压，编辑conf/hadoop-env.sh，修改JAVA_HOME为jdk安装目录。
至此，Windows环境下的Hadoop的安装和配置完成，为了运行还需要打包MapReduce作业。我们用maven的 assembly插件来将程序打包。
配置如下： 
  

<build>
  

 <plugins>
  

   <plugin>
  

     <artifactId>maven-assembly-plugin</artifactId>
  

     <configuration>
  

       <descriptorRefs>
  

	<descriptorRef>jar-with-dependencies</descriptorRef>
  

       </descriptorRefs>
  

     </configuration>
  

   </plugin>
  

  </plugins>
  

</build>
在pom.xml里加入以上配置，运行mvn assembly:assembly命令就可以打包了。
单机运行
  • 特点：
     单台机器、单线程运行、不需要启动hadoop进程，利于调试，但没有模拟hadoop集群多个进程的情况，只支持一个reducer。
  • 运行方式：
    $ bin/hadoop jar --config standalone path/xx.jar WordCount input output
  • 注意点：
     用--config指定单机运行时的配置目录（示例中配置目录文件夹名为standalone，在0.20.2版本这个文件夹可以为空目录，不要别的配置文件）
     WordCount为包含运行作业main函数的的类，如果有包名需要加上包名。
     Input文件夹下放置输入的文件。
     output为输出的目录，在运行job前需保证该目录不存在，否则会报错。
    伪分布式运行
  • 特点：
     单台机器，启动hadoop所有进程（如NameNode, DataNode, TaskTracker, JobTracker, SecondaryNameNode），较好的模拟hadoop集群情况。
  • 配置：
     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/hadoop namenode –format
     启动hadoop进程：$ bin/start-all.sh
     检查是否启动成功，可访问以下url
      NameNode - http://localhost:50070/
      JobTracker - http://localhost:50030/
     如果不能访问，检查logs目录下的日志分析原因。
     将输入文件复制到分布式文件系统：$ bin/hadoop fs -put local input
     运行作业：$ bin/hadoop jar path/xx.jar WordCount input output
     检查输出：$ bin/hadoop fs -cat output/*
     停止hadoop进程：$ bin/stop-all.sh
    完全分布式运行测试
    完全分布式运行需要利用多台机器，实现hadoop的分布式集群，通过高仿真环境进行集成测试。关于完全分布式运行测试环境搭建可见Cluster Setup。
    集成测试总结
    在掌握了如何运行hadoop作业后，测试要做的事就是通过脚本/代码将这个过程自动化起来，一般流程是：
    预设置（准备输入文件、启动hadoop进程等）->运行作业->输出结果跟预期结果的对比->报告导致失败的原因。
    在运行集成测试时需要考虑几个问题：
     集成环境的搭建：需要考虑机器资源，维护成本。
     输入构造：在单元测试时我们可以很容易的构造一些小的键值对，其输出结果可以很好的预期，但在集成测试时小文件意义已经不大了，我们需要仿真的大批量的数据来发现程序的问题，仿真度越高，发现问题的可能性越大。
     输出分析： 我们面对的输入是仿真的海量数据，不可能做输出结果的精确预期，需要借助日志或对输出进行二次分析。在开发时需要考虑这些情况，将有用信息通过日志或输出的方式存储。在完全分布式模式运行，日志散落在各台机器上，如何有效获取这些日志集中起来做分析?这个我们可以借助Scribe工具。同样，输出结果也可能为海量数据，如何高效对此进行分析，这可能需要针对输出数据编写测试的MapReduce任务来分析结果。