计算机中存储数据有两种:内存或磁盘
元数据存储磁盘: 存储磁盘无法面对客户端对元数据信息的任意的快速低延迟的响应,但是安全性高
元数据存储内存:元数据存放内存,可以高效的查询以及快速响应客户端的查询请求,数据保存在内存,如果断电,内存中的数据全部丢失
因此,考虑上述两种存储方式的优缺点,HDFS采用了内存+磁盘的形式来管理元数据。即: NameNode(内存)+FsImage文件
FsImage
FsImage: 是namenode中关于元数据的镜像,一般称为检查点(checkpoing),这里包含了HDFS文件系统所有目录以及文件相关信息(Block数量,副本数量,权限等信息)
由于如果要将操作写入FsImage(磁盘)会降低运行效率。所以想法就是对于增删改操作,只有内存中的元数据进行响应,而不直接进行磁盘IO读写。此时,为了保证两个数据的一致性,NameNode就引入了以一个edits文件,该日志文件只能进行追加写入,以此来记录client的每次增删改操作。虽然此时仍然有IO流的操作,但是相比于每次将元数据内容写入Fsimage,edits日志文件的写入内容更少,效率更高。
Edits文件
Edits:存储了客户端对HDFS文件系统所有的更新操作记录,Client对HDFS文件系统所有的更新操作都会被记录到Edits文件中(不包括查询操作)
edits文件记录的就是当原FsImage被载入内存后,Client又对元数据进行了哪些操作。 这样,只要在原FsImage中执行这些操作,对保存的元数据信息进行更新,就可以使得内存和磁盘汇总的元数据信息一致。通过此方法,即解决了为了保证一致性,要对FsImage直接进行写入的过程。这也是引入edits文件的关键原因。
Fsimage与Edits的合并
为了进行合并,还引入了另一个SecondaryNameNode节点。SecondaryNanoe是HDFS架构中的一个组成部分,它是用来保存namenode中对HDFS metadata的信息的备份而设定的。一般都是将SecondaryNamenode单独运行在一台机器上。
- SecondaryNamenode会定期的和NameNode通信,请求其停止使用edits文件,暂时将新的写操作写到一个新的文件edit.new上来,这个操作是瞬间完成,上层写日志的函数完全感觉不到差别;
- SecondaryNamenode通过HTTP GET方式从NameNode上获取到fsimage和edits文件,并下载到本地的相应目录下;
- SecondaryNamenode将下载下来的fsimage载入到内存,然后一条一条地执行edits文件中的各项更新操作,使得内存中的fsimage保存最新;这个过程就是edits和fsimage文件合并;
- SecondaryNamenode执行完(3)操作之后,会通过post方式将新的fsimage文件发送到NameNode节点上
- NameNode将从SecondaryNamenode接收到的新的fsimage替换旧的fsimage文件,同时将edit.new替换edits文件,通过这个过程edits就变小了!