signed

QiShunwang

“诚信为本、客户至上”

Secondary NameNode:的作用--转载

2020/8/20 11:16:52   来源:

文章一

前言

最近刚接触Hadoop, 一直没有弄明白NameNode和Secondary NameNode的区别和关系。很多人都认为,Secondary NameNode是NameNode的备份,是为了防止NameNode的单点失败的,直到读了这篇文章Secondary Namenode - What it really do? (需翻墙)才发现并不是这样。文章写的很通俗易懂,现将其翻译如下:

Secondary NameNode:它究竟有什么作用?

在Hadoop中,有一些命名不好的模块,Secondary NameNode是其中之一。从它的名字上看,它给人的感觉就像是NameNode的备份。但它实际上却不是。很多Hadoop的初学者都很疑惑,Secondary NameNode究竟是做什么的,而且它为什么会出现在HDFS中。因此,在这篇文章中,我想要解释下Secondary NameNode在HDFS中所扮演的角色。

从它的名字来看,你可能认为它跟NameNode有点关系。没错,你猜对了。因此在我们深入了解Secondary NameNode之前,我们先来看看NameNode是做什么的。

NameNode

NameNode主要是用来保存HDFS的元数据信息,比如命名空间信息,块信息等。当它运行的时候,这些信息是存在内存中的。但是这些信息也可以持久化到磁盘上。

上面的这张图片展示了NameNode怎么把元数据保存到磁盘上的。这里有两个不同的文件:

  1. fsimage - 它是在NameNode启动时对整个文件系统的快照
  2. edit logs - 它是在NameNode启动后,对文件系统的改动序列

只有在NameNode重启时,edit logs才会合并到fsimage文件中,从而得到一个文件系统的最新快照。但是在产品集群中NameNode是很少重启的,这也意味着当NameNode运行了很长时间后,edit logs文件会变得很大。在这种情况下就会出现下面一些问题:

  1. edit logs文件会变的很大,怎么去管理这个文件是一个挑战。
  2. NameNode的重启会花费很长时间,因为有很多改动[笔者注:在edit logs中]要合并到fsimage文件上。
  3. 如果NameNode挂掉了,那我们就丢失了很多改动因为此时的fsimage文件非常旧。[笔者注: 笔者认为在这个情况下丢失的改动不会很多, 因为丢失的改动应该是还在内存中但是没有写到edit logs的这部分。]

因此为了克服这个问题,我们需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件,这样也会减小在NameNode上的压力。这跟Windows的恢复点是非常像的,Windows的恢复点机制允许我们对OS进行快照,这样当系统发生问题时,我们能够回滚到最新的一次恢复点上。

现在我们明白了NameNode的功能和所面临的挑战 - 保持文件系统最新的元数据。那么,这些跟Secondary NameNode又有什么关系呢?

Secondary NameNode

SecondaryNameNode就是来帮助解决上述问题的,它的职责是合并NameNode的edit logs到fsimage文件中。

上面的图片展示了Secondary NameNode是怎么工作的。

  1. 首先,它定时到NameNode去获取edit logs,并更新到fsimage上。[笔者注:Secondary NameNode自己的fsimage]
  2. 一旦它有了新的fsimage文件,它将其拷贝回NameNode中。
  3. NameNode在下次重启时会使用这个新的fsimage文件,从而减少重启的时间。

Secondary NameNode的整个目的是在HDFS中提供一个检查点。它只是NameNode的一个助手节点。这也是它在社区内被认为是检查点节点的原因。

现在,我们明白了Secondary NameNode所做的不过是在文件系统中设置一个检查点来帮助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的备份。所以从现在起,让我们养成一个习惯,称呼它为检查点节点吧。

后记

这篇文章基本上已经清楚的介绍了Secondary NameNode的工作以及为什么要这么做。最后补充一点细节,是关于NameNode是什么时候将改动写到edit logs中的?这个操作实际上是由DataNode的写操作触发的,当我们往DataNode写文件时,DataNode会跟NameNode通信,告诉NameNode什么文件的第几个block放在它那里,NameNode这个时候会将这些元数据信息写到edit logs文件中。

 

9人点赞

 

大数据

 



作者:可文分身
链接:https://www.jianshu.com/p/5d292a9a8c86
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

 

文章二

前言

HDFS SecondaryNameNode是干什么的?

这是道经典的基础面试题,笔者问过面试者很多次(当然也被面试官问过很多次)。从印象看,大约有一半的被面试者无法正确作答,给出的答案甚至有“不就是NameNode的热备嘛”。本文来简单聊聊相关的知识,为节省篇幅,将SecondaryNameNode简称SNN,NameNode简称NN。

NN与fsimage、edits文件

NN负责管理HDFS中所有的元数据,包括但不限于文件/目录结构、文件权限、块ID/大小/数量、副本策略等等。客户端执行读写操作前,先从NN获得元数据。当NN在运行时,元数据都是保存在内存中,以保证响应时间。

显然,元数据只保留在内存中是非常不可靠的,所以也需要持久化到磁盘。NN内部有两类文件用于持久化元数据:

  • fsimage文件,以fsimage_为前缀,是序列化存储的元数据的整体快照;

  • edits文件(又称edit log),以edits_为前缀,是顺序存储的元数据的增量修改(即客户端写入操作)日志。

这两类文件均存储在${dfs.namenode.name.dir}/current/路径下,如下图所示。


可见,当前正在写入的edits文件名会有"inprogress"标识,而seen_txid文件保存的就是当前正在写入的edits文件的ID。

在任意时刻,最近的fsimage和edits文件的内容加起来就是全量元数据。NN在启动时,就会将最近的fsimage文件加载到内存,并重放它之后记录的edits文件,恢复元数据的现场。

SNN与checkpoint过程

为了避免edits文件过大,以及缩短NN启动时恢复元数据的时间,我们需要定期地将edits文件合并到fsimage文件,该合并过程叫做checkpoint(这个词是真正被用烂了哈)。

由于NN的负担已经比较重,再让它来进行I/O密集型的文件合并操作就不太科学了,所以Hadoop引入了SNN负责这件事。也就是说,SNN是辅助NN进行checkpoint操作的角色

checkpoint的触发由hdfs-site.xml中的两个参数来控制。

  • dfs.namenode.checkpoint.period:触发checkpoint的周期长度,默认为1小时。

  • dfs.namenode.checkpoint.txns:两次checkpoint之间最大允许进行的操作数,默认为100万。

只要满足上述两个参数的条件之一,就会触发checkpoint过程,叙述如下:

  1. NN生成新的edits_inprogress文件,后续的修改日志将写入该文件中,之前正在写的edits文件即为待合并状态。

  2. 将待合并的edits文件和fsimage文件一起复制到SNN本地。

  3. SNN像NN启动时一样,将fsimage文件加载到内存,并重放edits文件进行合并。生成合并结果为fsimage.chkpoint文件。

  4. SNN将fsimage.chkpoint复制回NN,并重命名为正式的fsimage文件名。

Hadoop官方给出的图示如下。虽然文件名称不同,但思想是一样的。


如果开启了NN高可用呢?

上面说的都是集群只有一个NN的情况。如果有两个NN并且开启了HA的话,SNN就没用了——checkpoint过程会直接交给Standby NN来负责。Active NN会将edits文件同时写到本地与共享存储(QJM方案就是JournalNode集群)上去,Standby NN从JournalNode集群拉取edits文件进行合并,并保持fsimage文件与Active NN的同步。