大数据开发HDFSNamenode元数据管理

　　HDFS作为分布式文件系统的代表性产品，在大数据学习当中的重要性是不言而喻的，基于Hadoop基础架构，HDFS更是得到了广泛的认可，在大规模离线数据处理上，提供稳固的底层支持。今天的大数据开发技术分享，我们就主要来讲讲HDFSNamenode元数据管理。
　　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和内存元数据有很大的差距。因为元数据的改变频率是不固定的。
　　每隔一段时间，会由secondaryNamenode将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和secondaryNamenode的工作目录存储结构完全相同，所以，当Namenode故障退出需要重新恢复时，可以从secondaryNamenode的工作目录中将fsimage拷贝到Namenode的工作目录，以恢复Namenode的元数据。
　　关于checkpoint操作的配置：
　　dfs。Namenode。checkpoint。check。period60检查触发条件是否满足的频率，60秒
　　dfs。Namenode。checkpoint。dirfile：｛hadoop。tmp。dir｝dfsnamesecondary
　　以上两个参数做checkpoint操作时，secondaryNamenode的本地工作目录
　　dfs。Namenode。checkpoint。edits。dir｛dfs。Namenode。checkpoint。dir｝
　　dfs。Namenode。checkpoint。maxretries3最大重试次数
　　dfs。Namenode。checkpoint。period3600两次checkpoint之间的时间间隔3600秒
　　dfs。Namenode。checkpoint。txns1000000两次checkpoint之间最大的操作记录
　　editslog和fsimage文件存储在dfs。Namenode。name。dircurrent目录下，这个目录可以在hdfssite。xml中配置的。
　　关于大数据开发，HDFSNamenode元数据管理，以上就为大家做了简单的介绍了。HDFS当中的元数据管理，是分布式存储的重要保障，对于数据存储安全性和可靠性都有显著的贡献。