我们知道HDFS是一个分布式文件存储系统，文件分布式存储在多个DataNode节点上。一个文件存储在哪些DataNode节点的哪些位置的元数据信息（metadata）由NameNode节点来处理。随着存储文件的增多，NameNode上存储的信息也会越来越多。那么HDFS是如何及时更新这些metadata的呢？
　　在HDFS中主要是通过两个组件FSImage和EditsLog来实现metadata的更新。在某次启动HDFS时，会从FSImage文件中读取当前HDFS文件的metadata，之后对HDFS的操作步骤都会记录到edit log文件中。比如下面这个操作过程
　　
　　那么完整的metadata信息就应该由FSImage文件和edit log文件组成。fsimage中存储的信息就相当于整个hdfs在某一时刻的一个快照。
　　FSImage文件和EditsLog文件可以通过ID来互相关联。在参数dfs.namenode.name.dir设置的路径下，会保存FSImage文件和EditsLog文件，如果是QJM方式HA的话，EditsLog文件保存在参数dfs.journalnode.edits.dir设置的路径下。

先看下namenode节点的备份节点 namesecondary节点

一、FsImage和Editslog分别是什么？

Editslog ：保存了所有对hdfs中文件的操作信息
FsImage：是内存元数据在本地磁盘的映射，用于维护管理文件系统树，即元数据(metadata)
在hdfs中主要是通过两个数据结构FsImage和EditsLog来实现metadata的更新。在某次启动hdfs时，会从FSImage文件中读取当前HDFS文件的metadata，之后对HDFS的操作步骤都会记录到edit log文件中。

metadata信息就应该由FSImage文件和edit log文件组成。fsimage中存储的信息就相当于整个hdfs在某一时刻的一个快照。

　　FsImage文件和EditsLog文件可以通过ID来互相关联。如果是非HA集群的话，这两个数据文件保存在dfs.namenode.name.dir设置的路径下，会保存FsImage文件和EditsLog文件，如果是HA集群的话，EditsLog文件保存在参数dfs.journalnode.edits.dir设置的路径下，即edits文件由qjournal集群管理。

查看namenode节点 fsimage和editlog文件

cd /usr/local/hadoop/hadoop-3.1.2/dfs/name/

在上图中edit log文件以edits_开头，后面跟一个txid范围段，并且多个edit log之间首尾相连，正在使用的edit log名字edits_inprogress_txid。该路径下还会保存两个fsimage文件（{dfs.namenode.num.checkpoints.retained}在namenode上保存的fsimage的数目，超出的会被删除。默认保存2个），文件格式为fsimage_txid。上图中可以看出fsimage文件已经加载到了最新的一个edit log文件，仅仅只有inprogress状态的edit log未被加载。

在启动HDFS时，只需要读入fsimage_0000000000000000058以及edits_inprogress_0000000000000000062就可以还原出当前hdfs的最新状况。

（FsImageid总是比editslogid小）

但是这里又会出现一个问题，如果edit log文件越来越多、越来越大时，当重新启动hdfs时，由于需要加载fsimage后再把所有的edit log也加载进来，就会出现第一段中出现的问题了。怎么解决？HDFS会采用checkpoing机制定期将edit log合并到fsimage中生成新的fsimage。这个过程就是接下来要讲的了。

那么这两个文件是如何合并的呢？这就引入了checkpoint机制

二、checkpoint机制：

fsimage和edit log合并的过程如下图所示：
　　
因为文件合并过程需要消耗io和cpu所以需要将这个过程独立出来，在Hadoop1.x中是由Secondnamenode来完成，且Secondnamenode必须启动在单独的一个节点最好不要和namenode在同一个节点，这样会增加namenode节点的负担，而且维护时也比较方便。同样在HA集群中这个合并的过程是由Standbynamenode完成的。

其实这个合并过程是一个很耗I/O与CPU的操作，并且在进行合并的过程中肯定也会有其他应用继续访问和修改hdfs文件。所以，这个过程一般不是在单一的NameNode节点上进行从。如果HDFS没有做HA的话，checkpoint由SecondNameNode进程(一般SecondNameNode单独起在另一台机器上)来进行。在HA模式下，checkpoint则由StandBy状态的NameNode来进行。
　　什么时候进行checkpoint由两个参数dfs.namenode.checkpoint.preiod(默认值是3600，即1小时)和dfs.namenode.checkpoint.txns(默认值是1000000)来决定。period参数表示，经过1小时就进行一次checkpoint，txns参数表示，hdfs经过100万次操作后就要进行checkpoint了。这两个参数任意一个得到满足，都会触发checkpoint过程。进行checkpoint的节点每隔dfs.namenode.checkpoint.check.period(默认值是60）秒就会去统计一次hdfs的操作次数

1.合并的过程：过程类似于TCP协议的关闭过程（四次挥手）

首先Standbynamenode进行判断是否达到checkpoint的条件（是否距离上次合并过了1小时或者事务条数是否达到100万条）
当达到checkpoint条件后，Standbynamenode会将qjournal集群中的edits和本地fsImage文件合并生成一个文件fsimage_ckpt_txid（此时的txid是与合并的editslog_txid的txid值相同），同时Standbynamenode还会生成一个MD5文件，并将fsimage_ckpt_txid文件重命名为fsimage_txid
向Activenamenode发送http请求（请求中包含了Standbynamenode的域名，端口以及新fsimage_txid的txid），询问是否进行获取
Activenamenode获取到请求后，会返回一个http请求来向Standbynamenode获取新的fsimage_txid，并保存为fsimage.ckpt_txid，生成一个MD5，最后再改名为fsimage_txid。合并成功。
2.合并的时机：
什么时候进行checkpoint呢？这由两个参数dfs.namenode.checkpoint.preiod(默认值是3600，即1小时)和dfs.namenode.checkpoint.txns(默认值是1000000)来决定

（1）距离上次checkpoint的时间间隔 {dfs.namenode.checkpoint.period}

（2） Edits中的事务条数达到{dfs.namenode.checkpoint.txns}限制，

事物条数又由{dfs.namenode.checkpoint.check.period(默认值是60）}决

定，checkpoint节点隔60秒就会去统计一次hdfs的操作次数。

三、HA模式下Checkpointing过程分析

　　在HA模式下checkpoint过程由StandBy NameNode来进行，以下简称为SBNN，Active NameNode简称为ANN。
　　HA模式下的edit log文件会同时写入多个JournalNodes节点的dfs.journalnode.edits.dir路径下，JournalNodes的个数为大于1的奇数，类似于Zookeeper的节点数，当有不超过一半的JournalNodes出现故障时，仍然能保证集群的稳定运行。
　　SBNN会读取FSImage文件中的内容，并且每隔一段时间就会把ANN写入edit log中的记录读取出来，这样SBNN的NameNode进程中一直保持着hdfs文件系统的最新状况namespace。当达到checkpoint条件的某一个时，就会直接将该信息写入一个新的FSImage文件中，然后通过HTTP传输给ANN。
　　
　　如上图所示，主要由4个步骤：
1. SBNN检查是否达到checkpoint条件：离上一次checkpoint操作是否已经有一个小时，或者HDFS已经进行了100万次操作。
2. SBNN检查达到checkpoint条件后，将该namespace以fsimage.ckpt_txid格式保存到SBNN的磁盘上，并且随之生成一个MD5文件。然后将该fsimage.ckpt_txid文件重命名为fsimage_txid。
3. 然后SBNN通过HTTP联系ANN。
4. ANN通过HTTP从SBNN获取最新的fsimage_txid文件并保存为fsimage.ckpt_txid，然后也生成一个MD5，将这个MD5与SBNN的MD5文件进行比较，确认ANN已经正确获取到了SBNN最新的fsimage文件。然后将fsimage.ckpt_txid文件重命名为fsimage_txit。
　　通过上面一系列的操作，SBNN上最新的FSImage文件就成功同步到了ANN上。

文章部分内容参考：https://blog.csdn.net/q35445762/article/details/91472746

https://www.cnblogs.com/nucdy/p/5892144.html

hadoop3.1.2版本中FsImage与Editslog合并解析相关推荐

HDFS fsimage和edits合并实现原理
2019独角兽企业重金招聘Python工程师标准>>> 1. Hadoop 1.x 版本 fsimage和edits合并实现原理在NameNode运行期间,HDFS的所有更新操作都 ...
php 5.6 mcrypt,php-mcrypt 在PHP5.60+的版本中怎么使用？
目前项目中的一个密码对接放在正式环境之后出现了问题, 原因是在PHP5.6以上的版本中修改了mcrypt_encrypt 和 mcrypt_decrypt, 有人知道在新版本的PHP中应该怎么使用这两 ...
Java最新版本中另外发现五项漏洞
就在Java披露两项安全漏洞的仅仅一周之后,一家波兰安全企业再次发布报告,称在Java最新版本中另外发现五项漏洞.在旧有漏洞的影响之下,***者能够利用新问题绕过Java的沙箱机制并安装恶意软件. S ...
php5.5.9 新特性,php,_PHP 5.5.9版本中COOKIE的奇怪现象，php - phpStudy
PHP 5.5.9版本中COOKIE的奇怪现象我在localhost下建了四个文件 /1.php /a/1.php /test/1.php /test/a/1.php 文件中的代码都是一样的 set ...
python3.7扩展库是什么_Python3.4以后的版本中,____________库用于安装管理Python扩展包,________________库用于发布Python包。_学小易找答案...
[填空题]Python3.4以后的版本中,____________库用于安装管理Python扩展包,________________库用于发布Python包. [判断题]Directions: The ...
Tensorflow：在Tensorflow的不同版本中如何实现Xavier参数权重初始化
Tensorflow:在Tensorflow的不同版本中如何实现Xavier参数权重初始化目录在Tensorflow的不同版本中实现Xavier参数权重初始化 Tensorflow1版本中实现
linux需要的GLIBCXX版本,GCC版本中没有GLIBCXX_3.4.15解决
run: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15"" not found 解决错误呈现该错误的原因是当前的GCC版本中, ...
HDFS底层原理系列讲解之fsimage、editslog
HDFS底层原理系列讲解之fsimage.editslog
Qt 5.12 LTS(长期维护版本)中Qt Quick的性能改进
我们一直致力于提高Qt的性能和优化其内存消耗.Qt 5.12的一个重点关注是在于减少QML引擎的内存消耗和优化JavaScript性能. 与上一个长期支持版Qt 5.6 LTS相比,Qt 5.9 LT ...

hadoop3.1.2版本中FsImage与Editslog合并解析

先看下namenode节点的备份节点 namesecondary节点

一、FsImage和Editslog分别是什么？

二、checkpoint机制：

1.合并的过程：过程类似于TCP协议的关闭过程（四次挥手）

三、HA模式下Checkpointing过程分析

hadoop3.1.2版本中FsImage与Editslog合并解析相关推荐

最新文章

热门文章

hadoop3.1.2版本中FsImage与Editslog合并解析

先看下namenode节点的备份节点 namesecondary节点

一、FsImage和Editslog分别是什么 ？

二、checkpoint机制：

1.合并的过程：过程类似于TCP协议的关闭过程（四次挥手）

三、HA模式下Checkpointing过程分析

hadoop3.1.2版本中FsImage与Editslog合并解析相关推荐

最新文章

热门文章

一、FsImage和Editslog分别是什么？