跟我学大数据之二:NameNode和SecondaryNameNode

浏览: 1859

NameNode和SecondaryNameNode

         SecondaryNameNode:看起来很像是第二个NameNode,目录结构与NameNode完全相同,但是没办法接替NameNode。

         在NameNode中元数据信息分成两个文件进行存储:fsimage和edits。NameNode启动时会先把fsimage文件读到内存中去,这样元数据信息就可以继续在内存中维护。

         Fsimage文件保存的是NameNode重启之前所有的元数据信息。edits文件保存的是变化的数据,比如上传文件,删除文件,修改文件产生的所有日志都会记录在edits文件中。那么为什么启动NameNode只需要读取fsimage文件,原因是考虑到当edits文件很大时,合并fsimage和edits很浪费时间,所以就让SecondaryNameNode定期将fsimage和edits合并成新的fsimage文件再替代NameNode上原来的fsimage文件,最后就只需要读取fsimage文件了。

Clipboard Image.png

HDFS适合存储小文件吗?

         其实主要是看NameNode,文件的元数据信息虽然是存放在硬盘中,但是在查询的过程中始终是在内存中维护的

Clipboard Image.png  

如果存储的小文件很多的话,存储小文件的磁盘空间虽然占用不大,但是会导致元数据信息很大,内存占用也很大,在NameNode一台机器上做大量查询,服务器的速度会被拖得很慢。所以HDFS不适合存储小文件。


深入理解NameNode

1、  如果删除NameNode工作目录是否还能找到元数据信息?

能,删除nn目录,磁盘中虽然没有元数据信息了,但是内存中还有,可以查询到。

2、  如果NameNode磁盘损坏,元数据是否还能恢复?

可以恢复一部分,通过将snn的文件都拷贝到nn下。如果edits文件未达到合并的条件,nn磁盘损坏后一段时间发生了文件更改,这时更改信息并没有保存在snn的fsimage文件中,所以nn通过备份snn的文件不能恢复到完整状态,可能发生元数据信息的丢失。

3、  我们在配置NameNode工作目录参数的时候有什么需要注意的?

路径写到网络磁盘上,多写几个网络存储地址(nfs)。

写文件流程

Clipboard Image.png

在写过程中,如果查询到hadoop.jar存在,在hadoop shell模式下,是不可写的,但是用java是可以覆盖写入的。

对于客户端来说,写完一块就算成功了,不需要等待DataNode完成3备份返回相应的状态。因为整个大数据环境并不是完全可靠的,在d1向d3传送数据时,如果d3这台机器挂了,没有返回数据,那么要客户端一直等待的话,没有意义,用户体验很差。


读文件流程

Clipboard Image.png


HDFS特点

1、  HDFS以流的方式读写文件。

2、  适合大文件(文件大于128M)的存储。

3、  一次写入,多次读取,不支持并发写入。

4、  整个环境对硬件配置的要求不高。

5、  不支持实时返回数据。

推荐 2
本文由 Kenny 创作,采用 知识共享署名-相同方式共享 3.0 中国大陆许可协议 进行许可。
转载、引用前需联系作者,并署名作者且注明文章出处。
本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责。本站是一个个人学习交流的平台,并不用于任何商业目的,如果有任何问题,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

1 个评论

看博客比视频舒服多了 - -@!!

要回复文章请先登录注册