一、什么是元数据
在HDFS中，元数据主要指的是文件相关的元数据，由NameNode管理维护。从广义的角度来说，因为NameNode还需要管理众多DataNode节点，因此DataNode的位置和健康状态信息也属于元数据。
二、元数据管理概述
1.文件相关元数据类型
在HDFS中，文件相关元数据具有两种类型：
文件自身属性信息：文件名称、权限，修改时间，文件大小，复制因子，数据块大小。
文件块位置映射信息：记录文件块和DataNode之间的映射信息，即哪个块位于哪个节点上。
2.存储相关元数据类型
按存储形式分为内存元数据和元数据文件两种，分别存在内存和磁盘上。
内存元数据
为了保证用户操作元数据交互高效，延迟低，NameNode把所有的元数据都存储在内存中，我们叫做内存元数据。内存中的元数据是最完整的，包括文件自身属性信息、文件块位置映射信息。
但是内存的致命问题是，断点数据丢失，数据不会持久化。因此NameNode又辅佐了元数据文件来保证元数据的安全完整。
元数据文件有两种：fsimage内存镜像文件、Edits log编辑日志
fsimage 内存镜像文件
是内存元数据的一个持久化的检查点。但是fsimage中仅包含Hadoop文件系统中文件自身属性相关的元数据信息，但不包含文件块位置的信息。文件块位置信息只存储在内存中，是由datanode启动加入集群的时候，向namenode进行数据块的汇报得到的，并且后续间断指定时间进行数据块报告。
持久化的动作是数据从内存到磁盘的IO过程。会对namenode正常服务造成一定的影响，不能频繁的进行持久化。
Edits log编辑日志
为了避免两次持久化之间数据丢失的问题，又设计了Edits log编辑日志文件。文件中记录的是HDFS所有更改操作（文件创建，删除或修改）的日志，文件系统客户端执行的更改操作首先会被记录到edits文件中。
3.NameNode加载元数据文件顺序
1.fsimage和edits文件都是经过序列化的，在NameNode启动的时候，它会先将fsimage文件中的内容加载到内存中，之后再执行edits文件中的各项操作，使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作，也是最完整的元数据。
2.当客户端对HDFS中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功后，相应的元数据会更新到内存元数据中。因为fsimage文件一般都很大（GB级别的很常见），如果所有的更新操作都往fsimage文件中添加，这样会导致系统运行的十分缓慢。
3.HDFS这种设计实现着手于：一是内存中数据更新、查询快，极大缩短了操作响应时间；二是内存中元数据丢失风险颇高（断电等），因此辅佐元数据镜像文件（fsimage）+编辑日志文件（edits）的备份机制进行确保元数据的安全。
4.NameNode维护整个文件系统元数据。因此，元数据的准确管理，影响着HDFS提供文件存储服务的能力。
三、元数据管理相关目录文件
1.元数据本地存储目录
namenode元数据存储目录由参数：dfs.namenode.name.dir指定；
格式化完成之后，将会在$dfs.namenode.name.dir/current目录下创建如下的文件：
dfs.namenode.name.dir是在hdfs-site.xml文件中配置的，默认值如下：
2.元数据相关文件--VERSION
namespaceID/clusterID/blockpoolID
这些都是HDFS集群的唯一标识符。标识符被用来防止DataNodes意外注册到另一个集群中的namenode上。这些标识在联邦（federation）部署中特别重要。联邦模式下，会有多个NameNode独立工作。每个的NameNode提供唯一的命名空间（namespaceID），并管理一组唯一的文件块池（blockpoolID）。clusterID将整个集群结合在一起作为单个逻辑单元，在集群中的所有节点上都是一样的。
storageType
说明这个文件存储的是什么进程的数据结构信息。如果是DataNode节点，storageType=DATA_NODE。
cTime
NameNode存储系统创建时间，首次格式化文件系统这个属性是0，当文件系统升级之后，该值会更新到升级之后的时间戳；
layoutVersion
HDFS元数据格式的版本。HDFS升级时会进行更新。
3.元数据相关文件--seen_txid
包含上一次checkpoint时的最后一个事务ID，这不是NameNode接受的最后一个事务ID。
seen_txid内容不会在每个事务性操作上都更新，只会在checkpoint时更新。
NameNode启动时会检查seen_txid文件，以验证它至少可以加载该数目的事务。如果无法验证加载事务，NameNode将中止启动。
4.元数据相关文件--fsimage
元数据镜像文件。每个fsimage文件还有一个对应的.md5文件，其中包含MD5校验和，HDFS使用该文件来防止磁盘损坏文件异常。
fsimage数据查看
fsimage文件是Hadoop文件系统元数据的一个永久性的检查点，包含Hadoop文件系统中的所有目录和文件idnode的序列化信息；对于文件来说，包含的信息有修改时间、访问时间、块大小和组成一个文件块信息等；而对于目录来说，包含的信息主要有修改时间、访问控制权限等信息。
oiv是offline image viewer的缩写，可将hdfs fsimage文件的内容转储为人类可读的格式。
常用命令：hdfs oiv -i fsimage_0000000000000000050 -p XML -o fsimage.xml
5.元数据相关文件--edits log
已完成且不可修改的编辑日志。这些文件中的每个文件都包含文件名定义的范围内的所有编辑日志事务。在HA高可用性部署中，主备namenode之间可以通过edits log进行数据同步。
edits log文件内容查看
edits log文件存放的是Hadoop文件系统的所有更新操作记录日志。
文件系统客户端执行的所有写操作首先会被记录到edits文件中。
oev是offline edits viewer（离线edits查看器）的缩写，该工具不需要hadoop集群处于运行状态。
命令：hdfs oev -i edits_0000000000000000011-0000000000000000025 -o edits.xml
在输出文件中，每个RECORD记录了一次操作,示例如下：
四、SecondaryNameNode
背景
当HDFS集群运行一段事件后，就会出现下面一些问题：
1.edits logs因操作记录多会变的很大，
2.fsimage因间隔时间长将会变得很旧；
3.namenode重启会花费很长时间，因为有很多改动要从edits log合并到fsimage文件上；
4.如果频繁进行fsimage持久化，又会影响NN正常服务，毕竟IO操作是一种内存到磁盘的耗精力操作.
1.SNN职责概述
因此为了克服上述问题，需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件，这样也会减小在NameNode上的压力。
SecondaryNameNode就是来帮助解决上述问题的，它的职责是合并NameNode的edit logs到fsimage文件中。
因此常把secondarynamenode称之为主角色的辅助角色，辅助NameNode做一些事。
2.SNN Checkpoint--概述
Checkpoint核心是把fsimage与edits log合并以生成新的fsimage的过程。
结果：fsimage版本不断更新不会太旧、edits log文件不会太大。
3.SNN Checkpoint--流程
1、当触发checkpoint操作条件时，SNN发送请求给NN滚动edits log。然后NN会生成一个新的编辑日志文件：edits new，便于记录后续操作记录。
2、SNN会将旧的edits log文件和上次fsimage复制到自己本地（使用HTTP GET方式）。
3、SNN首先将fsimage载入到内存，然后一条一条地执行edits文件中的操作，使得内存中的fsimage不断更新，这个过程就是edits和fsimage文件合并。合并结束，SNN将内存中的数据dump生成一个新的fsimage文件。
4、SNN将新生成的Fsimage new文件复制到NN节点。至此刚好是一个轮回，等待下一次checkpoint触发SecondaryNameNode进行工作，一直这样循环操作。
4.SNN Checkpoint--触发机制
# core-site.xml
dfs.namenode.checkpoint.period=3600 //两次连续的checkpoint之间的时间间隔。默认1小时
dfs.namenode.checkpoint.txns=1000000 //最大没有执行checkpoint事务的数量，满足将强制执行紧急checkpoint，即使尚未达到检查点周期。默认100万事务数量。
五、NameNode元数据恢复
1.NameNode存储多目录
namenode元数据存储目录由参数：dfs.namenode.name.dir指定。
dfs.namenode.name.dir属性可以配置多个目录，各个目录存储的文件结构和内容都完全一样，相当于备份，这样做的好处是当其中一个目录损坏了，也不会影响到hadoop的元数据，特别是当其中一个目录是NFS（网络文件系统Network File System，NFS）之上，即使你这台机器损坏了，元数据也得到保存。
2.从SecondaryNameNode恢复
SecondaryNameNode在checkpoint的时候会将fsimage和edits log下载到自己的本机上本地存储目录下。并且在checkpoint之后也不会进行删除。
如果NameNode中的fsimage真的出问题了，还是可以用SecondaryNamenode中的fsimage替换一下NameNode上的fsimage，虽然已经不是最新的fsimage，但是我们可以将损失减小到最少！
