随着分布式计算技术的推广，越来越多的大数据计算任务迁移到hadoop平台上进行，模型类的hadoop应用也越来越多。经过这一段时间在hadoop上的测试项目，在此简单分享下hadoop上项目测试的经验。本文主要介绍项目测试过程中一些常见的现象以及问题的说明和一些常见的测试方法

　　一、测试常见问题

　　1、reduce输出文件，上传文件，下载文件等操作的目的文件的删除。

　　【现象】程序第一次运行还是成功的，数据和程序都没有修改，同样的命令，运行第二次的时候，怎么失败了呢？

　　【问题说明】由于hdfs文件系统没有覆盖写的特性。对于reduce的输出，本地上传文件到hdfs上，下载hdfs文件到本地等操作，当目的文件已经存在，这些操作均会失败。

　　【测试方法】对于具有上述操作的程序，一定要在程序运行前把对应的目的文件删除，特别是具有多轮迭代程序的临时目录需要清楚。

　　2、HADOOP_HOME环境变量的设置

　　【现象】在自己独自使用的测试机上，利用hadoop命令新建了一个目录，并利用hadoop dfs –ls path命令能够查看到该目录存在，换到一个公用的机器上找不到该目录？

　　【问题说明】同一台测试机器可能会有多个hadoop客户端连接到多个不同的hadoop平台。而当在shell命令行直接输入hadoop命令时，系统默认是使用HADOOP_HOME下的hadoop客户端。当HADOOP_HOME环境变量被别的用户修改后，会连接到别的hadoop平台，当然找不到所要的目录：）。

　　【测试方法】当在程序中使用hadoop命令的时候，一定要指定hadoop命令的路径，特别在rd提供的程序中，hadoop命令的路径一定要可配。

　　3、Hadoop上程序输入目录的标准化

　　【现象】程序的输入数据完全没问题：文件路径和格式均正确，为什么结果文件都为空呢？

　　【问题说明】对于多路输入（即多种格式的输入文件），rd进行设计程序的时候，常常会根据路径名来进行文件类型的判断，进而进行不同的操作。此时，当外界输入的路径名没有标准化（比如存在：./a/，/a//b，/a/./b），map阶段通过比较传递的路径参数和map环境变量获取的当前处理文件路径来判断当前处理的文件块来自哪个目录，结果会判断当前处理的文件不来自任何输入目录，从而无法获取输入数据的类型。（当时针对这个问题排查很久，曾一度认为是hdfs的问题，后通过查看程序源代码才发现该问题）

　　【测试方法】出现该情况，首先查看该任务的监控页面： Map input records的输入是否为0，若是为0，则需检查输入数据地址正确性。Map output records是否为0. Map output records代表map的输出，若是为0，那么是数据在map阶段被过滤掉，需要检查输入数据的格式正确性。然后查看Reduce input records是否为0，若rduece的输入为0，那输出肯定为0了。

　　4、Hadoop副本任务对程序结果的影响

　　【现象】在reduce中生成的本地文件需要上传到hdfs上。在上传之前，为了避免目的文件存在而导致上传失败，需要先进行删除操作，然后再上传。所有的reduce任务都正常结束，可是结果文件偶尔会有缺失。而且是不能稳定复现。

　　【问题说明】hadoop运行map，red任务的时候，为了防止单个task运行缓慢，拖累整个任务的完成时间，会对一些task启用备奋task，即多个task运行同一份数据，当一个task运行完成后，系统自动kill掉备份task。这样可能导致备份task被kill前，正确的文件上传后，被备份任务删除，导致后结果文件的缺失。而该现象还不是稳定复现。

　　【测试方法】对hdfs上的同一个文件，目录进行操作时，一定要注意并行操作的干扰。特别当在reduce中进行hdfs操作的时候，一定要考虑到副本的影响（该问题比较隐蔽）。解决方案是：1，禁止平台生成副本任务（可以配置启动参数达到目的）。2，在一个统一的单机进行此类操作。比如，现在单机处理好环境，然后启动mapred任务。

　　5、Reduce数据分桶不均

　　【现象】通过查看任务的监控页面发现有的reduce运行时间很短，而有的reduce运行时间很长。

　　【问题说明】既然利用hadoop的任务，处理的数据一定是大数据量的。简单的hash映射分桶可能导致分桶不均，从而多个reduce处理的数据量差别很大。

　　【测试方法】当前hadoop任务处理的数据很多都上T，若是在处理这么大规模的数据，分桶不均，可能导致单个节点处理数据过大，导致性能降低，甚至可能导致内存超过阈值被平台kill。因此在测试之前，一定要弄清楚，分桶的key和分桶函数是否会造成分桶不均。

　　6、worker资源分配的指定

　　【现象】每个task运行时间很短，集群资源很充足，可是任务运行时间却很长。

　　【问题说明】当处理的数据量很大时，任务会被分成很多的task，而当任务启动时，集群默认分配的worker会比较少，导致即使集群资源空闲，运行该任务的worker数仍然很少，运行结束时间延长。

　　【测试方法】若是处理的数据很大，在任务启动的时候，一定要指定资源参数，否则按照系统默认值，分配的work会很少（在hy集群为50）。对于大数据量，该限制会大大降低性能。任务启动的时候，可以通过监控页面，查看该任务运行的worker数。