本文主要是介绍刀片机和机架块副本数HDFS架构块损坏修复小文件配置修改存储目录,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
机架和刀片机
块 副本数
块的理解
- 存储处理数据的最小单元,其中在hadoop1.x中默认大小为64M,hadoop2.0默认大小为128M,块的大小是由hdfs-site.xml文件中的dfs.blocksize 属性控制
key | value |
---|---|
dfs.blocksize | 134217728 |
- 块大小为什么要设置成128M?(参考其他人的博客)
是为了最小化寻址时间,目前磁盘的传输速率普遍是在100M/S左右,所以设计成128M每块
副本数的理解
副本数的设置使hdfs具有高可靠,数据不会丢失,一个dn只能存储一个块的一份副本,伪分布式部署只能为1个副本,因为只有一个dn;集群部署一般情况下设置3个副本即可,配置在hdfs-site.xml文件中
key | value |
---|---|
dfs.replication | 3 |
-
面试题
一个文件160M,块大小128M ,副本数2份,请问:实际存储多少块,实际多少存储空间?
回答之前有两个概念需要搞清楚:
a.数据上传到hdfs上,大小不会凭空增加
b.未满一个block块的大小,也会占用一个block文件160/128=1...32因为副本数为2,所以存储4块,空间占160*2=320M
HDFS架构
Namenode
概念和作用
namenode是hdfs的主节点,也是元数据节点,1.整个文件系统的文件目录树,2.文件/目录的元信息和每个文件对应的数据块列表;这些信息以两个文件永久存储在磁盘上,一个是镜像文件fsimage,另一个是 编辑日志文件editlog
文件系统的命名空间构成
a.文件的名称
b.文件的属性 权限 创建时间 副本数
c.文件的目录结构
d.文件对应切割为那些的block块和副本数==》数据分布在那些dn节点,当然nn不会持久化存储着写映射关系,是通过集群启动和运行时,dn定期向nn发送blockreport,nn在内存中维护这种关系
nn数据存储路径和内容
[root@JD current]# pwd
/tmp/hadoop-hadoop/dfs/name/current
[root@JD current]# ll
-rw-rw-r-- 1 hadoop hadoop 42 Dec 2 17:39 edits_0000000000000000328-0000000000000000329
-rw-rw-r-- 1 hadoop hadoop 1048576 Dec 2 17:39 edits_inprogress_0000000000000000330
-rw-rw-r-- 1 hadoop hadoop 1744 Dec 2 16:39 fsimage_0000000000000000327
-rw-rw-r-- 1 hadoop hadoop 62 Dec 2 16:39 fsimage_0000000000000000327.md5
-rw-rw-r-- 1 hadoop hadoop 1744 Dec 2 17:39 fsimage_0000000000000000329
-rw-rw-r-- 1 hadoop hadoop 62 Dec 2 17:39 fsimage_0000000000000000329.md5
-rw-rw-r-- 1 hadoop hadoop 4 Dec 2 17:39 seen_txid
-rw-rw-r-- 1 hadoop hadoop 202 Nov 28 17:55 VERSION
NN的fsimage的个数默认是保留2个
是在hdfs-site文件进行配置,属性为
key | value |
---|---|
dfs.namenode.num.checkpoints.retained | 2 |
NN的editlog文件不会保留所有的,如生产上的文件第一个edit文件就没了
edits文件(编辑日志)
文件名前缀:edits
文件名后缀:该文件存储的事务ID
文件系统客户端执行写操作时,这些事务首先会记录到edits日志中
fsimage(镜像文件)
每个fsimage文件存储的都是文件系统元数据信息(文件及目录结构 组成文件的块的信息 副本数量信息),如果namenode发生故障,最近的fsimage文件会被载入到内存中,用来重构元数据的最近状态,再从相关点开始向前执行edits日志文件中记录的每个事务
数据块Block存储在datanode中,但是fsimage文件中并不描述block和datanode的映射关系,取而代之的是,namenode将这种映射关系存储在内存中,这种映射关系通过datanode向namenode发送最新的块列表信息,使namenode在内存中生成这种映射关系。
安全模式
NameNode启动过的时候,会先将fsimage文件中的元数据加载到内存中,并执行编辑日志中的各项操作。一旦在内存中建立文件系统元数据的映像,则创建一个新的fsimage文件和一个空的edits文件,在这个过程中namenode运行在安全模式下。
系统中数据块的位置并不是由namenode维护的,而是以块列表的形势存储在datanode中,在安全模式中,datanode会向namenode发送最新的块列表信息,namenode在内存中建立一块和datanode的映射关系, namenode了解到足够多的块位置信息之后,namenode会对外提供服务。
fsimage和edits合并实现原理 为什么要合并?
在NameNode运行期间,客户端对HDFS的写操作都保存到edits文件中,久而久之edits文件会变得很大,虽然这对NameNode运行的时候是没有影响的,但是在NameNode重启的时候,NameNode先将fsimage中的内容映射到内存中,然后再一条一条执行edits编辑日志中的操作当edits文件非常大的时候会导致namenode启动的时间非常漫长,而在这段时间中HDFS处于安全模式,所以需要在Namenode运行的时候将edits和fsimage定时进行合并,减小edits文件的大小。
NN收到DN发送来的block report之后,是如何进行处理的
除了heartbeat,block report应该说是HDFS中另一个最重要的RPC。DataNode通过block report告诉NameNode,它都有哪些block,然后NameNode根据block report来确定一个DataNode上哪些block是无效的,哪些应该被删除,以及哪个block应该被replicate到其他的机器上,以及如何进行replicate。我们会介绍NameNode收到DataNode发送来的block report之后,是如何进行处理的,这一个过程。
- DataNode报告的block在NameNode中找不到,那么,这个block自然就是无效的。可能是DataNode中的这个block已经被更新的block给替代掉了。因为一个有效的block无论何时,在NameNode中都应该能找到。
- NameNode中存在DataNode中不存在的block。直接在NameNode的元数据中删除就好了
- DataNode报告的block的元数据,和NameNode中的不符,比如,block的长度不同,或者时间戳不对,就要先告诉DataNode把旧的block删除掉,然后告诉其他的DataNode把最新的block replicate到对应的DataNode上
- DataNode报告的block处于UNDER CONSTRUCTION状态,那么就把它加到NameNode中维护的关于block的under construction的replicas的列表中
- 如果DataNode报告的block能在NameNode中找到并且这个block是处于FINALIZED状态,那么就把它添加到NameNode维护的关于block的已经完成的replicas的列表中
总结
NameNode维护着2张表:
1.文件系统的目录结构,以及元数据信息
2.文件与数据块(block)列表的对应关系
元数据存放在fsimage中,在运行的时候加载到内存中的(读写比较快)。
操作日志写到edits中。(类似于LSM树中的log)
Datanode
-
概念和作用
datanode是hdfs的从节点,也称为数据节点,主要存储数据块和数据块校验和(.meta文件,主要是校验文件是否损坏) -
dn文件存储路径
[root@JD subdir0]# pwd/tmp/hadoop-hadoop/dfs/data/current/BP-497769727-192.168.0.3-1574934933514/current/finalized/subdir0/subdir0[root@JD subdir0]# ll-rw-rw-r-- 1 hadoop hadoop 33K Dec 1 17:24 blk_1073741838 #数据块-rw-rw-r-- 1 hadoop hadoop 271 Dec 1 17:24 blk_1073741838_1014.meta #数据块校验和-rw-rw-r-- 1 hadoop hadoop 138K Dec 1 17:24 blk_1073741839-rw-rw-r-- 1 hadoop hadoop 1.1K Dec 1 17:24 blk_1073741839_1015.meta
-
dn的心跳和报告
a. dn每隔3s向nn发送心跳,告诉nn我还健康,是在配置文件hdfs-site.xml文件中匹配值,属性和值为
key | value |
---|---|
dfs.heartbeat.interval | 3 |
b. dn每隔6h扫描块,并向nn发送blockreport,生产上根据数据量大小,建议配置3小时即可,在配置文件hdfs-site.xml文件中匹配值,其中dfs.datanode.directoryscan.interval表示扫描块的属性 21600s=6h,dfs.blockreport.intervalMsec表示blockreport的属性 21600000ms=6h属性和值为
key | value |
---|---|
dfs.blockreport.intervalMsec | 21600000 |
dfs.datanode.directoryscan.interval | 21600 |
SecondaryNamenode
- 概念
snn也称为元数据节点,是hdfs中的备用节点,主要作用是合并fsimage和editlog作为一个新的fsimage,并推送到nn,该过程也称为checkpoint - 配置合并的参数
在hdfs-site.xml中,有两个参数可以控制文件合并是由时间还是次数决定,其中这两个参数的默认值为1小时或者Editlog操作日志记录满 1000000条,两者满足一条就会合并文件
key | value |
---|---|
dfs.namenode.checkpoint.period | 3600 |
dfs.namenode.checkpoint.txns | 1000000 |
- snn的缺点
虽然snn能解决单点故障,但是还是会有风险的,因为如图所示,还有40分钟的数据是恢复不了的
nn和snn交互的流程
NN
edits_0000000000000000306-0000000000000000307
edits_0000000000000000308-0000000000000000324
edits_inprogress_0000000000000000325
fsimage_0000000000000000307
fsimage_0000000000000000307.md5
fsimage_0000000000000000324
fsimage_0000000000000000324.md5SNN
edits_0000000000000000302-0000000000000000303
edits_0000000000000000304-0000000000000000305
edits_0000000000000000306-0000000000000000307
edits_0000000000000000308-0000000000000000324
fsimage_0000000000000000307
fsimage_0000000000000000307.md5
fsimage_0000000000000000324
fsimage_0000000000000000324.md5fsimage_0000000000000000307 + edits_0000000000000000308-0000000000000000324
==>fsimage_0000000000000000324
a. fsimage和edits文件合并时,在nn生成一份新的edit.new文件
b. 复制fsimage和edits文件到snn,在snn进行合并,生成fsimage.ckpt
c.snn将fsimage.ckpt文件推送到nn,然后将fsimage.ckpt替换为fsimage文件,同时将edits.new文件替换为edits文件
手动自动修复损坏的文件
-
hadoop中有个命令是可以手动修复损坏的块,前提是多副本的情况下
[hadoop@JD hadoop]$ hdfs debugUsage: hdfs debug <command> [arguments]These commands are for advanced users only.Incorrect usages may result in data loss. Use at your own risk.verifyMeta -meta <metadata-file> [-block <block-file>]computeMeta -block <block-file> -out <output-metadata-file>recoverLease -path <path> [-retries <num-retries>]执行手动修复指定块命令(xxx指的是有问题的文件在hdfs的路径)[hadoop@JD hadoop]$ hdfs debug recoverLease -path xxx -retries 10
手动修复完整操作步骤
https://ruozedata.github.io/2019/06/06/%E7%94%9F%E4%BA%A7HDFS%20Block%E6%8D%9F%E5%9D%8F%E6%81%A2%E5%A4%8D%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5%28%E5%90%AB%E6%80%9D%E8%80%83%E9%A2%98%29/ -
自动修复
手动修复完整操作步骤:
https://ruozedata.github.io/2019/06/06/%E7%94%9F%E4%BA%A7HDFS%20Block%E6%8D%9F%E5%9D%8F%E6%81%A2%E5%A4%8D%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5(%E5%90%AB%E6%80%9D%E8%80%83%E9%A2%98)/
小文件的理解
定义:明显小于block size的文件 80%
危害:
1)磁盘IO
2)task启动销毁的开销
3)资源有限
hdfs适合存储小文件吗
不适合
假如不适合是为什么
因为hdfs的一个block块的大小是128M,虽然传上的文件小,但是也会占用一个block文件,如果存储上千万、上亿个小文件,Namenode需要维护的源数据信息越多,nn的压力会很大,也有可能撑爆nn的大小(生产上配置的4G)
假如上传文件都是小文件 比如 3m 5m 6m 10m四个文件怎么办
有两种解决方式,第一种是在上传之前进行文件的合并,第二种是在hdfs中进行文件的合并
假如已经在hdfs上 真的有小文件,该怎么办?合并 启动一个服务 单独合并目标 是为了小文件合并大文件,约定的:尽量合并的大文件 <=128M blocksize 比如控制 110M
改变hdfs的存储目录
hdfs的存储目录是在/tmp目录下的,但是linux有30天清理不在规则内的未访问的文件,所以为了防止文件被误删,我们将存储目录放到/home/hadoop/tmp目录下
切换为hadoop用户
[root@JD ~]# su - hadoop
Last login: Mon Dec 2 21:11:59 CST 2019 on pts/1
[hadoop@JD ~]$ pwd
/home/hadoop赋权限
[hadoop@JD ~]$ chmod -R 777 /home/hadoop/tmp
移动之前已生成的文件到新目录下
[hadoop@JD ~]$ mv /tmp/hadoop-hadoop/dfs/ /home/hadoop/tmp修改配置文件core-site.xml
[hadoop@JD ~]$ cd app/hadoop/etc/hadoop
[hadoop@JD hadoop]$ vi core-site.xml <property><name>hadoop.tmp.dir</name><value>/home/hadoop/tmp</value></property>重启hdfs
上传文件测试是否存在于新配置的目录里
进入dn目录
[hadoop@JD subdir0]$ pwd
/home/hadoop/tmp/dfs/data/current/BP-497769727-192.168.0.3-1574934933514/current/finalized/subdir0/subdir0查看文件
[hadoop@JD subdir0]$ ll
total 216
-rw-rw-r-- 1 hadoop hadoop 7 Nov 28 22:26 blk_1073741826
-rw-rw-r-- 1 hadoop hadoop 11 Nov 28 22:26 blk_1073741826_1002.meta
-rw-rw-r-- 1 hadoop hadoop 29 Dec 1 17:14 blk_1073741827
-rw-rw-r-- 1 hadoop hadoop 11 Dec 1 17:14 blk_1073741827_1003.meta
-rw-rw-r-- 1 hadoop hadoop 30 Dec 1 17:24 blk_1073741836
-rw-rw-r-- 1 hadoop hadoop 11 Dec 1 17:24 blk_1073741836_1012.meta
-rw-rw-r-- 1 hadoop hadoop 349 Dec 1 17:24 blk_1073741837
-rw-rw-r-- 1 hadoop hadoop 11 Dec 1 17:24 blk_1073741837_1013.meta
-rw-rw-r-- 1 hadoop hadoop 33508 Dec 1 17:24 blk_1073741838
-rw-rw-r-- 1 hadoop hadoop 271 Dec 1 17:24 blk_1073741838_1014.meta
-rw-rw-r-- 1 hadoop hadoop 141014 Dec 1 17:24 blk_1073741839
-rw-rw-r-- 1 hadoop hadoop 1111 Dec 1 17:24 blk_1073741839_1015.meta执行上传
[hadoop@JD subdir0]$ hadoop fs -put /home/hadoop/bbb.txt /
19/12/02 22:50:44 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable再次查看发现有我们刚才上传的文件,成功
[hadoop@JD subdir0]$ ll
total 224
-rw-rw-r-- 1 hadoop hadoop 7 Nov 28 22:26 blk_1073741826
-rw-rw-r-- 1 hadoop hadoop 11 Nov 28 22:26 blk_1073741826_1002.meta
-rw-rw-r-- 1 hadoop hadoop 29 Dec 1 17:14 blk_1073741827
-rw-rw-r-- 1 hadoop hadoop 11 Dec 1 17:14 blk_1073741827_1003.meta
-rw-rw-r-- 1 hadoop hadoop 30 Dec 1 17:24 blk_1073741836
-rw-rw-r-- 1 hadoop hadoop 11 Dec 1 17:24 blk_1073741836_1012.meta
-rw-rw-r-- 1 hadoop hadoop 349 Dec 1 17:24 blk_1073741837
-rw-rw-r-- 1 hadoop hadoop 11 Dec 1 17:24 blk_1073741837_1013.meta
-rw-rw-r-- 1 hadoop hadoop 33508 Dec 1 17:24 blk_1073741838
-rw-rw-r-- 1 hadoop hadoop 271 Dec 1 17:24 blk_1073741838_1014.meta
-rw-rw-r-- 1 hadoop hadoop 141014 Dec 1 17:24 blk_1073741839
-rw-rw-r-- 1 hadoop hadoop 1111 Dec 1 17:24 blk_1073741839_1015.meta
-rw-rw-r-- 1 hadoop hadoop 7 Dec 2 22:50 blk_1073741840
-rw-rw-r-- 1 hadoop hadoop 11 Dec 2 22:50 blk_1073741840_1016.meta
这篇关于刀片机和机架块副本数HDFS架构块损坏修复小文件配置修改存储目录的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!