HDFS(1)(2)——解读上传、下载（读写）、元数据管理原理

一、HDFS上传和下载流程图讲解

1.1 HDFS读数据流程

• 1. 客户端通过Distributed FileSystem向NameNode请求下载文件，NameNode通过查询元数据，找到文件块所在的DataNode地址（块信息和块存储的节点信息）。
• 2. 向DataNode（就近原则，然后随机）服务器发送请求读取数据。
• 3. DataNode开始传输数据给客户端（从磁盘里面读取数据输入流，以Packet为单位来做校验）。
• 4. 客户端以Packet为单位接收，先在本地缓存，然后写入目标文件。

1.2 HDFS写入数据流程

客户端进行切分操作

切块的规则是一个文件一个文件，128M为单位，不足也算一个

• 1. 客户端通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在。
• 2. NameNode返回是否可以上传。
• 3. 客户端请求第一个 Block上传到哪几个DataNode服务器上。
• 4. NameNode返回3个DataNode节点，分别为dn1、dn2、dn3。
• 5. 客户端通过FSDataOutputStream模块请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成。
• 6. dn1、dn2、dn3逐级应答客户端。
• 7. 客户端开始往dn1上传第一个Block（先从磁盘读取数据放到一个本地内存缓存），以Packet为单位，dn1收到一个Packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个确认队列等待确认。
• 8. 当一个Block传输完成之后，客户端再次请求NameNode上传第二个Block的服务器。（重复执行3-7步）。

二、HDFS元数据管理（NN与2NN）

(注：这里的NN是指NameNode ,2NN指SecondaryNameNode)

2.1 NameNode如何管理和存储元数据

NameNode在执行格式化之后，会在/opt/lagou/servers/hadoop-2.9.2/data/tmp/dfs/name/current 目录下产生FsImage文件和edit文件

如图：

NameNode引入了一个edit(日志文件)，只能追加，记录的是client的增删改操作。

2.1.1 nameNode启动

第一次启动NameNode格式化后，创建Fsimage和Edits文件。如果不是第一次启动，直接加 载编辑日志和镜像文件到内存。

客户端对元数据进行增删改的请求。

NameNode记录操作日志，更新滚动日志。

NameNode在内存中对数据进行增删改。

2.1.2 secondaryNameNode

1. 不接受客户端请求
2. 辅助NN管理维护元数据
3. 询问NameNode是否需要CheckPoint（流程为下图蓝颜色的线路）
   1. checkpoint促发时机（到了设定的定时时间或者达到了文件大小），hdfs-default.xml可以配置
   2. 进行checkPoint
   3. nn会先进行滚动edit,生成edit_001文件和edit_inprocess_002文件
   4. 拷贝edit_001和fsImage文件到2nn
   5. 进行合并，生成fsImage_checkPoint文件，拷贝到nn
   6. nn重命名fsImage_checkPoint为fsImage文件

文件下可以看到，fsImage和edit文件，edit不断增大，所以就会有edit被滚动（check_point机制）

Edits中只记录了更新相关的操作，查询或者下载文件并不会记录在内！！

2.1.3  checkpoint周期为[hdfs-default.xml]中进行配置

2.2 NameNode启动时如何确定加载哪些Edits文件呢？

nn启动时需要加载fsimage文件以及那些没有被2nn进行合并的edits文件，nn如何判断哪些edits已经 被合并了呢？ 可以通过fsimage文件自身的编号来确定哪些已经被合并。

2.3 fsimage

转换并查看fsimage文件

hdfs oiv -p XML -i fsimage_0000000000000000747 -o /root/fsImage.xml

hdfs oev -p XML -i edits_inprogress_0000000000000000748 -o /root/edits.xml

#下载到window查看

sz /root/fsImage.xml 回车

sz /root/edits.xml 回车

Fsimage中为什么没有记录块所对应DataNode

在内存元数据中是有记录块所对应的dn信息，但是fsimage中就剔除了这个信息；HDFS集群在启动的 时候会加载image以及edits文件，block对应的dn信息都没有记录，集群启动时会有一个安全模式 （safemode）,安全模式就是为了让dn汇报自己当前所持有的block信息给nn来补全元数据。后续每隔 一段时间dn都要汇报自己持有的block信息。

2.4 fsImage、edit文件特点

fsImage 生成慢，恢复快

edit 生成快，恢复慢

最新的edit编号 为fsImage文件编号+1

三 NN故障处理方案

NameNode故障后，HDFS集群就无法正常工作。

因为HDFS文件系统的元数据需要由NameNode来管 理维护并与Client交互，如果元数据出现损坏和丢失同样会导致NameNode无法正常工作进而HDFS文 件系统无法正常对外提供服务。

如果元数据出现丢失损坏如何恢复呢？

1. 将2NN的元数据拷贝到NN的节点下 此种方式会存在元数据的丢失。

2. 搭建HDFS的HA（高可用）集群，解决NN的单点故障问题！！

（借助Zookeeper实现HA，一个 Active的NameNode,一个是Standby的NameNode）

注：以上为本人小小总结，如果对您起到了一点点帮助，请给予我一点鼓励，在下方点个小小的赞，谢谢，如有错误之处，望不吝指出，非常感谢！