前言
以下修改的配置文件均在/opt/module/hadoop/etc/hadoop
目录下
一、HDFS——核心参数
1. NameNode 内存生产配置
🍟NameNode 内存计算:每个文件块大概占用 150byte,一台服务器 128G 内存为例,128 * 1024 * 1024 * 1024 / 150Byte ≈ 9.1 亿 个文件块
- Hadoop2.x 系列,配置 NameNode 内存
NameNode 内存默认 2000M,如果服务器内存 4G,NameNode 内存可以配置 3G。在hadoop-env.sh
文件中配置如下
HADOOP_NAMENODE_OPTS=-Xmx3072m
- Hadoop3.x 系列,配置 NameNode 内存,查看配置文件
hadoop-env.sh
得知内存是动态分配的,命令查看 NameNode 占用内存(jpsall
查询NameNodePid,查看发现 NameNode 和 DataNode 占用内存都是自动分配的,且相等,不是很合理)
jmap -heap NameNodePid
👉手动具体修改hadoop-env.sh
文件
vim /opt/moudle/hadoop/etc/hadoop/hadoop-env.sh
# 查找NAMENODE,直接输入
\NAMENODE
# 在最后面加入
export HDFS_NAMENODE_OPTS="-Dhadoop.security.logger=INFO,RFAS -Xmx1024m"
export HDFS_DATANODE_OPTS="-Dhadoop.security.logger=ERROR,RFAS -Xmx1024m"
# 分发
xsync hadoop-env.sh
# 重启集群
myhadoop.sh stop
myhadoop.sh start
2. NameNode 心跳并发配置
🍟配置文件hdfs-site.xml
,NameNode 有一个工作线程池,用来处理不同 DataNode 的并发心跳以及客户端并发的元数据操作。对于大集群或者有大量客户端的集群来说,通常需要增大该参数。默认值是 10。
<property>
<name>dfs.namenode.handler.count</name>
<value>21</value>
</property>
最后分发即可达最佳性能
xsync /opt/module/hadoop/etc/hadoop/hdfs-site.xml
👉企业经验:
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×logeClusterSize,比如集群规模(DataNode 台数)为 3 台时,此参数设置为 21。可通过简单的 python 代码计算该值:
3. 开启回收站配置
开启回收站功能,可以将删除的文件在不超时的情况下,恢复原数据,起到防止误删除、备份等作用。
🍟HDFS回收站工作机制:
启回收站功能参数说明:
- 默认值
fs.trash.interval = 0
,0 表示禁用回收站;其他值表示设置文件的存活时间。- 默认值
fs.trash.checkpoint.interval = 0
,检查回收站的间隔时间。如果该值为 0,则该值设置和 fs.trash.interval 的参数值想等- 要求 fs.trash.checkpoint.interval ≤ \leq ≤ fs.trash.interval。
🍟启用回收站:修改core-site.xml
,配置垃圾回收时间为 1 分钟
<property>
<name>fs.trash.interval</name>
<value>1</value>
</property>
分发到其他集群上,并重启集群
xsync core-site.xml
myhadoop.sh stop
myhadoop.sh start
🌰删除文件夹/output/
,可以看到收入了回收站
注意:通过网页上直接删除的文件不会走回收站,通过程序(java代码)删除的文件也不会经过回收站,需要调用
moveToTrash()
才进入回收站
Trash trash = New Trash(conf);
trash.moveToTrash(path);
🌰恢复回收站数据:
hadoop fs -mv /user/root/.Trash/Current/user/root/output /user/root/output
二、HDFS——集群压测
在企业中非常关心每天从 Java 后台拉取过来的数据,需要多久能上传到集群?消费者关心多久能从 HDFS 上拉取需要的数据?为了搞清楚 HDFS 的读写性能,生产环境上非常需要对集群进行压测。
1. 网速配置100bps
🍟HDFS 的读写性能主要受网络和磁盘影响比较大。为了方便测试,将 hadoop102、hadoop103、hadoop104 虚拟机网络都设置为 100mbps
100Mbps 单位是 bit;10M/s 单位是 byte;1byte=8bit,100Mbps/8=12.5M/s
🌰测试网速:进入hadoop102的/opt/software/
目录下将路径暴露允许外部下载:
python -m SimpleHTTPServer
👉打开hadoop:8000
后即可下载!
ctrl+c退出
2. 测试HDFS写性能
🍟测试原理图:
测试文件个数要保证每台服务器都有任务执行,以三台服务器为例,都是4核,故测试文件数在9~11最佳
🍟测试内容:向HDFS集群写10个128M的文件
hadoop jar /opt/module/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -write -nrFiles 10 -fileSize 128MB
🤯报错,因为虚拟内存不足(分配不均导致)
💡在yarn-site.xml
中设置虚拟内存检测为 false
<!--是否启动一个线程检查每个任务正使用的虚拟内存量,如果任务超出分配值,则直接将其杀掉,默认是 true -->
<property>
<name>yarn.nodemanager.vmem-check-enabled</name>
<value>false</value>
</property>
分发给其他服务器并且重启yarn(hadoop目录下)
xsync yarn-site.xml
sbin/stop-yarn.sh
sbin/start-yarn.sh
🍟重新运行,结果如图:
🍟测试结果分析:
- 由于副本一就在本地,所以该副本不参与测试,故一共生成 了20个副本
- 压测后的速度:1.19
- 实测速度:1.19M/s * 20个文件 ≈ 23.8M/s
- 三台服务器的带宽:100bps = 12.5M/s , 12.5 + 12.5 + 12.5 ≈ 30M/s
如果实测速度远远小于网络,并且实测速度不能满足工作需求,可以考虑采用固态硬盘或者增加磁盘个数。
如果客户端不在集群节点,三个副本都要参与计算
3. 测试HDFS读性能
🍟测试内容:读取 HDFS 集群 10 个 128M 的文件
hadoop jar /opt/module/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -read -nrFiles 10 -fileSize 128MB
读一份是本地读取,能超过网络带宽,数据读取就近原则,相当于都是读取的本地磁盘数据,没有走网络。
三、HDFS——多目录
1. NameNode多目录配置
🍟NameNode 的本地目录可以配置成多个,且每个目录存放内容相同,增加了可靠性
🍟想要多加一个NameNode2则配置如下:vim 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>
因为每台服务器节点的磁盘情况不同,所以这个配置配完之后,可以选择不分发,我们这里磁盘情况是相同的,故分发
xsync hdfs-site.xml
👉后续操作:
# 第一步:停掉集群
myhadoop.sh stop
# 第二步:删除data/ logs/ 文件夹,三台虚拟机上都需要删除
rm -rf data/ logs/
# 第三步:格式化NameNode
hdfs namenode -format
# 第四步:重启hdfs
sbin/start-dfs.sh
# 第五步:查看是否有两个目录name1、name2
cd data/dfs/ ; ll
进入name1、name2中发现内容均相同,增加了可靠性
2. DataNode多目录配置(重要)
🍟DataNode 可以配置成多个目录,每个目录存储的数据不一样(数据不是副本)
🍟具体配置如下:vim 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>
在生产环境下一般不分发,按照加的硬盘来决定增加几个目录,我们这里由于是一样的,才分发
# 分发
xsync hdfs-site.xml
# 重启HDFS
sbin/stop-dfs.sh
sbin/start-dfs.sh
# 查看是否增加目录成功
cd data/dfs ; ll
进行数据的操作后,所有data目录中内容都不同,例如:向集群上传一个文件,再次观察两个文件夹里面的内容发现不一致(一个有数一个没有)
3. 集群数据均衡之磁盘间数据均衡(重要)
生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(针对的是单节点的内部进行操作)
🍟操作步骤如下:
# 生成均衡计划(我们只有一块磁盘,不会生成计划)
hdfs diskbalancer -plan hadoop102
# 执行均衡计划
hdfs diskbalancer -execute hadoop102.plan.json
# 查看当前均衡任务的执行情况
hdfs diskbalancer -query hadoop102
# 取消均衡任务
hdfs diskbalancer -cancel hadoop102.plan.json
四、HDFS——集群扩容及缩容
1. 添加白名单
🍟白名单:表示在白名单的主机 IP 地址都可以访问,用来进行存储数据。在企业中配置白名单,可以尽量防止黑客恶意访问攻击
🍟配置白名单步骤如下:
- 在 NameNode 节点的
/opt/module/hadoop/etc/hadoop
目录下分别创建whitelist
和blacklist
文件
# 创建白名单(写入hadoop102、hadoop103)
vim whitelist
# 创建黑名单(空文件)
touch blacklist
- 在
hdfs-site.xml
配置文件中增加dfs.hosts
配置参数
<!-- 白名单 -->
<property>
<name>dfs.hosts</name>
<value>/opt/module/hadoop/etc/hadoop/whitelist</value>
</property>
<!-- 黑名单 -->
<property>
<name>dfs.hosts.exclude</name>
<value>/opt/module/hadoop/etc/hadoop/blacklist</value>
</property>
- 分发配置文件 whitelist,blacklist ,hdfs-site.xml
xsync whitelist blacelist hdfs-site.xml
- 第一次添加白名单必须重启集群,不是第一次,只需要刷新 NameNode 节点即可
# 重启集群
myhadoop.sh stop
myhadoop.sh start
# 刷新NameNode节点
hdfs dfsadmin -refreshNodes
-
在 web 浏览器上查看 DN,👉点此前往
-
在 hadoop104 上执行上传数据数据失败
-
二次修改白名单,增加haoop104,分发并刷新NameNode,又在 web 浏览器上查看 DN 是否有三台服务器了,👉点此前往
# 分发
xsync whitelist
# 刷新NameNode节点
hdfs dfsadmin -refreshNodes
2. 服役新数据节点
随着公司业务的增长,数据量越来越大,原有的数据节点的容量已经不能满足存储数据的需求,需要在原有集群基础上动态添加新的数据节点(就是再创建一台虚拟机出来)
🍟环境准备:
- 在 hadoop100 主机上再克隆一台 hadoop105 主机(注意一定要关机,像下面这种情况克隆不了)
- 修改 IP 地址和主机名称
vim /etc/sysconfig/network-scripts/ifcfg-ens33
vim /etc/hostname
- 拷贝 hadoop102 的
/opt/module
目录和/etc/profile.d/my_env.sh
到 hadoop105
scp -r module/* root@hadoop105:/opt/module/
scp /etc/profile.d/my_env.sh root@hadoop105:/etc/profile.d/my_env.sh
source /etc/profile
- 删除 hadoop105 上 Hadoop 的历史数据,data 和 log 数据
rm -rf data/ logs/
- 配置 hadoop102 和 hadoop103 到 hadoop105 的 ssh 无密登录
cd
cd .ssh/
ssh-copy-id hadoop105
🍟服役新节点具体步骤:
# 直接启动 DataNode,即可关联到集群
hdfs --daemon start datanode
yarn --daemon start nodemanager
# 在白名单中增加hadoop105并分发
xsync whitelist
# hadoop102 上刷新 NameNode
hdfs dfsadmin -refreshNodes
# 测试hadoop105
hadoop fs -put /opt/module/hadoop/LICENSE.txt
3. 服务器间数据均衡
在企业开发中,如果经常在 hadoop102 和 hadoop104 上提交任务,且副本数为 2,由于数据本地性原则,就会导致 hadoop102 和 hadoop104 数据过多,hadoop103 存储的数据量小。另一种情况,就是新服役的服务器数据量比较少,需要执行集群均衡命令(针对的是单节点的外部进行操作)
🍟开启数据均衡命令:
start-balancer.sh -threshold 10
对于参数 10,代表的是集群中各个节点的磁盘空间利用率相差不超过 10%,可根据实际情况进行调整
🍟停止数据均衡命令:
sbin/stop-balancer.sh
由于 HDFS 需要启动单独的 Rebalance Server 来执行 Rebalance 操作,所以尽量不要在 NameNode 上执行 start-balancer.sh,而是找一台比较空闲的机器
4. 黑名单动态退役节点
黑名单:表示在黑名单的主机 IP 地址不允许访问。企业中:配置黑名单,用来退役服务器。
🍟配置步骤:
- 编辑
/opt/module/hadoop/etc/hadoop
目录下的 blacklist 文件,添加要退役的节点名(hadoop105) - 分发配置文件 blacklist,hdfs-site.xml
xsync blacklist hdfs-site.xml
-
第一次添加黑名单必须重启集群,不是第一次,只需要刷新 NameNode 节点即可
-
查 Web 浏览器,退役节点的状态为
decommission in progress
(退役中),说明数据节点正在复制块到其他节点
-
等待退役节点状态为 decommissioned(所有块已经复制完成),停止该节点及节点资源管理器。注意:如果副本数是 3,服役的节点小于等于 3,是不能退役成功的,需要修改副本数后才能退役
# 执行以下命令,才能跟集群彻底断开连接
hdfs --daemon stop datanode
yarn --daemon stop nodemanager
- 如果数据不均衡,可以用命令实现集群的再平衡
start-balancer.sh -threshold 10
五、HDFS——存储优化
演示纠删码和异构存储需要一共 5 台虚拟机。尽量拿另外一套集群。提前准备 5 台服务器的集群。
1. 纠删码
🍟纠删码原理:HDFS 默认情况下,一个文件有 3 个副本,这样提高了数据的可靠性,但也带来了 2 倍的冗余开销。Hadoop3.x 引入了纠删码,采用计算的方式,可以节省约 50%左右的存储空间(用计算换存储)
🍟纠删码操作相关的命令:hdfs ec 参数
# 查看相关命令
hdfs ec
# 列出当前所有纠删码策略
hdfs ec -listPolicies
🍟纠删码策略解读
RS-3-2-1024k
策略:使用 RS 编码,每 3 个数据单元,生成 2 个校验单元,共 5 个单元,也就是说:这 5 个单元中,只要有任意的 3 个单元存在(不管是数据单元还是校验单元,只要总数=3),就可以得到原始数据。每个单元的大小是 1024k=1024*1024=1048576RS-10-4-1024k
策略:使用 RS 编码,每 10 个数据单元(cell),生成 4 个校验单元,共 14个单元,也就是说:这 14 个单元中,只要有任意的 10 个单元存在(不管是数据单元还是校验单元,只要总数=10),就可以得到原始数据。每个单元的大小是 1024k=1024*1024=1048576RS-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。
🍟纠删码案例实操:
纠删码策略是给具体一个路径设置。所有往此路径下存储的文件,都会执行此策略。默认只开启对
RS-6-3-1024k
策略的支持,如要使用别的策略需要提前启用。
🌰需求:将/input
目录设置为 RS-3-2-1024k
策略
🌰具体步骤:
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 web.log /input
上传的文件需要大于 2M 才能看出效果。(低于 2M,只有一个数据单元和两个校验单元)
4️⃣查看存储路径的数据单元和校验单元,并作破坏实验
# 查看存储的是数据还是校验单元,看不懂的就是校验单元
cat /opt/module/hadoop/data/current/BP-148040074-192.168.150.102-16122861234999/current/finalized/subdir0/subdir0/blk_-9223378036854775776
# 破坏实验:删除掉路径下所有文件,尝试删两台、三台,查看是否可以执行任务
2. 异构存储(冷热数据分离)
异构存储主要解决,不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。
2.1. 存储类型和存储策略
2.2. 异构存储和Shell操作
# 查看当前有哪些存储策略可以用
hdfs storagepolicies -listPolicies
# 为指定路径(数据存储目录)设置指定的存储策略
hdfs storagepolicies -setStoragePolicy -path xxx -policy xxx
# 获取指定路径(数据存储目录或文件)的存储策略
hdfs storagepolicies -getStoragePolicy -path xxx
# 取消存储策略;执行改命令之后该目录或者文件,以其上级的目录为准,如果是根目录,那么就是 HOT
hdfs storagepolicies -unsetStoragePolicy -path xxx
# 查看文件块的分布
hdfs fsck xxx -files -blocks -locations
# 查看集群节点
hadoop dfsadmin -report
2.3. 测试环境准备
🍟测试环境描述:服务器规模5 台,集群副本数为 2,创建好带有存储类型的目录(提前创建)
🍟配置文件信息:
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:///opt/module/hadoop/hdfsdata/ssd,[RAM_DISK]file:///opt/module/hadoop/hdfsdata/ram_disk</value>
</property>
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:///opt/module/hadoop/hdfsdata/ssd,[DISK]file:///opt/module/hadoop/hdfsdata/disk</value>
</property>
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:///opt/module/hdfsdata/ram_disk,[DISK]file:///opt/module/hadoop/hdfsdata/disk</value>
</property>
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:///opt/module/hadoop/hdfsdata/archive</value>
</property>
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:///opt/module/hadoop/hdfsdata/archive</value>
</property>
最后格式化集群
# 第一步:杀死进程
myhadoop.sh stop
# 第二步:删除data/ logs/文件,每个服务器都要
rm -rf data/ logs/
# 第三步:HDFS格式化
hdfs namenode -format
# 第四步:重启集群
myhadoop.sh start
🍟数据准备:
# 在 HDFS 上创建文件目录
hadoop fs -mkdir /hdfsdata
# 并将文件资料上传
hadoop fs -put /opt/module/hadoop/NOTICE.txt /hdfsdata
最后生成两个副本,在hadoop103、hadoop104上,说明存储在磁盘上(DISK)
2.4. HOT 存储策略案例
# 最开始我们未设置存储策略的情况下,我们获取该目录的存储策略
hdfs storagepolicies -getStoragePolicy -path /hdfsdata
# 我们查看上传的文件块分布
hdfs fsck /hdfsdata -files -blocks -locations
未设置存储策略,所有文件块都存储在 DISK 下。所以,默认存储策略为 HOT
2.5. WARM 存储策略测试
# 接下来我们为数据降温
hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy WARM
# 再次查看文件块分布,我们可以看到文件块依然放在原处。
hdfs fsck /hdfsdata -files -blocks -locations
# 我们需要让他 HDFS 按照存储策略自行移动文件块
hdfs mover /hdfsdata
# 再次查看文件块分布,
hdfs fsck /hdfsdata -files -blocks -location
查看可知,文件块一半在 DISK,一半在 ARCHIVE,符合我们设置的 WARM 策略
2.6. COLD 策略测试
# 我们继续将数据降温为 cold
hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy COLD
# 注意:当我们将目录设置为 COLD 并且我们未配置 ARCHIVE 存储目录的情况下,不可以向该目录直接上传文件,会报出异常。
# 手动转移
hdfs mover /hdfsdata
# 再次查看文件块分布,
hdfs fsck /hdfsdata -files -blocks -location
查看可知,所有文件块都在 ARCHIVE,符合 COLD 存储策略
2.7. ONE_SSD 策略测试
# 接下来我们将存储策略从默认的 HOT 更改为 One_SSD
hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy One_SSD
# 手动转移文件块
hdfs mover /hdfsdata
# 转移完成后,我们查看文件块分布
bin/hdfs fsck /hdfsdata -files -blocks -locations
查看可知,文件块分布为一半在 SSD,一半在 DISK,符合 One_SSD 存储策略。
2.8. ALL_SSD 策略测试
# 接下来,我们再将存储策略更改为 All_SSD
hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy All_SSD
# 手动转移文件块
hdfs mover /hdfsdata
# 查看文件块分布,我们可以看到
bin/hdfs fsck /hdfsdata -files -blocks -locations
查看可知,所有的文件块都存储在 SSD,符合 All_SSD 存储策略。
2.9. LAZY_PERSIST 策略测试
# 继续改变策略,将存储策略改为 lazy_persist
hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy lazy_persist
# 手动转移文件块
hdfs mover /hdfsdata
# 查看文件块分布
hdfs fsck /hdfsdata -files -blocks -locations
这里我们发现所有的文件块都是存储在 DISK,按照理论一个副本存储在 RAM_DISK,其他副本存储在 DISK 中,这是因为
hdfs-default.xml
配置文件写了不许存在内存里(0),而且是一块一块存要有那么大的内存吧,我们还需要配置dfs.datanode.max.locked.memory
、dfs.block.size
参数。
💡存储策略为 LAZY_PERSIST 时,文件块副本都存储在 DISK 上的原因有如下两点:
- 当客户端所在的 DataNode 节点没有 RAM_DISK 时,则会写入客户端所在的DataNode 节点的 DISK 磁盘,其余副本会写入其他节点的 DISK 磁盘。
- 当客户端所在的 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.
👉查看max locked memory
的值(64KB):
ulimit -a
六、HDFS——故障排除
采用三台服务器即可,恢复到 Yarn 开始的服务器快照
1. NameNode故障处理
🍟需求:NameNode 进程挂了并且存储的数据也丢失了,如何恢复 NameNode
# 故障模拟
kill -9 NameNode 进程
# 再删除 NameNode 存储的数据(/opt/module/hadoop/data/tmp/dfs/name)
rm -rf /opt/module/hadoop/data/dfs/name/*
# 解决方案
# 拷贝 SecondaryNameNode 中数据到原 NameNode 存储数据目录
scp -r hadoop@hadoop104:/opt/module/hadoop/data/dfs/namesecondary/* ./name/
# 再重新启动 NameNode
hdfs --daemon start namenode
2. 集群安全模式&磁盘修复(重要)
重新启动集群后,立即来到集群上删除数据,集群提示处于安全模式
🍟安全模式:文件系统只接受读数据请求,而不接受删除、修改等变更请求
🍟进入安全模式场景:
➢ NameNode 在加载镜像文件和编辑日志期间处于安全模式
➢ NameNode 再接收 DataNode 注册时,处于安全模式
🍟退出安全模式条件:
dfs.namenode.safemode.min.datanodes
:最小可用 datanode 数量,默认 0dfs.namenode.safemode.threshold-pct
:副本数达到最小要求的 block 占系统总 block 数的百分比,默认 0.999f(只允许丢一个块)dfs.namenode.safemode.extension
:稳定时间,默认值 30000 毫秒,即 30 秒
🍟基本语法:集群处于安全模式,不能执行重要操作(写操作)。集群启动完成后,自动退出安全模式。
# 查看安全模式状态
bin/hdfs dfsadmin -safemode get
# 进入安全模式状态
bin/hdfs dfsadmin -safemode enter
# 离开安全模式状态
bin/hdfs dfsadmin -safemode leave
# 等待安全模式状态
bin/hdfs dfsadmin -safemode wait
🌰案例:磁盘修复(数据块损坏,进入安全模式,如何处理)
- 分 别 进 入 hadoop102 、 hadoop103 、 hadoop104 的
/opt/module/hadoop/data/dfs/data/current/BP-1015489500-192.168.150.102-1611909480872/current/finalized/subdir0/subdir0
目录,统一删除某 2 个块信息
rm -rf blk_1073741847 blk_1073741847_1023.meta
rm -rf blk_1073741865 blk_1073741865_1042.meta
- 重新启动集群
- 查看安全模式是否开启 👉点击前往
- 离开安全模式
bin/hdfs dfsadmin -safemode leave
- 这下每次都会显示丢失的文件,要么断电恢复数据,要么把元数据删除,才能解除报错
🌰案例:模拟等待安全模式
- 查看当前模式,并进入安全模式
bin/hdfs dfsadmin -safemode get
bin/hdfs dfsadmin -safemode enter
/opt/module/hadoop/
创建并执行safemode.sh脚本
#!/bin/bash
hdfs dfsadmin -safemode wait
hdfs dfs -put /opt/module/hadoop/README.txt /
- 加上执行权限并执行
# 加上权限
chmod 777 safemode.sh
# 执行发现阻塞了,进入了等待安全模式
./safemode.sh
# 离开安全模式,脚本执行完毕
sbin/hdfs dfsadmin -safemode leave
3. 慢磁盘监控
“慢磁盘”指的时写入数据非常慢的一类磁盘。其实慢性磁盘并不少见,当机器运行时间长了,上面跑的任务多了,磁盘的读写性能自然会退化,严重时就会出现写入数据延时的问题
🍟如何发现慢磁盘?正常在 HDFS 上创建一个目录,只需要不到 1s 的时间。如果你发现创建目录超过 1 分钟及以上,而且这个现象并不是每次都有。只是偶尔慢了一下,就很有可能存在慢磁盘。
🍟可以采用如下方法找出是哪块磁盘慢:
- 通过心跳未联系时间
一般出现慢磁盘现象,会影响到 DataNode 与 NameNode 之间的心跳。正常情况心跳时间间隔是 3s。超过 3s 说明有异常。 fio
命令,测试磁盘的读写性能(看读写速度)
yum install -y fio
# 顺序读测试
fio -filename=/home/ygy/test.log -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_r
# 顺序写测试
fio -filename=/home/ygy/test.log -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_w
# 随机写测试
fio -filename=/home/ygy/test.log -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_randw
# 混合随机读写
fio -filename=/home/ygy/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
4. 小文件归档
HDFS 存储小文件弊端
每个文件均按块存储,每个块的元数据存储在 NameNode 的内存中,因此 HDFS 存储小文件会非常低效。因为大量的小文件会耗尽 NameNode 中的大部分内存。但注意,存储小文件所需要的磁盘容量和数据块的大小无关。例如,一个 1MB 的文件设置为 128MB 的块存储,实际使用的是 1MB 的磁盘空间,而不是 128MB
🍟解决存储小文件办法之一
HDFS 存档文件或 HAR 文件,是一个更高效的文件存档工具,它将文件存入 HDFS 块,在减少 NameNode 内存使用的同时,允许对文件进行透明的访问。具体说来,HDFS 存档文件对内还是一个一个独立文件,对 NameNode 而言却是一个整体,减少了 NameNode 的内存
🌰案例实操:把/input
目录里面的所有文件归档成一个叫 input.har
的归档文件,并把归档后文件存储到/output
路径下
# 启动Yarn进程
start-yarn.sh
# 归档文件
hadoop archive -archiveName input.har -p /input /output
# 查看归档(合集)
hadoop fs -ls /output/input.har
# 查看归档(独立)
hadoop fs -ls har:///output/input.har
# 解归档文件
hadoop fs -cp har:///output/input.har/* /
七、HDFS——集群迁移
Apache 和 Apache 集群间数据拷贝
🍟scp
实现两个远程主机之间的文件复制
# 推 push
scp -r hello.txt root@hadoop103:/user/ygy/hello.txt
# 拉 pull
scp -r root@hadoop103:/user/ygy/hello.txt hello.txt
# 是通过本地主机中转实现两个远程主机的文件复制;如果在两个远程主机之间 ssh 没有配置的情况下可以使用该方式
scp -r root@hadoop103:/user/ygy/hello.txt root@hadoop104:/user/ygy
🍟采用 distcp
命令实现两个 Hadoop 集群之间的递归数据复制
bin/hadoop distcp hdfs://hadoop102:8020/user/ygy/hello.txt hdfs://hadoop105:8020/user/ygy/hello.txt
八、MapReduce生产经验
MapReduce程序效率的瓶颈在于两点:
- 计算机性能
CPU、内存、磁盘、网络- I/O 操作优化
数据倾斜、Map 运行时间太长、导致 Reduce 等待过久、小文件过多
1. MapReduce 常用调优参数
🍟MapReduce优化
- Map阶段的shuffer
- Reduce阶段的shuffer
Reduce 能不用就尽量不用,避免有 shuffer 阶段降低效率
2. MapReduce 数据倾斜问题
🍟数据倾斜现象(reduce)
- 数据频率倾斜——某一个区域的数据量要远远大于其他区域。
- 数据大小倾斜——部分记录的大小远远大于平均值。
🍟减少数据倾斜的方法
- 首先检查是否空值过多造成的数据倾斜。生产环境,可以直接过滤掉空值;如果想保留空值,就自定义分区,将空值加随机数打散。最后再二次聚合。
- 能在 map 阶段提前处理,最好先在 Map 阶段处理。如:Combiner(Map阶段提前预聚合)、MapJoin
- 设置多个 reduce 个数
九、Hadoop_Yarn生产经验
常用的调优参数
# Resourcemanager 相关
# 处理调度器请求的线程数量
yarn.resourcemanager.scheduler.client.thread-count ResourceManager
# 配置调度器
yarn.resourcemanager.scheduler.class
# Nodemanager 相关
# 使用内存数
yarn.nodemanager.resource.memory-mb NodeManager
# 为系统保留多少内存,和上一个参数二者取一即可
yarn.nodemanager.resource.system-reserved-memory-mb NodeManager
# 使用 CPU 核数
yarn.nodemanager.resource.cpu-vcores NodeManager
# 是否将虚拟核数当作 CPU 核数
yarn.nodemanager.resource.count-logical-processors-as-cores
# 虚拟核数和物理核数乘数,例如:4 核 8 线程,该参数就应设为 2
yarn.nodemanager.resource.pcores-vcores-multiplier
# 是否让 yarn 自己检测硬件进行配置
yarn.nodemanager.resource.detect-hardware-capabilities
# 是否开启物理内存检查限制 container
yarn.nodemanager.pmem-check-enabled
# 是否开启虚拟内存检查限制 container
yarn.nodemanager.vmem-check-enabled
# 虚拟内存物理内存比例
yarn.nodemanager.vmem-pmem-ratio
# Container 容器相关
# 容器最小内存
yarn.scheduler.minimum-allocation-mb
# 容器最大内存
yarn.scheduler.maximum-allocation-mb
# 容器最小核数
yarn.scheduler.minimum-allocation-vcores
# 容器最大核数
yarn.scheduler.maximum-allocation-vcores
容量调度器使用以及公平调度器使用,详见👉这里
十、Hadoop综合调优
1. Hadoop小文件优化方法
🍟Hadoop 小文件弊端:
- HDFS 上每个文件都要在 NameNode 上创建对应的元数据,这个元数据的大小约为150byte,这样当小文件比较多的时候,就会产生很多的元数据文件,一方面会大量占用NameNode 的内存空间,另一方面就是元数据文件过多,使得寻址索引速度变慢
- 小文件过多,在进行 MR 计算时,会生成过多切片,需要启动过多的 MapTask。每个MapTask 处理的数据量小,导致 MapTask 的处理时间比启动时间还小,白白消耗资源
🍟Hadoop 小文件解决方案
- 在数据采集的时候,就将小文件或小批数据合成大文件再上传 HDFS(数据源头)
- Hadoop Archive(存储方向):是一个高效的将小文件放入 HDFS 块中的文件存档工具,能够将多个小文件打包成一个 HAR 文件,从而达到减少 NameNode 的内存使用
- CombineTextInputFormat(计算方向):CombineTextInputFormat 用于将多个小文件在切片过程中生成一个单独的切片或者少量的切片。
- 开启 uber 模式,实现 JVM 重用(计算方向):默认情况下,每个 Task 任务都需要启动一个 JVM 来运行,如果 Task 任务计算的数据量很小,我们可以让同一个 Job 的多个 Task 运行在一个 JVM 中,不必为每个 Task 都开启一个 JVM。
# 未开启 uber 模式,在/input 路径上上传多个小文件并执行 wordcount 程序
hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar wordcount /input /output2
# 观察控制台,可以看到开启了9个容器,uber模式未打开
running in uber mode : false
- 修改
mapred-site.xml
,开启 uber 模式(只能向下调整)
<!-- 开启 uber 模式,默认关闭 -->
<property>
<name>mapreduce.job.ubertask.enable</name>
<value>true</value>
</property>
<!-- uber 模式中最大的 mapTask 数量,可向下修改 -->
<property>
<name>mapreduce.job.ubertask.maxmaps</name>
<value>9</value>
</property>
<!-- uber 模式中最大的 reduce 数量,可向下修改 -->
<property>
<name>mapreduce.job.ubertask.maxreduces</name>
<value>1</value>
</property>
<!-- uber 模式中最大的输入数据量,默认使用 dfs.blocksize 的值,可向下修改 -->
<property>
<name>mapreduce.job.ubertask.maxbytes</name>
<value></value>
</property>
- 分发
xsync mapred-site.xml
,再次执行wordcount程序,观察 👉点击前往,发现只开启了一个容器
2. 测试MapReduce计算性能
使用 Sort 程序评测 MapReduce,一个虚拟机不超过 150G 磁盘尽量不要执行这段代码
# 使用 RandomWriter 来产生随机数,每个节点运行 10 个 Map 任务,每个 Map 产生大约 1G 大小的二进制随机数
hadoop jar /opt/module/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar randomwriter random-data
# 执行 Sort 程序
hadoop jar /opt/module/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar sort random-data sorted-data
# 验证数据是否真正排好序了
hadoop jar /opt/module/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar testmapredsort -sortInput random-data -sortOutput sorted-data
3. 企业开发场景案例
🍟需求:从 1G 数据中,统计每个单词出现次数。服务器 3 台,每台配置 4G 内存,4 核 CPU,4 线程【1G / 128m = 8 个 MapTask;1 个 ReduceTask;1 个 mrAppMaster;平均每个节点运行 10 个 / 3 台 ≈ 3 个任务(4 3 3)】
3.1. HDFS 参数调优
1️⃣修改hadoop-env.sh
export HDFS_NAMENODE_OPTS="-Dhadoop.security.logger=INFO,RFAS -Xmx1024m"
export HDFS_DATANODE_OPTS="-Dhadoop.security.logger=ERROR,RFAS -Xmx1024m"
2️⃣修改 hdfs-site.xml
<!-- NameNode 有一个工作线程池,默认值是 10 -->
<property>
<name>dfs.namenode.handler.count</name>
<value>21</value>
</property>
3️⃣修改 core-site.xml
<!-- 配置垃圾回收时间为 60 分钟 -->
<property>
<name>fs.trash.interval</name>
<value>60</value>
</property>
4️⃣分发配置
xsync hadoop-env.sh hdfs-site.xml core-site.xml
3.2.MapReduce 参数调优
1️⃣修改 mapred-site.xml
<!-- 环形缓冲区大小,默认 100m -->
<property>
<name>mapreduce.task.io.sort.mb</name>
<value>100</value>
</property>
<!-- 环形缓冲区溢写阈值,默认 0.8 -->
<property>
<name>mapreduce.map.sort.spill.percent</name>
<value>0.80</value>
</property>
<!-- merge 合并次数,默认 10 个 -->
<property>
<name>mapreduce.task.io.sort.factor</name>
<value>10</value>
</property>
<!-- maptask 内存,默认 1g; maptask 堆内存大小默认和该值大小一致 mapreduce.map.java.opts -->
<property>
<name>mapreduce.map.memory.mb</name>
<value>-1</value>
<description>The amount of memory to request from the scheduler for each map task. If this is not specified or is non-positive, it is inferred from mapreduce.map.java.opts and mapreduce.job.heap.memory-mb.ratio. If java-opts are also not specified, we set it to 1024.
</description>
</property>
<!-- matask 的 CPU 核数,默认 1 个 -->
<property>
<name>mapreduce.map.cpu.vcores</name>
<value>1</value>
</property>
<!-- matask 异常重试次数,默认 4 次 -->
<property>
<name>mapreduce.map.maxattempts</name>
<value>4</value>
</property>
<!-- 每个 Reduce 去 Map 中拉取数据的并行数。默认值是 5 -->
<property>
<name>mapreduce.reduce.shuffle.parallelcopies</name>
<value>5</value>
</property>
<!-- Buffer 大小占 Reduce 可用内存的比例,默认值 0.7 -->
<property>
<name>mapreduce.reduce.shuffle.input.buffer.percent</name>
<value>0.70</value>
</property>
<!-- Buffer 中的数据达到多少比例开始写入磁盘,默认值 0.66 -->
<property>
<name>mapreduce.reduce.shuffle.merge.percent</name>
<value>0.66</value>
</property>
<!-- reducetask 内存,默认 1g;reducetask 堆内存大小默认和该值大小一致mapreduce.reduce.java.opts -->
<property>
<name>mapreduce.reduce.memory.mb</name>
<value>-1</value>
<description>The amount of memory to request from the scheduler for each reduce task. If this is not specified or is non-positive, it is inferred from mapreduce.reduce.java.opts and mapreduce.job.heap.memory-mb.ratio. If java-opts are also not specified, we set it to 1024.
</description>
</property>
<!-- reducetask 的 CPU 核数,默认 1 个 -->
<property>
<name>mapreduce.reduce.cpu.vcores</name>
<value>2</value>
</property>
<!-- reducetask 失败重试次数,默认 4 次 -->
<property>
<name>mapreduce.reduce.maxattempts</name>
<value>4</value>
</property>
<!-- 当 MapTask 完成的比例达到该值后才会为 ReduceTask 申请资源。默认是 0.05 -->
<property>
<name>mapreduce.job.reduce.slowstart.completedmaps</name>
<value>0.05</value>
</property>
<!-- 如果程序在规定的默认 10 分钟内没有读到数据,将强制超时退出 -->
<property>
<name>mapreduce.task.timeout</name>
<value>600000</value>
</property>
2️⃣分发配置
xsync mapred-site.xml
3.3. Yarn 参数调优
1️⃣修改 yarn-site.xml
配置参数如下
<!-- 选择调度器,默认容量 -->
<property>
<description>The class to use as the resource scheduler.</description>
<name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value>
</property>
<!-- ResourceManager 处理调度器请求的线程数量,默认 50;如果提交的任务数大于 50,可以
增加该值,但是不能超过 3 台 * 4 线程 = 12 线程(去除其他应用程序实际不能超过 8) -->
<property>
<description>Number of threads to handle scheduler interface.</description>
<name>yarn.resourcemanager.scheduler.client.thread-count</name>
<value>8</value>
</property>
<!-- 是否让 yarn 自动检测硬件进行配置,默认是 false,如果该节点有很多其他应用程序,建议手动配置。如果该节点没有其他应用程序,可以采用自动 -->
<property>
<description>Enable auto-detection of node capabilities such as memory and CPU.
</description>
<name>yarn.nodemanager.resource.detect-hardware-capabilities</name>
<value>false</value>
</property>
<!-- 是否将虚拟核数当作 CPU 核数,默认是 false,采用物理 CPU 核数 -->
<property>
<name>yarn.nodemanager.resource.count-logical-processors-ascores</name>
<value>false</value>
</property>
<!-- 虚拟核数和物理核数乘数,默认是 1.0 -->
<property>
<name>yarn.nodemanager.resource.pcores-vcores-multiplier</name>
<value>1.0</value>
</property>
<!-- NodeManager 使用内存数,默认 8G,修改为 4G 内存 -->
<property>
<name>yarn.nodemanager.resource.memory-mb</name>
<value>4096</value>
</property>
<!-- nodemanager 的 CPU 核数,不按照硬件环境自动设定时默认是 8 个,修改为 4 个 -->
<property>
<name>yarn.nodemanager.resource.cpu-vcores</name>
<value>4</value>
</property>
<!-- 容器最小内存,默认 1G -->
<property>
<name>yarn.scheduler.minimum-allocation-mb</name>
<value>1024</value>
</property>
<!-- 容器最大内存,默认 8G,修改为 2G -->
<property>
<name>yarn.scheduler.maximum-allocation-mb</name>
<value>2048</value>
</property>
<!-- 容器最小 CPU 核数,默认 1 个 -->
<property>
<name>yarn.scheduler.minimum-allocation-vcores</name>
<value>1</value>
</property>
<!-- 容器最大 CPU 核数,默认 4 个,修改为 2 个 -->
<property>
<name>yarn.scheduler.maximum-allocation-vcores</name>
<value>2</value>
</property>
<!-- 虚拟内存检查,默认打开,修改为关闭 -->
<property>
<description>Whether virtual memory limits will be enforced for
containers.</description>
<name>yarn.nodemanager.vmem-check-enabled</name>
<value>false</value>
</property>
<!-- 虚拟内存和物理内存设置比例,默认 2.1 -->
<property>
<name>yarn.nodemanager.vmem-pmem-ratio</name>
<value>2.1</value>
</property>
2️⃣分发配置
xsync yarn-site.xml
3.4. 执行程序
1️⃣重启集群
myhadoop.sh stop
myhadoop.sh start
2️⃣执行 WordCount 程序
hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar wordcount /input /output
3️⃣查看 Yarn 任务执行页面👉点击前往
总结
一、Hadoop入门
1、常用端口号
hadoop3.x
HDFS NameNode 内部通常端口:8020/9000/9820
HDFS NameNode 对用户的查询端口:9870
Yarn查看任务运行情况的:8088
历史服务器:19888
hadoop2.x
HDFS NameNode 内部通常端口:8020/9000
HDFS NameNode 对用户的查询端口:50070
Yarn查看任务运行情况的:8088
历史服务器:19888
2、常用的配置文件
3.x core-site.xml hdfs-site.xml yarn-site.xml mapred-site.xml workers
2.x core-site.xml hdfs-site.xml yarn-site.xml mapred-site.xml slaves
二、HDFS
1、HDFS文件块大小(面试重点)
硬盘读写速度
在企业中 一般128m(中小公司) 256m (大公司)
2、HDFS的Shell操作(开发重点)
3、HDFS的读写流程(面试重点)
三、Map Reduce
1、InputFormat
1)默认的是TextInputformat kv key偏移量,v :一行内容
2)处理小文件CombineTextInputFormat 把多个文件合并到一起统一切片
2、Mapper
setup()初始化; map()用户的业务逻辑; clearup() 关闭资源;
3、分区
默认分区HashPartitioner ,默认按照key的hash值%numreducetask个数
自定义分区
4、排序
1)部分排序 每个输出的文件内部有序。
2)全排序: 一个reduce ,对所有数据大排序。
3)二次排序: 自定义排序范畴, 实现 writableCompare接口, 重写compareTo方法
总流量倒序 按照上行流量 正序
5、Combiner
前提:不影响最终的业务逻辑(求和 没问题 求平均值)
提前聚合map => 解决数据倾斜的一个方法
6、Reducer
用户的业务逻辑;
setup()初始化;reduce()用户的业务逻辑; clearup() 关闭资源;
7、OutputFormat
1)默认TextOutputFormat 按行输出到文件
2)自定义
四、Yarn
1、Yarn的工作机制(面试题)
2、Yarn的调度器
1)FIFO/容量/公平
2)apache 默认调度器 容量; CDH默认调度器 公平
3)公平/容量默认一个default ,需要创建多队列
4)中小企业:hive spark flink mr
5)中大企业:业务模块:登录/注册/购物车/营销
6)好处:解耦 降低风险 11.11 6.18 降级使用
7)每个调度器特点:
相同点:支持多队列,可以借资源,支持多用户
不同点:容量调度器:优先满足先进来的任务执行
公平调度器,在队列里面的任务公平享有队列资源
8)生产环境怎么选:
中小企业,对并发度要求不高,选择容量
中大企业,对并发度要求比较高,选择公平。
3、开发需要重点掌握:
1)队列运行原理
2)Yarn常用命令
3)核心参数配置
4)配置容量调度器和公平调度器。
5)tool接口使用。