本节书摘来异步社区《Hadoop技术详解》一书中的第2章，第2.5节，作者： 【美】Eric Sammer 译者： 刘敏 , 麦耀锋 , 李冀蕾 , 等，更多章节内容可以访问云栖社区“异步社区”公众号查看。
2.5 管理文件系统元数据
NameNode将文件系统的元数据以不同的文件保存在本地磁盘中，其中最重要的两个文件是fsimage和edits。和数据库一样，fsimage包含文件系统元数据的完整快照，而edits仅包含元数据的增量修改。对高吞吐率的数据存储而言，一个常用方法是使用预写日志（WAL），如edits文件，实现顺序增加操作来减少I/O操作（在NameNode中，所有操作都在RAM中完成），从而避免高消耗的查找操作，获取更好的整体性能。NameNode启动后，直接加载fsimage到RAM，再通过回放引入edits的增量变化，最终在内存中建立拥有最新信息的文件系统视图。
在Hadoop较新的几个版本中（具体地说，就是Apache Hadoop 2.0和CDH4；有关Hadoop更多版本信息，请参见4.1节“挑选Hadoop的发行版本”），底层元数据的存储拥有更好的可恢复性和支持NameNode的高可用性。在概念上，元数据的存储和以前的版本是类似的，除了事务不再保存在单一的edits文件中以外。在新版本中，NameNode周期性轮换edits文件（关闭一个文件，然后打开一个新文件），用事务ID号来标识。这样就提供了一种可能：NameNode可以保留旧的fsimage和edits文件备份，从而可以更好地支持数据的回滚功能。大部分的这类改变对使用者几乎没有什么影响。之所以在这里提起是为了让读者能更好地理解磁盘上这些文件的用途，同时提醒读者不要轻易改动这些文件，除非你十分清楚你在干什么。本书接下来的章节提到这些文件的时候会使用它们的名字，分别用fsimage和edits来表明它们的功能。
NameNode只将改动内容写入WAL，即edits。随着时间的推移，edits文件会像其他的日志系统文件一样变得越来越大，当服务器发生故障时就需要很长的时间来回放。所以像传统的关系数据库那样，需要定期将edits文件引入到fsimage文件中。这样就带来了新的问题，NameNode在为集群提供服务时可能无法提供足够的资源——CPU或RAM来支持此运算。为了解决这一问题，引入了次NameNode。
NameNode和次NameNode之间的交互如图2-4所示。[1]
1． 次NameNode引导NameNode滚动更新edits文件，并开始将新的内容写入edits.new。
2．次NameNode将NameNode的fsimage和edits文件复制到本地的检查点目录。
3．次NameNode载入fsimage文件，回放edits内容，将其合并到fsimage，将新的fsimage文件压缩后写入磁盘。
4．次NameNode将新的fsimage文件送回NameNode，NameNode在接收新的fsimage文件后，直接加载和应用该文件。
5．NameNode将edits.new更名为edits。
默认情况下，该过程每小时发生一次，或者当NameNode的edits文件大小达到默认的64MB时也会被触发。尽管后面我们会研究如何改变这些配置，但通常来说无需改变。在新版本的Hadoop中，通过使用预定义的事务次数而不是文件大小来触发该过程。
