【基础组件10】hadoop拓展(三)NameNode工作机制

一、Hadoop NameNode详解

参考:

https://blog.csdn.net/lb812913059/article/details/78713634   (主要看这篇即可)

https://blog.csdn.net/u010846741/article/details/52369527

其他拓展HDFS参考:

https://blog.csdn.net/sjmz30071360/article/details/79877846

https://blog.csdn.net/nihaoa50/article/details/88419432

NameNode在内存中保存着整个文件系统的名字空间和文件数据块的地址映射(Blockmap)。如果NameNode宕机,那么整个集群就瘫痪了
整个HDFS可存储的文件数受限于NameNode的内存大小
这个关键的元数据结构设计得很紧凑,因而一个有4G内存的Namenode就足够支撑大量的文件和目录。

一般情况下,单namenode集群的最大集群规模为4000台

1、NameNode元数据信息 

在内存中加载文件系统中每个文件和每个数据块的引用关系(文件、block、datanode之间的映射信息) 。
数据会定期保存到本地磁盘,但不保存block的位置信息而是由DataNode注册时上报和在运行时维护。

2、NameNode职责
全权管理数据块的复制,周期性的接受心跳和块的状态报告信息(包含该DataNode上所有数据块的列表)
若接受到心跳信息,NN认为DN工作正常,如果在10分钟后还接受到不到DN的心跳,那么NN认为DN已经宕机
这时候NN准备要把DN上的数据块进行重新的复制。
块的状态报告包含了一个DN上所有数据块的列表,blocks report 每个1小时发送一次


3、NameNode容错机制 

运行一个辅助的Namenode(SecondaryNamenode)。 事实上SecondaryNamenode并不能被用作Namenode它的主要作用是定期的将Namespace镜像与操作日志文件(edit log)合并,以防止操作日志文件(edit log)变得过大。通常,SecondaryNamenode 运行在一个单独的物理机上,因为合并操作需要占用大量的CPU时间以及和Namenode相当的内存。辅助Namenode保存着合并后的Namespace镜像的一个备份,万一哪天Namenode宕机了,这个备份就可以用上了。

4.NameNode的存储目录

hdfs的命名空间存储在namenode的内存中,EditLog/FsImage存储在namenode本地的文件系统中

EditLog事务日志:

  记录发生在文件系统元数据上的所有变化。

  比如: 在文件系统中创建一个文件,namenode就会在EditLog中插入一条记录标记一下。

     同样的,修改一个文件的副本因子同样会在触发EditLog中插入一条记录。

FsImage文件:

  简单的说,Fsimage就是在某一时刻,整个hdfs的快照

  就是这个时刻hdfs上所有的文件块和目录,分别的状态,位于哪些个datanode,各自的权限,副本个数等。

  和编辑日志不同,它不会在每个文件系统的写操作后都进行更新

  因为写出fsimage文件会非常慢(fsimage可能增长到GB大小)。

  这种设计并不会影响系统的恢复力 如果NameNode失败,可以通过读出磁盘中fsimage文件加载到内存中来进行重建恢复

原文地址:https://www.cnblogs.com/Agnes1994/p/12227890.html