Hadoop7-HDFS的NameNode的元数据管理机制与Hadoop的高可用架构

在介绍HDFS的元数据管理之前，有必要先了解下HDFS的架构

1. HDFS架构简介

HDFS主要包含两个组件，NameNode与DataNode，其中NameNode主要用来管理元数据，DataNode用来存储数据，在分布式HDFS架构中，通常会有一台NameNode，一台SecondaryNameNode,多台DataNode。

 

2. 上传文件

使用HDFS上传文件通常包含以下几个步骤

1. 客户端向NN请求上传文件

2. NN接到请求后，首先网edits log文件中记录元数据操作日志

3. NN返回分配的block元信息给客户端

4. 客户端开始上传文件，上传完成后返回成功信息给NN

5. NN在内存中写入这次操作产生的元数据信息

6. 每当edits log写满后，要将这段时间的元数据信息刷到fsimage中

 

3. NN元数据的存储

一条元数据信息在150B以内，1G空间大概能存700w条左右的元数据。

这么多的元信息，客户端在查询的时候如何才能保证高效呢？首先要考虑元信息存储的位置，磁盘？内存？

磁盘肯定速度会很慢，因此需要将所有的元信息映射到内存中以便高效查找。

NN元数据通常分为两部分，一部分叫做edits log，位于磁盘中，用于记录最新的元数据信息，另外一份交fsimage，也位于磁盘中，当edits log写满时，需要将edits log的信息刷新到fsimage中，内存中有这两个文件的映像，因此，内存中包含了所有的元信息，当客户端文件上传成功时，NN才会在内存中写入这次操作产生的元信息。

3.1 NN的fsImage中存了些什么内容？

由于fsImage中存的内容是经过序列化的内容，不能直接看到里面的信息，因此需要通过hdfs oiv工具

 

hdfs oiv -i fsimage_xxxx -p Web
http://localhost:50070/webhdfs/v1/aa?op=GETFILESTATUS

jdk-8u60-linux-x64.tar.gz
{"FileStatus":{"accessTime":1496214541163,"blockSize":134217728,"childrenNum":0,"fileId":16392,"group":"supergroup","length":181238643,"modificationTime":1452395391526,"owner":"root","pathSuffix":"","permission":"644","replication":1,"storagePolicy":0,"type":"FILE"}}
aa
{"FileStatus":{"accessTime":0,"blockSize":0,"childrenNum":3,"fileId":16447,"group":"supergroup","length":0,"modificationTime":1503929690683,"owner":"sheldonwong","pathSuffix":"","permission":"755","replication":0,"storagePolicy":0,"type":"DIRECTORY"}}

hdfs oiv -i fsimage_xxxx -o ~/fsimage.xml -p XML
jdk-8u60-linux-x64.tar.gz
<inode>
    <id>16392</id>
    <type>FILE</type>
    <name>jdk-8u60-linux-x64.tar.gz</name>
    <replication>1</replication>
    <mtime>1452395391526</mtime>
    <atime>1496214541163</atime>
    <perferredBlockSize>134217728</perferredBlockSize>
    <permission>root:supergroup:rw-r--r--</permission>
    
    <blocks>
        <block>
            <id>1073741827</id>
            <genstamp>1003</genstamp>
            <numBytes>134217728</numBytes>
        </block>
        <block>
            <id>1073741828</id>
            <genstamp>1004</genstamp>
            <numBytes>47020915</numBytes>
        </block>
    </blocks>
</inode>

可以看到namenode维护了整个文件系统的目录树，同时存了文件与block的映射信息，以及一些文件元信息

1）由此可见，namenode维护的整个文件系统的目录树、文件/目录的元信息以及文件和数据块的映射信息（目录树，元信息，文件-block映射）

文件元信息：包括创建时间、修改时间、权限等。

文件-block映射：文件对应的block集合。

2）注意，与数据节点相关的信息并不保存在名字节点的本地文件系统中，而是系统启动时，名字节点动态重建这些信息。
 

 

4. checkpoint与SN（Secondary NameNode）

当edits log写满时，需要将edits log与fsimage合并，这个时间节点就叫做checkpoint，但是又不能在NN中进行合并，因为这样会降低NN的响应速度，所以就出现了SN，合并步骤具体如下

1）edits log写满，到达checkpoint

2）此时，SN向NN发出请求，要通过http下载edits log与fsimage，不能再向edits log中写数据了，但是NN还是要向外提供服务，因此就会新建一个edits log.new的文件，

3）SN从NN下载好edits log与fsimage后，就开始合并，并将合并后的文件命名为 fsimage.chkpoint,合并好后上传给NN

4）NN在接收到SN上传的fsimage.chkpoint后，就将原有的edits log文件删除，将fsimage.chkpoint重命名为fsimage，将edits log.new重命名为edits log，这样NN就又恢复了开始的状态

 

5. NameNode高可用的实现