大数据小白系列——HDFS(2)

这里是大数据小白系列，这是本系列的第二篇，介绍一下HDFS中SecondaryNameNode、单点失败（SPOF）、以及高可用（HA）等概念。

上一篇我们说到了大数据、分布式存储，以及HDFS中的一些基本概念，为了能更好的理解后续介绍的内容，这里先补充介绍一下NameNode到底是怎么存储元数据的。

首先，在启动的时候，将磁盘中的元数据文件读取到内存，后续所有变化将被直接写入内存，同时被写入一个叫Edit Log的磁盘文件。（如果你熟悉关系型数据库，这个Edit Log有点像Oracle Redo Log，这是题外话）。

Q: 为什么不把这些变化直接写到磁盘上的元数据中，使磁盘上的元数据保持最新呢？Edit Log是不是多此一举？

A: 这个主要是基于性能考虑，由于对Edit Log的写是“顺序写”（追加），对元数据的写是“随机写”，两者在磁盘上表现出来的性能有相当大的差异。有兴趣的同学可以搜索学习一下磁盘相关原理哦。

上面这个方案，带来了一些明显的副作用。

• NameNode长期运行，不停地向Edit Log追加内容，导致它变得巨大无比。
• NameNode在重启时，需要使用Edit Log更新元数据文件，当Edit Log太大时，这一步骤就会耗费很长的时间。

为了消除这些副作用，HDFS中引入了另外一个角色，SecondaryNameNode。

它定期（比如每小时）从NameNode上抓取Edit Log，使用它更新元数据文件，并把最新的元数据文件写回到NameNode。

说完了SecondaryNameNode的职责之后，大家应该明白，它并不是一个“备用NameNode”，其实这是典型的命名不当，它应该被命名成“Checkpoint NameNode”才比较恰当。

接下来我们来说说HDFS中的单点失败问题（SPOF, Single Point Of Failure），即，当NameNode掉线之后，整个HDFS集群就变得不可用了。为解决这个问题，Hadoop 2.0中真正引入了一个“备用NameNode”。

• 对元数据的修改首先发生在NameNode，并被写入某个“共享位置”，备用NameNode将从该位置获取Edit Log。
• DataNode节点们同时向两台NameNode汇报状态。

由于这两点，两台NameNode上的元数据将一直保持同步。这将保证当NameNode掉线后，用户可以立即切换到备用NameNode，系统将保持可用。

由于备用NameNode比较空闲（不用处理用户请求），系统又给它安排了另外一份工作——定期使用Edit Log更新元数据文件，也就是说它接手了SecondaryNameNode的工作。

所以，在HA环境中，我们就不再需要SecondaryNameNode了。

今天就到这里，下一篇准备介绍JournalNode、NameNode选举等概念，Cheers！

---

公众号“程序员杂书馆”，专注大数据，欢迎关注，每位关注者将获赠《Spark快速大数据分析》纸质书一本！