标签：拓展 大小 bsp epo names 管理 cond 引用 second
参考：
https://blog.csdn.net/lb812913059/article/details/78713634 （主要看这篇即可）
https://blog.csdn.net/u010846741/article/details/52369527
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文件加载到内存中来进行重建恢复
【基础组件10】hadoop拓展（三）NameNode工作机制
标签：拓展 大小 bsp epo names 管理 cond 引用 second
原文地址：https://www.cnblogs.com/Agnes1994/p/12227890.html
