hadoop及NameNode和SecondaryNameNode工作机制

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就够了。

原文地址:https://www.cnblogs.com/zhqin/p/11904249.html