关于Hadoop调优

Hadoop生产调优

一、HDFS—核心参数

1、NameNode 内存生产配置

1） NameNode 内存计算

每个文件块大概占用 150byte，一台服务器 128G 内存为例，能存储多少文件块呢？

128 * 1024 * 1024 * 1024 / 150Byte ≈ 9.1 亿

2） Hadoop2.x 系列，配置 NameNode 内存

​ NameNode 内存默认 2000m，如果服务器内存 4G，NameNode 内存可以配置 3g。在hadoop-env.sh 文件中配置如下。

HADOOP_NAMENODE_OPTS=-Xmx3072m

3） Hadoop3.x 系列，配置 NameNode 内存

（1）hadoop-env.sh 中描述 Hadoop 的内存是动态分配的

# The maximum amount of heap to use (Java -Xmx). If no unit
# is provided, it will be converted to MB. Daemons will
# prefer any Xmx setting in their respective _OPT variable.
# There is no default; the JVM will autoscale based upon machine
# memory size.
# export HADOOP_HEAPSIZE_MAX=
# 要使用的最大堆数量(Java -Xmx)。如果没有提供单位，它将被转换为MB。守护进程会更喜欢在它们各自的_OPT变量中设置任何Xmx。没有违约;JVM将根据机器内存大小自动伸缩。
# The minimum amount of heap to use (Java -Xms). If no unit
# is provided, it will be converted to MB. Daemons will
# prefer any Xms setting in their respective _OPT variable.
# There is no default; the JVM will autoscale based upon machine
# memory size.
# export HADOOP_HEAPSIZE_MIN=
# 要使用的最小堆数量(Java -Xms)。如果没有提供单位，它将被转换为MB。守护进程会更喜欢在它们各自的_OPT变量中设置任何Xms。没有违约;JVM将根据机器内存大小自动伸缩。

HADOOP_NAMENODE_OPTS=-Xmx102400m

（2）查看 NameNode 占用内存

[chaos@hadoop102 ~]$ jps 

3088 NodeManager
2611 NameNode
3271 JobHistoryServer
2744 DataNode
3579 Jps   

[chaos@hadoop102 ~]$ jmap -heap 2611 

Heap Configuration:
	MaxHeapSize = 1031798784 (984.0MB)

（3）查看 DataNode 占用内存

 [chaos@hadoop102 ~]$ jmap -heap 2744
 Heap Configuration:
 	MaxHeapSize = 1031798784 (984.0MB)

查看发现 hadoop102 上的 NameNode 和 DataNode 占用内存都是自动分配的，且相等。不是很合理。 经验参考：

Component	Memory	CPU	Disk
JournalNode 日志节点	1 GB (default)Set this value using the Java Heap Size of JournalNode in Bytes HDFS configuration property. 1 GB（默认）使用字节HDFS 配置属性中 JournalNode的Java 堆大小设置此值。	1 core minimum 最少 1 个核心	1 dedicated disk 1个专用磁盘
NameNode	Minimum: 1 GB (for proof-of-concept deployments) Add an additional 1 GB for each additional 1,000,000 blocksSnapshots and encryption can increase the required heap memory. See Sizing NameNode Heap Memory Set this value using the Java Heap Size of NameNode in Bytes HDFS configuration property.最低：1 GB（用于概念验证部署） 每增加 1,000,000 个block 增加 1 GB 快照和加密可以增加所需的堆内存。 请参阅调整 NameNode 堆内存大小 使用字节HDFS 配置属性中 NameNode的Java 堆大小设置此值。	Minimum of 4 dedicated cores; more may be required for larger clusters 最少 4 个专用内核；更大的集群可能需要更多	Minimum of 2 dedicated disks for metadata1 dedicated disk for log files (This disk may be shared with the operating system.)Maximum disks: 4 至少 2 个用于元数据的专用磁盘 1 个用于日志文件的专用磁盘（该磁盘可能与操作系统共享。） 最大磁盘数：4
DataNode	Minimum: 4 GBIncrease the memory for higher replica counts or a higher number of blocks per DataNode. When increasing the memory, Cloudera recommends an additional 1 GB of memory for every 1 million replicas above 4 million on the DataNodes. For example, 5 million replicas require 5 GB of memory.Set this value using the Java Heap Size of DataNode in Bytes HDFS configuration property. 最低：4 GB 增加内存以获得更高的副本计数或每个 DataNode 的更多块数。在增加内存时，Cloudera 建议为 DataNode 上 400 万个以上的每 100 万个副本增加 1 GB 内存。例如，500 万个副本需要 5 GB 内存。 使用字节HDFS 配置属性中 DataNode的Java 堆大小设置此值。	Minimum: 4 cores. Add more cores for highly active clusters. 最低：4 核。为高度活跃的集群添加更多核心。	Minimum: 4Maximum: 24The maximum acceptable size will vary depending upon how large average block size is. The DN’s scalability limits are mostly a function of the number of replicas per DN, not the overall number of bytes stored. That said, having ultra-dense DNs will affect recovery times in the event of machine or rack failure. Cloudera does not support exceeding 100 TB per data node. You could use 12 x 8 TB spindles or 24 x 4TB spindles. Cloudera does not support drives larger than 8 TB. 最少：4 最大：24 最大可接受大小将取决于平均块大小有多大。DN 的可扩展性限制主要取决于每个 DN 的副本数，而不是存储的总字节数。也就是说，如果机器或机架出现故障，拥有超密集 DN 将影响恢复时间。Cloudera 不支持每个数据节点超过 100 TB。您可以使用 12 x 8 TB 轴或 24 x 4TB 轴。Cloudera 不支持大于 8 TB 的驱动器。

具体修改：hadoop-env.sh

export HDFS_NAMENODE_OPTS="-Dhadoop.security.logger=INFO,RFAS - Xmx1024m"
export HDFS_DATANODE_OPTS="-Dhadoop.security.logger=ERROR,RFAS -Xmx1024m"

2、NameNode 心跳并发配置

hdfs-site.xml

The number of Namenode RPC server threads that listen to requests from clients. If dfs.namenode.servicerpc-address is not configured then Namenode RPC server threads listen to requests from all nodes.
NameNode有一个工作线程池，用来处理不同DataNode的并发心跳以及客户端并发的元数据操作。对于大集群或者有大量客户端的集群来说，通常需要增大该参数。默认值是10。
<property>
    <name>dfs.namenode.handler.count</name>
    <value>21</value>
</property>

企业经验

dfs.namenode.handler.count=20 × ^e

比如集群规模（DataNode 台 数）为 3 台时，此参数设置为 21。可通过简单的 python 代码计算该值，代码如下。

[chaos@hadoop102 ~]$ sudo yum install -y python
[chaos@hadoop102 ~]$ python
Python 2.7.5 (default, Apr 11 2018, 07:36:10)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import math
>>> print int(20*math.log(3))
21
>>> quit()

3、开启回收站配置

开启回收站功能，可以将删除的文件在不超时的情况下，恢复原数据，起到防止误删除、 备份等作用。

1）回收站工作机制

2）开启回收站功能参数说明

（1）默认值 fs.trash.interval = 0，0 表示禁用回收站；其他值表示设置文件的存活时间。

（2）默认值 fs.trash.checkpoint.interval = 0，检查回收站的间隔时间。如果该值为 0，则该值设置和 fs.trash.interval 的参数值相等。

（3）要求 fs.trash.checkpoint.interval <= fs.trash.interval。

3）启用回收站

修改 core-site.xml，配置垃圾回收时间为 1 分钟

<property>
    <name>fs.trash.interval</name>
    <value>1</value>
</property>

4）查看回收站

回收站目录在 HDFS 集群中的路径：/user/chaos/.Trash/….

5）注意

（1）通过网页上直接删除的文件也不会走回收站。

（2）通过程序删除的文件不会经过回收站，需要调用 moveToTrash()才进入回收站

Trash trash = New Trash(conf); trash.moveToTrash(path);

（3）只有在命令行利用 hadoop fs -rm 命令删除的文件才会走回收站。

[chaos@hadoop102 hadoop-3.1.3]$ hadoop fs -rm -r 

/user/chaos/input

2021-07-14 16:13:42,643 INFO fs.TrashPolicyDefault: Moved: 'hdfs://hadoop102:9820/user/chaos/input' to trash at: hdfs://hadoop102:9820/user/chaos/.Trash/Current/user/chaos /input

8）恢复回收站数据

[chaos@hadoop102 hadoop-3.1.3]$ hadoop fs -mv /user/chaos/.Trash/Current/user/chaos/input /user/chaos/input

二、HDFS—集群压测

在企业中非常关心每天从 Java 后台拉取过来的数据，需要多久能上传到集群？消费者关心多久能从 HDFS 上拉取需要的数据？

为了搞清楚 HDFS 的读写性能，生产环境上非常需要对集群进行压测

HDFS 的读写性能主要受网络和磁盘影响比较大。为了方便测试，将 hadoop102、 hadoop103、hadoop104 虚拟机网络都设置为 100mbps。

100Mbps 单位是 bit；10M/s 单位是 byte ; 1byte=8bit，100Mbps/8=12.5M/s。测试网速：来到 hadoop102 的/opt/module 目录，创建一个

[chaos@hadoop102 software]$ python -m SimpleHTTPServer

1、测试 HDFS 写性能

写测试底层原理：

1）测试内容：向 HDFS 集群写 10 个 128M 的文件

[chaos@hadoop102 mapreduce]$ hadoop jar /opt/module/hadoop3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-clientjobclient-3.1.3-tests.jar TestDFSIO -write -nrFiles 10 fileSize 128MB 

2021-02-09 10:43:16,853 INFO fs.TestDFSIO: ----- TestDFSIO ----- : write 

2021-02-09 10:43:16,854 INFO fs.TestDFSIO:       Date & time: Tue Feb 

09 10:43:16 CST 2021 

2021-02-09 10:43:16,854 INFO fs.TestDFSIO:     Number of files: 10 

2021-02-09 10:43:16,854 INFO fs.TestDFSIO: Total MBytes processed: 1280 

2021-02-09 10:43:16,854 INFO fs.TestDFSIO:    Throughput mb/sec: 1.61 

2021-02-09 10:43:16,854 INFO fs.TestDFSIO:  Average IO rate mb/sec: 1.9 

2021-02-09 10:43:16,854 INFO fs.TestDFSIO:  IO rate std deviation: 0.76 2021-02-09 10:43:16,854 INFO fs.TestDFSIO:   Test exec time sec: 133.05 2021-02-09 10:43:16,854 INFO fs.TestDFSIO:

注意：nrFiles n 为生成 mapTask 的数量，生产环境一般可通过 hadoop103:8088 查看 CPU 核数，设置为（CPU 核数 - 1）

Number of files：生成 mapTask 数量，一般是集群中（CPU 核数-1），我们测试虚拟机就按照实际的物理内存-1 分配即可

Total MBytes processed：单个 map 处理的文件大小

Throughput mb/sec:单个 mapTak 的吞吐量

计算方式：处理的总文件大小/每一个 mapTask 写数据的时间累加集群整体吞吐量：生成 mapTask 数量*单个 mapTak 的吞吐量

Average IO rate mb/sec::平均 mapTak 的吞吐量

计算方式：每个 mapTask 处理文件大小/每一个 mapTask 写数据的时间

全部相加除以 task 数量

IO rate std deviation:方差、反映各个 mapTask 处理的差值，越小越均衡

2）注意：如果测试过程中，出现异常

（1）可以在 yarn-site.xml 中设置虚拟内存检测为 false

<!--是否启动一个线程检查每个任务正使用的虚拟内存量，如果任务超出分配值，则直接将其杀掉，默认是true --> 

<property>

   <name>yarn.nodemanager.vmem-check-enabled</name> 

   <value>false</value>

</property>

（2）分发配置并重启 Yarn 集群

3）测试结果分析

（1）由于副本 1 就在本地，所以该副本不参与测试

一共参与测试的文件：10 个文件 * 2 个副本 = 20 个压测后的速度：1.61

实测速度：1.61M/s * 20 个文件 ≈ 32M/s 三台服务器的带宽：12.5 + 12.5 + 12.5 ≈ 30m/s

所有网络资源都已经用满。

如果实测速度远远小于网络，并且实测速度不能满足工作需求，可以考虑采用固态硬盘或者增加磁盘个数。

（2）如果客户端不在集群节点，那就三个副本都参与计算

2、测试 HDFS 读性能

1）测试内容：读取 HDFS 集群 10 个 128M 的文件

[chaos@hadoop102 mapreduce]$ hadoop jar /opt/module/hadoop-

3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-clientjobclient-3.1.3-tests.jar TestDFSIO -read -nrFiles 10 -fileSize 

128MB

2021-02-09 11:34:15,847 INFO fs.TestDFSIO: ----- TestDFSIO ----- : read 

2021-02-09 11:34:15,847 INFO fs.TestDFSIO:       Date & time: Tue Feb 

09 11:34:15 CST 2021 

2021-02-09 11:34:15,847 INFO fs.TestDFSIO:     Number of files: 10 

2021-02-09 11:34:15,847 INFO fs.TestDFSIO: Total MBytes processed: 1280 

2021-02-09 11:34:15,848 INFO fs.TestDFSIO:    Throughput mb/sec: 200.28 

2021-02-09 11:34:15,848 INFO fs.TestDFSIO: Average IO rate mb/sec: 266.74 

2021-02-09 11:34:15,848 INFO fs.TestDFSIO:  IO rate std deviation: 143.12 

2021-02-09 11:34:15,848 INFO fs.TestDFSIO:   Test exec time sec: 20.83

2）删除测试生成数据

[chaos@hadoop102 mapreduce]$ hadoop jar /opt/module/hadoop3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-clientjobclient-3.1.3-tests.jar TestDFSIO -clean

测试结果分析：为什么读取文件速度大于网络带宽？由于目前只有三台服务器，且有三个副本，数据读取就近原则，相当于都是读取的本地磁盘数据，没有走网络。

3、HDFS—多目录

NameNode 多目录配置

1）NameNode 的本地目录可以配置成多个，且每个目录存放内容相同，增加了可靠性

2）具体配置如下

在 hdfs-site.xml 文件中添加如下内容

<property>
   <name>dfs.namenode.name.dir</name>
   <value>file://${hadoop.tmp.dir}/dfs/name1,file://${hadoop.tmp. dir}/dfs/name2</value>
</property>

注意：因为每台服务器节点的磁盘情况不同，所以这个配置配完之后，可以选择不分发（2）停止集群，删除三台节点的 data 和 logs 中所有数据。

[chaos@hadoop102 hadoop-3.1.3]$ rm -rf data/ logs/ 

[chaos@hadoop103 hadoop-3.1.3]$ rm -rf data/ logs/ 

[chaos@hadoop104 hadoop-3.1.3]$ rm -rf data/ logs/

（3）格式化集群并启动。

[chaos@hadoop102 hadoop-3.1.3]$ bin/hdfs namenode -format 

[chaos@hadoop102 hadoop-3.1.3]$ sbin/start-dfs.sh

3）查看结果

 [chaos@hadoop102  dfs]$ ll 

总用量 12
drwx------.  3 chaos chaos 4096 12月 11  08:03 data
drwxrwxr-x. 3 chaos chaos 4096 12月 11 08:03 name1
drwxrwxr-x. 3 chaos chaos 4096 12月 11 08:03 name2

检查 name1 和 name2 里面的内容，发现一模一样

DataNode 多目录配置

1）DataNode 可以配置成多个目录，每个目录存储的数据不一样（数据不是副本）

2）具体配置如下

在 hdfs-site.xml 文件中添加如下内容

<property>
    <name>dfs.datanode.data.dir</name>
	<value>file://${hadoop.tmp.dir}/dfs/data1,file://${hadoop.tmp.dir}/dfs/data2</value>
</property>

3）查看结果

[chaos@hadoop102 dfs]$ ll
总用量 12
drwx------.  3 chaos chaos 4096 4月  4 14:22 data1
drwx------. 3 chaos chaos 4096 4月  4 14:22 data2
drwxrwxr-x. 3 chaos chaos 4096 12月  11 08:03 name1
drwxrwxr-x. 3 chaos chaos 4096 12月 11 08:03  name2

4）向集群上传一个文件，再次观察两个文件夹里面的内容发现不一致（一个有数一个没有）

[chaos@hadoop102 hadoop-3.1.3]$ hadoop fs -put wcinput/word.txt /

三、 集群数据均衡之磁盘间数据均衡

生产环境，由于硬盘空间不足，往往需要增加一块硬盘。刚加载的硬盘没有数据时，可以执行磁盘数据均衡命令。（Hadoop3.x 新特性）

1、生成均衡计划

（如果只有一块磁盘，不会生成计划）

hdfs diskbalancer -plan hadoop103

2、执行均衡计划

hdfs diskbalancer -execute hadoop103.plan.json

3、查看当前均衡任务的执行情况

hdfs diskbalancer -query hadoop103

4、取消均衡任务

hdfs diskbalancer -cancel hadoop103.plan.json

四、 HDFS—集群扩容及缩容

1、添加白名单

白名单：表示在白名单的主机 IP 地址可以，用来存储数据。

企业中：配置白名单，可以尽量防止黑客恶意访问攻击。

配置白名单步骤如下：

1）在 NameNode 节点的/opt/module/hadoop-3.1.3/etc/hadoop 目录下分别创建 whitelist 和 blacklist 文件

（1）创建白名单

[chaos@hadoop102 hadoop]$ vim whitelist

在 whitelist 中添加如下主机名称，假如集群正常工作的节点为 102 103

hadoop102 hadoop103

（2）创建黑名单

[chaos@hadoop102 hadoop]$ touch blacklist

保持空的就可以

2）在 hdfs-site.xml 配置文件中增加 dfs.hosts 配置参数

<!-- 白名单 --> 

<property>

   <name>dfs.hosts</name> 

   <value>/opt/module/hadoop-3.1.3/etc/hadoop/whitelist</value>

</property>

<!-- 黑名单 --> 

<property>

   <name>dfs.hosts.exclude</name>

   <value>/opt/module/hadoop-3.1.3/etc/hadoop/blacklist</value>

</property>

3）分发配置文件 whitelist，hdfs-site.xml

[chaos@hadoop104 hadoop]$ xsync hdfs-site.xml whitelist

4）第一次添加白名单必须重启集群，不是第一次，只需要刷新 NameNode 节点即可

[chaos@hadoop102 hadoop-3.1.3]$ myhadoop.sh stop
[chaos@hadoop102 hadoop-3.1.3]$ myhadoop.sh start

5）在 web 浏览器上查看 DN，http://hadoop102:9870/dfshealth.html#tab-datanode

6）在 hadoop104 上执行上传数据数据失败

[chaos@hadoop104 hadoop-3.1.3]$ hadoop fs -put NOTICE.txt /

7）二次修改白名单，增加 hadoop104

[chaos@hadoop102 hadoop]$ vim whitelist
修改为如下内容
hadoop102
hadoop103
hadoop104

8）刷新 NameNode

[chaos@hadoop102 hadoop-3.1.3]$ hdfs dfsadmin -refreshNodes
Refresh nodes successful

9）在 web 浏览器上查看 DN，http://hadoop102:9870/dfshealth.html#tab-datanode

2、服役新服务器

1）需求

随着公司业务的增长，数据量越来越大，原有的数据节点的容量已经不能满足存储数据的需求，需要在原有集群基础上动态添加新的数据节点。

2）环境准备

（1）在 hadoop100 主机上再克隆一台 hadoop105 主机

（2）修改 IP 地址和主机名称

[root@hadoop105 ~]# vim /etc/sysconfig/network-scripts/ifcfgens33 

[root@hadoop105 ~]# vim /etc/hostname

（3）拷贝 hadoop102 的/opt/module 目录和/etc/profile.d/my_env.sh 到 hadoop105

[chaos@hadoop102   opt]$ scp -r module/* chaos@hadoop105:/opt/module/
[chaos@hadoop102 opt]$ sudo scp /etc/profile.d/my_env.sh root@hadoop105:/etc/profile.d/my_env.sh
[chaos@hadoop105 hadoop-3.1.3]$ source /etc/profile

（4）删除 hadoop105 上 Hadoop 的历史数据，data 和 log 数据

[chaos@hadoop105 hadoop-3.1.3]$ rm -rf data/ logs/

（5）配置 hadoop102 和 hadoop103 到 hadoop105 的 ssh 无密登录

[chaos@hadoop102 .ssh]$ ssh-copy-id hadoop105
[chaos@hadoop103 .ssh]$ ssh-copy-id hadoop105

3）服役新节点具体步骤

直接启动 DataNode，即可关联到集群

[chaos@hadoop105 hadoop-3.1.3]$ hdfs --daemon start datanode
[chaos@hadoop105 hadoop-3.1.3]$ yarn --daemon start nodemanager

4）在白名单中增加新服役的服务器

（1）在白名单 whitelist 中增加 hadoop104、hadoop105，并重启集群

[chaos@hadoop102 hadoop]$ vim  whitelist   

hadoop102
hadoop103
hadoop104
hadoop105

（2）分发

[chaos@hadoop102 hadoop]$ xsync whitelist

（3）刷新 NameNode

[chaos@hadoop102 hadoop-3.1.3]$ hdfs dfsadmin -refreshNodes Refresh nodes successful

5）在 hadoop105 上上传文件

[chaos@hadoop105 hadoop-3.1.3]$ hadoop fs -put /opt/module/hadoop-3.1.3/LICENSE.txt /

3、服务器间数据均衡

1）企业经验

在企业开发中，如果经常在 hadoop102 和 hadoop104 上提交任务，且副本数为 2，由于数据本地性原则，就会导致 hadoop102 和 hadoop104 数据过多，hadoop103 存储的数据量小。

另一种情况，就是新服役的服务器数据量比较少，需要执行集群均衡命令。

2）开启数据均衡命令：

[chaos@hadoop105 hadoop-3.1.3]$ sbin/start-balancer.sh -
threshold 10

对于参数 10，代表的是集群中各个节点的磁盘空间利用率相差不超过 10%，可根据实际情况进行调整。

3）停止数据均衡命令：

[chaos@hadoop105 hadoop-3.1.3]$ sbin/stop-balancer.sh

注意：由于 HDFS 需要启动单独的 Rebalance Server 来执行 Rebalance 操作，所以尽量不要在 NameNode 上执行 start-balancer.sh，而是找一台比较空闲的机器。

4、黑名单退役服务器

黑名单：表示在黑名单的主机 IP 地址不可以，用来存储数据。

企业中：配置黑名单，用来退役服务器。

1）编辑/opt/module/hadoop-3.1.3/etc/hadoop 目录下的 blacklist 文件

[chaos@hadoop102 hadoop] vim blacklist 

添加如下主机名称（要退役的节点） 

hadoop105

注意：如果白名单中没有配置，需要在 hdfs-site.xml 配置文件中增加 dfs.hosts 配置参数

<!-- 黑名单 --> 

<property>

   <name>dfs.hosts.exclude</name>

   <value>/opt/module/hadoop-3.1.3/etc/hadoop/blacklist</value>

</property>

2）分发配置文件 blacklist，hdfs-site.xml

[chaos@hadoop104 hadoop]$ xsync hdfs-site.xml blacklist

3）第一次添加黑名单必须重启集群，不是第一次，只需要刷新 NameNode 节点即可

[chaos@hadoop102 hadoop-3.1.3]$ hdfs dfsadmin -refreshNodes Refresh nodes successful

4）检查 Web 浏览器，退役节点的状态为 decommission in progress（退役中），说明数据节点正在复制块到其他节点

5）等待退役节点状态为 decommissioned（所有块已经复制完成），停止该节点及节点资源管理器。注意：如果副本数是 3，服役的节点小于等于 3，是不能退役成功的，需要修改副本数后才能退役

[chaos@hadoop105 hadoop-3.1.3]$ hdfs --daemon stop datanode 

stopping datanode

[chaos@hadoop105 hadoop-3.1.3]$ yarn --daemon stop nodemanager

stopping nodemanager

6）如果数据不均衡，可以用命令实现集群的再平衡

[chaos@hadoop102 hadoop-3.1.3]$ sbin/start-balancer.sh -threshold 10

五、HDFS—存储优化

1、纠删码

纠删码原理 HDFS 默认情况下，一个文件有 3 个副本，这样提高了数据的可靠性，但也带来了 2 倍 的冗余开销。Hadoop3.x 引入了纠删码，采用计算的方式，可以节省约 50％左右的存储空间。

1）纠删码操作相关的命令

[chaos@hadoop102 hadoop-3.1.3]$ hdfs ec
Usage: bin/hdfs ec [COMMAND]
 [-listPolicies]
 [-addPolicies -policyFile <file>]
 [-getPolicy -path <path>]
 [-removePolicy -policy <policy>]
 [-setPolicy -path <path> [-policy <policy>] [-replicate]]
 [-unsetPolicy -path <path>]
 [-listCodecs]
 [-enablePolicy -policy <policy>]
 [-disablePolicy -policy <policy>]
 [-help <command-name>].

2）查看当前支持的纠删码策略

[chaos@hadoop102 hadoop-3.1.3] hdfs ec -listPolicies 

Erasure Coding Policies:
ErasureCodingPolicy=[Name=RS-10-4-1024k, Schema=[ECSchema=[Codec=rs, numDataUnits=10, numParityUnits=4]], CellSize=1048576, Id=5], State=DISABLED

ErasureCodingPolicy=[Name=RS-3-2-1024k, Schema=[ECSchema=[Codec=rs, numDataUnits=3, numParityUnits=2]], CellSize=1048576, Id=2],
State=DISABLED

ErasureCodingPolicy=[Name=RS-6-3-1024k, Schema=[ECSchema=[Codec=rs, numDataUnits=6, numParityUnits=3]], CellSize=1048576, Id=1],
State=**ENABLED** 

ErasureCodingPolicy=[Name=RS-LEGACY-6-3-1024k,
Schema=[ECSchema=[Codec=rs-legacy, numDataUnits=6, numParityUnits=3]], 

CellSize=1048576, Id=3], State=DISABLED 

ErasureCodingPolicy=[Name=XOR-2-1-1024k, Schema=[ECSchema=[Codec=xor, numDataUnits=2, numParityUnits=1]], CellSize=1048576, Id=4], State=DISABLED

3）纠删码策略解释:

RS-3-2-1024k：使用 RS 编码，每 3 个数据单元，生成 2 个校验单元，共 5 个单元，也就是说：这 5 个单元中，只要有任意的 3 个单元存在（不管是数据单元还是校验单元，只要总数=3），就可以得到原始数据。每个单元的大小是 1024k=1024*1024=1048576。

RS-10-4-1024k：使用 RS 编码，每 10 个数据单元（cell），生成 4 个校验单元，共 14个单元，也就是说：这 14 个单元中，只要有任意的 10 个单元存在（不管是数据单元还是校验单元，只要总数=10），就可以得到原始数据。每个单元的大小是 1024k=1024*1024=1048576。

RS-6-3-1024k：使用 RS 编码，每 6 个数据单元，生成 3 个校验单元，共 9 个单元，也就是说：这 9 个单元中，只要有任意的 6 个单元存在（不管是数据单元还是校验单元，只要总数=6），就可以得到原始数据。每个单元的大小是 1024k=1024*1024=1048576。

RS-LEGACY-6-3-1024k：策略和上面的 RS-6-3-1024k 一样，只是编码的算法用的是 rslegacy。

XOR-2-1-1024k：使用 XOR 编码（速度比 RS 编码快），每 2 个数据单元，生成 1 个校验单元，共 3 个单元，也就是说：这 3 个单元中，只要有任意的 2 个单元存在（不管是数据单元还是校验单元，只要总数= 2），就可以得到原始数据。每个单元的大小是1024k=1024*1024=1048576。

4）纠删码案例实操

纠删码策略是给具体一个路径设置。所有往此路径下存储的文件，都会执行此策略。默认只开启对 RS-6-3-1024k 策略的支持，如要使用别的策略需要提前启用。

1）需求：将/input 目录设置为 RS-3-2-1024k 策略

2）具体步骤

（1）开启对 RS-3-2-1024k 策略的支持

[chaos@hadoop102 hadoop-3.1.3]$ hdfs ec -enablePolicy -policy RS-3-2-1024k
Erasure coding policy RS-3-2-1024k is enabled

（2）在 HDFS 创建目录，并设置 RS-3-2-1024k 策略

[chaos@hadoop102 hadoop-3.1.3]$ hdfs dfs -mkdir /input
[chaos@hadoop202 hadoop-3.1.3]$ hdfs ec -setPolicy -path /input -policy RS-3-2-1024k

（3）上传文件，并查看文件编码后的存储情况

[chaos@hadoop102 hadoop-3.1.3]$ hdfs dfs -put web.log /input

注：你所上传的文件需要大于 2M 才能看出效果。（低于 2M，只有一个数据单元和两个校验单元）

（4）查看存储路径的数据单元和校验单元，并作破坏实验

2、异构存储（冷热数据分离）

异构存储主要解决，不同的数据，存储在不同类型的硬盘中，达到最佳性能的问题。

1）关于存储类型

RAM_DISK：（内存镜像文件系统）

SSD：（SSD固态硬盘）

DISK：（普通磁盘，在HDFS中，如果没有主动声明数据目录存储类型默认都是DISK）

ARCHIVE：（没有特指哪种存储介质，主要的指的是计算能力比较弱而存储密度比较高的存储介质，用来解决数据量的容量扩增的问题，一般用于归档）

2）关于存储策略

说明：从Lazy_Persist到Cold，分别代表了设备的访问速度从快到慢

策略ID	策略名称	副本分布	策略
15	Lazy_Persist	RAM_DISK:1，DISK:n-1	一个副本保存在内存RAM_DISK中，其余副本保存在磁盘中。
12	All_SSD	SSD:n	所有副本都保存在SSD中。
10	One_SSD	SSD:1，DISK:n-1	一个副本保存在SSD中，其余副本保存在磁盘中。
7	Hot(default)	DISK:n	Hot：所有副本保存在磁盘中，这也是默认的存储策略。
5	Warm	DSIK:1，ARCHIVE:n-1	一个副本保存在磁盘上，其余副本保存在归档存储上。
2	Cold	ARCHIVE:n	所有副本都保存在归档存储上。

3）异构存储 Shell 操作

（1） 查看当前有哪些存储策略可以用

[chaos@hadoop102 hadoop-3.1.3]$ hdfs storagepolicies listPolicies

（2） 为指定路径（数据存储目录）设置指定的存储策略

hdfs storagepolicies -setStoragePolicy -path xxx -policy xxx

（3） 获取指定路径（数据存储目录或文件）的存储策略

hdfs storagepolicies -getStoragePolicy -path xxx

（4） 取消存储策略；执行改命令之后该目录或者文件，以其上级的目录为准，如果是根目录，那么就是 HOT

hdfs storagepolicies -unsetStoragePolicy -path xxx

（5） 查看文件块的分布

bin/hdfs fsck xxx -files -blocks -locations

（6） 查看集群节点

hadoop dfsadmin -report

六、HDFS—故障排除

1、NameNode 故障处理

1）需求：

NameNode 进程挂了并且存储的数据也丢失了，如何恢复 NameNode

2）故障模拟

（1）kill -9 NameNode 进程

[chaos@hadoop102 current]$ kill -9 19886

（2）删除 NameNode 存储的数据（/opt/module/hadoop-3.1.3/data/tmp/dfs/name）

[chaos@hadoop102 hadoop-3.1.3]$ rm -rf /opt/module/hadoop-1.3/data/dfs/name/*

3）问题解决

（1）拷贝 SecondaryNameNode 中数据到原 NameNode 存储数据目录

[chaos@hadoop102 dfs]$ scp -r chaos@hadoop104:/opt/module/hadoop-3.1.3/data/dfs/namesecondary/* ./name/

（2）重新启动 NameNode

[chaos@hadoop102 hadoop-3.1.3]$ hdfs --daemon start namenode

（3）向集群上传一个文件

2、集群安全模式&磁盘修复

1）安全模式

文件系统只接受读数据请求，而不接受删除、修改等变更请求

2）进入安全模式场景

NameNode 在加载镜像文件和编辑日志期间处于安全模式；

NameNode 再接收 DataNode 注册时，处于安全模式

3）退出安全模式条件

dfs.namenode.safemode.min.datanodes:最小可用 datanode 数量，默认 0

dfs.namenode.safemode.threshold-pct:副本数达到最小要求的 block 占系统总 block 数的百分比，默认 0.999f。（只允许丢一个块）

dfs.namenode.safemode.extension:稳定时间，默认值 30000 毫秒，即 30 秒

4）基本语法

集群处于安全模式，不能执行重要操作（写操作）。集群启动完成后，自动退出安全模式。

（1）bin/hdfs dfsadmin -safemode get （功能描述：查看安全模式状态）

（2）bin/hdfs dfsadmin -safemode enter （功能描述：进入安全模式状态）

（3）bin/hdfs dfsadmin -safemode leave（功能描述：离开安全模式状态）

（4）bin/hdfs dfsadmin -safemode wait （功能描述：等待安全模式状态）

3、慢磁盘监控

“慢磁盘”指的时写入数据非常慢的一类磁盘。其实慢性磁盘并不少见，当机器运行时间长了，上面跑的任务多了，磁盘的读写性能自然会退化，严重时就会出现写入数据延时的问题。

如何发现慢磁盘？正常在 HDFS 上创建一个目录，只需要不到 1s 的时间。如果你发现创建目录超过 1 分钟及以上，而且这个现象并不是每次都有。只是偶尔慢了一下，就很有可能存在慢磁盘。

可以采用如下方法找出是哪块磁盘慢：

1）通过心跳未联系时间

一般出现慢磁盘现象，会影响到 DataNode 与 NameNode 之间的心跳。正常情况心跳时间间隔是 3s。超过 3s 说明有异常。

2）fio 命令，测试磁盘的读写性能

（1）顺序读测试

[chaos@hadoop102 ~]# sudo yum install -y fio
[chaos@hadoop102 ~]# sudo fio -
filename=/home/chaos/test.log -direct=1 -iodepth 1 -thread -
rw=read -ioengine=psync -bs=16k -size=2G -numjobs=10 -
runtime=60 -group_reporting -name=test_r
Run status group 0 (all jobs):
 READ: bw=360MiB/s (378MB/s), 360MiB/s-360MiB/s (378MB/s-378MB/s),
io=20.0GiB (21.5GB), run=56885-56885msec

结果显示，磁盘的总体顺序读速度为 360MiB/s。

（2）顺序写测试

[chaos@hadoop102 ~]# sudo fio -
filename=/home/chaos/test.log -direct=1 -iodepth 1 -thread -
rw=write -ioengine=psync -bs=16k -size=2G -numjobs=10 -
runtime=60 -group_reporting -name=test_w
Run status group 0 (all jobs):
 WRITE: bw=341MiB/s (357MB/s), 341MiB/s-341MiB/s (357MB/s357MB/s), io=19.0GiB (21.4GB), run=60001-60001msec

结果显示，磁盘的总体顺序写速度为 341MiB/s。

（3）随机写测试

[chaos@hadoop102 ~]# sudo fio -filename=/home/chaos/test.log -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_randw

Run status group 0 (all jobs):
 WRITE: bw=309MiB/s (324MB/s), 309MiB/s-309MiB/s (324MB/s-324MB/s),
io=18.1GiB (19.4GB), run=60001-60001msec

结果显示，磁盘的总体随机写速度为 309MiB/s。

（4）混合随机读写：

[chaos@hadoop102 ~]# sudo fio -filename=/home/chaos/test.log -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_r_w -ioscheduler=noop

Run status group 0 (all jobs):
 READ: bw=220MiB/s (231MB/s), 220MiB/s-220MiB/s (231MB/s231MB/s), io=12.9GiB (13.9GB), run=60001-60001msec
WRITE: bw=94.6MiB/s (99.2MB/s), 94.6MiB/s-94.6MiB/s
(99.2MB/s-99.2MB/s), io=5674MiB (5950MB), run=60001-60001msec

结果显示，磁盘的总体混合随机读写，读速度为 220MiB/s，写速度 94.6MiB/s。

4、小文件归档

1）HDFS 存储小文件弊端

每个文件均按块存储，每个块的元数据存储在 NameNode 的内存中，因此 HDFS 存储小文件会非常低效。因为大量的小文件会耗尽 NameNode 中的大部分内存。但注意，存储小 文件所需要的磁盘容量和数据块的大小无关。例如，一个 1MB 的文件设置为 128MB 的块 存储，实际使用的是 1MB 的磁盘空间，而不是 128MB。

2）解决存储小文件办法之一

HDFS 存档文件或 HAR 文件，是一个更高效的文件存档工具，它将文件存入 HDFS 块， 在减少 NameNode 内存使用的同时，允许对文件进行透明的访问。具体说来，HDFS 存档文 件对内还是一个一个独立文件，对 NameNode 而言却是一个整体，减少了 NameNode 的内存。

3）案例实操

（1）需要启动 YARN 进程

[chaos@hadoop102 hadoop-3.1.3]$ start-yarn.sh

（2）归档文件

把/input 目录里面的所有文件归档成一个叫 input.har 的归档文件，并把归档后文件存储

到/output 路径下。

[chaos@hadoop102 hadoop-3.1.3]$ hadoop archive -archiveName input.har -p /input /output

（3）查看归档

[chaos@hadoop102 hadoop-3.1.3]$ hadoop fs -ls /output/input.har
[chaos@hadoop102 hadoop-3.1.3]$ hadoop fs -ls har:///output/input.har

（4）解归档文件

[chaos@hadoop102 hadoop-3.1.3]$ hadoop fs -cp har:///output/input.har/* /