1.首先，我们做个假设，如果存储在 NameNode 节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。**因此产生在磁盘中备份元数据的 FsImage。**2.这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新 FsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦 NameNode 节点断电，就会产生数据丢失。因此，引入 Edits 文件（只进行追加操作，效率很高）。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到 Edits 中。这样，一旦 NameNode 节点断电，可以通过 FsImage 和 Edits 的合并，合成元数据。3.但是，如果长时间添加数据到 Edits 中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行 FsImage 和 Edits 的合并，如果这个操作由NameNode节点完成，又会效率过低。**因此，引入一个新的节点SecondaryNamenode， 专门用于 FsImage 和 Edits 的合并**。
1、NN的作用
（1）NN保存着HDFS上所有文件的元数据，这些信息以两个文件的形式永久保存在本地磁盘上：fsimage镜像文件和edits编辑日志文件。
（2）负责接受客户端的请求
（3）负责接收DN上报的信息，给DN分配任务
2、DN的作用
DN是文件系统的工作结点。它们根据需要来存储并检索数据块(受客户端和NN的调度)，并且定期向NN发送它们所存储的块的列表。（心跳机制）
3、2NN的作用
定期合并编辑日志和镜像文件，以防止编辑日志过大。2NN一般在另一条单独的物理计算机上运行，因为需要占用大量CPU时间，并且需要与NN一样多的内存来执行合并操作。
注意：SecondaryNamenode永远无法取代Namenode的位置，也算不上Namenode的一个热备。(热备:在程序运行时进行备份，而它是定期检查合并)
第一阶段：NameNode 启动
（1）第一次启动 NameNode 格式化后，创建 Fsimage 和 Edits 文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
（2）客户端对元数据进行增删改的请求。（这里就是客户端对hdfs的读/取请求）
（3）NameNode 记录操作日志，更新滚动日志。（edits）
（4）NameNode 在内存中对元数据进行增删改。（fsimage）
注意：先更新日志，再对元数据进行操作（假如先对内存的元数据操作，此时NameNode挂了，下次启动的时候上次的操作就丢失了）
第二阶段：Secondary NameNode 工作
（1）Secondary NameNode 询问 NameNode 是否需要 CheckPoint(默认1小时)。直接带回 NameNode 是否检查结果。
（2）Secondary NameNode 请求执行 CheckPoint。
（3）NameNode 滚动正在写的 Edits 日志。 (滚动在NameNode中生成edits_inprogress_002，2NN没有。)
（4）将滚动前的编辑日志和镜像文件拷贝到 Secondary NameNode。
（5）Secondary NameNode 加载编辑日志和镜像文件到内存，并合并。
（6）生成新的镜像文件 fsimage.chkpoint。
（7）拷贝 fsimage.chkpoint 到 NameNode。
（8）NameNode 将 fsimage.chkpoint 重新命名成 fsimage。
4、Fsimage镜像文件和edits编辑日志文件
（1）fsimage（镜像文件）：是Hadoop文件系统元数据的一个永久性的检查点，含了整个HDFS文件系统的所有目录和文件的信息。
（2）edits（编辑日志）：存放的是Hadoop文件系统的所有更新操作的路径，客户端执行的所有写操作首先会被记录到edits文件中。
（3）每次NameNode启动的时候都会将Fsimage文件和Edits读入内存，加载Edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成NameNode启动的时候就将Fsimage和Edits文件进行了合并。
（4）怎么查看这两个文件？
1）oiv 查看 Fsimage 文件
基本语法：hdfs oiv -p 文件类型 -i 镜像文件 -o 转换后文件输出路径。
思考：可以看出，Fsimage 中没有记录块所对应 DataNode，为什么？因为在集群启动后，要求 DataNode 上报数据块信息，并间隔一段时间后再次上报。
2）oev 查看 Edits 文件
基本语法：hdfs oev -p 文件类型 -i 编辑日志 -o 转换后文件输出路径
思考：NameNode 如何确定下次开机启动的时候合并哪些 Edits？ 小于当前最新的fsimage文件最后的id号的那些Edits文件不管，只合并大于这个值的那些Edits和这个fsimage。
5、CheckPoint 时间设置：（针对2NN何时工作，也就是两个触发条件，满足一个就开始工作，也就是完成一次对FsImage和Edits的合并）
思考：定时时间到，2NN直接完成CheckPoint不就行了么，为什么还要经常询问呢？
就是要检查NN中Edits的操作次数，达到一百万了，就需要CheckPoint了，假如Edits的命令超出很多再进行CheckPoint，那么此时也没有足够的资源能处理如此巨大的数据量，因此只要操作数达到1百万条就可以触发CheckPoint。
6、NameNode的故障恢复
当2NN对NN中的fsimage和edits文件进行合并时，每次都会先将NN中的这两个文件拷贝过来，所以2NN上存储了一份fsimage个edits。 如果NN的的fsimage与edits文件损坏，那么我们可以将2NN当中的fsimage与edits拷贝过去给NN继续使用，只不过有可能会丢失一部分数据。
NN故障恢复步骤：
（1）杀死NN进程；（jps查看，kill杀死）
（2）删除NN的fsimage与edits文件；
（3）拷贝 2NN的 fsimage 与 edits 文件到 NN的 fsimage 与 edits 文件夹下面去；
（4）启动 NN；
1、DN的作用
DN是文件系统的工作结点。它们根据需要来存储并检索数据块(受客户端和NN的调度)，并且定期向NN发送它们所存储的块的列表。（心跳机制）
2、工作机制
（1）一个数据块在 DataNode 上以文件形式存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据包括数据块的长度，块数据的校验和，以及时间戳。
（2）DataNode 启动后向 NameNode 注册，通过后，周期性（6 小时）的向 NameNode 上 报所有的块信息。
（3）心跳是每 3 秒一次，心跳返回结果带有 NameNode 给该 DataNode 的命令如复制块数据到另一台机器（主要是datanode向namenode说"我还活着"。），或删除某个数据块。如果超过 10 分钟没有收到某个 DataNode 的心跳， 则认为该节点不可用。
（4）集群运行中可以安全加入和退出一些机器。