第1章 HDFS-核心参数
1.1 NameNode内存生产配置
1)NameNode 内存计算
- 每个文件块大概占用 150 byte,一台服务器 128G 内存为例,能存储多少文件块呢?
- 128 * 1024 * 1024 * 1024 / 150byte ≈ 9.1 亿
- G MB KB Byte
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=# 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=
HADOOP_NAMENODE_OPTS=-Xmx102400m
(2)查看 NameNode 占用内存
[root@node1 ~]# jps
1990 NameNode
2135 DataNode
2553 ResourceManager
1771 QuorumPeerMain
3069 Jps
2703 NodeManager
[root@node1 ~]# jmap -heap 1990
Attaching to process ID 1990, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.241-b07using thread-local object allocation.
Parallel GC with 2 thread(s)Heap Configuration:MinHeapFreeRatio = 0MaxHeapFreeRatio = 100MaxHeapSize = 2046820352 (1952.0MB) ☆NewSize = 42467328 (40.5MB)MaxNewSize = 682098688 (650.5MB)OldSize = 85458944 (81.5MB)NewRatio = 2SurvivorRatio = 8MetaspaceSize = 21807104 (20.796875MB)CompressedClassSpaceSize = 1073741824 (1024.0MB)MaxMetaspaceSize = 17592186044415 MBG1HeapRegionSize = 0 (0.0MB)Heap Usage:
PS Young Generation
Eden Space:capacity = 127926272 (122.0MB)used = 114224304 (108.93278503417969MB)free = 13701968 (13.067214965820312MB)89.28916806080302% used
From Space:capacity = 5242880 (5.0MB)used = 0 (0.0MB)free = 5242880 (5.0MB)0.0% used
To Space:capacity = 18874368 (18.0MB)used = 0 (0.0MB)free = 18874368 (18.0MB)0.0% used
PS Old Generationcapacity = 122683392 (117.0MB)used = 42217192 (40.261451721191406MB)free = 80466200 (76.7385482788086MB)34.411497197599495% used15419 interned Strings occupying 1436248 bytes.
(3)查看 DataNode 占用内存
[root@node1 ~]# jmap -heap 2135
Attaching to process ID 2135, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.241-b07using thread-local object allocation.
Parallel GC with 2 thread(s)Heap Configuration:MinHeapFreeRatio = 0MaxHeapFreeRatio = 100MaxHeapSize = 2046820352 (1952.0MB) ☆NewSize = 42467328 (40.5MB)MaxNewSize = 682098688 (650.5MB)OldSize = 85458944 (81.5MB)NewRatio = 2SurvivorRatio = 8MetaspaceSize = 21807104 (20.796875MB)CompressedClassSpaceSize = 1073741824 (1024.0MB)MaxMetaspaceSize = 17592186044415 MBG1HeapRegionSize = 0 (0.0MB)Heap Usage:
PS Young Generation
Eden Space:capacity = 127926272 (122.0MB)used = 18529608 (17.67121124267578MB)free = 109396664 (104.32878875732422MB)14.484599379242443% used
From Space:capacity = 5242880 (5.0MB)used = 0 (0.0MB)free = 5242880 (5.0MB)0.0% used
To Space:capacity = 12058624 (11.5MB)used = 0 (0.0MB)free = 12058624 (11.5MB)0.0% used
PS Old Generationcapacity = 78118912 (74.5MB)used = 15015288 (14.319694519042969MB)free = 63103624 (60.18030548095703MB)19.221066468514053% used15063 interned Strings occupying 1353568 bytes.
查看发现主节点上的 NameNode 和 DataNode 占用内存都是自动分配的,且相等。不是很合理。
可以参考 CDH 官方说明配置
Hardware Requirements | 6.x | Cloudera Documentation
具体修改:hadoop-env.sh
export HDFS_NAMENODE_OPTS="-Dhadoop.security.logger=INFO,RFAS -Xmx1024m"
export HDFS_DATANODE_OPTS="-Dhadoop.security.logger=ERROR,RFAS -Xmx1024m"
1.2 NameNode 心跳并发配置
1)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>
企业经验:
d f s . n a m e n o d e . h a n d l e r . c o u n t = 20 ∗ 〖 l o g 〗 e ( C l u s t e r S i z e ) dfs.namenode.handler.count = 20 *〖log〗_e^(Cluster Size) dfs.namenode.handler.count=20∗〖log〗e(ClusterSize)
,比如集群规模 (DataNode 台数)为3台时,此参数设置为21.可通过简单的python代码计算该值,代码如下:
[root@node1 ~]# python
Python 2.7.5 (default, Aug 7 2019, 00:51:29)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> print int(20*math.log(3))
21
1.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/root《随用户而变》/.Trash
5)注意:通过web的9870端口删除的文件不会走回收站
6)通过程序删除的文件不会经过回收站,需要调用 moveToTrash()才进入回收站
Trash trash = New Trash(conf);
trash.moveToTrash(path);
7)在命令行利用hadoop fs -rm
命令删除的文件才会走回收站。
[root@node1 hadoop]# hadoop fs -rm /tmp/lj_tmp/202312/10/input/new_node1_2023-12-10_14_56_54.log
2024-01-28 18:43:21,365 INFO fs.TrashPolicyDefault: Moved: 'hdfs://node1:8020/tmp/lj_tmp/202312/10/input/new_node1_2023-12-10_14_56_54.log' to trash at: hdfs://node1:8020/user/root/.Trash/Current/tmp/lj_tmp/202312/10/input/new_node1_2023-12-10_14_56_54.log
8)恢复回收站数据
hadoop fs -mv hdfs://node1:8020/user/root/.Trash/Current/tmp/lj_tmp/202312/10/input/new_node1_2023-12-10_14_56_54.log hdfs://node1:8020/tmp/lj_tmp/202312/10/input
第2章 HDFS-集群压测
在企业中非常关心每天从Java后台拉取过来的数据,需要多久能上传到集群?消费者关心多久能从HDFS上拉取需要的数据?
为了搞清楚HDFS的读写性能,生产环境上非常需要对集群进行压测。
HDFS的读写性能主要受网络和磁盘影响比较大。为了方便测试,将hadoop102、hadoop103、hadoop104虚拟机网络都设置为100mbps。
100Mbps单位是bit;10M/s单位是byte ; 1byte=8bit,100Mbps/8=12.5M/s。
测试网速:来到node2的/opt/module目录,创建一个
[root@node1 hadoop]# python -m SimpleHTTPServer
2.1 测试 HDFS 写性能
1)写测试底层原理
2)测试内容:向HDFS集群写10个128M的文件
[root@node1 hadoop]# hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -write -nrFiles 10 -fileSize 128MB2021-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处理的差值,越小越均衡
3)注意:如果测试过程中,出现异常
(1)可以在 yarn-site.xml 中设置虚拟内存检测为 false
<!--是否启动一个线程检查每个任务正使用的虚拟内存量,如果任务超出分配值,则直接将其杀掉,默认是true -->
<property><name>yarn.nodemanager.vmem-check-enabled</name><value>false</value>
</property>
(2)分发配置并重启 Yarn 集群
4)测试结果分析
(1)由于副本1就在本地,所以该副本不参与测试
一共参与测试的文件:10个文件 * 2个副本 = 20个
压测后的速度:1.61
实测速度:1.61M/s * 20个文件 ≈ 32M/s
三台服务器的带宽:12.5 + 12.5 + 12.5 ≈ 30m/s
所有网络资源都已经用满。
如果实测速度远远小于网络,并且实测速度不能满足工作需求,可以考虑采用固态硬盘或者增加磁盘个数。
(2)如果客户端不在集群节点,那就三个副本都参与计算
2.2 测试 HDFS 读性能
1)测试内容:读取HDFS集群10个128M的文件
[root@node1 hadoop]# hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -read -nrFiles 10 -fileSize 128MB2021-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)删除测试生成数据
[root@node1 hadoop]# hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -clean
3)测试结果分析:为什么读取文件速度大于网络带宽?由于目前只有三台服务器,且有三个副本,数据读取就近原则,相当于都是读取的本地磁盘数据,没有走网络。
第3章 HDFS 多目录
3.1 NameNode 多目录配置
1)NameNode的本地目录可以配置成多个,且每个目录存放内容相同,增加了可靠性
2)具体配置如下
(1)在 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中所有数据。
[root@node1 hadoop]# rm -rf data/ logs/
[root@node1 hadoop]# rm -rf data/ logs/
[root@node1 hadoop]# rm -rf data/ logs/
(3)格式化集群并启动
[root@node1 hadoop]# bin/hdfs namenode -format
[root@node1 hadoop]# sbin/start-dfs.sh
3)查看结果
[root@node1 dfs]# ls
data name1 name2
检查 name1 和 name2 里面的内容,发现一模一样。
3.2 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)查看结果
[root@node1 hadoop]# ls
data1 data2 name1 name2
4)向集群上传一个文件,再次观察两个文件夹里面的内容发现不一致(一个有数一个没有)
3.3 集群数据均衡之磁盘间数据均衡
生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(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
第4章 HDFS–集群扩容及缩容
4.1 添加白名单
白名单:表示在白名单的主机IP地址可以,用来存储数据
企业中:配置白名单,可以尽量防止黑客恶意访问攻击
配置白名单步骤如下:
1)在 NameNode 节点的 ./hadoop/etc/hadoop 目录下分别创建 whitelist 和blacklist 文件
(1)创建白名单
vim whitelist
在 whitelist 中添加如下主机名称,假如集群正常工作节点为 102 103
hadoop102
hadoop103
(2)创建黑名单
# 保持空的就可以
touch blacklist
2)在 hdfs-site.xml 配置文件中增加 dfs.hosts 配置参数
<!-- 白名单 -->
<property><name>dfs.hosts</name><value>/export/server/hadoop/etc/hadoop/whitelist</value>
</property><!-- 黑名单 -->
<property><name>dfs.hosts.exclude</name><value>/export/server/hadoop/etc/hadoop/blacklist</value>
</property>
3)分发配置文件 whitelist,hdfs-site.xml
xsync whitelist hdfs-site.xml
4)第一次添加白名单必须重启集群,不是第一次,只需刷新 NameNode 节点即可
5)在 web 浏览器上查看 DN,http://hadoop102:9870/dfshealth.html#tab-datanode
6)在 hadoop104 上执行上传数据失败
7)二次修改白名单,增加 hadoop104
vim whitelist
hadoop102
hadoop103
hadoop104
8)刷新 NameNode
hdfs dfsadmin -refreshNodes
9)在 web 浏览器上查看 DN,http://hadoop102:9870/dfshealth.html#tab-datanode
4.2 服役新服务器
1)需求
随着公司业务的增长,数据量越来越大,原有的数据节点的容量已经不能满足存储数据的需求,需要在原有集群基础上动态添加新的数据节点。
2)环境准备
(1)在hadoop100主机上再克隆一台hadoop105主机
(2)修改IP地址和主机名称
vim /etc/sysconfig/network-scripts/ifcfg-ens33
vim /etc/hostname
(3)拷贝hadoop102的 /export/server 目录和 /etc/profile.d/my_env.sh 到 hadoop105
scp -r /export/server/* root@hadoop105:/export/server
scp /etc/profile.d/my_env.sh root@hadoop105:/etc/profile.d/my_env.sh
source /etc/profile
(4)删除 hadoop105 上 Hadoop 的历史数据,data 和 log 数据
rm -rf data/ logs/
(5)配置 hadoop102 和 hadoop103 到 hadoop105 的ssh 免密登陆
# 在 hadoop102 上执行
ssh-copy-id hadoop105
# 在 hadoop103 上执行
ssh-copy-id hadoop105
3)服役新节点具体步骤
(1)直接启动 DataNode,即可关联到集群
hdfs --daemon start datanode
yarn --daemon start nodemanager
4)白名单中增加新服役的服务器
(1)在白名单whitelist中增加hadoop105
vim whitelist
修改为如下内容
hadoop102
hadoop103
hadoop104
hadoop105
(2)分发
xsync whitelist
(3)刷新 NameNode
dfs dfsadmin -refreshNodes
5)在 hadoop105 上上传文件
hadoop dfs -put ./test.txt /tmp
4.3 服务器间数据均衡
1)企业经验:在企业开发中,如果经常在hadoop102和hadoop104上提交任务,且副本数为2,由于数据本地性原则,就会导致hadoop102和hadoop104数据过多,hadoop103存储的数据量小。
另一种情况,就是新服役的服务器数据量比较少,需要执行集群均衡命令。
2)开启数据均衡命令
sbin/start-balancer.sh -threshold 10
对于参数10,代表的是集群中各个节点的磁盘空间利用率相差不超过10%,可根据实际情况进行调整。
3)停止数据均衡命令
sbin/stop-balancer.sh
注意:由于 HDFS 需要启动单独的 Rebalance Server 来执行 Rebalance 操作,所以尽量不要在 NameNode 上执行 start-balancer.sh,而是找一台比较空闲的机器。
4.4 黑名单退役服务器
黑名单:表示在黑名单的主机IP地址不可用,用来存储数据
企业中:配置黑名单,用来退役服务器。
黑名单配置步骤如下:
1)编辑 blacklist 文件
vim blacklist
添加如下主机名称(要退役的节点)
hadoop105
注意:如果白名单中没有配置,需要在 hdfs-site.xml 配置文件中增加 dfs.host 配置参数
<!-- 黑名单 -->
<property><name>dfs.hosts.exclude</name><value>/export/server/hadoop-3.1.3/etc/hadoop/blacklist</value>
</property>
2)分发配置文件 blacklist 和 hdfs-site.xml
xsync hdfs-site.xml blacklist
3)第一次添加黑名单必须重启集群,不是第一次,只需要刷新 NameNode 节点即可
hdfs dfsadmin -refreshNodes
4)检查 web 浏览器,退役节点的状态为 decommission in progress(退役中),说明数据节点正在复制块到其他节点
5)等待退役节点状态为 decommissioned(所有块以复制完成),停止该节点及节点资源管理器。
注意:如果副本数是 3,退役的节点小于等于3,是不能退役成功的,需要修改副本数后才能退役
hdfs --daemon stop datanode
yarn --daemon stop nodemanager
6)如果数据不均衡,可以用命令实现集群的再平衡
sbin/start-balancer.sh -threshold 10
第5章 HDFS-存储优化
注:演示纠删码和异构存储需要一共5台虚拟机。尽量拿另外一套集群。提前准备5台服务器的集群。
5.1 纠删码
5.1.1 纠删码原理
HDFS默认情况下,一个文件有3个副本,这样提高了数据的可靠性,但也带来了2倍的冗余开销。Hadoop3.x引入了纠删码,采用计算的方式,可以节省约50%左右的存储空间。
1)纠删码操作相关的命令
hdfs ec
2)查看当前支持的纠删码策略
hdfs ec -listPolicies
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策略的支持
hdfs ec -enablePolicy -policy RS-3-2-1024k
(2)在 HDFS 创建目录,并设置 RS-3-2-1024k 策略
hdfs dfs -mkdir /input
hdfs ec -setPolicy -path /input -policy RS-3-2-1024k
(3)上传文件,并查看文件编码后的存储情况
hdfs dfs -put test.txt /input
注:你所上传的文件需要大于2M才能看出效果。(低于2M,只有一个数据单元和两个校验单元)
(4)查看存储路径的数据单元和校验单元,并作破坏实验
5.2 异构存储(冷热数据分离)
异构存储主要解决,不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。
1)关于存储类型
RAM_DISK:内存镜像文件系统
SSD:SSD固态硬盘
DISK:普通硬盘,在 HDFS 中,如果没有主动声明数据目录存储类型默认都是 DISK
ARCHIVE:没有特指哪种存储介质,主要的指的是计算能力比较弱而存储密度比较高的存储介质,用来解决数据量的容量扩增的问题,一般用于归档
2)关于存储策略
说明:从 Lazy_Persist 到 Cold,分别代表了设备的访问速度从快到慢
5.2.1 异构存储 Shell 操作
(1)查看当前有哪些存储策略可以用
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)查看文件块的分布
hdfs fsck xxx -files -blocks -locations
(5)查看集群节点
hadoop dfsadmin -report
5.2.2 测试环境准备
1)测试环境描述
服务器规模:5台
集群配置:副本数为2,创建好带有存储类型的目录(提前创建)
集群规划:
节点 | 存储类型分配 |
---|---|
hadoop102 | RAM_DISK,SSD |
hadoop103 | SSD,DISK |
hadoop104 | DISK,RAM_DISK |
hadoop105 | ARCHIVE |
hadoop106 | ARCHIVE |
2)配置文件信息
(1)为 hadoop102 节点的 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:///export/server/hadoop-3.1.3/hdfsdata/ssd,[RAM_DISK]file:///export/server/hadoop-3.1.3/hdfsdata/ram_disk</value>
</property>
(2)为 hadoop103 节点的 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:///export/server/hadoop-3.1.3/hdfsdata/ssd,[DISK]file:///export/server/hadoop-3.1.3/hdfsdata/disk</value>
</property>
(3)为 hadoop104 节点的 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:///export/server/hdfsdata/ram_disk,[DISK]file:///export/server/hadoop-3.1.3/hdfsdata/disk</value>
</property>
(4)为 hadoop105 节点的 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:///export/server/hadoop-3.1.3/hdfsdata/archive</value>
</property>
(5)为 hadoop106 节点的 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:///export/server/hadoop-3.1.3/hdfsdata/archive</value>
</property>
3)数据准备
(1)启动集群
start-all.sh
(2)在 HDFS 上创建文件目录
hdfs fs -mkdir /testdir
(3)并将文件资料上传
hdfs dfs -put ./text.txt /testdir
5.2.3 HOT 存储策略案例
(1)最开始我们未设置存储策略的情况下,我们获取该目录的存储策略
hdfs storagepolicies -getStoragePolicy -path /testdir
(2)我们查看上传的文件块分布
hdfs fsck /testdir -files -blocks -locations[DatanodeInfoWithStorage[192.168.10.104:9866,DS-0b133854-7f9e-48df-939b-5ca6482c5afb,DISK], DatanodeInfoWithStorage[192.168.10.103:9866,DS-ca1bd3b9-d9a5-4101-9f92-3da5f1baa28b,DISK]]
未设置存储策略,所有文件块都存储在 DISK 下。所以,默认存储策略为 HOT。
5.2.4 WARM存储策略测试
(1)接下来我们为数据降温
hdfs storagepolicies -setStoragePolicy -path /testdir -policy WARM
(2)再次查看文件块分布,我们可以看到文件块依然放在原处。
hdfs fsck /testdir -files -blocks -locations
(3)我们需要让他 HDFS 按照存储策略自行移动文件块
hdfs mover /testdir
(4)再次查看文件块分布
hdfs fsck /testdir -files -blocks -locations[DatanodeInfoWithStorage[192.168.10.105:9866,DS-d46d08e1-80c6-4fca-b0a2-4a3dd7ec7459,ARCHIVE], DatanodeInfoWithStorage[192.168.10.103:9866,DS-ca1bd3b9-d9a5-4101-9f92-3da5f1baa28b,DISK]]
文件块一半在 DISK,一半在 ARCHIVE,符合我们设置的WARM策略
5.2.5 COLD 策略测试
(1)我们继续将数据降温为cold
hdfs storagepolicies -setStoragePolicy -path /testdir -policy COLD
注意:当我们将目录设置为 COLD 并且我们未配置 ARCHIVE 存储目录的情况下,不可以向该目录直接上传文件,会报出异常。
(2)手动转移
hdfs mover /testdir
(3)检查文件块的分布
hdfs fsck /testdir -files -blocks -locations[DatanodeInfoWithStorage[192.168.10.105:9866,DS-d46d08e1-80c6-4fca-b0a2-4a3dd7ec7459,ARCHIVE], DatanodeInfoWithStorage[192.168.10.106:9866,DS-827b3f8b-84d7-47c6-8a14-0166096f919d,ARCHIVE]]
所有文件块都在 ARCHIVE,符合 COLD 存储策略。
5.2.6 ONE_SSD策略测试
(1)接下来我们将存储策略从默认的 HOT 更改为 ONE_SSD
hdfs storagepolicies -setStoragePolicy -path /testdir -policy One_SSD
(2)手动转移
hdfs mover /testdir
(3)检查文件块的分布
hdfs fsck /testdir -files -blocks -locations[DatanodeInfoWithStorage[192.168.10.104:9866,DS-0b133854-7f9e-48df-939b-5ca6482c5afb,DISK], DatanodeInfoWithStorage[192.168.10.103:9866,DS-2481a204-59dd-46c0-9f87-ec4647ad429a,SSD]]
文件块分布为一半在SSD,一半在DISK,符合One_SSD存储策略。
5.2.7 ALL_SSD策略测试
(1)接下来,我们再将存储策略更改为 All_SSD
hdfs storagepolicies -setStoragePolicy -path /testdir -policy All_SSD
(2)手动转移
hdfs mover /testdir
(3)检查文件块的分布
hdfs fsck /testdir -files -blocks -locations[DatanodeInfoWithStorage[192.168.10.102:9866,DS-c997cfb4-16dc-4e69-a0c4-9411a1b0c1eb,SSD], DatanodeInfoWithStorage[192.168.10.103:9866,DS-2481a204-59dd-46c0-9f87-ec4647ad429a,SSD]]
所有的文件块都存储在SSD,符合All_SSD存储策略。
5.2.8 LAZY_PERSIST策略测试
(1)将存储策略改为lazy_persist
hdfs storagepolicies -setStoragePolicy -path /testdir -policy lazy_persist
(2)手动转移
hdfs mover /testdir
(3)检查文件块的分布
hdfs fsck /testdir -files -blocks -locations[DatanodeInfoWithStorage[192.168.10.104:9866,DS-0b133854-7f9e-48df-939b-5ca6482c5afb,DISK], DatanodeInfoWithStorage[192.168.10.103:9866,DS-ca1bd3b9-d9a5-4101-9f92-3da5f1baa28b,DISK]]
所有的文件块都存储在SSD,符合All_SSD存储策略。
这里我们发现所有的文件块都是存储在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.
我们可以通过该命令查询此参数的内存
ulimit -a
第6章 HDFS-故障排除
注意:采用三台服务器即可,恢复到Yarn开始的服务器快照。
6.1 NameNode 故障处理
1)需求:
NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode
2)故障模拟
(1)kill -9 NameNode 进程
kill -9 2078
(2)删除 NameNode 存储的数据(/export/server/hadoop-3.1.3/data/tmp/dfs/name)
rm -rf /export/server/hadoop-3.1.3/data/tmp/dfs/name/*
(3)问题解决
(1)拷贝 SecondaryNameNode 中数据到原 NameNode 存储数据目录
scp -r root@hadoop104:/export/server/hadoop-3.1.3/data/tmp/dfs/name /export/server/hadoop-3.1.3/data/tmp/dfs/name
(2)重新启动 NameNode
hdfs --daemon start namenode
(3)向集群上传一个文件
hdfs dfs ./test.txt /tmp
6.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)基本语法
集群处于安全模式,不能执行重要操作(写操作)。集群启动完成后,自动退出安全模式。
hdfs dfsadmin -safemode get (功能描述:查看安全模式状态)
hdfs dfsadmin -safemode enter (功能描述:进入安全模式状态)
hdfs dfsadmin -safemode leave (功能描述:离开安全模式状态)
hdfs dfsadmin -safemode wait (功能描述:等待安全模式状态)
5)案例1:启动集群进入安全模式
(1)重新启动集群
stop-all.sh
start-all.sh
(2)集群启动后,立即来到集群式伤处数据,提示集群处于安全模式
6)案例2:磁盘修复
需求:数据块损坏,进入安全模式,如何处理
(1)分别进入hadoop102、hadoop103、hadoop104的/export/server/hadoop-3.1.3/data/dfs/data/current/BP-1015489500-192.168.10.102-1611909480872/current/finalized/subdir0/subdir0目录,统一删除某2个块信息
cd /export/server/hadoop-3.1.3/data/dfs/data/current/BP-1015489500-192.168.10.102-1611909480872/current/finalized/subdir0/subdir0
rm -rf blk_1073741847 blk_1073741847_1023.meta
rm -rf blk_1073741865 blk_1073741865_1042.meta
说明:hadoop103/hadoop104重复执行以上命令
(2)重新启动集群
start-all.sh
(3)观察http://hadoop102:9870/dfshealth.html#tab-overview
说明:安全模式已经打开,块的数量没有达到要求。
(4)离开安全模式
hdfs dfsadmin -safemode get
hdfs dfsadmin -safemode leave
(5)观察http://hadoop102:9870/dfshealth.html#tab-overview
(6)将元数据删除
(7)观察http://hadoop102:9870/dfshealth.html#tab-overview,集群已经正常
7)案例3:
需求:模拟等待安全模式
(1)查看当前模式
hdfs dfsadmin -safemode get
(2)先进入安全模式
hdfs dfsadmin -safemode enter
(3)创建并执行下面的脚本
在/export/server/hadoop-3.1.3路径上,编辑一个脚本safemode.sh
vim safemode.sh#!/bin/bash
hdfs dfsadmin -safemode wait
hdfs dfs -put /opt/module/hadoop-3.1.3/README.txt /sh safemode.sh
(4)再打开一个窗口,执行
hdfs dfsadmin -safemode leave
(5)再观察上一个窗口
Safe mode is OFF
(6)HDFS 集群上已经有上传的数据了
6.3 慢磁盘监控
“慢磁盘”指的时写入数据非常慢的一类磁盘。其实慢性磁盘并不少见,当机器运行时间长了,上面跑的任务多了,磁盘的读写性能自然会退化,严重时就会出现写入数据延时的问题。
如何发现慢磁盘?
正常在HDFS上创建一个目录,只需要不到1s的时间。如果你发现创建目录超过1分钟及以上,而且这个现象并不是每次都有。只是偶尔慢了一下,就很有可能存在慢磁盘。
可以采用如下方法找出是哪块磁盘慢:
1)通过心跳未联系时间。
一般出现慢磁盘现象,会影响到DataNode与NameNode之间的心跳。正常情况心跳时间间隔是3s。超过3s说明有异常。
2)fio命令,测试磁盘的读写性能
(1)顺序读测试
yum install -y fio
fio -filename=/home/atguigu/test.log -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_rRun 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)顺序写测试
fio -filename=/home/atguigu/test.log -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_wRun status group 0 (all jobs):WRITE: bw=341MiB/s (357MB/s), 341MiB/s-341MiB/s (357MB/s-357MB/s), io=19.0GiB (21.4GB), run=60001-60001msec
结果显示,磁盘的总体顺序写速度为341MiB/s。
(3)随机写测试
fio -filename=/home/atguigu/test.log -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_randwRun 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)混合随机读写
fio -filename=/home/atguigu/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=noopRun status group 0 (all jobs):READ: bw=220MiB/s (231MB/s), 220MiB/s-220MiB/s (231MB/s-231MB/s), io=12.9GiB (13.9GB), run=60001-60001msecWRITE: 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****。
6.4 小文件归档
1)HDFS存储小文件弊端
每个文件均按块存储,每个块的元数据存储在NameNode的内存中,因此HDFS存储小文件会非常低效。因为大量的小文件会耗尽NameNode中的大部分内存。但注意,存储小文件所需要的磁盘容量和数据块的大小无关。例如,一个1MB的文件设置为128MB的块存储,实际使用的是1MB的磁盘空间,而不是128MB。
2)解决存储小文件办法之一
HDFS存档文件或HAR文件,是一个更高效的文件存档工具,它将文件存入HDFS块,在减少NameNode内存使用的同时,允许对文件进行透明的访问。具体说来,HDFS存档文件对内还是一个一个独立文件,对NameNode而言却是一个整体,减少了NameNode的内存。
3)实例操作
(1)需要启动 YARN 进程
start-yarn.sh
(2)归档文件
把 /input 目录里面的所有文件归档成一个叫 input.har 的归档文件,并把归档后文件存储到 /output 路径下。
hadoop archive -archiveName input.har -p /input /output
(3)查看归档
hadoop fs -ls /output/input.har
(4)解归档文件
hadoop fs -cp har:///output/input.har/* /