HDFS存储原理（存储原理、fsck命令、namenode元数据、读写流程）

目录

一、存储原理       

二、fsck命令

1.HDFS副本数量的配置

2.检查文件的副本数

3.block配置

三、NameNode元数据

1.edits文件

2.fsiimage文件

        将全部的edits文件，合并为最终结果，即可得到一个FSImage文件。​编辑3.NameNode元数据管理维护

4.元数据合并控制参数

四、HDFS的读写流程

        1.数据写入流程

        2.数据读取流程

---

一、存储原理       

 分布式存储：每个服务器（节点）存储文件的一部分。

        问题：文件大小不一，不利于统一管理。在遇到多个大小不等的文件需要存储时，由于文件大小不同，所分出的部分的大小也不相同。

        解决：设定统一的管理单位，block块（HDFS最小的存储单位，每个256MB（可以修改））

        问题：如果丢失或损坏了某个Block块呢？由于是将文件分成若干个小块分开存储，如果在还原时丢失某一个block块，可能会导致文件无法还原。block块越多，损坏的几率越大。

        解决：通过多个副本（备份）解决，将备份放到其他服务器存储

二、fsck命令

1.HDFS副本数量的配置

        （1）全局修改

        在hdfs-site.xml中配置以下属性：

        <property>

                <name>dfs.replication</name>

                <value>3</value>

        </property>

        这个属性默认是3，一般情况下，无需主动配置（除非需要设置非3的数值），如果需要自定义，需要将三台机器文件配置文件都修改。

       (2) 临时修改：

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

        如上命令，就可以上传test.txt的时候，临时设置其副本数为2

        (3)修改已存在文件：

        hadoop fs -setrep [-R] 2 path

        如上命令，指定path路径的内容将会被修改为2个副本存储。-R选项可选，使用-R表示对子目录也有效。

2.检查文件的副本数

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

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

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

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

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

3.block配置

        对于块（block），hdfs默认设置为256MB一个。

        块大小可以通过参数：

        <property>

                <name>dfs.blocksize</name>

                <value>268435456</value>  #设置为256MB

               <description>设置HDFS块大小，单位是b</description>

        </property>

三、NameNode元数据

1.edits文件

        NameNode基于一批edits和一个fsimage文件的配合。完成整个文件系统的管理和维护。edits文件，是一个流水账文件，记录hdfs中的每一次操作，以及本次操作影响的文件及其对应的block。但是edits记录每一次HDFS操作逐渐变得越来越大，所以会存在多个edits文件确保不会有超大edits的存在保证检索性能。

        但是edits文件检索有一个问题：当用户想要查看某文件内容，如/tmp/data/test.txt，就需要在全部的edits中搜索（还需要按顺序从头到尾，避免后期改名或者删除效率非常低）。

2.fsiimage文件

        将全部的edits文件，合并为最终结果，即可得到一个FSImage文件。3.NameNode元数据管理维护

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

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

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

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

                ·如当前没有FSImage文件，将全部edits合并为第一个FSImage

                ·如果当前已存在FSImage文件，将全部edits和已存在的FSImage进行合并，形成新的FSImage。

        4.重复123流程。

4.元数据合并控制参数

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

        ·dfs.namenode.checkpoint.period，默认3600秒 ，即一个小时

        ·dfs.namenode.checkpoint.txns，默认100000，即100W事务

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

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

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

        合并元数据的事情是由SecondaryNameNode会通过http从NameNode拉取数据（edits和FSImage），然后合并完成后提供给NameNode使用。

四、HDFS的读写流程

        1.数据写入流程

        （1）客户端向NameNode发起请求.

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

        （3）客户端向指定的DataNode发送数据包。

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

        （5）如下图，DataNode1复制给DataNode2，然后基于DataNode2复制给DataNode3和DataNode4。

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

注意：

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

        ②客户端直接向一台DataNode写数据，这个DataNode也一般是距离客户端网络距离最近的DataNode。

        ③数据块副本的复制工作，由DataNode之间自行完成（构建一个PipLine，按顺序复制分发）。

        2.数据读取流程

        （1）客户端向NameNode申请读取文件。

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

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

 注意：

        ①数据同样不通过NameNode提供

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