HDFS元数据机制与checkpoint

元数据存在namenode中，主要是描述数据属性的信息，用来支持如存储位置、历史数据、资源查找、文件记录功能。Namenode中的元数据就是记录hdfs存储信息数据的数据。

namenode主要负责三个功能，分别是(1)管理元数据 (2)维护目录树 (3)响应客户请求

hdfs的修改添加等信息先记录在edits.log。

如果存储在namenode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。所以元数据metadata要存储在内存中！！！方便随机存储！

但如果只存在内存中，一旦断点，元数据丢失，整个集群就无法工作了！！！

因此解决办法是元数据存储在内存中，但在磁盘中有备份，这个备份就是fsImage，存放在namenode节点对应的磁盘中。

新的问题：当在内存中的元数据更新时，如果同时更新fsImage，就会导致效率过低，相当于第一种；但如果不更新，就会发生一致性问题，一旦namenode节点断点，就会产生数据丢失。

解决办法：引入edits.log文件(只进行追加操作，效率很高)。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到edits.log中。这样，一旦namenode节点断电，可以通过fsImage和edits.log的合并，合成元数据。

但是，如果长时间添加数据到edit.log中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行fsImage和edits.log的合并。

如果这个操作有namenode节点完成，又会效率过低。因此，引入一个新的节点secondaryNamenode，专门用于fsImage和edits.log的合并。

合并操作发生在secondary namenode中。

具体的checkpoint执行过程如下：

1.secondary namenode请求主Namenode停止使用edits文件，暂时将新的写操作记录到一个新文件中，如edits.new。
2.secondary namenode节点从主Namenode节点获取fsimage和edits文件（采用HTTP GET）
3.secondary namenode将fsimage文件载入到内存，逐一执行edits文件中的操作，创建新的fsimage文件
4.secondary namenode将新的fsimage文件发送回主Namenode（使用HTTP POST）
5.主Namenode节点将从secondary namenode节点接收的fsimage文件替换旧的fsimage文件，用步骤1产生的edits.new文件替换旧的edits文件（即改名）。同时更新fstime文件来记录检查点执行的时间