SecondaryNameNode介绍

SecondaryNameNode主要负责定期的把edits文件中的内容合并到fsimage中

这个合并操作称为checkpoint,在合并的时候会对edits中的内容进行转换,生成新的内容保存到fsimage文件中。

注意:在NameNode的HA架构中没有SecondaryNameNode进程,文件合并操作会由standby NameNode负责实现。所以在Hadoop集群中,SecondaryNameNode进程并不是必须的。

DataNode介绍

DataNode是提供真实文件数据的存储服务

针对datanode主要掌握两个概念,一个是block,一个是replication

首先是block

HDFS会按照固定的大小,顺序对文件进行划分并编号,划分好的每一个块称一个Block,HDFS默认Block大小是 128MB

Blokc块是HDFS读写数据的基本单位,不管你的文件是文本文件 还是视频 或者音频文件,针对hdfs而言 都是字节。

比如hbase-2.2.3-bin.tar.gz文件,他的block信息可以在fsimage文件中看到,也可以在hdfs web上面看到, 里面有block的id信息,并且也会显示这个数据在哪个节点上面

SecondaryNameNode、DataNode、NameNode介绍及总结_hadoop

这里显示在hadoop91和hadoop92以及hadoop93上面都有,那我们过去看一下,datanode中数据的具体存储位置是由dfs.datanode.data.dir来控制的,通过查询hdfs-default.xml或者hdfs-site.xml可以知道,具体的位置在这里

<property>
          <name>dfs.datanode.data.dir</name>
          <value>file:///data02,file:///data01,file:///data03</value>
        </property>

连接到任意一个datanode节点检查:

[hadoop@hadoop91 subdir0]$ cd /data01/
[hadoop@hadoop91 data01]$ ls
current  in_use.lock  nm-local-dir
[hadoop@hadoop91 data01]$ 

然后进入current目录,继续一路往下走

[hadoop@hadoop91 data01]$ cd current/
[hadoop@hadoop91 current]$ ll
total 8
drwx------ 4 hadoop hadoop 4096 Sep 15 15:12 BP-101069233-192.168.115.81-1646921983629
-rw-rw-r-- 1 hadoop hadoop  229 Sep 15 10:47 VERSION
[hadoop@hadoop91 current]$ cd BP-101069233-192.168.115.81-1646921983629/
[hadoop@hadoop91 BP-101069233-192.168.115.81-1646921983629]$ ll
total 12
drwxrwxr-x 4 hadoop hadoop 4096 Sep 14 20:40 current
-rw-rw-r-- 1 hadoop hadoop  166 Sep 15 15:12 scanner.cursor
drwxrwxr-x 2 hadoop hadoop 4096 Sep 15 10:47 tmp
[hadoop@hadoop91 BP-101069233-192.168.115.81-1646921983629]$ cd current/
[hadoop@hadoop91 current]$ ll
total 16
-rw-rw-r-- 1 hadoop hadoop   23 Sep 14 20:40 dfsUsed
drwxrwxr-x 3 hadoop hadoop 4096 Mar 26  2022 finalized
drwxrwxr-x 2 hadoop hadoop 4096 Sep 14 16:32 rbw
-rw-rw-r-- 1 hadoop hadoop  144 Sep 15 10:47 VERSION
[hadoop@hadoop91 current]$ cd finalized/
[hadoop@hadoop91 finalized]$ ll
total 4
drwxrwxr-x 5 hadoop hadoop 4096 Mar  2  2023 subdir0
[hadoop@hadoop91 finalized]$ cd subdir0/
[hadoop@hadoop91 subdir0]$ ll
total 12
drwxrwxr-x 2 hadoop hadoop 4096 May  7  2022 subdir0
drwxrwxr-x 2 hadoop hadoop 4096 Apr  4 10:28 subdir1
drwxrwxr-x 2 hadoop hadoop 4096 Sep 14 16:32 subdir2
[hadoop@hadoop91 subdir0]$ cd subdir0/
[hadoop@hadoop91 subdir0]$ ll
total 56
-rw-rw-r-- 1 hadoop hadoop   42 Apr  1  2022 blk_1073741858
-rw-rw-r-- 1 hadoop hadoop   11 Apr  1  2022 blk_1073741858_1034.meta
-rw-rw-r-- 1 hadoop hadoop   42 Apr  1  2022 blk_1073741867
-rw-rw-r-- 1 hadoop hadoop   11 Apr  1  2022 blk_1073741867_1043.meta
-rw-rw-r-- 1 hadoop hadoop  913 Apr  7  2022 blk_1073741943
-rw-rw-r-- 1 hadoop hadoop   15 Apr  7  2022 blk_1073741943_1119.meta
-rw-rw-r-- 1 hadoop hadoop 1359 Apr 19  2022 blk_1073742022
-rw-rw-r-- 1 hadoop hadoop   19 Apr 19  2022 blk_1073742022_1198.meta
-rw-rw-r-- 1 hadoop hadoop 4967 Apr 19  2022 blk_1073742031
-rw-rw-r-- 1 hadoop hadoop   47 Apr 19  2022 blk_1073742031_1207.meta
-rw-rw-r-- 1 hadoop hadoop 5055 Apr 19  2022 blk_1073742039
-rw-rw-r-- 1 hadoop hadoop   47 Apr 19  2022 blk_1073742039_1215.meta

这里面就有很多的block块了,

注意: 这里面的.meta文件也是做校验用的。

根据前面看到的blockid信息到这对应的找到文件,可以直接查看,发现文件内容就是我们之前上传上去的内容。

[hadoop@hadoop91 subdir0]$ cat blk_1073742039
jack
tom
jessic

注意:这个block中的内容可能只是文件的一部分,如果你的文件较大的话,就会分为多个block存储,默认 hadoop中一个block的大小为128M。根据字节进行截取,截取到128M就是一个block。如果文件大小没有默认的block块大,那最终就只有一个block。

HDFS中,如果一个文件小于一个数据块的大小,那么并不会占用整个数据块的存储空间

SecondaryNameNode、DataNode、NameNode介绍及总结_HDFS_02

size是表示我们上传文件的实际大小,blocksize是指文件的最大块大小。

注意;这个block块是hdfs产生的,如果我们直接把文件上传到这个block文件所在的目录,这个时候hdfs是不识别的,没有用的

假设我们上传了两个10M的文件 又上传了一个200M的文件

问1:会产生多少个block块? 4个

问2:在hdfs中会显示几个文件?3个

下面看一下副本,副本表示数据有多少个备份

我们现在的集群有两个从节点,所以最多可以有2个备份,这个是在hdfs-site.xml中进行配置的,dfs.replication

默认这个参数的配置是3。表示会有3个副本。

副本只有一个作用就是保证数据安全。

NameNode总结

注意:block块存放在哪些datanode上,只有datanode自己知道,当集群启动的时候,datanode会扫描自己节点上面的所有block块信息,然后把节点和这个节点上的所有block块信息告诉给namenode。这个关系是每次重启集群都会动态加载的【这个其实就是集群为什么数据越多,启动越慢的原因】

之前说的fsimage(edits)文件中保存的有文件和block块之间的信息。

这里说的是block块和节点之间的关系,这两块关联在一起之后,就可以根据文件找到对应的block块,再根据block块找到对应的datanode节点,这样就真正找到了数据。

所以说 其实namenode中不仅维护了文件和block块的信息 还维护了block块和所在的datanode节点的信息。

可以理解为namenode维护了两份关系:

第一份关系:file 与block list的关系,对应的关系信息存储在fsimage和edits文件中,当NameNode启动的时候会把文件中的元数据信息加载到内存中

第二份关系:datanode与block的关系,对应的关系主要在集群启动的时候保存在内存中,当DataNode启动时会把当前节点上的Block信息和节点信息上报给NameNode

注意了,刚才我们说了NameNode启动的时候会把文件中的元数据信息加载到内存中,然后每一个文件的元数据信息会占用150字节的内存空间,这个是恒定的,和文件大小没有关系,咱们前面在介绍HDFS的时候说过,HDFS不适合存储小文件,其实主要原因就在这里,不管是大文件还是小文件,一个文件的元数据信息在NameNode中都会占用150字节,NameNode节点的内存是有限的,所以它的存储能力也是有限的,如果我们存储了一堆都是几KB的小文件,最后发现NameNode的内存占满了,确实存储了很多文件,但是文件的总体大小却很小,这样就失去了HDFS存在的价值

最后,在datanode的数据目录下面的current目录中也有一个VERSION文件

这个VERSION和namenode的VERSION文件是有一些相似之处的,我们来具体对比一下两个文件的内容。

namenode的VERSION文件

[hadoop@hadoop81 current]$ cat VERSION 
#Thu Sep 14 20:02:34 CST 2023
namespaceID=936782430
clusterID=CID-54d1528b-8db1-4d0d-80dd-d1b01a83f441
cTime=1646921983629
storageType=NAME_NODE
blockpoolID=BP-101069233-192.168.115.81-1646921983629
layoutVersion=-64

datanode的VERSION文件

hadoop@hadoop91 current]$ cat VERSION 
#Fri Sep 15 10:47:50 CST 2023
storageID=DS-291a7d20-34a8-4b01-b30f-e5911d389bbb
clusterID=CID-54d1528b-8db1-4d0d-80dd-d1b01a83f441
cTime=0
datanodeUuid=ca16d32a-4a7d-4c89-802f-c061426146e2
storageType=DATA_NODE
layoutVersion=-57

我们前面说了namenode不要随便格式化,因为格式化了以后VERSION里面的clusterID会变,但是datanode的VERSION中的clusterID并没有变,所以就对应不上了。