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文件了。
HDFS适合存储小文件吗?
其实主要是看NameNode,文件的元数据信息虽然是存放在硬盘中,但是在查询的过程中始终是在内存中维护的
如果存储的小文件很多的话,存储小文件的磁盘空间虽然占用不大,但是会导致元数据信息很大,内存占用也很大,在NameNode一台机器上做大量查询,服务器的速度会被拖得很慢。所以HDFS不适合存储小文件。
深入理解NameNode
1、 如果删除NameNode工作目录是否还能找到元数据信息?
能,删除nn目录,磁盘中虽然没有元数据信息了,但是内存中还有,可以查询到。
2、 如果NameNode磁盘损坏,元数据是否还能恢复?
可以恢复一部分,通过将snn的文件都拷贝到nn下。如果edits文件未达到合并的条件,nn磁盘损坏后一段时间发生了文件更改,这时更改信息并没有保存在snn的fsimage文件中,所以nn通过备份snn的文件不能恢复到完整状态,可能发生元数据信息的丢失。
3、 我们在配置NameNode工作目录参数的时候有什么需要注意的?
路径写到网络磁盘上,多写几个网络存储地址(nfs)。
写文件流程
在写过程中,如果查询到hadoop.jar存在,在hadoop shell模式下,是不可写的,但是用java是可以覆盖写入的。
对于客户端来说,写完一块就算成功了,不需要等待DataNode完成3备份返回相应的状态。因为整个大数据环境并不是完全可靠的,在d1向d3传送数据时,如果d3这台机器挂了,没有返回数据,那么要客户端一直等待的话,没有意义,用户体验很差。
读文件流程
HDFS特点
1、 HDFS以流的方式读写文件。
2、 适合大文件(文件大于128M)的存储。
3、 一次写入,多次读取,不支持并发写入。
4、 整个环境对硬件配置的要求不高。
5、 不支持实时返回数据。