大数据面试题之Hadoop:每日三题(二)

1.NameNode在启动的时候会做哪些操作

NameNode数据存储在内存和本地磁盘，本地磁盘数据存储在fsimage镜像文件和edits编辑日志文件

• 首次启动NameNode
  1.格式化文件系统，为了生成fsimage镜像文件
  2.启动NameNode
  （1）读取fsimage文件，将文件内容加载进内存
  （2） 等待DataNode注册与发送block report
  3.启动DataNode
  (1) 向NameNode注册
  (2) 发送block report
  (3) 检查fsimage中记录的块的数量和block report中的块的总数是否相同
  4.对文件系统进行操作(创建目录，上传文件，删除文件等)
  （1）此时内存中已经有文件系统改变的信息，但是磁盘中没有文件系统改变的信息，此时会将这些
  改变信息写入edits文件中，edits文件中存储的是文件系统元数据改变的信息。

• 第二次启动NameNode
  1.读取fsimage和edits文件
  2.将fsimage和edits文件合并成新的fsimage文件
  3.创建新的edits文件，内容为空
  4.启动DataNode

2.Secondary NameNode了解吗?它的工作机制是怎样的

Secondary NameNode 是合并NameNode的edit logs到 fsimage文件中；
它的具体工作机制：

（1）Secondary NameNode询问NameNode是否需要checkpoint。直接带回NameNode
是否检查结果
(2） Secondary NameNode请求执行checkpoint
(3) NameNode滚动正在写的edits日志
(4) 将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode
(5) Secondary NamenNode加载编辑日志和镜像文件到内存，并合并
(6） 生成新的镜像文件fsimage.chkpoint
(7) 拷贝fsimage.chkpoint 到 NameNode
(8）NameNode 将fsimage.chkpoint 重新命名成fsimage
所以如果NameNode中的元数据丢失，是可以从Secondary NameNode 恢复一部所以如果NameNode中的元数据丢失，是可以从Secondary NameNode恢复一部分元数据信息的，但是不是全部，因为Namenode正在写的edits日志还没有拷贝到Secondary NameNode，这部分恢复不了

3.Secondary NameNode 不能恢复NameNode的全部数据，那如何保证NameNode数据存储安全

这个问题就要说 NameNode 的高可用了，即 NameNode HA 一个 NameNode 有单点故障的问题，那就配置双 NameNode，配置有两个关键点，一是必须要保证这两个 NN 的元数据信息必须要同步的，二是一个 NN 挂掉之后，另一个要立马补上。

1. 元数据信息同步在 HA 方案中采用的是“共享存储”。每次写文件时，需要将日志同步写入共享存储，这个步骤成功才能认定写文件成功。然后备份节点定期从共享存储同步日志，以便进行主备切换。

2. 监控 NN 状态采用 zookeeper，两个 NN 节点的状态存放在 ZK 中，另外两个 NN 节点分别有一个进程监控程序，实施读取 ZK 中有 NN 的状态，来判断当前的 NN 是不是已经 down 机。如果 standby 的 NN 节点的 ZKFC 发现主节点已经挂掉，那么就会强制给原本的 active NN 节点发送强制关闭请求，之后将备用的 NN 设置为 active。

3. 如果面试官再问 HA 中的 共享存储 是怎么实现的知道吗？
   可以进行解释下：NameNode 共享存储方案有很多，比如 Linux HA, VMware FT, QJM 等，目前社区已经把由 Clouderea 公司实现的基于 QJM（Quorum Journal Manager）的方案合并到 HDFS 的 trunk 之中并且作为默认的共享存储实现基于 QJM 的共享存储系统主要用于保存 EditLog，并不保存 FSImage 文件。FSImage 文件还是在 NameNode 的本地磁盘上。QJM 共享存储的基本思想来自于 Paxos 算法，采用多个称为 JournalNode 的节点组成的 JournalNode 集群来存储 EditLog。每个 JournalNode 保存同样的 EditLog 副本。每次 NameNode 写 EditLog 的时候，除了向本地磁盘写入EditLog 之外，也会并行地向 JournalNode 集群之中的每一个 JournalNode 发送写请求，只要大多数 (majority) 的 JournalNode 节点返回成功就认为向 JournalNode 集群写入EditLog 成功。如果有2N+1 台 JournalNode，那么根据大多数的原则，最多可以容忍有 N台 JournalNode 节点挂掉