HDFS元数据

2.1 概述

从形式上讲，元数据可分为内存元数据和元数据文件两种。其中NameNode在内存中维护整个文件系统的元数据镜像，用于HDFS的管理；元数据文件则用于持久化存储。

从类型上讲，元数据有三类重要信息：

第一类是文件和目录自身的属性信息，例如文件名、目录名、父目录信息、文件大小、创建时间、修改时间等。

第二类记录文件内容存储相关信息，例如文件块情况、副本个数、每个副本所在的Data Node 信息等。

第三类用来记录HDFS中所有Data Node信息，用于Data Node管理。

2.2 内存元数据结构

2.2.1 INode

文件和目录是文件系统的基本元素，HDFS将这些元素抽象成INode，每一个文件或目录都对应一个唯一的INode。它由FSNamesystem的成员变量dir实现对整个HDFS中INode的组织和操作，它是一个FSDirectory类。

INode信息完全位于内存，因此有效的提高元数据的服务性能，然而一旦掉电将不再存在，故需要将INode信息保存到磁盘，这个功能是由FSImage完成的，它是架构在内存元数据与磁盘元数据文件之间的桥梁。

由于所有的元数据位于内存，其大小随文件系统的规模增大而增大，如果每次都将整个内存元数据导出磁盘，将会带来很大的系统开销，所以HDFS在实现时，没有采用定期导出元数据的方法，而是采用元数据镜像文件（FSImage）+日志文件（edits）的备份机制，其中镜像文件是某一时刻内存元数据的真实组织情况，而日志文件则记录了该时刻以后所有的元数据操作 。

2.2.2 Block

Block是对于文件内容组织而言的，按照固定大小，顺序对文件进行划分并编号，划分好的每一个块就称之为一个Block，HDFS默认的Block大小为64MB。

当一个客户端访问某一个文件特定偏移量的内容时，HDFS首先根据路径信息找到该文件对应的INode ，根据偏移计算出Block位置，然后找出相应的BlockInfo，再找到副本所在Data Node 的信息，选择其中一个Data Node进行连接，获取相应的内容。

2.3 磁盘元数据文件

磁盘元数据文件包括以下四个：

fsimage：元数据镜像文件。

edits：日志文件。

fstime：保存最近一次Checkpoint的时间。

VERSION：标志性文件，最后被创建，它的存在表明前三个元数据文件的创建成功。

2.4 Format 情景分析

format 主要分为以下几个步骤：

确定能否格式化；

创建元数据文件在内存中的镜像；

对内存镜像中的数据结构进行初始化；

将内存镜像写入元数据备份目录。

2.5 元数据应用场景分析

下面我们按照元数据的生命周期顺序，列举元数据所出现的各个应用场景。

场景1

HDFS在第一次使用前，需要进行格式化，格式化的结果是：在元数据镜像文件备份路径的current目录下，产生元数据文件：fsimage、fstime、VERSION等；在日志文件备份路径的current目录下，产生日志文件：edits、fstime、VERSION等。

场景2

启动HDFS，HDFS将fsimage和edits文件内容读入内存，进行合并，填充与INode相关的元数据结构，并将新的元数据内存镜像导出，在磁盘上形成新的fsimage和edits文件。HDFS同时还接收Data Node的心跳信息，填充与Block和Data Node相关的元数据结构。

场景3

HDFS正常运行，此时如果有元数据更新操作，HDFS会更新对应的内存元数据结构，并将该元数据操作日志记录写入磁盘的日志文件edits。

场景4

如果NameNode与Secondary NameNode、 Backup Node或Checkpoint Node配合使用，那么，一定间隔后会进行Checkpoint操作，Checkpoint操作会形成当前某一时刻的元数据镜像文件fsimage，以该文件替换NameNode上原有的fsimage，并以最新fsimage对应时刻之后的日志记录文件edits替换NameNode上原有的edits。该机制可以有效限制日志文件的大小，防止其无限制增长，同时也降低了HDFS启动时的合并时间。