1 NN和2NN工作机制

思考：NameNode中的元数据是存储在哪里的？
首先，我们做个假设，如果存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。

这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新FsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦NameNode节点断电，就会产生数据丢失。因此，引入Edits文件(只进行追加操作，效率很高)。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到Edits中。这样，一旦NameNode节点断电，可以通过FsImage和Edits的合并，合成元数据。

但是，如果长时间添加数据到Edits中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行FsImage和Edits的合并，如果这个操作由NameNode节点完成，又会效率过低。因此，引入一个新的节点SecondaryNamenode，专门用于FsImage和Edits的合并。

1）第一阶段：NameNode启动

（1）第一次启动NameNode格式化后，创建Fsimage和Edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
（2）客户端对元数据进行增删改的请求。
（3）NameNode记录操作日志，更新滚动日志。
（4）NameNode在内存中对元数据进行增删改。

2）第二阶段：Secondary NameNode工作

（1）Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否检查结果。
（2）Secondary NameNode请求执行CheckPoint。
（3）NameNode滚动正在写的Edits日志，即更改当前正在写的日志文件名称，修改为只读模式，并创建一个新的Edits_inprogress文件中继续工作。
（4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
（5）Secondary NameNode加载编辑日志和镜像文件到内存，并合并。
（6）生成新的镜像文件fsimage.chkpoint。
（7）拷贝fsimage.chkpoint到NameNode。
（8）NameNode将fsimage.chkpoint重新命名成fsimage。

PS：Fsimage记录的是数据状态，Edits记录的是执行过程。

CheckPoint时间设置

1）通常情况下，SecondaryNameNode每隔一小时执行一次。

[hdfs-default.xml]

<property>
  <name>dfs.namenode.checkpoint.period</name>
  <value>3600</value>
</property>

2）一分钟检查一次操作次数，当操作次数达到1百万时，SecondaryNameNode执行一次。

<property>
  <name>dfs.namenode.checkpoint.txns</name>
  <value>1000000</value>
<description>操作动作次数</description>
</property>

<property>
  <name>dfs.namenode.checkpoint.check.period</name>
  <value>60</value>
<description> 1分钟检查一次操作次数</description>
</property >

集群安全模式

namenode为什么不自己保存一份块信息呢？
因为如果某个DataNode挂掉后，namenode还能使用该DataNode的数据？所以，保留了也没有意义，该数据是动态的。

光环大数据：
namenode一般需要预留多大内存？
需要根据实际的datenode及将来的可能会增加的数据存储计算。
一条元数据 = 150byte
1000W = 1.5G
10E = 150G

NameNode 职责

1、负责客户端请求（读写数据请求）的响应
2、维护目录树结构（元数据的管理：查询，修改）
3、配置和应用副本存放策略
4、管理集群数据块负载均衡问题

NameNode 元数据管理

WAL （Write ahead Log ）: 预写日志系统

在使用 WAL 的系统中，所有的修改在提交之前都要先写入 log 文件中。

Log 文件中通常包括 redo 和 undo 信息。这样做的目的可以通过一个例子来说明。假设一个程序在执行某些操作的过程中机器掉电了。在重新启动时，程序可能需要知道当时执行的操作是成功了还是部分成功或者是失败了。如果使用了 WAL，程序就可以检查 log 文件，并对突然掉电时计划执行的操作内容跟实际上执行的操作内容进行比较。在这个比较的基础上，程序就可以决定是撤销已做的操作还是继续完成已做的操作，或者是保持原样。

WAL 允许用 in-place 方式更新数据库。另一种用来实现原子更新的方法是 shadow paging，它并不是 in-place方式。用 in-place 方式做更新的主要优点是减少索引和块列表的修改。ARIES是 WAL 系列技术常用的算法。在文件系统中，WAL 通常称为 journaling。PostgreSQL 也是用WAL 来提供 point-in-time 恢复和数据库复制特性。

NameNode 对数据的管理采用了 两 种存储形式：内存和磁盘

首先是 内存中存储了一份完整的元数据，包括目录树结构，以及文件和数据块和副本存储地的映射关系；

1 、 内存元数据 metadata（全部存在内存中）
其次是在 磁盘中也存储了一份完整的元数据。有三种格式：
2 、 磁盘元数据镜像文件 fsimage_0000000000000000555
fsimage_0000000000000000555
等价于
edits_0000000000000000001-0000000000000000018
……
edits_0000000000000000444-0000000000000000555
合并之和

3 、 数据 历史 操作日志文件 edits ：edits_0000000000000000001-0000000000000000018
（可通过日志运算出元数据，全部存在磁盘中）

4 、数据预写操作日志文件 edits_inprogress_0000000000000000556
（存储在磁盘中）
metadata = 最新 fsimage_0000000000000000555 + edits_inprogress_0000000000000000556
metadata = 所有的 edits 之和（edits_001_002 + …… + edits_444_555 + edits_inprogress_556）

VERSION文件

存放 hdfs 集群的版本信息

#Sun Jan 06 20:12:30 CST 2017 ## 集群启动时间
namespaceID=844434736 ## 文件系统唯一标识符
clusterID=CID-5b7b7321-e43f-456e-bf41-18e77c5e5a40 ## 集群唯一标识符
cTime=0 ## fsimage 创建的时间，初始为 0，随 layoutVersion 更新
storageType=NAME_NODE ##节点类型
blockpoolID=BP-265332847-192.168.123.202-1483581570658 ## 数据块池 ID，可以有多个
layoutVersion=-60 ## hdfs 持久化数据结构的版本号

查看 edits 文件信息：

hdfs oev -i edits_0000000000000000482-0000000000000000483 -o edits.xml

cat edits.xml

记录起始seq与结束seq，和起始seq与结束seq之间的操作。

查看 fsimage 镜像文件信息：

hdfs oiv -i fsimage_0000000000000000348 -p XML -o fsimage.xml
cat fsimage.xml

NameNode 元数据存储机制

A、内存中有一份完整的元数据(内存 metadata)
B、磁盘有一个“准完整”的元数据镜像（fsimage）文件(在 namenode 的工作目录中)
C、用于衔接内存 metadata 和持久化元数据镜像 fsimage 之间的操作日志（edits 文件）

PS：当客户端对 hdfs 中的文件进行新增或者修改操作，操作记录首先被记入 edits 日志
文件中，当客户端操作成功后，相应的元数据会更新到内存 metadata 中

元数据的 CheckPoint

每隔一段时间，会由 secondary namenode 将 namenode 上积累的所有 edits 和一个最新的fsimage 下载到本地，并加载到内存进行 merge（这个过程称为 checkpoint）

CheckPoint 详细过程图解：

CheckPoint 触发配置

CheckPoint

Namenode 和 SecondaryNamenode 的工作目录存储结构完全相同，所以，当 Namenode 故障退出需要重新恢复时，可以从SecondaryNamenode的工作目录中将fsimage拷贝到Namenode的工作目录，以恢复 namenode 的元数据。