无论何时,无论遇到何事,都要保持年轻的心态。放下过往陈旧的观念,打破固有的认知经验,去探索新鲜的事物,把更多时间放在修炼自我上。——人民日报
HDFS—核心参数
NameNode内存生产配置
1)NameNode内存计算
每个文件块大概占用150byte,一台服务器128G内存为例,能存储多少文件块呢?
128 * 1024 * 1024 * 1024 / 150Byte ≈ 9.1亿
G MB KB Byte
2)Hadoop2.x系列,配置NameNode内存
NameNode内存默认2000m,如果服务器内存4G,NameNode内存可以配置3g。在hadoop-env.sh文件中配置如下。
1 | HADOOP_NAMENODE_OPTS=-Xmx3072m |
3)Hadoop3.x系列,配置NameNode内存
(1)hadoop-env.sh中描述Hadoop的内存是动态分配的
1 | The maximum amount of heap to use (Java -Xmx). If no unit |
(2)查看NameNode占用内存
1 | [shangbaishuyao@hadoop102 ~]$ jps |
(3)查看DataNode占用内存
1 | [shangbaishuyao@hadoop102 ~]$ jmap -heap 2744 |
查看发现hadoop102上的NameNode和DataNode占用内存都是自动分配的,且相等。不是很合理。
经验参考:
具体修改:hadoop-env.sh
1 | export HDFS_NAMENODE_OPTS="-Dhadoop.security.logger=INFO,RFAS -Xmx1024m" |
NameNode心跳并发配置
1)hdfs-site.xml
1 | 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. |
企业经验:dfs.namenode.handler.count=,比如集群规模(DataNode台数)为3台时,此参数设置为21。可通过简单的python代码计算该值,代码如下。
1 | [shangbaishuyao@hadoop102 ~]$ sudo yum install -y python |
开启回收站配置
开启回收站功能,可以将删除的文件在不超时的情况下,恢复原数据,起到防止误删除、备份等作用。
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分钟。
1 | <property> |
4)查看回收站
回收站目录在HDFS集群中的路径:/user/shangbaishuyao/.Trash/….
5)注意:通过网页上直接删除的文件也不会走回收站。
6)通过程序删除的文件不会经过回收站,需要调用moveToTrash()才进入回收站
1 | Trash trash = New Trash(conf); |
7)只有在命令行利用hadoop fs -rm命令删除的文件才会走回收站。
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hadoop fs -rm -r /user/shangbaishuyao/input |
8)恢复回收站数据
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hadoop fs -mv |
HDFS—集群压测
在企业中非常关心每天从Java后台拉取过来的数据,需要多久能上传到集群?消费者关心多久能从HDFS上拉取需要的数据?
为了搞清楚HDFS的读写性能,生产环境上非常需要对集群进行压测。
HDFS的读写性能主要受网络和磁盘影响比较大。为了方便测试,将hadoop102、hadoop103、hadoop104虚拟机网络都设置为100mbps。
100Mbps单位是bit;10M/s单位是byte ; 1byte=8bit,100Mbps/8=12.5M/s。
测试网速:来到hadoop102的/opt/module目录,创建一个
1 | [shangbaishuyao@hadoop102 software]$ python -m SimpleHTTPServer |
测试HDFS写性能
0)写测试底层原理
1)测试内容:向HDFS集群写10个128M的文件
1 | [shangbaishuyao@hadoop102 mapreduce]$ 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 128MB |
注意: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
1 | <!--是否启动一个线程检查每个任务正使用的虚拟内存量,如果任务超出分配值,则直接将其杀掉,默认是true --> |
(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)如果客户端不在集群节点,那就三个副本都参与计算
测试HDFS读性能
1)测试内容:读取HDFS集群10个128M的文件
1 | [shangbaishuyao@hadoop102 mapreduce]$ 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 128MB |
2)删除测试生成数据
1 | [shangbaishuyao@hadoop102 mapreduce]$ hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -clean |
3)测试结果分析:为什么读取文件速度大于网络带宽?由于目前只有三台服务器,且有三个副本,数据读取就近原则,相当于都是读取的本地磁盘数据,没有走网络。
HDFS—多目录
NameNode多目录配置
1)NameNode的本地目录可以配置成多个,且每个目录存放内容相同,增加了可靠性
2)具体配置如下
(1)在hdfs-site.xml文件中添加如下内容
1 | <property> |
注意:因为每台服务器节点的磁盘情况不同,所以这个配置配完之后,可以选择不分发
(2)停止集群,删除三台节点的data和logs中所有数据。
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ rm -rf data/ logs/ |
(3)格式化集群并启动。
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ bin/hdfs namenode -format |
3)查看结果
1 | [shangbaishuyao@hadoop102 dfs]$ ll |
检查name1和name2里面的内容,发现一模一样。
DataNode多目录配置
1)DataNode可以配置成多个目录,每个目录存储的数据不一样(数据不是副本)
2)具体配置如下
在hdfs-site.xml文件中添加如下内容
1 | <property> |
3)查看结果
1 | [shangbaishuyao@hadoop102 dfs]$ ll |
4)向集群上传一个文件,再次观察两个文件夹里面的内容发现不一致(一个有数一个没有)
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hadoop fs -put wcinput/word.txt / |
集群数据均衡之磁盘间数据均衡
生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性)
(1)生成均衡计划(我们只有一块磁盘,不会生成计划)
1 | hdfs diskbalancer -plan hadoop103 |
(2)执行均衡计划
1 | hdfs diskbalancer -execute hadoop103.plan.json |
(3)查看当前均衡任务的执行情况
1 | hdfs diskbalancer -query hadoop103 |
(4)取消均衡任务
1 | hdfs diskbalancer -cancel hadoop103.plan.json |
HDFS—集群扩容及缩容
添加白名单
白名单:表示在白名单的主机IP地址可以,用来存储数据。
企业中:配置白名单,可以尽量防止黑客恶意访问攻击。
配置白名单步骤如下:
1)在NameNode节点的/opt/module/hadoop-3.1.3/etc/hadoop目录下分别创建whitelist 和blacklist文件
(1)创建白名单
1 | [shangbaishuyao@hadoop102 hadoop]$ vim whitelist |
在whitelist中添加如下主机名称,假如集群正常工作的节点为102 103
1 | hadoop102 |
(2)创建黑名单
1 | [shangbaishuyao@hadoop102 hadoop]$ touch blacklist |
保持空的就可以
2)在hdfs-site.xml配置文件中增加dfs.hosts配置参数
1 | <!-- 白名单 --> |
3)分发配置文件whitelist,hdfs-site.xml
1 | [shangbaishuyao@hadoop104 hadoop]$ xsync hdfs-site.xml whitelist |
4)第一次添加白名单必须重启集群,不是第一次,只需要刷新NameNode节点即可
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ myhadoop.sh stop |
5)在web浏览器上查看DN,http://hadoop102:9870/dfshealth.html#tab-datanode 注意: hadoop102位服务器IP地址
6)在hadoop104上执行上传数据数据失败
1 | [shangbaishuyao@hadoop104 hadoop-3.1.3]$ hadoop fs -put NOTICE.txt / |
7)二次修改白名单,增加hadoop104
1 | [shangbaishuyao@hadoop102 hadoop]$ vim whitelist |
8)刷新NameNode
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs dfsadmin -refreshNodes |
9)在web浏览器上查看DN,http://hadoop102:9870/dfshealth.html#tab-datanode
服役新服务器
1)需求
随着公司业务的增长,数据量越来越大,原有的数据节点的容量已经不能满足存储数据的需求,需要在原有集群基础上动态添加新的数据节点。
2)环境准备
(1)在hadoop100主机上再克隆一台hadoop105主机
(2)修改IP地址和主机名称
1 | [root@hadoop105 ~]# vim /etc/sysconfig/network-scripts/ifcfg-ens33 |
(3)拷贝hadoop102的/opt/module目录和/etc/profile.d/my_env.sh到hadoop105
1 | [shangbaishuyao@hadoop102 opt]$ scp -r module/* shangbaishuyao@hadoop105:/opt/module/ |
(4)删除hadoop105上Hadoop的历史数据,data和log数据
1 | [shangbaishuyao@hadoop105 hadoop-3.1.3]$ rm -rf data/ logs/ |
(5)配置hadoop102和hadoop103到hadoop105的ssh无密登录
1 | [shangbaishuyao@hadoop102 .ssh]$ ssh-copy-id hadoop105 |
3)服役新节点具体步骤
(1)直接启动DataNode,即可关联到集群
1 | [shangbaishuyao@hadoop105 hadoop-3.1.3]$ hdfs --daemon start datanode |
4)在白名单中增加新服役的服务器
(1)在白名单whitelist中增加hadoop104、hadoop105,并重启集群
1 | [shangbaishuyao@hadoop102 hadoop]$ vim whitelist |
(2)分发
1 | [shangbaishuyao@hadoop102 hadoop]$ xsync whitelist |
(3)刷新NameNode
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs dfsadmin -refreshNodes |
5)在hadoop105上上传文件
1 | [shangbaishuyao@hadoop105 hadoop-3.1.3]$ hadoop fs -put /opt/module/hadoop-3.1.3/LICENSE.txt / |
思考:如果数据不均衡(hadoop105数据少,其他节点数据多),怎么处理?
服务器间数据均衡
1)企业经验:
在企业开发中,如果经常在hadoop102和hadoop104上提交任务,且副本数为2,由于数据本地性原则,就会导致hadoop102和hadoop104数据过多,hadoop103存储的数据量小。
另一种情况,就是新服役的服务器数据量比较少,需要执行集群均衡命令。
2)开启数据均衡命令:
1 | [shangbaishuyao@hadoop105 hadoop-3.1.3]$ sbin/start-balancer.sh -threshold 10 |
对于参数10,代表的是集群中各个节点的磁盘空间利用率相差不超过10%,可根据实际情况进行调整。
3)停止数据均衡命令:
1 | [shangbaishuyao@hadoop105 hadoop-3.1.3]$ sbin/stop-balancer.sh |
注意:由于HDFS需要启动单独的Rebalance Server来执行Rebalance操作,所以尽量不要在NameNode上执行start-balancer.sh,而是找一台比较空闲的机器。
黑名单退役服务器
黑名单:表示在黑名单的主机IP地址不可以,用来存储数据。
企业中:配置黑名单,用来退役服务器。
黑名单配置步骤如下:
1)编辑/opt/module/hadoop-3.1.3/etc/hadoop目录下的blacklist文件
1 | [shangbaishuyao@hadoop102 hadoop] vim blacklist |
添加如下主机名称(要退役的节点)
hadoop105
注意:如果白名单中没有配置,需要在hdfs-site.xml配置文件中增加dfs.hosts配置参数
1 | <!-- 黑名单 --> |
2)分发配置文件blacklist,hdfs-site.xml
1 | [shangbaishuyao@hadoop104 hadoop]$ xsync hdfs-site.xml blacklist |
3)第一次添加黑名单必须重启集群,不是第一次,只需要刷新NameNode节点即可
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs dfsadmin -refreshNodes |
4)检查Web浏览器,退役节点的状态为decommission in progress(退役中),说明数据节点正在复制块到其他节点
5)等待退役节点状态为decommissioned(所有块已经复制完成),停止该节点及节点资源管理器。注意:如果副本数是3,服役的节点小于等于3,是不能退役成功的,需要修改副本数后才能退役
1 | [shangbaishuyao@hadoop105 hadoop-3.1.3]$ hdfs --daemon stop datanode |
stopping datanode
1 | [shangbaishuyao@hadoop105 hadoop-3.1.3]$ yarn --daemon stop nodemanager |
stopping nodemanager
6)如果数据不均衡,可以用命令实现集群的再平衡
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ sbin/start-balancer.sh -threshold 10 |
HDFS—存储优化
注:演示纠删码和异构存储需要一共5台虚拟机。尽量拿另外一套集群。提前准备5台服务器的集群。
纠删码
纠删码原理
HDFS默认情况下,一个文件有3个副本,这样提高了数据的可靠性,但也带来了2倍的冗余开销。Hadoop3.x引入了纠删码,采用计算的方式,可以节省约50%左右的存储空间。
1)纠删码操作相关的命令
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs ec |
2)查看当前支持的纠删码策略
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3] 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=10241024=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。
纠删码案例实操
纠删码策略是给具体一个路径设置。所有往此路径下存储的文件,都会执行此策略。
默认只开启对RS-6-3-1024k策略的支持,如要使用别的策略需要提前启用。
1)需求:将/input目录设置为RS-3-2-1024k策略
2)具体步骤
(1)开启对RS-3-2-1024k策略的支持
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs ec -enablePolicy -policy RS-3-2-1024k |
(2)在HDFS创建目录,并设置RS-3-2-1024k策略
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs dfs -mkdir /input |
(3)上传文件,并查看文件编码后的存储情况
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs dfs -put web.log /input |
注:你所上传的文件需要大于2M才能看出效果。(低于2M,只有一个数据单元和两个校验单元)
(4)查看存储路径的数据单元和校验单元,并作破坏实验
异构存储(冷热数据分离)
异构存储主要解决,不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。
异构存储Shell操作
(1)查看当前有哪些存储策略可以用
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs storagepolicies -listPolicies |
(2)为指定路径(数据存储目录)设置指定的存储策略
1 | hdfs storagepolicies -setStoragePolicy -path xxx -policy xxx |
(3)获取指定路径(数据存储目录或文件)的存储策略
1 | hdfs storagepolicies -getStoragePolicy -path xxx |
(4)取消存储策略;执行改命令之后该目录或者文件,以其上级的目录为准,如果是根目录,那么就是HOT
1 | hdfs storagepolicies -unsetStoragePolicy -path xxx |
(5)查看文件块的分布
1 | bin/hdfs fsck xxx -files -blocks -locations |
(6)查看集群节点
1 | hadoop dfsadmin -report |
测试环境准备
1)测试环境描述
服务器规模:5台
集群配置:副本数为2,创建好带有存储类型的目录(提前创建)
集群规划:
节点 | 存储类型分配 |
---|---|
hadoop102 | RAM_DISK,SSD |
hadoop103 | SSD,DISK |
hadoop104 | DISK,RAM_DISK |
hadoop105 | ARCHIVE |
hadoop106 | ARCHIVE |
2)配置文件信息
(1)为hadoop102节点的hdfs-site.xml添加如下信息
1 | <property> |
(2)为hadoop103节点的hdfs-site.xml添加如下信息
1 | <property> |
(3)为hadoop104节点的hdfs-site.xml添加如下信息
1 | <property> |
(4)为hadoop105节点的hdfs-site.xml添加如下信息
1 | <property> |
(5)为hadoop106节点的hdfs-site.xml添加如下信息
1 | <property> |
3)数据准备
(1)启动集群
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs namenode -format |
(1)并在HDFS上创建文件目录
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hadoop fs -mkdir /hdfsdata |
(2)并将文件资料上传
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hadoop fs -put /opt/module/hadoop-3.1.3/NOTICE.txt /hdfsdata |
HOT存储策略案例
(1)最开始我们未设置存储策略的情况下,我们获取该目录的存储策略
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs storagepolicies -getStoragePolicy -path /hdfsdata |
(2)我们查看上传的文件块分布
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs fsck /hdfsdata -files -blocks -locations |
未设置存储策略,所有文件块都存储在DISK下。所以,默认存储策略为HOT。
WARM存储策略测试
(1)接下来我们为数据降温
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy WARM |
(2)再次查看文件块分布,我们可以看到文件块依然放在原处。
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs fsck /hdfsdata -files -blocks -locations |
(3)我们需要让他HDFS按照存储策略自行移动文件块
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs mover /hdfsdata |
(4)再次查看文件块分布,
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs fsck /hdfsdata -files -blocks -locations |
文件块一半在DISK,一半在ARCHIVE,符合我们设置的WARM策略
COLD策略测试
(1)我们继续将数据降温为cold
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy COLD |
注意:当我们将目录设置为COLD并且我们未配置ARCHIVE存储目录的情况下,不可以向该目录直接上传文件,会报出异常。
(2)手动转移
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs mover /hdfsdata |
(3)检查文件块的分布
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ bin/hdfs fsck /hdfsdata -files -blocks -locations |
所有文件块都在ARCHIVE,符合COLD存储策略。
ONE_SSD策略测试
(1)接下来我们将存储策略从默认的HOT更改为One_SSD
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy One_SSD |
(2)手动转移文件块
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs mover /hdfsdata |
(3)转移完成后,我们查看文件块分布,
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ bin/hdfs fsck /hdfsdata -files -blocks -locations |
文件块分布为一半在SSD,一半在DISK,符合One_SSD存储策略。
ALL_SSD策略测试
(1)接下来,我们再将存储策略更改为All_SSD
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy All_SSD |
(2)手动转移文件块
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs mover /hdfsdata |
(3)查看文件块分布,我们可以看到,
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ bin/hdfs fsck /hdfsdata -files -blocks -locations |
所有的文件块都存储在SSD,符合All_SSD存储策略。
LAZY_PERSIST策略测试
(1)继续改变策略,将存储策略改为lazy_persist
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy lazy_persist |
(2)手动转移文件块
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs mover /hdfsdata |
(3)查看文件块分布
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs fsck /hdfsdata -files -blocks -locations |
这里我们发现所有的文件块都是存储在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,所以,如果参数配置过大,还会报出错误:
1 | ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: Exception in secureMain |
我们可以通过该命令查询此参数的内存
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ ulimit -a |
HDFS—故障排除
注意:采用三台服务器即可,恢复到Yarn开始的服务器快照。
NameNode故障处理
1)需求:
NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode
2)故障模拟
(1)kill -9 NameNode进程
1 | [shangbaishuyao@hadoop102 current]$ kill -9 19886 |
(2)删除NameNode存储的数据(/opt/module/hadoop-3.1.3/data/tmp/dfs/name)
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ rm -rf /opt/module/hadoop-3.1.3/data/dfs/name/* |
3)问题解决
(1)拷贝SecondaryNameNode中数据到原NameNode存储数据目录
1 | [shangbaishuyao@hadoop102 dfs]$ scp -r shangbaishuyao@hadoop104:/opt/module/hadoop-3.1.3/data/dfs/namesecondary/* ./name/ |
(2)重新启动NameNode
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs --daemon start namenode |
(3)向集群上传一个文件
集群安全模式&磁盘修复
1)安全模式:文件系统只接受读数据请求,而不接受删除、修改等变更请求
2)进入安全模式场景
Ø NameNode在加载镜像文件和编辑日志期间处于安全模式;
Ø NameNode再接收DataNode注册时,处于安全模式
3)退出安全模式条件
1 | dfs.namenode.safemode.min.datanodes:最小可用datanode数量,默认0 |
4)基本语法
集群处于安全模式,不能执行重要操作(写操作)。集群启动完成后,自动退出安全模式。
1 | (1)bin/hdfs dfsadmin -safemode get (功能描述:查看安全模式状态) |
5)案例1:启动集群进入安全模式
(1)重新启动集群
1 | [shangbaishuyao@hadoop102 subdir0]$ myhadoop.sh stop |
(2)集群启动后,立即来到集群上删除数据,提示集群处于安全模式
案例2:磁盘修复
需求:数据块损坏,进入安全模式,如何处理
(1)分别进入hadoop102、hadoop103、hadoop104的/opt/module/hadoop-3.1.3/data/dfs/data/current/BP-1015489500-192.168.10.102-1611909480872/current/finalized/subdir0/subdir0目录,统一删除某2个块信息
1 | [shangbaishuyao@hadoop102 subdir0]$ pwd |
说明:hadoop103/hadoop104重复执行以上命令
(2)重新启动集群
1 | [shangbaishuyao@hadoop102 subdir0]$ myhadoop.sh stop |
(3)观察http://hadoop102:9870/dfshealth.html#tab-overview
说明:安全模式已经打开,块的数量没有达到要求。
(4)离开安全模式
1 | [shangbaishuyao@hadoop102 subdir0]$ hdfs dfsadmin -safemode get |
(5)观察http://hadoop102:9870/dfshealth.html#tab-overview
(6)将元数据删除
(7)观察http://hadoop102:9870/dfshealth.html#tab-overview,集群已经正常
案例3:
需求:模拟等待安全模式
(1)查看当前模式
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hdfs dfsadmin -safemode get |
(2)先进入安全模式
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ bin/hdfs dfsadmin -safemode enter |
(3)创建并执行下面的脚本
在/opt/module/hadoop-3.1.3路径上,编辑一个脚本safemode.sh
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ vim safemode.sh |
(4)再打开一个窗口,执行
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ bin/hdfs dfsadmin -safemode leave |
(5)再观察上一个窗口
1 | Safe mode is OFF |
(6)HDFS集群上已经有上传的数据了
慢磁盘监控
“慢磁盘”指的时写入数据非常慢的一类磁盘。其实慢性磁盘并不少见,当机器运行时间长了,上面跑的任务多了,磁盘的读写性能自然会退化,严重时就会出现写入数据延时的问题。
如何发现慢磁盘?
正常在HDFS上创建一个目录,只需要不到1s的时间。如果你发现创建目录超过1分钟及以上,而且这个现象并不是每次都有。只是偶尔慢了一下,就很有可能存在慢磁盘。
可以采用如下方法找出是哪块磁盘慢:
1)通过心跳未联系时间。
一般出现慢磁盘现象,会影响到DataNode与NameNode之间的心跳。正常情况心跳时间间隔是3s。超过3s说明有异常。
2)fio命令,测试磁盘的读写性能
(1)顺序读测试
1 | [shangbaishuyao@hadoop102 ~]# sudo yum install -y fio |
结果显示,磁盘的总体顺序读速度为360MiB/s。
(2)顺序写测试
1 | [shangbaishuyao@hadoop102 ~]# sudo fio -filename=/home/shangbaishuyao/test.log -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_w |
结果显示,磁盘的总体顺序写速度为341MiB/s。
(3)随机写测试
1 | [shangbaishuyao@hadoop102 ~]# sudo fio -filename=/home/shangbaishuyao/test.log -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_randw |
结果显示,磁盘的总体随机写速度为309MiB/s。
(4)混合随机读写:
1 | [shangbaishuyao@hadoop102 ~]# sudo fio -filename=/home/shangbaishuyao/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 |
结果显示,磁盘的总体混合随机读写,读速度为220MiB/s,写速度94.6MiB/s。
小文件归档
1)HDFS存储小文件弊端
每个文件均按块存储,每个块的元数据存储在NameNode的内存中,因此HDFS存储小文件会非常低效。因为大量的小文件会耗尽NameNode中的大部分内存。但注意,存储小文件所需要的磁盘容量和数据块的大小无关。例如,一个1MB的文件设置为128MB的块存储,实际使用的是1MB的磁盘空间,而不是128MB。
2)解决存储小文件办法之一
HDFS存档文件或HAR文件,是一个更高效的文件存档工具,它将文件存入HDFS块,在减少NameNode内存使用的同时,允许对文件进行透明的访问。具体说来,HDFS存档文件对内还是一个一个独立文件,对NameNode而言却是一个整体,减少了NameNode的内存。
3)案例实操
(1)需要启动YARN进程
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ start-yarn.sh |
(2)归档文件
把/input目录里面的所有文件归档成一个叫input.har的归档文件,并把归档后文件存储到/output路径下。
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hadoop archive -archiveName input.har -p /input /output |
(3)查看归档
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hadoop fs -ls /output/input.har |
(4)解归档文件
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hadoop fs -cp har:///output/input.har/* / |
HDFS—集群迁移
Apache和Apache集群间数据拷贝
1)scp实现两个远程主机之间的文件复制
scp -r hello.txt root@hadoop103:/user/shangbaishuyao/hello.txt // 推 push
scp -r root@hadoop103:/user/shangbaishuyao/hello.txt hello.txt // 拉 pull
scp -r root@hadoop103:/user/shangbaishuyao/hello.txt root@hadoop104:/user/shangbaishuyao //是通过本地主机中转实现两个远程主机的文件复制;如果在两个远程主机之间ssh没有配置的情况下可以使用该方式。
2)采用distcp命令实现两个Hadoop集群之间的递归数据复制
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ bin/hadoop distcp hdfs://hadoop102:8020/user/shangbaishuyao/hello.txt hdfs://hadoop105:8020/user/shangbaishuyao/hello.txt |
Apache和CDH集群间数据拷贝
迁移数据
1)准备两套集群,我这使用apache集群和CDH集群。
2)启动集群
3)启动完毕后,将apache集群中,hive库里dwd,dws,ads三个库的数据迁移到CDH集群
4)在apache集群里hosts加上CDH Namenode对应域名并分发给各机器
1 | [root@hadoop101 ~]# vim /etc/hosts |
1 | [root@hadoop101 ~]# scp /etc/hosts hadoop102:/etc/ |
5)因为集群都是HA模式,所以需要在apache集群上配置CDH集群,让distcp能识别出CDH的nameservice
1 | [root@hadoop101 hadoop]# vim /opt/module/hadoop-3.1.3/etc/hadoop/hdfs-site.xml |
6)修改CDH hosts
1 | [root@hadoop101 ~]# vim /etc/hosts |
7)进行分发,这里的hadoop104,hadoop105,hadoop106分别对应apache的hadoop101,hadoop102,hadoop103
1 | [root@hadoop101 ~]# scp /etc/hosts hadoop102:/etc/ |
8)同样修改CDH集群配置,在所有hdfs-site.xml文件里修改配置
1 | <property> |
9)最后注意:重点由于我的Apahce集群和CDH集群3台集群都是hadoop101,hadoop102,hadoop103所以要关闭域名访问,使用IP访问
CDH把钩去了
10)apache设置为false
11)再使用hadoop distcp命令进行迁移,-Dmapred.job.queue.name指定队列,默认是default队列。上面配置集群都配了的话,那么在CDH和apache集群下都可以执行这个命令
1 | [root@hadoop101 hadoop]# hadoop distcp -Dmapred.job.queue.name=hive webhdfs://mycluster:9070/user/hive/warehouse/dwd.db/ hdfs://nameservice1/user/hive/warehouse |
12)会启动一个MR任务,正在迁移
13)查看cdh 9870 http地址
14)数据已经成功迁移。数据迁移成功之后,接下来迁移hive表结构,编写shell脚本
1 | [root@hadoop101 module]# vim exportHive.sh |
15)执行脚本后将tablesDDL.txt文件分发到CDH集群下
1 | [root@hadoop101 module]# scp tablesDDL.txt hadoop104:/opt/module/ |
16)然后CDH下导入此表结构,先进到CDH的hive里创建dwd库
1 | [root@hadoop101 module]# hive |
17)创建数据库后,边界tablesDDL.txt在最上方加上use dwd;
18)并且将createtab_stmt都替换成空格
1 | [root@hadoop101 module]# sed -i s"#createtab_stmt# #g" tablesDDL.txt |
19)最后执行hive -f命令将表结构导入
1 | [root@hadoop101 module]# hive -f tablesDDL.txt |
20)最后将表的分区重新刷新下,只有刷新分区才能把数据读出来,编写脚本
1 | [root@hadoop101 module]# vim msckPartition.sh |
21)刷完分区后,查询表数据
MapReduce生产经验
MapReduce跑的慢的原因
MapReduce程序效率的瓶颈在于两点:
1)计算机性能
CPU、内存、磁盘、网络
2)I/O操作优化
(1)数据倾斜
(2)Map运行时间太长,导致Reduce等待过久
(3)小文件过多
MapReduce常用调优参数
MapReduce数据倾斜问题
1)数据倾斜现象
数据频率倾斜——某一个区域的数据量要远远大于其他区域。
数据大小倾斜——部分记录的大小远远大于平均值。
2)减少数据倾斜的方法
(1)首先检查是否空值过多造成的数据倾斜
生产环境,可以直接过滤掉空值;如果想保留空值,就自定义分区,将空值加随机数打散。最后再二次聚合。
(2)能在map阶段提前处理,最好先在Map阶段处理。如:Combiner、MapJoin
(3)设置多个reduce个数
Hadoop-Yarn生产经验
常用的调优参数
1)调优参数列表
(1)Resourcemanager相关
1 | yarn.resourcemanager.scheduler.client.thread-count ResourceManager处理调度器请求的线程数量 |
(2)Nodemanager相关
1 | yarn.nodemanager.resource.memory-mb NodeManager使用内存数 |
(3)Container容器相关
yarn.scheduler.minimum-allocation-mb 容器最小内存
1 | yarn.scheduler.maximum-allocation-mb 容器最大内存 |
Hadoop综合调优
Hadoop小文件优化方法
Hadoop小文件弊端
HDFS上每个文件都要在NameNode上创建对应的元数据,这个元数据的大小约为150byte,这样当小文件比较多的时候,就会产生很多的元数据文件,一方面会大量占用NameNode的内存空间,另一方面就是元数据文件过多,使得寻址索引速度变慢。
小文件过多,在进行MR计算时,会生成过多切片,需要启动过多的MapTask。每个MapTask处理的数据量小,导致MapTask的处理时间比启动时间还小,白白消耗资源。
Hadoop小文件解决方案
1)在数据采集的时候,就将小文件或小批数据合成大文件再上传HDFS(数据源头)
2)Hadoop Archive(存储方向)
是一个高效的将小文件放入HDFS块中的文件存档工具,能够将多个小文件打包成一个HAR文件,从而达到减少NameNode的内存使用
3)CombineTextInputFormat(计算方向)
CombineTextInputFormat用于将多个小文件在切片过程中生成一个单独的切片或者少量的切片。
4)开启uber模式,实现JVM重用(计算方向)
默认情况下,每个Task任务都需要启动一个JVM来运行,如果Task任务计算的数据量很小,我们可以让同一个Job的多个Task运行在一个JVM中,不必为每个Task都开启一个JVM。
(1)未开启uber模式,在/input路径上上传多个小文件并执行wordcount程序
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar wordcount /input /output2 |
(2)观察控制台
2021-02-14 16:13:50,607 INFO mapreduce.Job: Job job_1613281510851_0002 running in uber mode : false
(3)观察http://hadoop103:8088/cluster
(4)开启uber模式,在mapred-site.xml中添加如下配置
1 | <!-- 开启uber模式,默认关闭 --> |
(5)分发配置
1 | [shangbaishuyao@hadoop102 hadoop]$ xsync mapred-site.xml |
(6)再次执行wordcount程序
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar wordcount /input /output2 |
(7)观察控制台
1 | 2021-02-14 16:28:36,198 INFO mapreduce.Job: Job job_1613281510851_0003 running in uber mode : true |
(8)观察http://hadoop103:8088/cluster
测试MapReduce计算性能
使用Sort程序评测MapReduce
注:一个虚拟机不超过150G磁盘尽量不要执行这段代码
(1)使用RandomWriter来产生随机数,每个节点运行10个Map任务,每个Map产生大约1G大小的二进制随机数
1 | [shangbaishuyao@hadoop102 mapreduce]$ hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar randomwriter random-data |
(2)执行Sort程序
1 | [shangbaishuyao@hadoop102 mapreduce]$ hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar sort random-data sorted-data |
(3)验证数据是否真正排好序了
1 | [shangbaishuyao@hadoop102 mapreduce]$ |
企业开发场景案例
需求
(1)需求:从1G数据中,统计每个单词出现次数。服务器3台,每台配置4G内存,4核CPU,4线程。
(2)需求分析:
1G / 128m = 8个MapTask;1个ReduceTask;1个mrAppMaster
平均每个节点运行10个 / 3台 ≈ 3个任务(4 3 3)
HDFS参数调优
(1)修改:hadoop-env.sh
1 | export HDFS_NAMENODE_OPTS="-Dhadoop.security.logger=INFO,RFAS -Xmx1024m" |
(2)修改hdfs-site.xml
1 | <!-- NameNode有一个工作线程池,默认值是10 --> |
(4)分发配置
1 | [shangbaishuyao@hadoop102 hadoop]$ xsync hadoop-env.sh hdfs-site.xml core-site.xml |
MapReduce参数调优
(1)修改mapred-site.xml
1 | <property> |
(2)分发配置
1 | [shangbaishuyao@hadoop102 hadoop]$ xsync mapred-site.xml |
Yarn参数调优
(1)修改yarn-site.xml配置参数如下:
1 | <!-- 选择调度器,默认容量 --> |
(2)分发配置
1 | [shangbaishuyao@hadoop102 hadoop]$ xsync yarn-site.xml |
执行程序
(1)重启集群
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ sbin/stop-yarn.sh |
(2)执行WordCount程序
1 | [shangbaishuyao@hadoop102 hadoop-3.1.3]$ hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar wordcount /input /output |
(3)观察Yarn任务执行页面
http://hadoop103:8088/cluster/apps
- 本文作者: xubatian
- 本文链接: http://xubatian.cn/Hadoop生产调优手册/
- 版权声明: 本博客所有文章除特别声明外均为原创,采用 CC BY 4.0 CN协议 许可协议。转载请注明出处:https://www.xubatian.cn/