大数据开发：HDFS Namenode元数据管理

HDFS作为分布式文件系统的代表性产品，在大数据学习当中的重要性是不言而喻的，基于Hadoop基础架构，HDFS更是得到了广泛的认可，在大规模离线数据处理上，提供稳固的底层支持。今天的大数据开发分享，我们就主要来讲讲HDFS Namenode元数据管理。

Namenode元数据管理

首先明确Namenode的职责：响应客户端请求、管理元数据。

Namenode对元数据有三种存储方式：

内存元数据(NameSystem)

磁盘元数据镜像文件

数据操作日志文件（可通过日志运算出元数据）

注意：HDFS不适合存储小文件的原因，每个文件都会产生元信息，当小文件多了之后元信息也就多了，对Namenode会造成压力。

对三种存储机制的进一步解释

内存元数据就是当前Namenode正在使用的元数据，是存储在内存中的。

磁盘元数据镜像文件是内存元数据的镜像，保存在Namenode工作目录中，它是一个准元数据，作用是在Namenode宕机时能够快速较准确的恢复元数据，称为fsimage。

数据操作日志文件是用来记录元数据操作的，在每次改动元数据时都会追加日志记录，如果有完整的日志就可以还原完整的元数据。主要作用是用来完善fsimage，减少fsimage和内存元数据的差距，称为editslog。

Checkpoint机制分析

因为Namenode本身的任务就非常重要，为了不再给Namenode压力，日志合并到fsimage就引入了另一个角色secondaryNamenode。secondaryNamenode负责定期把editslog合并到fsimage，“定期”是Namenode向secondaryNamenode发送RPC请求的，是按时间或者日志记录条数为“间隔”的，这样即不会浪费合并操作又不会造成fsimage和内存元数据有很大的差距。因为元数据的改变频率是不固定的。

每隔一段时间，会由secondary Namenode将Namenode上积累的所有edits和一个最新的fsimage下载到本地，并加载到内存进行merge（这个过程称为checkpoint）。

1）Namenode向secondaryNamenode发送RPC请求，请求合并editslog到fsimage。

2）secondaryNamenode收到请求后从Namenode上读取（通过http服务）editslog（多个，滚动日志文件）和fsimage文件。

3）secondaryNamenode会根据拿到的editslog合并到fsimage。形成最新的fsimage文件。（中间有很多步骤，把文件加载到内存，还原成元数据结构，合并，再生成文件，新生成的文件名为fsimage.checkpoint）。

4）secondaryNamenode通过http服务把fsimage.checkpoint文件上传到Namenode，并且通过RPC调用把文件改名为fsimage。

Namenode和secondary Namenode的工作目录存储结构完全相同，所以，当Namenode故障退出需要重新恢复时，可以从secondary Namenode的工作目录中将fsimage拷贝到Namenode的工作目录，以恢复Namenode的元数据。

关于checkpoint操作的配置：

dfs.Namenode.checkpoint.check.period=60#检查触发条件是否满足的频率，60秒

dfs.Namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary

#以上两个参数做checkpoint操作时，secondary Namenode的本地工作目录

dfs.Namenode.checkpoint.edits.dir=${dfs.Namenode.checkpoint.dir}

dfs.Namenode.checkpoint.max-retries=3#最大重试次数

dfs.Namenode.checkpoint.period=3600#两次checkpoint之间的时间间隔3600秒

dfs.Namenode.checkpoint.txns=1000000#两次checkpoint之间最大的操作记录

editslog和fsimage文件存储在$dfs.Namenode.name.dir/current目录下，这个目录可以在hdfs-site.xml中配置的。

关于大数据开发，HDFS Namenode元数据管理，以上就为大家做了简单的介绍了。HDFS当中的元数据管理，是分布式存储的重要保障，对于数据存储安全性和可靠性都有显著的贡献。