刀片机和机架&块副本数&HDFS架构&块损坏修复&小文件&配置修改存储目录

最新推荐文章于 2023-11-23 10:11:04 发布

Stefanboy

最新推荐文章于 2023-11-23 10:11:04 发布

阅读量492

点赞数

分类专栏： hadoop

本文链接：https://blog.csdn.net/csdn_mycsdn/article/details/103364187

版权

hadoop 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

机架和刀片机

在这里插入图片描述

块副本数

块的理解

存储处理数据的最小单元，其中在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.md5

SNN
edits_0000000000000000302-0000000000000000303
edits_0000000000000000304-0000000000000000305
edits_0000000000000000306-0000000000000000307
edits_0000000000000000308-0000000000000000324
fsimage_0000000000000000307
fsimage_0000000000000000307.md5
fsimage_0000000000000000324
fsimage_0000000000000000324.md5

fsimage_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 debug
  Usage: 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

Stefanboy

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
刀片机和机架&块副本数&HDFS架构&块损坏修复&小文件&配置修改存储目录

机架和刀片机块副本数块的理解存储处理数据的最小单元，其中在hadoop1.x中默认大小为64M，hadoop2.0默认大小为128M，块的大小是由hdfs-site.xml文件中的dfs.blocksize 属性控制dfs.blocksize 134217728(128M) 块大小为什么要设置成128M？（参考其他人的博客）是为了最小化寻址时间，目前磁盘的传输速率普遍是...
复制链接

扫一扫