hadoop中的fsimage和edits的介绍

在进入下面的主题之前想来搞清楚edits和fsimage文件的概念：

1，fsimage文件其实是hadoop文件系统元数据的一个永久性的检查点，其中包含hadoop文件系统中的所有目录和文件idnode的序列化信息。

2，edits文件存放的是hadoop文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到edits文件中。

 

元数据的介绍：

元数据的分类
按形式分类：内存元数据和元数据文件；它们的存在的位置分别为：内存和磁盘上。其中内存元数据主要是hdfs文件目录的管理；元数据文件则用于持久化存储。
按类型分，元数据主要包括：
1、文件、目录自身的属性信息，例如文件名，目录名，修改信息等。
2、文件记录的信息的存储相关的信息，例如存储块信息，分块情况，副本个数等。
3、记录HDFS的Datanode的信息，用于DataNode的管理。

内存元数据主要fsimage，而通过checkpoint功能备份的也主要是内存的元数据。

 

 

fsimage和edits文件都是经过序列化的，在NameNode启动的时候，他会将fsimage文件中的内容加载到内存中，之后再执行edits文件中的各项操作，使得内存中的元数据和实际

的同步，存在内存中的元数据支持客户端的读操作。

NameNode起来之后，HDFS的更新操作会重新写到edits文件中，因为fsimage文件一般都很大（GB级别的很常见），如果所有的更新操作都往fsimage文件中添加，这样会导致系统运行

的十分缓慢。但如果往edits文件里面写就不会这样，因此，客户端对hdfs进行写文件时首先被记录在edits文件中，edits修改时元数据也会更新，每次hdfs更新时edits先

更新后客户端才会看到最新信息。如果一个文件比较大，使得写操作需要向多台机器进行操作，只有所有的操作都执行完成后，写操作才会返回成功，这样的好处是任何的操作都不会因为机器的故障而导致元数据的不同步。

fsimage包含hadoop文件系统中的所有目录和文件idnode的序列化信息，对于文件来说，包含的信息有修改时间，访问时间，块大小和组成一个文件块信息等；对于目录来说，包含的信息主要有修改时间，

访问控制权限等信息。fsimage并不包含DataNode的信息，而是包含DataNode上快的映射信息，并放到内存中，当一个新的DataNode加入到集群中，DataNode都会向NameNode提供块的信息，而NameNode

会定期的索取块的信息，以使得NameNode拥有最新的块映射。因为fsimage包含Hadoop文件系统中的所有目录和文件idnode的序列化信息，所以如果fsimage丢失或者损坏了，那么即使DataNode上有块的数据，但是我们没有文件到块的映射关系，我们也无法用DataNode上的数据！所以定期及时的备份fsimage和edits文件非常重要！

 

文件系统客户端执行的所有写操作首先会被记录到edits文件中，长此下去，edits会非常的大，而NameNode在重启的时候需要执行edits文件中的各项操作，由此会导致NameNode启动的时间会很长，由此，定期地合并fsimage和edits文件的内容，然后清空edits文件是非常重要的。

 

 

完成合并的是secondaryNamenode，会请求namenode停止使用edits，暂时将新写操作放入一个新的文件中（edits.new）。

secondarynamenode将namenode中通过http get获得edits，因为要和fsimage合并，所以也是通过http get的方式把fsimage加载到内存，然后执行具体对文件系统的操作，与fsimage合并，生成新的

fsimage，然后把fsimage发送到namenode，通过http post的方式。namenode从secondarynamenode获得了fsimage后会把原有的fsimage替换为新的fsimage，把edits.new变成edits。同时会更新fstime。

secondarynamenode在合并edits和fsimage时需要消耗的内存和namenode差不多，所以一般把namenode和secondarynamenode放在不同的机器上。

 

fs.checkpoint.period:默认是一个小时

fs.checkpoint.size:edits达到一定大小时也会出发合并。