HDFS核心进阶-namenode进阶

SecondaryNameNode 介绍

刚才在分析 edits 日志文件的时候我们已经针对 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 而言

都是字节。

我们之前上传的一个 user.txt 文件，他的 block 信息可以在 fsimage 文件中看到，也可以在 hdfs webui 上面

看到 , 里面有 block 的 id 信息 , 并且也会显示这个数据在哪个节点上面

这里显示在 bigdata02 和 bigdata03 上面都有，那我们过去看一下， datanode 中数据的具体存储位置是由

dfs.datanode.data.dir 来控制的，通过查询 hdfs-default.xml 可以知道，具体的位置在这里

<property>

<name>dfs.datanode.data.dir</name>

<value>file://${hadoop.tmp.dir}/dfs/data</value>

<description>Determines where on the local filesystem an DFS data node

should store its blocks. If this is a comma-delimited

list of directories, then data will be stored in all named

directories, typically on different devices. The directories should be tagg

with corresponding storage types ([SSD]/[DISK]/[ARCHIVE]/[RAM_DISK]) for HD

storage policies. The default storage type will be DISK if the directory do

not have a storage type tagged explicitly. Directories that do not exist wi

be created if local filesystem permission allows.

</description>

</property>

那我们连接到 bigdata02 这个节点上去看一下

[root@bigdata02 ~]# cd /data/hadoop_repo/dfs/data/

[root@bigdata02 data]# ll

total 4

drwxr-xr-x. 3 root root 72 Apr 7 22:21 current

-rw-r--r--. 1 root root 14 Apr 8 20:30 in_use.lock

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

[root@bigdata02 data]# cd current/

[root@bigdata02 current]# ll

total 4

drwx------. 4 root root 54 Apr 8 20:30 BP-1517789416-192.168.182.100-158626

-rw-r--r--. 1 root root 229 Apr 8 20:30 VERSION

[root@bigdata02 current]# cd BP-1517789416-192.168.182.100-1586268855170/

[root@bigdata02 BP-1517789416-192.168.182.100-1586268855170]# ll

total 4

drwxr-xr-x. 4 root root 64 Apr 8 20:25 current

-rw-r--r--. 1 root root 166 Apr 7 22:21 scanner.cursor

drwxr-xr-x. 2 root root 6 Apr 8 20:30 tmp

[root@bigdata02 BP-1517789416-192.168.182.100-1586268855170]# cd current/

[root@bigdata02 current]# ll

total 8

-rw-r--r--. 1 root root 20 Apr 8 20:25 dfsUsed

drwxr-xr-x. 3 root root 21 Apr 8 15:34 finalized

drwxr-xr-x. 2 root root 6 Apr 8 22:13 rbw

-rw-r--r--. 1 root root 146 Apr 8 20:30 VERSION

[root@bigdata02 current]# cd finalized/

[root@bigdata02 finalized]# ll

total 0

drwxr-xr-x. 3 root root 21 Apr 8 15:34 subdir0

[root@bigdata02 finalized]# cd subdir0/

[root@bigdata02 subdir0]# ll

total 4

drwxr-xr-x. 2 root root 4096 Apr 8 22:13 subdir0

[root@bigdata02 subdir0]# cd subdir0/

[root@bigdata02 subdir0]# ll

total 340220

-rw-r--r--. 1 root root 22125 Apr 8 15:55 blk_1073741828

-rw-r--r--. 1 root root 183 Apr 8 15:55 blk_1073741828_1004.meta

-rw-r--r--. 1 root root 1361 Apr 8 15:55 blk_1073741829

-rw-r--r--. 1 root root 19 Apr 8 15:55 blk_1073741829_1005.meta

-rw-r--r--. 1 root root 17 Apr 8 20:31 blk_1073741830

-rw-r--r--. 1 root root 11 Apr 8 20:31 blk_1073741830_1006.meta

-rw-r--r--. 1 root root 134217728 Apr 8 22:13 blk_1073741831

-rw-r--r--. 1 root root 1048583 Apr 8 22:13 blk_1073741831_1007.meta

-rw-r--r--. 1 root root 134217728 Apr 8 22:13 blk_1073741832

-rw-r--r--. 1 root root 1048583 Apr 8 22:13 blk_1073741832_1008.meta

-rw-r--r--. 1 root root 77190019 Apr 8 22:13 blk_1073741833

-rw-r--r--. 1 root root 603055 Apr 8 22:13 blk_1073741833_1009.meta

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

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

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

[root@bigdata02 subdir0]# cat blk_1073741830

jack

tom

jessic

[root@bigdata02 subdir0]#

注意：这个 block 中的内容可能只是文件的一部分，如果你的文件较大的话，就会分为多个 block

存储，默认 hadoop3 中一个 block 的大小为 128M 。根据字节进行截取，截取到 128M 就是一个

block 。如果文件大小没有默认的 block 块大，那最终就只有一个 block 。

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

 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 维护了两份关系：

第一份关系： fifile 与 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 文件

[root@bigdata01 current]# cat VERSION

#Wed Apr 08 20:30:00 CST 2020

namespaceID=498554338

clusterID=CID-cc0792dd-a861-4a3f-9151-b0695e4c7e70

cTime=1586268855170

storageType=NAME_NODE

blockpoolID=BP-1517789416-192.168.182.100-1586268855170

layoutVersion=-65

datanode 的 VERSION 文件

[root@bigdata02 current]# cat VERSION

#Wed Apr 08 20:30:04 CST 2020

storageID=DS-0e86cd27-4961-4526-bacb-3b692a90b1b0

clusterID=CID-cc0792dd-a861-4a3f-9151-b0695e4c7e70

cTime=0

datanodeUuid=0b09f3d7-442d-4e28-b3cc-2edb0991bae3

storageType=DATA_NODE

layoutVersion=-

namenode 不要随便格式化，因为格式化了以后 VERSION 里面的 clusterID 会变，但是

datanode 的 VERSION 中的 clusterID 并没有变，所以就对应不上了。

咱们之前说过如果确实要重新格式化的话需要把 /data/hadoop_repo 数据目录下的内容都清空，全部都

重新生成是可以的。