6、worker资源分配的指定

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

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

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

　　7、单个worker内存限制

　　【现象】小数据量，测试通过，可是运行大数据，任务总是被平台kill。

　　【问题说明】现在hadoop平台对每个task运行时的内存进行了限制，默认是800M，当程序运行内存超过800M，平台自动会kill该任务

　　【测试方法】针对该点测试有2种方法：1，在集群运行大数据量，被平台kill后，查看日志，确认是因为内存超出被平台kill。2，在本地运行mapred程序，查看程序内存占用。若是在800M左右，上线就会有很大风险。

　　8、MPI程序对hadoop上文件目录的操作

　　【现象】在mpi节点上对同一目录上的文件进行操作，偶尔会失败。

　　【问题说明】该问题同Hadoop副本任务对程序结果的影响 原因一样，都多个节点对hadoop上同一个文件的操作。只是一个是hadoop上，一个是mpi上。

　　【测试方法】多个地方对hdfs上的同一个文件或者目录进行操作。特别是同一个模块即在hadoop，又在mpi集群上运行。不要在每个mpi节点同时对同一个hadoop目录或者文件进行修改操作。

　　9、对于map reduce的运行参数的设置

　　【现象】程序在本地就能执行成功，可是在hadoop上却无法运行

　　【问题说明】有时候，map reduce的运行参数比较长，为了阅读方便，rd可能会对程序参数进行折行，添加tab键排版，这样反倒使hadoop上解析命令失败。

　　【测试方法】对于map reduce的运行参数比较长的情况，可以督促rd用shell变量进行设置。然后在hadoop程序启动参数用shell变量进行替换。即阅读方便，又不会出错。

　　10、Hadoop程序的结果使用的bistreaming的二进制文件结果

　　【现象】程序结果文件是二进制格式，可是下载到本地，按照详细设计中描述的格式，解析格式总是错误。

　　【问题说明】当前流模式可以用streaming和bistreaming，当使用bistreaming时，生成的结果文件是hadoop的 sequence file文件格式，文件格式中含有key length和value length信息。在hadoop上使用该数据时，这个格式对用户是透明的。下载到本地后，就不能直接使用了。

　　【测试方法】当任务的输出outputformat=SequenceFileAsBinaryOutputFormat 时，可以使用hadoop dfs -copySeqFileToLocal –ignoreLen命令，把二进制数据下载到本地，并去掉长度信息，就和文档中写的格式一致了。

　　11、Hadoop对于输入文件的切分

　　【现象】输入文件是基于session的query日志行，session之间空行分割。当设置一个map的时候，程序结果正确，当设置多个map时，运行结果错误。

　　【问题说明】hadoop对于输入文件会以行为最小单元切分，因此，当输入以空行为分割，有二次数据格式的时候，hadoop无法保证不把一个session切到两个map task中。这样就把一个session拆分为多个session了。

　　【测试方法】当程序实现逻辑依赖于比行粒度更大的单元时，需要设置map的切分大小比单个输入文件大，否则就回出现把输入文件切分成多个map输入，导致切断更大的输入单元。