嘉兴市住房和城乡建设局网站,wordpress nodejs版本,wordpress的密码算法,文化建设设计公司网站Hadoop集群Datanode数据倾斜，个别节点hdfs空间使用率达到95%以上，于是新增加了三个Datenode节点，由于任务还在跑，数据在不断增加中，这几个节点现有的200GB空间估计最多能撑20小时左右，所以必须要进行balance操作。
通过观察磁盘使用情况，发现balance的速度明显跟不上新…
Hadoop集群Datanode数据倾斜，个别节点hdfs空间使用率达到95%以上，于是新增加了三个Datenode节点，由于任务还在跑，数据在不断增加中，这几个节点现有的200GB空间估计最多能撑20小时左右，所以必须要进行balance操作。
通过观察磁盘使用情况，发现balance的速度明显跟不上新增数据的速度！！！
跟踪了一下balance的日志，发现两个问题：一是balance时原有的十几个节点都被列入了待balance的节点中，上面的数据分块移动到新增加的3个节点上，由于节点多，最迫切需要balance的几个节点轮到的机会很少；二是balance的速度太慢了，Hadoop集群为了防止balance影响吞吐、I/O性能，默认balance的速度为1MB，这样一共8TB的数据需要balance，这需要太长时间了。
于是针对上述问题，进行了如下尝试：
提高blance的速度，将默认的balance速度从1MB/s增大到50MB/s#set balance to 50M/s
[hdfs@sudops.com hadoop]$ hdfs dfsadmin -setBalancerBandwidth 52428800
Balancer bandwidth is set to 52428800 for nn01.sudops.com/10.233.100.161:9000
Balancer bandwidth is set to 52428800 for nn02.sudops.com/10.233.100.162:9000
调整balance的平衡比例：将原来的%5 提高到20%，调整原则就是尽量先让balance影响到最需要平衡数据的节点。
简单说明一下：原有集群的hdfs占用率为80%，新增加3个节点后，集群hdfs的整体占用量为70%, 如果比例是%5的话，那么原有节点都在这个调整范围内，所以各个节点都要被balance，而接受balance的节点只有三个，所以轮到迫切需要balance的节点的概率就比较小； 如果调整到20%，那么原来使用量小于90%的节点都不会被balance，那几台占用量90%以上的节点才会被最先balance，这样只有3个节点符合这个条件，balance的精确性就高了很多。
综合以上两点，balance的效果好多了，解决了最紧迫的节点的磁盘占满的问题，balance的速度终于快于新增数据，20%时需要balance的数据为6TB左右，待这次balance结束后，再运行一次%5的balance，还有2TB的数据要balance，这样经过两次的balance的操作，集群基本平衡了。 hdfs dfsadmin -setBalancerBandwidth 52428800nohup hdfs balancer -threshold 20 tail -F nohup.out
一、概述 hdfs 需要存写大量文件，有时磁盘会成为整个集群的性能瓶颈，所以需要优化 hdfs 存取速度，将数据目录配置多磁盘，既可以提高并发存取的速度，还可以解决一块磁盘空间不够的问题。 Hadoop 环境部署可以参考我之前的文章：大数据Hadoop之——Hadoop 3.3.4 HA（高可用）原理与实现（QJM）
二、Hadoop DataNode多目录磁盘配置
1）配置hdfs-site.xml
在配置文件中$HADOOP_HOME/etc/hadoop/hdfs-site.xml添加如下配置：
!-- dfs.namenode.name.dir是保存FsImage镜像的目录，作用是存放hadoop的名称节点namenode里的metadata--
propertynamedfs.namenode.name.dir/namevaluefile:/opt/bigdata/hadoop/hadoop-3.3.4/data/namenode/value
/property
!-- 存放HDFS文件系统数据文件的目录（存储Block），作用是存放hadoop的数据节点datanode里的多个数据块。 --
propertynamedfs.datanode.data.dir/namevalue/data1,/data2,/data3,/data4/value
/property!-- 设置数据存储策略，默认为轮询，现在的情况显然应该用“选择空间多的磁盘存”模式 --
propertynamedfs.datanode.fsdataset.volume.choosing.policy/namevalueorg.apache.hadoop.hdfs.server.datanode.fsdataset.AvailableSpaceVolumeChoosingPolicy/value
/property!-- 默认值0.75。它的含义是数据块存储到可用空间多的卷上的概率，由此可见，这个值如果取0.5以下，对该策略而言是毫无意义的，一般就采用默认值。--
propertynamedfs.datanode.available-space-volume-choosing-policy.balanced-space-preference-fraction/namevalue0.75f/value
/property!-- 配置各个磁盘的均衡阈值的，默认为10G（10737418240），在此节点的所有数据存储的目录中，找一个占用最大的，找一个占用最小的，如果在两者之差在10G的范围内，那么块分配的方式是轮询。 --
propertynamedfs.datanode.available-space-volume-choosing-policy.balanced-space-threshold/name value10737418240/value
/property【温馨提示】此处的dfs.namenode.name.dir和dfs.datanode.data.dir位置需要不一样，不能是一个文件夹，之前设置成一个文件夹报错ERROR org.apache.hadoop.hdfs.server.common.Storage: It appears that another node 1003@iZ2zeh8q22e14pvqr3bu01Z has already locked the storage directory: 【原因】是当namenode启动后，锁定了文件夹，导致datanode无法启动。 2）配置详解
1、 dfs.datanode.data.dir HDFS数据应该存储Block的地方。可以是逗号分隔的目录列表（典型的，每个目录在不同的磁盘）。这些目录被轮流使用，一个块存储在这个目录，下一个块存储在下一个目录，依次循环。每个块在同一个机器上仅存储一份。不存在的目录被忽略。必须创建文件夹，否则被视为不存在。 2、dfs.datanode.fsdataset.volume.cho
