浅谈HDFS 之NameNode元数据管理机制
元数据存储机制
NameNode在内存中保留一份元数据信息，在磁盘中保存一份接近完整的元数据镜像文件（fsimage），以及记录元数据操作信息的edits文件；元数据信息以树状结构存储整个HDFS上的文件和目录，它保存着文件与数据块之间的映射信息，目的是为了数据的可读取性。
为何在内存中保留一份元数据信息之后还在磁盘中保留一份呢？元数据究竟是先存放在元数据中还是磁盘中呢？那么fsimage，edits log究竟是什么？不要着急哈，且听娓娓道来......
PART1：首先来了解一下HDFS中的NameNode在本地目录下的存储结构，NameNode有一个重要的职责，就是保存元数据信息，那磁盘中的元数据信息主要是由fsimage和edits log构成，具体解释请往下看 ↓↓↓
图1 NameNode存储结构
fsimage
通俗一点，可以理解为一个快照（也可以理解为一个照片啦），它是元数据的镜像文件，里面保存着包括数据块到文件的映射，文件的属性等信息
fsimage.md5
在fsimage和edits 进行checkpoint之后生成新的fsimage和对应的md5文件，用来对文件做完整性校验
edits log
对HDFS文件系统的操作记录；记录在Edit log之中的每一个操作又称为一个事务，每个事务有一个整数形式的事务 id 作为编号，Edit log 会被切割为很多段，每一段称为一个Segment。
edits_inprogress log
正在写入的日志处于in-progress状态，HDFS默认会为该文件提前申请1MB空间以提升性能
PS.写入完成的Edit log Segment处于finalized状态,在HA环境中，Standby Namenode只能读取finalized log。
VERSION
java属性文件
图2 VERSION内容展示
seen_txid
保存最近一次fsimage或者edits_inprogress的transaction Id，在NameNode重启的时候，会按照seen_txid的数字，依次遍历。这个文件的目的在于判断在Namenode启动过程中是否有丢失的edits，一旦出现丢失的情况，Namenode进程将不会完成启动，从而保护数据的一致性。
图3 seen_txid内容展示
敲黑板↓↓↓
NameNode在格式化后第一次启动时，会创建一个edits和fsimage文件，后面再次启动时，直接加载每个 edits 和最新的 fsimage 文件。
PART2：为何在内存中保留一份元数据信息之后还在磁盘中保留一份呢？
HDFS作为文件系统，要考虑到数据的安全性还有数据的读写速度这两大特性；如果元数据信息只保存在内存中，一旦NameNode出现宕机，内存中的元数据便会丢失；所以在磁盘中保存一份元数据信息就是必不可少的。
那可能有人又有疑问了，为何不直接在磁盘中保存一份元数据就好了，还要在内存中保留一份呢？
直接从磁盘中获取元数据信息，会大大降低文件的读取速度，明显影响读写效率；所以磁盘中的元数据信息用于数据写入的场景下，而内存中的元数据是用于数据读取的情况。
PART3：元数据究竟是先存放在元数据中还是磁盘中呢？
在回答这个问题之前，先来了解一下HDFS的数据写入过程：
图4 HDFS 数据写入过程
从上面的图中可以看到，客户端每次写入的时候，都会去请求NameNode，此时NameNode会先往磁盘中edits log中记录这次写入的操作日志；文件上传完成之后，会返回成功的信息给NameNode，NameNode在收到写入成功的信息之后才会往内存中写入本次上传操作的元数据信息。
HA模式下的checkpoint机制
谈及元数据管理，肯定要关注checkpoint机制，它到底有着怎样的魔力呢？类似于爱的魔力转圈圈......
话不多说，看图↓↓↓
图5 checkpoint 过程图
checkpoint 具体过程:
1.当满足触发条件时（时间周期为一小时或edits log产生了100万条），随即触发checkpoint机制
2.Standby NameNode检查达到checkpoint条件后，将该namespace以fsimage.ckpt_txid格式保存到Standby NameNode的磁盘上，并且随之生成一个MD5文件。然后将该fsimage.ckpt_txid文件重命名为fsimage_txid。PS. txid-transactionId为操作日志的事务ID
3.Standby NameNode通过HTTP GET请求连接active NameNode
4.active NameNode反过来通过HTTP GET请求从Standby NameNode获取最新的fsimage_txid文件并保存为fsimage.ckpt_txid，同时也生成一个MD5文件，将这个MD5文件与Standby NameNode的MD5文件进行比较，确认active NameNode已经正确获取到了Standby NameNode最新的fsimage文件。然后将fsimage.ckpt_txid文件重命名为fsimage_txit。
补充说明
看完之后，可以想想下面几个问题：
Q1：NameNode在启动时，为何需要加载所有的edits，fsimage中不是已经包含edits文件了吗？
Q2：对NameNode的操作都放在edits中，为什么不直接放在fsimage中呢？
Q3：旧的edits 文件一直保存，fsimage 也合并之后保留着数据块的信息，内存中还保留着一份元数据信息，总有一天空间不足怎么办？
An1：为了再次校验数据，确保加载内存中元数据的可靠性。
An2：fsimage是NameNode的完整镜像，内容很大，如果每次都加载到内存并生成树状拓扑结构，这是非常耗“内存和CPU”，继而影响性能。
An3：edtis和fsimage保留的只是每个文件的位置等的信息，并不会占太多的空间；但不可避免的会遇到很多小文件的问题，过多小文件的元数据信息会占用NameNode过多的内存空间，所以一般默认以数据块大小为128M进行上传；其次，访问大量的小文件，其速度相较于会直接影响到性能。
NameNode中的元数据信息记录着文件与数据块的映射信息，有着重要地位，一旦丢失，将无法读取DataNode 上的数据。本文简单梳理了元数据的组成部分，以及介绍了checkpoint过程，从存储机制层面提出了多个WHY，更加明确了元数据在HDFS的重要性。
参考网址：
元数据简介:https://issues.apache.org/jira/browse/HDFS-1073
NameNode 存储结构:https://blog.csdn.net/opensure/article/details/51452058
常见问题:https://blog.csdn.net/weixin_33796205/article/details/87366231
有什么疑问或者好的建议可以加入我们的微信群交流。
