优化Hadoop Balancer平衡的速度
之前我在博客中介绍了HDFS的Block数据balancer重分布实战内容：
http://blog.csdn.net/jiangshouzhuang/article/details/51879102
本篇文章我们再来简单介绍一下优化Hadoop Balancer平衡的速度涉及到的几个重要参数。
1. dfs.datanode.max.transfer.threads
修改dfs.datanode.max.transfer.threads=4096 (如果运行HBase的话建议为16384)，指定用于在DataNode间传输block数据的最大线程数，老版本的对应参数为dfs.datanode.max.xcievers。
2. dfs.datanode.balance.bandwidthPerSec
修改dfs.datanode.balance.bandwidthPerSec=52428800，指定DataNode用于balancer的带宽为50MB，这个根据情况而定，如果交换机性能好点的，完全可以设定100MB，单位是Byte，如果机器的网卡和交换机的带宽有限，可以适当降低该速度，比如10MB，默认是1048576(1MB)。
hdfs dfsadmin-setBalancerBandwidth 52428800
之前遇到一位朋友，他们公司的Hadoop生产环境上，HDFS分配非常不均匀，而且有的DataNode节点的磁盘使用率几乎100%了，导致一些作业报错。后来公司采取Hadoop balancer来对数据进行平衡操作，但是数据量太大，高达50T作业，所以采用Hadoop balancer方法进行平衡，需要的时间太长。
后来这位朋友咨询我，刚开始我是让他调整hadoop halancer的参数，比如线程数，带宽等，效果都没有那么明显，毕竟数据量太大。后面考虑到他们的数据副本为3，所以可以考虑将一些DataNode磁盘利用率太高的节点先下线操作（必须逐个节点操作，不可同时下线多个节点，防止数据丢失），即Decommission Datanode。完成下线后，再进行格式化数据磁盘操作，然后再将此DataNode添加到集群中，这样新的数据就会较快地同步过来。
最后，我们补充点Decommission Datanode相关知识。
Decommission Datanode主要有两个步骤：
1. 在Namenode上，把需要Decommission的Datanode的机器名加入到dfs.hosts.exclude(该配置项在hdfs-site.xml)所指定文件中，也就是告诉Namenode哪些Datanode要被Decommission。
把需要Decommission的节点写到文件/etc/hadoop/conf/dfs.exclude中去。
2. 用如下命令启动Decommission
hdfs dfsadmin -refreshNodes
Decommission Datanode的时候需要保证在该Datanode移除以后，HDFS上的文件还能满足replica factor的最低要求。
比如，一个只有3个Datanode的HDFS集群，文件默认replica factor(dfs.replication参数设置)是3，那么移除任何一个Datanode都会导致某些文件不能满足replica factor的最低要求。当试图移除一个Datanode的时候，会一直处在Decommissioning的状态，因为它找不到别的机器来迁移它的数据了。这个问题通常容易出现在小集群上。
一个解决办法就是临时把相应文件的replica factor调低。
1. 用如下命令来查看HDFS中所有文件的replica factor
hdfsfsck / -files -blocks
其中repl=1表示该文件的该block的replica factor为1。通过这个命令就可以找到那些replica factor比较高的文件了。
2 . 调整文件的replicafactor
我们需要注意的是，replica factor是文件的属性，而不是集群的属性，也就是说同一个集群中的文件可以有不同的replica factor。因此，我们需要针对文件修改replica factor。对应的命令是：
hdfs dfs -setrep [-R] [-w]
其中
- -R表示recursive，可以对一个目录及其子目录设置replica factor
表示需要设置的replica factor的值 表示需要设置的replica factor的文件或目录路径 - -w表示等待复制完成，可能需要等待很长时间