深入理解HDFS:最强辅助SecondaryNameNode

前言

现在业内使用的大多数分布式框架都是主从结构,HDFS也不例外。在HDFS框架中,我们可以理解NameNode是主,DataNode为从,但是HDFS框架并非只有这两个组件,今天我们就来聊一聊HDFS中的最强辅助——SecondaryNameNode。

NameNode的工作

在了解SecondaryNameNode之前,我们先来看下NameNode是做什么的。在一个文件系统中,有一个元数据的概念,关于一个文件的路径/名称/大小/修改日期等描述信息,我们称之为这个文件的元信息。在windows中我们右键文件选择属性,看到的就是元数据。

文件系统中,为了便于管理存储介质上的,给每个目录、目录中的文件、子目录都起了名字,这样形成的层级结构,称之为命名空间。因为同一个目录中不能有同名的文件或目录,所以在一个命名空间中,通过目录+文件名称的方式能够唯一的定位一个文件。而这些数据也都属于元数据的一种。

在HDFS中,命名空间就存储在NameNode的内存中。另外还使用一个称为EditLog的事务日志来永久记录文件系统元数据发生的所有更改。熟悉mysql的朋友,可以参考一下binlog。例如,我们在HDFS中创建一个新文件会导致NameNode在EditLog中插入一条记录来表明这一点。同样,更改文件的操作也将被记录到EditLog中。NameNode将EditLog保存在本地主机的磁盘上,如果NameNode宕机重启后,内存中的元数据信息丢失,也可以通过逐条读取EditLog记录到内存中来恢复元数据。虽然NameNode使用EditLog解决了内存中元数据易丢失的问题。但是EditLog会随着时间变得越来越大,重启后恢复所需要的时间也会越来越长。为了避免这种情况,HDFS引入了为检查点机制(checkpoint)。NameNode定期将内存中的命名空间镜像写到磁盘中名为fsimage的文件中,待到恢复时只需将最近的检查点的fsimage文件读取到内存中,再执行这个检查点之后的EditLog即可恢复命名空间数据。

最强辅助SecondaryNameNode

尽管我们有了EditLog和检查点机制,但是当HDFS数据量大的时候,两个检查点之间的数据依然会非常大。NameNode重启后恢复期间,HDFS的服务是不可用的,这使得我们不得不再次寻求更快的恢复速度,所以我们有了SecondaryNameNode来辅助NameNode。

首先,创建检查点checkpoint的两大条件:

  • SecondaryNameNode每隔1小时创建一个检查点
  • Secondary NameNode每1分钟检查一次,从上一检查点开始,edits日志文件中是否包括100万个事务,也会创建检查点

当满足创建检查点的条件时,SecondaryNameNode首先请求原NameNode进行EditLog的滚动,这样新的编辑操作就能够进入新的文件中;再通过HTTP GET方式读取NameNode中的fsimage及EditLog;然后,SecondaryNameNode读取fsimage到内存中,然后执行EditLog中的每个操作,并创建一个新的统一的fsimage文件;再通过HTTP PUT方式将新的fsimage发送到原NameNode;随后NameNode用新的fsimage替换旧的fsimage,同时系统会更新fsimage文件到记录检查点的时间。这个过程结束后,NameNode就有了最新的fsimage文件和更小的edits文件。因为合并操作需要占用大量的CPU时间,并需要占用与原命名空间一样甚至更多的内存,来执行合并操作,所以将这个操作放到SecondaryNameNode而不是直接在NameNode上完成。

总结

SecondaryNameNode是为了让NameNode更快处理fsimage与EditLog的合并而诞生的。为了完成这个操作,SecondaryNameNode往往拥有和NameNode同样的性能。因此称它为最强辅助也不足为过啦。


关注 零一大数据,获取更多技术干货