大数据小白系列——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快速大数据分析》纸质书一本！