扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
在NameNode的${dfs.namenode.name.dir}/current目录下,有这样几个文件:
在数据库系统中,log是用于记录写操作的日志的,并使用该Log进行备份、恢复数据等工作。有关写的操作的记录的,目前见过了两种:关系型数据库的log,HBase的WALs等等都是这样的写操作的日志。
HDFS也采用了类似的机制。在HDFS中,会将第一次的文件操作,看作一个事务。譬如说一个文件的创建、文件内容追加、文件移动等等写操作。从这个角度来看呢,fsp_w_picpath文件就相当于HDFS 的元数据的数据库文件了,而edit log就相当于是操作日志文件了。
Fsp_w_picpath:
每个fsp_w_picpath文件都会包括整个文件系统中所有的目录和文件inodes信息。每个inode是HDFS内部的一个代表文件、或者目录的元数据,如果inode代表一个文件,它包括:文件的备份级别、修改时间、访问时间、访问权限、block的size、所有blocks的构成等信息。如果inode代表一个目录,它包括:修改时间、权限、其它相关元数据等。
Edit log:
它在逻辑上,是一个实例(也就是说可以理解为一个对象),实际上是由多个文件组成的。每个文件都被称为一个segment,并以 edits_作为前缀,文件名后面的是事务id。
譬如上面的:edits_0000000000011403382-0000000000011403408 就代表该文件中放的是
事务Id为0000000000011403382到0000000000011403408之间的那些事务的信息。当客户端完成了一个写操作,并收到namenode的success的响应码时,Namenode才会将该事务信息写到editlog文件中。
为什么将事务信息处理后不直接写到fsp_w_picpath中?
如果这样做的话,也就是每个write操作完毕时,都去更新fsp_w_picpath文件,在一个大的文件系统中,文件就会变得很大,上GB都是有可能的,那么将是一个缓慢的过程。
先写到edit log中,怎么合并到fsp_w_picpath中呢?
解决方案是启动一个Secondary namenode。它的存在就是在内存中生成Primary NameNode的fsp_w_picpath文件。它的处理过程是这样的:
1、Secondary 告诉Primary去滚动它的in-progress edits文件,这样新来的write操作就会放到一个新的edit 文件中。同时Primary也会更新seen_txid文件。
2、Secondary 通过HTTP GET方式从Primary获取到最新的fsp_w_picpath和edits文件
3、Secondary 将fsp_w_picpath加载到内存中,并从edits文件中取出每一次事务,应用到fsp_w_picpath上,如此就产生了一个合并的新的fsp_w_picpath文件。
4、Secondary将这个新合并的fsp_w_picpath文件通过HTTP PUT发到Primary,Primary把它保存到临时.ckpt文件中。
5、Primary再把临时文件重命名,并使它可用。
同时,这也是为啥Secondary需要与Primary类似的内存配置,并且需要部署在一个单独的机器。
NameNode为什么不自己做合并,而是由Seconary NameNode来做呢?
NameNode不是不自己做,只是在启动时做。
首先,所有的写操作都会经过NameNode来处理,所以fap_w_picpath的内容,在NameNode的内存里,
肯定是有同样的一份。所以在运行期间,不需要通过合并来保证与内存一致。
其次,NameNode只是在启动时才进行合并操作。
也正由于这两点原因,所以需要由Secondary NameNode来完成了。不然NameNode运行了很长时间,比如累积了大量的editlog,而fsp_w_picpath又是NameNode启动后的那一次合并后的状态。那么NameNode重启后必然要进行长时间的合并操作。
另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流