hadoop及NameNode和SecondaryNameNode工作机制

Posted 2020-11-22 crazy_cat

hadoop及NameNode和SecondaryNameNode工作机制

1.hadoop组成

Common
MapReduce
Yarn
HDFS

（1）HDFS

namenode：存放目录，最重要的（主机）
datanode：存放数据。（从机）
2namenode：“助手”

（2）YARN

ResourceManager

NodeManager

ApplicationMaster

Container

NameNode和SecondaryNameNode工作机制

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

那么问题来了，如何写呢？如果一次性写入磁盘的话，粗略算一下，如果128G内存的namenode，如果把内存中的数据一次性全部写入磁盘的话大概需要3分钟的时间，那么意味着这三分钟之内，集群不能再接收任何的数据，只能完成写磁盘操作后才能执行其他功能，这无疑不可取。

所以HDFS选择了一种持久化措施，类似于Redis的AOF持久化过程。

工作过程：

每进行一次写磁盘操作，将这个操作追加到edits文件中，然后将内存作为一个状态（内存镜像）保存在硬盘中，然后2nn根据edits中记录的写操作，逐条执行，把edits中的写操作和磁盘中保存的内存镜像FsImage进行合并然后保存下来。

具体过程为：

首先namenode启动，启动的同时，首先将之前的edits.log和FsImage合并加载到内存中，至此namenode启动完毕。如果此时从客户端发来一个增删改请求，首先namenode会记录操作日志、更新滚动日志，先在磁盘中edits文件中追加这条增删改的请求，然后在到内存中进行数据的增删改。

然后2nn定时向namenode请求是否需要CheckPoint，（2nn帮忙完成edits合并成FsImage，CheckPoint类似于“存档”。）

CheckPoint的触发条件：
（1）定时时间到；
（2）Edits中的数据达到一定数量。

如果namenode需要CheckPoint（触发了CheckPoint），那么，2nn向nn请求执行CheckPoint，NameNode收到CheckPoint请求之后，将日志edits重命名，并且建立一个新的正在写的Edits文件，将重命名之后的edits文件拿给2nn去进行合并操作，建立的新的Edits文件用来记录当前客户端发来的写请求。

2nn将之前namenode重命名之后的edits文件和FsImage拷贝到自己的节点上，先将FsImage（内存状态）加载到内存中，然后将edits加载到内存中，进行合并。此时内存恢复的状态就恢复到了当时namenode重命名的日志edits日志结束时候的位置，然后2nn将内存中的数据全部写到磁盘上生成新的FsImage，这里我们称其为FsImage.chkpoint，然后将FsImage.chkpoint拷贝发送到nn节点。这是第一次合并，从第二次开始，2nn就不会加载FsImage了，只需要加载edits就够了。