hadoop 集群 rebalance 和磁盘 均衡

在我们使用hadoop集群的时候 ，由于 日志 数据不断流入写入到hdfs上，而且 算法人员 不断的清洗 数据做特征工程 又会产生 新的中间数据 ，而且量一点都不小。
这个时候 hadoop 集群 就要面临着 hdfs 空间扩容 和 数据的 rebalance
hdfs 的扩容 和磁盘 扩容 有关，在我上一片文章介绍了磁盘 扩容 ，集群各个节点 添加新的磁盘 volume disk，然后把这些 格式化的disk 修改权限 添加到hadoop 的 hdfs yarn 的配置文件中，重启hadoop 集群就可以了。

但是 数据的rebalance 其实分好几种 情况 ，如果我们 理解错误了，只能是浪费时间，不断 在原地打转
首先 rebalance policy 就分三种 ，主要还是 针对的粒度

A.DataNode级别的rebalance
B.BlockPool 级别的rebalance
C.Volume & Disk 级别的rebalance
在 hadoop 2.X 版本 只支持 A,B ,而 hadoop 3.0版本 支持 A,B,C,
不过 对于勤劳 勇敢的大数据 管理者来说，可以迂回实现 hadoop 2.X 版本 对C 的支持

首先 我们要 对 集群扩容 也要客观分三种种情况
D. 一种是 添加节点 ，比如 原来的机器 一共有 1个 NameNode 4个 DataNode，突然 又添加了6个新的 DataNode，这样一来总共就有了 10个DataNode，
E. 一种 是在原来的节点 添加 磁盘，比如 原来的机器 一共有 1个 NameNode 4个 DataNode，其中每个DataNode 原来有5个 作为 DataNode的挂载磁盘 volume，每一个磁盘 都是2T，这样一来，整体的hdfs的总容量就是 2T x5x4=40T，然后突然 为每个DataNode节点再各添加 两个3T的 volume，这样一来 hdfs 的新的总容量就是
2Tx5x4 +3Tx2x4=64T，
F. 最后一种就是 D E 的结合体 ，即 增加DataNode 节点数量又增添每个DataNode的磁盘挂载量。

在 hadoop 2.X 版本的默认只支持 A B，如果不同DataNode节点的 各个挂载的总磁盘量 发生了 不平衡，可以通过 start-balance.sh 或者 hdfs balancer 两种 方式 启动 balance
程序，如果 不同 blockpool 不平衡 就启动 -policy blockpool 形式的 即可。
对于 A B 参考 http://blog.csdn.net/jiangshouzhuang/article/details/51879102

image.png

https://www.cloudera.com/documentation/enterprise/5-6-x/topics/admin_hdfs_balancer.html

image.png

https://community.hortonworks.com/articles/87440/hdfs-balancer-balancing-data-between-disks-on-a-da.html

image.png

但是一定要注意的 就是 在 一个DataNode 内部 ，如果 出现了 挂载的多个磁盘 写入量百分比 差别巨大，hdfs-balancer 是无能无力的，即使启动了，还是会没有报错的退出，因为 hadoop balancer 无法侦查到这种 单个DataNode 的 disk 之间数据不平衡，如果所有节点的 DataNode的总磁盘写入都差不多的话，hadoop 认为 你的集群是平衡状态的，麻蛋，就是这么任性。不管你怎么 调整参数 他都是无动于衷的。

image.png

image.png

但是hadoop 2.x 也是可以可以迂回实现 disk 级别的rebalance 就是 在 hdfs-site.xml中设置 每块磁盘的预留空间，比如当你设置预留 30G,当某块磁盘 快只剩下30G的时候，DataNode在写入的时候就会忽略掉他，去 写到别的挂载磁盘上，这个其实还是不够友好，万一 一个DataNode 挂载的好几款不同大小的磁盘，有50G 500G 1T 2T 3T,设置 30G,显然对50G影响是最大的，如果是百分比才是比较现实的选项，另外磁盘按道理一定要预留空间是有原因的，如果 没有空间了，你连 mapreduce job 都 跑不了了，必须的，详勘我之前写的 job 卡死的原因

image.png

<property>
<name>dfs.datanode.du.reserved</name>
<value>82212254720</value>

</property>

另外就是启动 磁盘的自 我 banlancer ，其实这个按道理在hadoop 2.x不会生效的属性，但是在hadoop 3.x 是支持的啊，求安慰吧，万一hadoop 2.x你写上了有点作用呢
<property>
<name>dfs.disk.balancer.enabled</name>
<value>true</value>
</property>

这些就是hadoop 2.x 的迂回策略 rebalance ，对于 DataNode 级别在 D F 情况下是肯定会起作用的， 肯定DataNode的磁盘使用量是有区别，前提是 达到我说的 需要 balancer的阈值了 在 -threshould 中你可以设置阈值，达到阈值后 hadoop 就会认为 整个集群的DataNode是已经平衡了

对于hadoop 3.x 版本的 DataNode blockPool policy rebalance 和2.x 应该是相同的，额外的选项是多了 diskbalancer 的命令 这个命令的执行 也是挺讲究的
需要先做plan 然后 excute 最后query
大家可以参考 这篇 https://www.iteblog.com/archives/1905.html
http://blog.csdn.net/jsjsjs1789/article/details/73997497

当然 我说的磁盘均衡和 rebalance 是 一个 治病的过程 ，如果不生病是 最好的，所以就要未雨绸缪 ，预防为主，尽量让 hdfs 自愈就更好不过了 ，当然也是有方法的， 比如 让hdfs 优先往新盘 写入数据 ，改变 hdfs 的默认写入策略，监控 各个磁盘写入差额 启动自平衡。
<property>
<name>dfs.datanode.fsdataset.volume.choosing.policy</name>
<value>org.apache.hadoop.hdfs.server.datanode.fsdataset.AvailableSpaceVolumeChoosingPolicy</value>
</property>

<property>
    <name>dfs.datanode.available-space-volume-choosing-policy.balanced-space-threshold</name>
    <value>20737418240</value> <!-- 20 GB -->
</property>

<property>
    <name>dfs.datanode.available-space-volume-choosing-policy.balanced-space-preference-fraction</name>
    <value>1.0f</value>
</property>

balance 源代码的研究 http://blog.csdn.net/tracymkgld/article/details/18358455

http://blog.csdn.net/xinganshenguang/article/details/55810047

另外 阿里云的 rebalance
https://yq.aliyun.com/articles/60406
https://yq.aliyun.com/articles/183113
https://yq.aliyun.com/articles/100912