hadoop实战经验总结--遇到问题及解决方案

可以下面问题来阅读：
1.为什么hadoop压缩文件能够提高部分计算效率？
2.reduce的数量设多少合适？
3.运行一段时间后hadoop不能stop-all.sh，可能的原因是什么？


1.关于计算过程中的压缩和效率的对比问题
    之前曾经介绍过对输入文件采用压缩可以提高部分计算效率。现在作更进一步的说明。
    为什么压缩会提高计算速度？这是因为mapreduce计算会将数据文件分散拷贝到所有datanode上，压缩可以减少数据浪费在带宽上的时间，当这些时间大于压缩/解压缩本身的时间时，计算速度就会提高了。
    hadoop的压缩除了将输入文件进行压缩外，hadoop本身还可以在计算过程中将map输出以及将reduce输出进行压缩。这种计算当中的压缩又有什么样的效果呢？
    测试环境：35台节点的hadoop cluster，单机2 CPU,8 core,8G内存，redhat 2.6.9, 其中namenode和second namenode各一台，namenode和second namenode不作datanode
    输入文件大小为2.5G不压缩，records约为3600万条。mapreduce程序分为两个job:
    job1:map将record按user字段作key拆分，reduce中作外连接。这样最后reduce输出为87亿records，大小540G
    job2:map读入这87亿条数据并输出，reduce进行简单统计，最后的records为2.5亿条，大小16G
    计算耗时54min

    仅对第二个阶段的map作压缩(第一个阶段的map输出并不大，没有压缩的必要)，测试结果：计算耗时39min

    可见时间上节约了15min，注意以下参数的不同。
    不压缩时:
     Local bytes read=1923047905109
     Local bytes written=1685607947227
     压缩时：
     Local bytes read=770579526349
     Local bytes written=245469534966
     本地读写的的数量大大降低了

     至于对reduce输出的压缩，很遗憾经过测试基本没有提高速度的效果。可能是因为第一个job的输出大多数是在本地机上进行map，不经过网络传输的原因。
     附：对map输出进行压缩，只需要添加 jobConf.setMapOutputCompressorClass(DefaultCodec.class)


2 关于reduce的数量设置问题
    reduce数量究竟多少是适合的。目前测试认为reduce数量约等于cluster中datanode的总cores的一半比较合适，比如 cluster中有32台datanode,每台8 core，那么reduce设置为128速度最快。因为每台机器8 core，4个作map,4个作reduce计算，正好合适。
    附小测试：对同一个程序
            reduce num=32,reduce time = 6 min
            reduce num=128, reduce time = 2 min
            reduce num=320, reduce time = 5min



3某次正常运行mapreduce实例时,抛出错误

java.io.IOException: All datanodes xxx.xxx.xxx.xxx:xxx are bad. Aborting…

at org.apache.hadoop.dfs.DFSClient$DFSOutputStream.processDatanodeError(DFSClient.java:2158)

at org.apache.hadoop.dfs.DFSClient$DFSOutputStream.access$1400(DFSClient.java:1735)

at org.apache.hadoop.dfs.DFSClient$DFSOutputStream$DataStreamer.run(DFSClient.java:1889)

java.io.IOException: Could not get block locations. Aborting…

at org.apache.hadoop.dfs.DFSClient$DFSOutputStream.processDatanodeError(DFSClient.java:2143)

at org.apache.hadoop.dfs.DFSClient$DFSOutputStream.access$1400(DFSClient.java:1735)

at org.apache.hadoop.dfs.DFSClient$DFSOutputStream$DataStreamer.run(DFSClient.java:1889)

经查明，问题原因是linux机器打开了过多的文件导致。用命令ulimit -n可以发现linux默认的文件打开数目为1024，修改/ect/security/limit.conf，增加hadoop soft 65535

再重新运行程序（最好所有的datanode都修改），问题解决

P.S:据说hadoop dfs不能管理总数超过100M个文件，有待查证


4 运行一段时间后hadoop不能stop-all.sh的问题，显示报错

no tasktracker to stop ，no datanode to stop

问题的原因是hadoop在stop的时候依据的是datanode上的mapred和dfs进程号。而默认的进程号保存在/tmp下，linux 默认会每隔一段时间（一般是一个月或者7天左右）去删除这个目录下的文件。因此删掉hadoop-hadoop-jobtracker.pid和 hadoop-hadoop-namenode.pid两个文件后，namenode自然就找不到datanode上的这两个进程了。

在配置文件中的export HADOOP_PID_DIR可以解决这个问题

来自群组: Hadoop技术组

这些太珍贵了，只有实践才能遇到的问题

参考一下，感谢分享