Hadoop元数据

HDFS的元数据包含三部分：

1. 抽象目录树
2. 数据和块映射关系
3. 数据块的存储节点

元数据有两个存储位置：

• 内存：1、2、3
  3在集群启动时，Datanode 通过心跳机制向Namenode发送。
• 磁盘：1、2
  集群启动时需要将磁盘中的元数据加载到内存中，所以磁盘中的元数据不适宜过多。

元数据的存储格式：data/hadoopdata/目录下有三个文件夹

• data
  数据的真实存储目录，即datanode存储数据的存储目录
• name：元数据存储目录
  namenode存储元数据的存储目录
  该目录下的文件分为4类

edits_0000000000000000001-0000000000000000002 
edits_0000000000000000003-0000000000000000004  
...
edits_0000000000000000547-0000000000000000548  
edits_0000000000000000549-0000000000000000550  

edits_inprogress_000000000000000551

fsimage_0000000000000000000
fsimage_0000000000000000000.md5
seen_txid
VERSION

name中的元数据包含三部分：
（1） 历史日志文件：编辑完成的日志文件。
即：edits_开始偏移量-结束偏移量。例如：edits_0000000000000000001-0000000000000000002。
日志文件：记录客户端对元数据操作的日志 只记录操作。 比如：某一个用户对某一个目录执行某一种操作

（2）正在编辑的日志文件
即edits_inprogress_000000000000000551

（3）镜像文件：真实的元数据信息经过序列化后的文件
序列化：为了减少存储的容量。集群启动时，会加载该文件，加载时会进行反序列化。
fsimage_0000000000000000000 镜像文件序列化之后的文件
fsimage_0000000000000000000.md5 镜像文件序列化后的加密文件

（4）seen_txid：记录合并点，即下一次需要合并的日志文件的起始偏移量。
需要用日志（edits）文件更新镜像（fsimage）文件，seen_txid记录了上一次合并的位置。
上一次合并的日志文件为

edits_0000000000000000001-0000000000000000002 
...
edits_0000000000000000549-0000000000000000550  

现在需要合并的日志文件为：
edits_inprogress_000000000000000551

1 刚刚将hdfs初始化（hdfs namenode -format）时，只有文件：

fsimage_0000000000000000000 
fsimage_0000000000000000000.md5 
seen_txid

cat seen_txid中是0。
2 hdfs第一次启动（start-dfs.sh）后

edits_inprogress_000000000000000551
fsimage_0000000000000000000 
fsimage_0000000000000000000.md5 
seen_txid

真实硬盘上存储的完整元数据：fsimage+正在编辑的日志文件
内存中的元数据是完整的吗？
无论什么时候，内存中保存的元数据永远是最新最完整的元数据。
内存中元数据由硬盘中的fsimage和正在编辑的日志文件合并而来，该工作由SecondaryNamenode完成。
Secondarynamenode的具体合并过程：
Secondarynamenode定期从namenode获取元数据，当准备获取元数据时，通知namenode暂停写入edits文件。Secondary获取到元数据后，将edits文件和fsimage文件在本机合并，创建出一个新的fsimage文件，然后将fsimage文件发回namenode，覆盖掉原来的fsimage文件，并删除原来的edits文件，将edits.new重命名为edits。上述操作避免了Namenode中edits日志的无限增长，从而加速了NameNode的启动过程。

• nm-local-dir
  hdfs的本地缓存