HDFS的Checkpoint



Snapshot（快照）：在数据库或者文件系统中，一个快照表示对当前系统状态的一个备份，当系统发生故障时，可以利用这个快照将系统恢复到产生快照时的样子。

Checkpoint（检查点）：因为数据库系统或者像HDFS这样的分布式文件系统，对文件数据的修改不是直接写回到磁盘的，很多操作是先缓存到内存的Buffer中，当遇到一个检查点Checkpoint时，系统会强制将内存中的数据写回磁盘，当然此时才会记录日志，从而产生持久的修改状态。

对于这两者的区别，个人认为主要是Snapshot是对数据的备份，而Checkpoint只是一个将数据修改持久化的机制。

那么对于HDFS来说，这两个技术是如何实现的呢？

1. Snapshot

首先来看Snapshot，很不幸，目前为止最新的Hadoop2.0.5-alpha也没有支持这一功能，个人感觉实现的可能性不大。因为HDFS是用来存储大数据的，对于这么大规模的数据，即便是采用增量备份的方式，也会带来很大的存储开销。不知道以后的Hadoop版本是否会支持，拭目以待。

2. Checkpoint

对于Checkpoint，hadoop已经很好地支持了，不过它是将Checkpoint用在了Namenode元数据的持久化上。

2.1 Namenode

在介绍Checkpoint之前，先来看看Namenode上面有些什么数据：

1. edits：HDFS操作的日志记录，没此对HDFS进行修改操作后，都会往edits中记录一条日志；
2. fsimage：HDFS中命名空间、数据块分布、文件属性等信息都存放在fsimage中；

Namenode中主要就包含上面两个文件，HDFS是怎样处理这两个文件的呢？

前面已经说来，edits是在每次修改HDFS时都会插入记录，那么fsimage则在整个HDFS运行期间不会产生变化，用HDFS官方文档的说法就是：NameNode merges fsimage and edits files only during start up。（引自：http://hadoop.apache.org/docs/stable/hdfs_user_guide.html）也就是说，只有在每次启动Namenode时，才会把edits中的操作增加到fsimage中，并且把edits清空。所以fsimage总是记录启动Namenode时的状态，而edits在每次启动时也是空的，它只记录本次启动后的操作日志。

2.2 Checkpoint触发时机

说了这么多，还没有涉及到Checkpoint呢，别急。我们先来分析一下为什么需要Checkpoint？

按照fsimage和edits的工作机制，在一次启动后，edits的文件可能会增长到很大，这样在下次启动Namenode时需要花费很长时间来恢复；另一方面，如果在HDFS运行过程中发生Namenode的故障，那么edits中的记录就会丢失。所以，我们需要利用Checkpoint即使将修改操作持久化。

在配置文件中有两个参数：

1. fs.checkpoint.period：设置两次相邻checkpoint之间的时间间隔，默认是1小时；
2. fs.checkpoint.size：设置一个edits文件大小的阈值，达到这个阈值，就强制执行一此checkpoint（即使此时没有达到period的时限），默认为64MB。

也就说触发HDFS中Checkpoint的机制有两种，一是时间，另一个是日志记录的大小。

2.3 Checkpoint执行过程

Chekpoint主要干的事情是，将Namenode中的edits和fsimage文件拷贝到Second Namenode上，然后将edits中的操作与fsimage文件merge以后形成一个新的fsimage，这样不仅完成了对现有Namenode数据的备份，而且还产生了持久化操作的fsimage。最后一步，Second Namenode需要把merge后的fsimage文件upload到Namenode上面，完成Namenode中fsimage的更新。

以上提到的文件都可以在hadoop系统的data目录下找到。

2.4 Checkpoint导入

当Namenode发生故障丢失元数据后，可以利用Second Namenode进行导入恢复，过程如下：

1. 在Namenode的节点上面创建dfs.name.dir指定的目录；
2. 指定配置文件中的fs.checkpoint.dir（应该是hdfs-site.xml文件）；
3. 启动Namenode时带上选项 -importCheckpoint。

Namenode首先会将fs.checkpoint.dir中的文件拷贝到dfs.name.dir中，如果此时dfs.name.dir中已经包含了合法的fsimage文件（也就是Namenode没有发生元数据丢失却执行了导入操作），那么Namenode就会执行失败。否则，Namenode会检测导入的fsimage文件是否与文件系统中的数据一致，若一致则成功完成导入恢复。

另外一点，在HDFS官方文档中没有提到，就是Checkpoint对于edits文件很大时启动Namenode时间长的问题，因为需要花费更长的时间去将edits日志merge到fsimage中。我个人认为是否可以利用Second Namenode中的fsimage进行启动呢，也就是说，直接将Second Namenode中的image文件拷贝到Namenode中，这就节省了merge的时间。这样做可以吗？

后来仔细想想，貌似行不通。因为Second Namenode中的image文件不能保证是最新的，它只有在触发Checkpoint时才更新，而启动Namenode需要将edits中全部的操作都merge到fsimgae中。另外，即使拷贝Second数据的方案可行，也不能保证启动时间会减少，因为虽然节省Namenode本地merge操作的时间，却增加了网络数据传输的时间，两者大小还不确定。所以综合这两点原因，Namenode在edits文件大时启动慢的问题暂时没法解决。

3. Recovery

除了上面介绍的Checkpoint机制，Namenode还提供了一种Recovery方式。

在配置文件hdfs-site.xml中有两个参数:

1. dfs.namenode.name.dir：指定namenode中元数据的本地存储位置，这里的位置可以指定多个，并且用逗号分割；
2. dfs.namenode.name.dir.restore：布尔变量，若为true，在每次checkpoint的时候会自动恢复丢失数据的dir。

可见，Recovery只是在本地存储了多个元数据的备份，虽说可以避免文件损害带来的故障，但是对于节点故障来说，本地的多个备份都将不能使用，所以还是有一定局限性的。不过一般情况下都会把多个本地备份设置在不同的物理磁盘分区上面，当一个分区坏掉以后可以使用另一个。

至于如何利用这些本地备份进行recovery