第5章、HDFS_存储优化

注：演示纠删码和异构存储需要一共 5 台虚拟机。尽量拿另外一套集群。提前准备 5 台服务器的集群。
自行配置一台服务器，启动后查看是否工作

5.1 纠删码

5.1.1 纠删码原理

HDFS 默认情况下，一个文件有 3 个副本，这样提高了数据的可靠性，但也带来了 2 倍的冗余开销。Hadoop3.x 引入了纠删码，采用计算的方式，可以节省约 50％左右的存储空间。
该方式损耗的是计算性能，占用CPU的时间会比较长，这个设置需要根据实际情况修改，如果CPU计算资源充足，可通过该方式代替存储空间的不足

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

[pcz@hadoop1 ~]$ 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）查看当前支持的纠删码策略

[pcz@hadoop1 ~]$ 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 一样，只是编码的算法用的是 rs-legacy。

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

5.1.2 纠删码案例实操

纠删码策略是给具体一个路径设置。所有往此路径下存储的文件，都会执行此策略。默认只开启对 RS-6-3-1024k 策略的支持，如要使用别的策略需要提前启用。
1）需求：将/input 目录设置为 RS-3-2-1024k 策略
2）具体步骤
（1）开启对 RS-3-2-1024k 策略的支持

[pcz@hadoop1 ~]$ hdfs ec -enablePolicy -policy RS-3-2-1024k
Erasure coding policy RS-3-2-1024k is enabled

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

[pcz@hadoop1 ~]$ hadoop fs -mkdir /input
[pcz@hadoop1 ~]$ hdfs ec -setPolicy -path /input -policy RS-3-2-1024k
Set RS-3-2-1024k erasure coding policy on /input

（3）上传文件，并查看文件编码后的存储情况、注：你所上传的文件需要大于 2M 才能看出效果。（低于 2M，只有一个数据单元和两个校验单元）

[pcz@hadoop1 software]$  hadoop fs -put spark-3.0.2-bin-hadoop3.2.gz  /input

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

[pcz@hadoop1 ~]$ cd /opt/module/hadoop-3.1.3/data/dfs/data1/current/BP-1792716619-192.168.150.211-1641814536369/current/finalized/subdir0/subdir0/
[pcz@hadoop1 subdir0]$ vim blk_-9223372036854775792

如果是这种状态，那么就说明是存储的数据单元

如果是下面这种状态，说明存储的是校验单元

乱码的原因是需要特殊的编译器打开
经过验证发现：
hadoop1、hadoop4、hadoop5是数据单元，hadoop2、hadoop3是校验单元。
通过破坏实验发现：
当删除一个数据单元和一个校验单元中的block时，数据会逐渐自动恢复且上传到HDFS上的数据仍然可以下载。
当删除三个节点上的数据时，数据将无法自动恢复。
在指定目录（/input）设置了纠删策略（RS-3-2-1024k），则只有上传到该目录的文件执行此策略，其他目录依旧按照指定默认策略(RS-6-3-1024k)存储

5.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_DSIK中，其余副本保存在磁盘中
12	All_SSD	SSD:n	所有副本保存在SSD中
10	One_SSD	SSD:1,DSIK:n-1	一个副本保存在SSD中，其余副本保存在磁盘中
7	Hot(default)	DISK:n	Hot：所有副本保存在磁盘，这也是默认的存储策略
5	Warm	DISK:1,ARCHIVE:n-1	一个副本保存在磁盘上，其余副本保存在归档储存上
2	Cold	ARCHIVE:n	所有副本都保存在归档存储上

5.2.1 异构存储 Shell 操作

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

[pcz@hadoop1 ~]$ 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

5.2.2 测试环境准备

1）测试环境描述
服务器规模：5 台
集群配置：副本数为 2，创建好带有存储类型的目录（提前创建）
集群规划：

节点	储存类型分配
hadoop1	RAM_DISK,SSD
hadoop2	SSD,DISK
hadoop3	DISK,RAM_DISK
hadoop4	ARCHIVE
hadoop5	ARCHIVE

2）配置文件信息
注意：

• 需删除原来已有重复的配置信息，比如<name>dfs.datanode.data.dir</name>
• 删除hadoop集群各节点的data和logs目录

[pcz@hadoop5 ~]$ rm -rf /opt/module/hadoop-3.1.3/data/ /opt/module/hadoop-3.1.3/logs/
[pcz@hadoop4 ~]$ rm -rf /opt/module/hadoop-3.1.3/data/ /opt/module/hadoop-3.1.3/logs/
[pcz@hadoop3 ~]$ rm -rf /opt/module/hadoop-3.1.3/data/ /opt/module/hadoop-3.1.3/logs/
[pcz@hadoop2 ~]$ rm -rf /opt/module/hadoop-3.1.3/data/ /opt/module/hadoop-3.1.3/logs/
[pcz@hadoop1 hadoop]$ rm -rf /opt/module/hadoop-3.1.3/data/ /opt/module/hadoop-3.1.3/logs/

（1）为 hadoop1 节点的 hdfs-site.xml 添加如下信息

<property>
<name>dfs.replication</name>
<value>2</value>
</property>
<property>
<name>dfs.storage.policy.enabled</name>
<value>true</value>
</property>
<property>
<name>dfs.datanode.data.dir</name> 
<value>[SSD]file:///opt/module/hadoop-3.1.3/hdfsdata/ssd,[RAM_DISK]file:///opt/module/hadoop-3.1.3/hdfsdata/ram_disk</value>
</property>

（2）为 hadoop2 节点的 hdfs-site.xml 添加如下信息

<property>
<name>dfs.replication</name>
<value>2</value>
</property>
<property>
<name>dfs.storage.policy.enabled</name>
<value>true</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>[SSD]file:///opt/module/hadoop-3.1.3/hdfsdata/ssd,[DISK]file:///opt/module/hadoop-3.1.3/hdfsdata/disk</value>
</property>

（3）为 hadoop3 节点的 hdfs-site.xml 添加如下信息

<property>
<name>dfs.replication</name>
<value>2</value>
</property>
<property>
<name>dfs.storage.policy.enabled</name>
<value>true</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>[RAM_DISK]file:///opt/module/hdfsdata/ram_disk,[DISK]file:///opt/module/hadoop-3.1.3/hdfsdata/disk</value>
</property>

（4）为 hadoop4 节点的 hdfs-site.xml 添加如下信息

<property>
<name>dfs.replication</name>
<value>2</value>
</property>
<property>
<name>dfs.storage.policy.enabled</name>
<value>true</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>[ARCHIVE]file:///opt/module/hadoop-3.1.3/hdfsdata/archive</value>
</property>

（5）为 hadoop5 节点的 hdfs-site.xml 添加如下信息

<property>
<name>dfs.replication</name>
<value>2</value>
</property>
<property>
<name>dfs.storage.policy.enabled</name>
<value>true</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>[ARCHIVE]file:///opt/module/hadoop3.1.3/hdfsdata/archive</value>
</property>

3）数据准备
（1）启动集群并在 HDFS 上创建文件目录

[pcz@hadoop1 ~]$ hdfs namenode -format
[pcz@hadoop1 ~]$ pczhd start
[pcz@hadoop1 ~]$ hadoop fs -mkdir /hdfsdata

（2）并将文件资料上传

[pcz@hadoop1 ~]$ cd /opt/module/hadoop-3.1.3/
[pcz@hadoop1 hadoop-3.1.3]$ hadoop fs -put NOTICE.txt /hdfsdata

5.2.3 HOT存储策略实例

（1）最开始我们未设置存储策略的情况下，我们获取该目录的存储策略

[pcz@hadoop1 hadoop-3.1.3]$ hdfs storagepolicies -getStoragePolicy -path /hdfsdata
The storage policy of /hdfsdata is unspecified

（2）我们查看上传的文件块分布

[pcz@hadoop1 hadoop-3.1.3]$ hdfs fsck /hdfsdata -files -blocks -locations
Connecting to namenode via http://hadoop1:9870/fsck?ugi=pcz&files=1&blocks=1&locations=1&path=%2Fhdfsdata
FSCK started by pcz (auth:SIMPLE) from /192.168.150.211 for path /hdfsdata at Thu Jan 13 13:19:55 CST 2022
/hdfsdata <dir>
/hdfsdata/NOTICE.txt 21867 bytes, replicated: replication=2, 1 block(s):  OK
0. BP-1485681155-192.168.150.211-1642050375276:blk_1073741825_1001 len=21867 Live_repl=2  [DatanodeInfoWithStorage[192.168.150.212:9866,DS-d89c782e-c4b7-4dca-af5b-016b3b6a7f26,DISK], DatanodeInfoWithStorage[192.168.150.213:9866,DS-b3c86b18-2af0-4a0e-a33a-cc0362308126,DISK]]


Status: HEALTHY

未设置存储策略，所有文件块都存储在DISK下，所以，默认存储策略为HOT。

5.2.4 WARM存储策略测试

（1）为数据降温（采用WARM存储策略）

[pcz@hadoop1 hadoop-3.1.3]$ hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy WARM
Set storage policy WARM on /hdfsdata

（2）再次查看文件块分布，我们可以看到文件块依然放在原处

[pcz@hadoop1 hadoop-3.1.3]$ hdfs fsck /hdfsdata -files -blocks -locations

（3）我们需要让HDFS按照存储策略自行移动文件块

[pcz@hadoop1 hadoop-3.1.3]$ hdfs mover /hdfsdata

（4）再次查看文件块分布

[pcz@hadoop1 hadoop-3.1.3]$ hdfs fsck /hdfsdata -files -blocks -locations
Connecting to namenode via http://hadoop1:9870/fsck?ugi=pcz&files=1&blocks=1&locations=1&path=%2Fhdfsdata
FSCK started by pcz (auth:SIMPLE) from /192.168.150.211 for path /hdfsdata at Thu Jan 13 13:51:53 CST 2022
/hdfsdata <dir>
/hdfsdata/NOTICE.txt 21867 bytes, replicated: replication=2, 1 block(s):  OK
0. BP-1485681155-192.168.150.211-1642050375276:blk_1073741825_1001 len=21867 Live_repl=2  [DatanodeInfoWithStorage[192.168.150.212:9866,DS-d89c782e-c4b7-4dca-af5b-016b3b6a7f26,DISK], DatanodeInfoWithStorage[192.168.150.214:9866,DS-36beafe0-f1f5-4be0-afe2-d9b3e25b26f0,ARCHIVE]]

文件块一半在DISK，一半在ARCHIVE，符合我们WARM策略

5.2.5 COLD策略测试

（1）我们继续将数据降温为 cold（采用COLD存储策略）

[pcz@hadoop1 hadoop-3.1.3]$ hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy COLD
Set storage policy COLD on /hdfsdata

注意：当我们将目录设置为 COLD 并且我们未配置 ARCHIVE 存储目录的情况下，不可以向该目录直接上传文件，会报出异常。
（2）手动转移

[pcz@hadoop1 hadoop-3.1.3]$ hdfs mover /hdfsdata

（3）查看文件块的分布

[pcz@hadoop1 hadoop-3.1.3]$ hdfs fsck /hdfsdata -files -blocks -locations
Connecting to namenode via http://hadoop1:9870/fsck?ugi=pcz&files=1&blocks=1&locations=1&path=%2Fhdfsdata
FSCK started by pcz (auth:SIMPLE) from /192.168.150.211 for path /hdfsdata at Thu Jan 13 15:28:43 CST 2022
/hdfsdata <dir>
/hdfsdata/NOTICE.txt 21867 bytes, replicated: replication=2, 1 block(s):  OK
0. BP-1485681155-192.168.150.211-1642050375276:blk_1073741825_1001 len=21867 Live_repl=2  [DatanodeInfoWithStorage[192.168.150.215:9866,DS-20d2853e-db58-4291-9c86-26a7b4940c15,ARCHIVE], DatanodeInfoWithStorage[192.168.150.214:9866,DS-36beafe0-f1f5-4be0-afe2-d9b3e25b26f0,ARCHIVE]]

所有文件块都在ARCHIVE,符合COLD存储策略

5.2.6 ONE_SSD策略测试

（1）将存储策略从默认的 HOT 更改为 One_SSD

[pcz@hadoop1 hadoop-3.1.3]$ hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy One_SSD
Set storage policy One_SSD on /hdfsdata

（2）移动文件块

[pcz@hadoop1 hadoop-3.1.3]$ hdfs mover /hdfsdata

（3）查看文件块分布

[pcz@hadoop1 hadoop-3.1.3]$ hdfs fsck /hdfsdata -files -blocks -locations
Connecting to namenode via http://hadoop1:9870/fsck?ugi=pcz&files=1&blocks=1&locations=1&path=%2Fhdfsdata
FSCK started by pcz (auth:SIMPLE) from /192.168.150.211 for path /hdfsdata at Thu Jan 13 16:00:22 CST 2022
/hdfsdata <dir>
/hdfsdata/NOTICE.txt 21867 bytes, replicated: replication=2, 1 block(s):  OK
0. BP-1485681155-192.168.150.211-1642050375276:blk_1073741825_1001 len=21867 Live_repl=2  [DatanodeInfoWithStorage[192.168.150.213:9866,DS-b3c86b18-2af0-4a0e-a33a-cc0362308126,DISK], DatanodeInfoWithStorage[192.168.150.212:9866,DS-d5f4412e-294c-48c2-9284-8c3d6d019005,SSD]]

文件块一半为SSD，一半在DISK，符合One_SSD存储策略。

5.2.7 ALL_SSD 策略测试

注：一般在实际生产环境中，不会使用该策略，因为将数据存储在内存中虽然速度最快，但是稳定性不高，可能会造成数据丢失，一般SSD存储就能满足企业需求。
（1）将存储策略更改为 All_SSD

[pcz@hadoop1 hadoop-3.1.3]$ hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy ALL_SSD
Set storage policy ALL_SSD on /hdfsdata

（2）移动文件块

[pcz@hadoop1 hadoop-3.1.3]$ hdfs mover /hdfsdata

（3）查看文件块分布

[pcz@hadoop1 hadoop-3.1.3]$ hdfs fsck /hdfsdata -files -blocks -locations
Connecting to namenode via http://hadoop1:9870/fsck?ugi=pcz&files=1&blocks=1&locations=1&path=%2Fhdfsdata
FSCK started by pcz (auth:SIMPLE) from /192.168.150.211 for path /hdfsdata at Thu Jan 13 16:35:36 CST 2022
/hdfsdata <dir>
/hdfsdata/NOTICE.txt 21867 bytes, replicated: replication=2, 1 block(s):  OK
0. BP-1485681155-192.168.150.211-1642050375276:blk_1073741825_1001 len=21867 Live_repl=2  [DatanodeInfoWithStorage[192.168.150.211:9866,DS-f4ef6db6-470a-4f5f-9300-c64301e24192,SSD], DatanodeInfoWithStorage[192.168.150.212:9866,DS-d5f4412e-294c-48c2-9284-8c3d6d019005,SSD]]

所有的文件块都存储在 SSD，符合All_SSD 存储策略

5.2.8 LAZY_PERSIST 策略测试

（1）存储策略改为 lazy_persist

[pcz@hadoop1 hadoop-3.1.3]$ hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy lazy_persist
Set storage policy lazy_persist on /hdfsdata

（2）移动文件块

[pcz@hadoop1 hadoop-3.1.3]$ hdfs mover /hdfsdata

（3）查看文件块分布

[pcz@hadoop1 hadoop-3.1.3]$ hdfs fsck /hdfsdata -files -blocks -locations
Connecting to namenode via http://hadoop1:9870/fsck?ugi=pcz&files=1&blocks=1&locations=1&path=%2Fhdfsdata
FSCK started by pcz (auth:SIMPLE) from /192.168.150.211 for path /hdfsdata at Thu Jan 13 17:27:16 CST 2022
/hdfsdata <dir>
/hdfsdata/NOTICE.txt 21867 bytes, replicated: replication=2, 1 block(s):  OK
0. BP-1485681155-192.168.150.211-1642050375276:blk_1073741825_1001 len=21867 Live_repl=2  [DatanodeInfoWithStorage[192.168.150.213:9866,DS-b3c86b18-2af0-4a0e-a33a-cc0362308126,DISK], DatanodeInfoWithStorage[192.168.150.212:9866,DS-d89c782e-c4b7-4dca-af5b-016b3b6a7f26,DISK]]

这里我们发现所有的文件块都是存储在DISK，按照理论一个副本存储在RAM_DISK，其他副本存储在 DISK 中，这是因为，我们还需要配置“dfs.datanode.max.locked.memory”，
“dfs.block.size”参数。那么出现存储策略为LAZY_PERSIST 时，文件块副本都存储在 DISK 上的原因有如下两点：
（1）当客户端所在的 DataNode 节点没有 RAM_DISK 时，则会写入客户端所在的
DataNode 节点的 DISK 磁盘，其余副本会写入其他节点的 DISK 磁盘。
（2）当客户端所在的 DataNode 有RAM_DISK，但“dfs.datanode.max.locked.memory”参数值未设置或者设置过小（小于“dfs.block.size”参数值）时，则会写入客户端所在的DataNode 节点的 DISK 磁盘，其余副本会写入其他节点的 DISK 磁盘。但是由于虚拟机的“max locked memory”为64KB，所以，如果参数配置过大，还会报出错误：

ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: Exception in
secureMain
java.lang.RuntimeException: Cannot start datanode because the configured
max locked memory size (dfs.datanode.max.locked.memory) of 209715200
bytes is more than the datanode's available RLIMIT_MEMLOCK ulimit of
65536 bytes.

我们可以通过该命令查询此参数的内存

[pcz@hadoop1 hadoop-3.1.3]$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 14949
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 4096
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited