NameNode详解
- 管理DataNode和记录元数据Meta
- 元数据包含:
a. 记录数据的虚拟存储路径
b. 记录文件的切块数量
c. 记录数据块的存储位置
d. 记录数据块的复本数量
e. 记录文件权限
- 元数据的大小是在150B左右
- NameNode将元数据维系在内存以及磁盘中
- 元数据维系在内存中的目的是为了快速查询
- 元数据维系在磁盘中的目的是为了崩溃恢复
- 元数据的存储位置是由hadoop.tmp.dir属性决定,如果不配置则默认使用/tmp
- 元数据在磁盘中是以edits文件和fsimage文件的形式存在
a. edits:记录写操作
b. fsimage:记录元数据。fsimage中的元数据和内存中的元数据并不是同步的
NameNode的运行流程
- 当NameNode接收到写请求之后,会先将该请求记录到edits_inprogess文件中,如果记录成功,则将该请求同步更新到内存中,修改内存中的元数据,内存修改完成之后会给客户端返回一个ack表示成功
- 在HDFS中,会给每一次的写操作分配一个编号 - 事务id - txid
- 当edits文件达到条件的时候会将操作更新到fsimage文件中,即修改fsimage文件中的元数据:
a. 空间维度:当edits_inprogress文件达到指定大小的时候就会触发更新,默认是64M,大小可以由fs.checkpoint.size(core-site.xml)来指定,默认单位是字节
b. 时间维度:当距离上一次更新达到指定间隔时候的时候就会触发更新,默认是1H,大小可以由fs.checkpoint.period来指定,默认单位是秒
c. 重启更新:NameNode重启之后,会自动的将edits_inprogress中的操作更新到fsimage中
d. 强制更新:hadoop dfsadmin -rollEdits
- 在更新的时候,会将edits_inprogress重命名为edits_XXXXXX-XXXXXX,同时产生一个新的edits_inprogress
- 在Hadoop中,如果存在SecondaryNameNode,则更新过程是发生在SecondaryNameNode
- 在HDFS中,最核心的节点是NameNode。但是在Hadoop1.0版本中只能有1个NameNode,在Hadoop2.0版本中,进行了改变,允许多设置一个NameNode,代价是丢掉SecondaryNameNode
- NameNode通过心跳机制来管理DataNode:DataNode每隔定长时间会给NameNode发送心跳信息
- 默认情况下,DataNode每隔3s给NameNode发送一条信息
- 如果NameNode长时间(默认是10min)没有收到某个DataNode的心跳信息,则认为这个DataNode已经lost(丢失),此时NameNode会将这个DataNode中的数据再次备份,保证复本数量
- 心跳信息包含:
a. 当前节点的状态
b. 当前节点中所存储的数据块信息 - NameNode重新启动的时候,将edits中的操作更新到fsimage中,将fsimage中的元数据加载到内存中,等待DataNode的心跳(如果DataNode没有心跳过来则要重新备份保证复本数量,校验数据总量),这个过程称之为是安全模式(safe mode)。如果所有的校验都成功,则HDFS会自动退出安全模式
- 因为安全模式的问题,所以在伪分布式下,复本数量必须为1 - 如果复本数量不为1,则重启NameNode的时候,会导致HDFS一直处于安全模式