大数据技术之Hadoop：HDFS存储原理篇（五）

た入场券 2024-03-08 04:11 41阅读 0赞

**目录**

一、原理介绍

1.1 Block块

1.2 副本机制

二、fsck命令

2.1 设置默认副本数量

2.2 临时设置文件副本大小

2.3 fsck命令检查文件的副本数

2.4 block块大小的配置

三、NameNode元数据

3.1 NameNode作用

3.2 edits文件

3.3 FSImage文件

3.4 元素据合并控制参数

3.5 SecondaryNameNode的作用

四、HDFS的读写流程

4.1 写入流程

4.2 读取流程

--------------------

## 一、原理介绍 ##

### 1.1 Block块 ###

HDFS分布式文件存储，通常是将1个文件拆分成多个部分，然后分别发送到不同服务器节点上。

![e46d064edd204d92947c1ed62a77bbb2.gif][]![8e00b1b2121e404b94eaf135458cdb52.gif][]

> **问题：不同的文件大小不一，粗暴的拆分然后放到服务器不同节点，会导致各个部分的大小也不一样，不利于统一管理。**

**解决办法：设定统一的管理单位，****block****块。**

*  Block块，HDFS最小存储单位
 *  每个256MB（可以修改）

这样可以将文件分成多个Block块，不同的Block块存入对应服务器。

> 举例说明

某个文件大小1G，那么理论上可以分为4个Block块。

如果集群有三台服务器，那么某台服务器放2个Block块，然后其他两台服务器各1个Block块。

### 1.2 副本机制 ###

如果不备份，假如某个块损坏了，那么就会导致整个文件不可用。

所以，副本机制是保障数据安全的非常重要的机制。

![3e99109ebe444ee7ad7f086d38ff5ac0.png][]

## 二、fsck命令 ##

### 2.1 设置默认副本数量 ###

![43f5e305d4834d2d80ecc148eadd832f.png][]

默认的HDFS文件的副本数量就是3个。

当然这个值可以修改，具体可以在**hdfs-site.xml**中配置如下属性

<property>
        <name>dfs.replication</name>
        <value>3</value>
    </property>

这个属性默认是3，一般情况下，我们无需主动配置（除非需要设置非3的数值）

如果需要自定义这个属性，请修改每一台服务器的hdfs-site.xml文件，并设置此属性。

### 2.2 临时设置文件副本大小 ###

如果不加限制，我们创建的文件或者上传的文件，默认副本数就是上面设置的值。

但是单次文件上传，我们也可以指定某个文件拥有多少个副本。

hadoop fs -D dfs.replication=2 -put test.txt /tmp/

![2d3a67da242b4031ad200ad09aa03696.png][]对于已经存在HDFS的文件，修改dfs.replication属性不会生效，如果要修改已存在文件可以通过命令

hadoop fs -setrep [-R] 2 path

如上命令，指定path的内容将会被修改为2个副本存储。

\-R选项可选，使用\-R表示对子目录也生效。

###  ###

### 2.3 **fsck****命令检查文件的副本数** ###

我们要查看详细的文件副本数信息，可以通过如下命令：

hdfs fsck path [-files [-blocks [-locations]]]

fsck可以检查指定路径是否正常

\-files可以列出路径内的文件状态

\-files -blocks 输出文件块报告（有几个块，多少副本）

\-files -blocks -locations 输出每一个block的详情

![cbf0db36f3d543e6a3f7cd9cab88e1e7.png][]

### 2.4 block块大小的配置 ###

默认情况下，block块的大小是256MB，当然我们也可以修改。

<property>
        <name>dfs.blocksize</name>
        <value>268435456</value>
        <description>设置HDFS块大小，单位是b</description>
      </property>

## 三、NameNode元数据 ##

### 3.1 NameNode作用 ###

**NameNode作用：管理Block块。**

在hdfs中，文件是被划分了一堆堆的block块，那如果文件很大、以及文件很多，Hadoop是如何记录和整理文件和block块的关系呢？

答案就在于NameNode。

NameNode基于一批edits和一个fsimage文件的配合完成整个文件系统的管理和维护。

### 3.2 edits文件 ###

edits文件，是一个流水账文件，记录了hdfs中的每一次操作，以及本次操作影响的文件其对应的block。

![b2969ca2929d4dc08944da742e4cea0a.png][]

![50a6d3c335ff4e91a91e4b9d611c5d3a.png][]

![5638bc88f2d9498eb1861c8046c616ae.png][]

![869919b2328847f28d5a7ab17a08ac6c.png][] ![976d734ca00348e7a7aedb6f072c0f32.png][]

### 3.3 FSImage文件 ###

将全部的edits文件，合并为最终结果，即可得到一个FSImage文件

![0831bbcb7b4645b79066d0b5e07d0084.png][]

> 小结

NameNode基于edits和FSImage的配合，完成整个文件系统文件的管理。

1. 每次对HDFS的操作，均被edits文件记录

2. edits达到大小上线后，开启新的edits记录

3. 定期进行edits的合并操作

*  如当前没有fsimage文件， 将全部edits合并为第一个fsimage
 *  如当前已存在fsimage文件，将全部edits和已存在的fsimage进行合并，形成新的fsimage

4. 重复123流程

### 3.4 元素据合并控制参数 ###

对于元数据的合并，是一个定时过程，基于：

dfs.namenode.checkpoint.period，默认3600（秒）即1小时

dfs.namenode.checkpoint.txns，默认1000000，即100W次事务

只要有一个达到条件就执行。

检查是否达到条件，默认60秒检查一次，基于：

dfs.namenode.checkpoint.check.period，默认60（秒），来决定。

### 3.5 **SecondaryNameNode****的作用** ###

对于元数据的合并，还记得HDFS集群有一个辅助角色：SecondaryNameNode吗？

![3f26cdf2369e4f3cb3a575f6eed5f222.png][]

没错，合并元数据的事情就是它干的

SecondaryNameNode会通过http从NameNode拉取数据（edits和fsimage）

然后合并完成后提供给NameNode使用。

## 四、HDFS的读写流程 ##

### 4.1 写入流程 ###

![4431f4aaaf2d4656841f091ededc9e99.png][]

1. 客户端向NameNode发起请求

2. NameNode审核权限、剩余空间后，满足条件允许写入，并告知客户端写入的DataNode地址

3. 客户端向指定的DataNode发送数据包

4. 被写入数据的DataNode同时完成数据副本的复制工作，将其接收的数据分发给其它DataNode

5. 如上图，DataNode1复制给DataNode2，然后基于DataNode2复制给Datanode3和DataNode4

6. 写入完成客户端通知NameNode，NameNode做元数据记录工作

> 关键信息点：

NameNode不负责数据写入，只负责元数据记录和权限审批

客户端直接向1台DataNode写数据，这个DataNode一般是离客户端最近（网络距离）的那一个

数据块副本的复制工作，由DataNode之间自行完成（构建一个PipLine，按顺序复制分发，如图1给2, 2给3和4）

### 4.2 读取流程 ###

![09fee67989b9480fbb5b01431bcee3da.png][]

1、客户端向NameNode申请读取某文件

2、 NameNode判断客户端权限等细节后，允许读取，并返回此文件的block列表

3、客户端拿到block列表后自行寻找DataNode读取即可

> 关键点：

数据同样不通过NameNode提供

NameNode提供的block列表，会基于网络距离计算尽量提供离客户端最近的

这是因为1个block有3份，会尽量找离客户端最近的那一份让其读取。

最难不过坚持，继续下一关~✨

[e46d064edd204d92947c1ed62a77bbb2.gif]: https://img-blog.csdnimg.cn/e46d064edd204d92947c1ed62a77bbb2.gif
[8e00b1b2121e404b94eaf135458cdb52.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/f30d3494090f4d27994bb3e917923c32.png
[3e99109ebe444ee7ad7f086d38ff5ac0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/91b0c532c9de424e8f9deeb4cf8f2f51.png
[43f5e305d4834d2d80ecc148eadd832f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/5d51ab96bb1c47c89d07f1586c23e2d1.png
[2d3a67da242b4031ad200ad09aa03696.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/33824f28d0f443f896b0ddd9994e3b73.png
[cbf0db36f3d543e6a3f7cd9cab88e1e7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/d2dc995e40254271b83ef0d5b9d8ccc1.png
[b2969ca2929d4dc08944da742e4cea0a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/75d43cb842f14d5dbf1b83f93273413d.png
[50a6d3c335ff4e91a91e4b9d611c5d3a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/a41d929ded8742b4ab77753fed78d7d0.png
[5638bc88f2d9498eb1861c8046c616ae.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/55d4601d08d1454380588d32b0ba59d6.png
[869919b2328847f28d5a7ab17a08ac6c.png]: https://img-blog.csdnimg.cn/869919b2328847f28d5a7ab17a08ac6c.png
[976d734ca00348e7a7aedb6f072c0f32.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/18169a82c85a4381a440f4b582f90b00.png
[0831bbcb7b4645b79066d0b5e07d0084.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/afa06e9cd7bc45bca7b20dcb2c591f50.png
[3f26cdf2369e4f3cb3a575f6eed5f222.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/b4ba2b5d76204280b83af30a42e72328.png
[4431f4aaaf2d4656841f091ededc9e99.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/6092b9a86cce4836980680ed0bdc7031.png
[09fee67989b9480fbb5b01431bcee3da.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/bfcf9d002cd04dd98a10d36e85863ecf.png