Hadoop集群datanode磁盘不均衡的解决方案
![](https://images2015.cnblogs.com/blog/437881/201609/437881-20160913210907602-249420698.png)
![](https://images2015.cnblogs.com/blog/437881/201608/437881-20160825204343460-2141080347.png)
![](https://images2015.cnblogs.com/blog/437881/201608/437881-20160825205030054-502094990.png)
<property> <name>dfs.datanode.du.reserved</name> <value>107374182400</value> </property>
上面这个参数的意思:
Reserved space in bytes per volume. Always leave this much space free for non dfs use.
再查看datanode日志,希望能找到可靠的线索:
这种错误无法通过namenode来避免,因为它不会再failed的时候去尝试往别的节点写数, 最初的办法是将该节点的datanode关闭掉,就能顺利地跑完这个mapreduce。
再者查看namenode的页面,看到有好多datanode的节点的Remaining快要趋于0B了,这个时候就很容易出现上面的报错。
The balancer is a tool that balances disk space usage on an HDFS cluster when some datanodes become full or when new empty nodes join the cluster.
The tool is deployed as an application program that can be run by the cluster administrator on a live HDFS cluster while applications adding and deleting files.
下面的图片是官网中balancer命令得详解:
![](https://images2015.cnblogs.com/blog/437881/201609/437881-20160913210933820-687834278.png)
start-balancer.sh -threshold 20 -policy blockpool -include -f /tmp/ip.txt
<property> <name>dfs.datanode.balance.bandwidthPerSec</name> <value>10485760</value> </property>
但是这个需要重启,hadoop提供了一个动态调整的命令:
hdfs dfsadmin -fs hdfs://ns1:8020 -setBalancerBandwidth 104857600 hdfs dfsadmin -fs hdfs://ns2:8020 -setBalancerBandwidth 104857600 hdfs dfsadmin -fs hdfs://ns3:8020 -setBalancerBandwidth 104857600 hdfs dfsadmin -fs hdfs://ns4:8020 -setBalancerBandwidth 104857600 hdfs dfsadmin -fs hdfs://ns5:8020 -setBalancerBandwidth 104857600
hdfs dfs -get hdfs://ns1/test/dt=2016-07-24/000816_0.lzo hdfs dfs -put -f 000816_0.lzo hdfs://ns1/test/dt=2016-07-24/000816_0.lzo hdfs dfs -chown dd_edw:dd_edw hdfs://ns1/test/dt=2016-07-24/000816_0.lzo
前提条件需要将这个节点的datanode重新启动。
hdfs dfs -setrep -R -w 2 hdfs://ns1/tmp/test.db
升副本的命令如下:
hdfs dfs -setrep -R -w 3 hdfs://ns1/tmp/test.db
上面的命令是将ns1下的/tmp/test.db副本数降至2个,然后又将它升至3哥副本。具体的hdfs dfs -setrep命令如下图:
这样动态的升降副本可以解决。
另外在升降副本的遇到一个BUG:
推测可能是namenode的replications模块有夯住情况,所以出现该情况执行kill掉进行,跳过该块再跑!
总结:之所以选择使用升降副本是因为它不受带宽的控制,另外在升降副本的时候hadoop是需要重新写数的,这个时候它会优先往磁盘低写数据,这样就能将磁盘高的数据迁移至磁盘低的。
4、distcp
DistCp (distributed copy) is a tool used for large inter/intra-cluster copying. It uses MapReduce to effect its distribution, error handling and recovery, and reporting. It expands a list of files and directories into input to map tasks, each of which will copy a partition of the files specified in the source list. Its MapReduce pedigree has endowed it with some quirks in both its semantics and execution. The purpose of this document is to offer guidance for common tasks and to elucidate its model.
在这里举一个例子:
通过distcp将/tmp/output12上的数据调用mapreduce迁移至/tmp/zhulh目录下,原先/tmp/output12上的数据还是有存在的,但是它的块就发生了变化。
这个时候有人可能会说怎么不使用cp命令呢?
两者的区别如下:
CP的模式是不走mapreduce的;DISTCP的模式是走mapreduce的,所以它优先写有nodemanager的机器;
CP是单线程的,类似scp的模式,在执行速度上比DISTCP要慢很多。
5、提高dfs.datanode.du.reserved值
官网是这么说的:Reserved space in bytes per volume. Always leave this much space free for non dfs use.
在上面的提到dfs.datanode.du.reserved的值是设成100G,因为namenode认为该节点还有剩余的空间,所以给分配到这里,假如这个块是128K,但是实际剩余空间只有100K,所以就会报上面的错误,假如把dfs.datanode.du.reserved成300G,让namenode知道该节点已经没有剩余空间,所以就不会往这里写数据了。
6、关闭nodemanger进程
在现有计算资源多余的情况下,可以考虑关闭高磁盘节点的nodemanager,避免在该节点起YarnChild,因为如果在该节点上进行计算的话,数据存储首先会往本地写一份,这样更加加重了本地节点的负担。
7、删除旧数据
该方案是在迫不得已的情况下进行的,因为删掉的数据可能以后还得补回来,这样的话又是得要浪费一定的时间。
另外在删除数据时候就得需要跳过回收站才能算是真正删除,可以使用的命令如下:
本篇文章主要介绍了对hadoop数据出现不均衡情况下可以使用的方案,并以实例来解决问题!
对此有兴趣的同学欢迎一起交流 。