Hadoop Namenode 数据

简单来讲，NameNode就是HDFS的大脑，任何客户端或者DataNode的数据迁移、目录操作都是由NameNode来完成的。

     再了解了NameNode会干什么事情之后，最好深入的办法就是来看NameNode有哪些重要的数据结构，每个数据结构都干什么事情。

 

     我们提到NameNode主要是维护文件在哪里这个映射关系。故而主要包含的内容是：

     1、fileName和目录block的关系。

     2、block到mist(机器列表)的关系。

     fileName到block的关系是fsimage（类似镜像文件）写入到本地，每次启动的时候进行加载。block到mlist的的关系则是通过HDFS启动后，DataNode向NameNode报告心跳实现。为什么这样设计的原因：

     1、文件和目录block的关系存在的时候不会发生变化。

     2、block和mlist的关系会因为均衡数据迁移，机器故障数据迁移发生变化。

     3、架构考虑点。

    NameNode只有三种交互。

     1、client访问NameNode获取相关DataNode信息。

     2、DataNode心跳汇报当前block情况。

     3、SecondaryNameNode做checkpoint交互。

先来看类图：

 

FSNameSystem

    在NameNode中，基本上重要的创建，维护，同步，更新都操作都是通过FSNameSystem来完成的。各种关键的数据结构也是在FSNameSystem中维护的。可以这样说基本上做的所有操作都是通过和FSNameSystem打交道来完成的。

FSDirectory

    顾名思义，该类是用来维护所有以文件路径的。这个类维护着 HDFS中所有的目录信息，并且会被持久化到NameNode本地作为FSImage（非常紧凑的二进制文件）存储起来。FSImage的相关操作也是通过FSDirectory完成的，HDFS的各种操作，会记录到EditLog中(EditLog也是通过FSDriectory维护)，周期性的把FSImage和EditLog合并起来就是当前所有的目录信息。

HDFS所有的目录信息是通过树的方式来维护的。（想象一下普通的电脑上的文件不都是以树的方式维护的吗），在HDFS中所有文件的抽象是INode，目录则是INodeDirectory，文件则是INodeFile。

FSImage

    从上一部分我们已经了解到了，FSImage就是文件目录元数据的某个时间段的镜像文件。每次启动后所有文件目录操作都会通过FSDriectory记录到EditLog，这带来一个问题，启动的时间越长EditLog中的内容会更多，下次再做合并的时候（这个合并我们称为checkpoint），会随着EidtLog文件的大小增加合并的时间，HDFS针对这个问题设置了两种机制进行条件合并，例如配置EditLog达到多大做一次合并，或者离上次合并过了多久做一次合并。 但是如果NameNode合并文件占用过多的资源，可能会引发其他的问题。那么如何来避免这样一个问题呢？后续我们会介绍，如何用

SecondaryNameNode来避免这个问题。

FSImage文件格式如下：

   

当namenode重启加载fsimage时，就是按照如下格式协议从文件流中加载元数据信息。从fsimag的存储格式可以看出，fsimage保存有如下信息：

一、加载Img头信息，如下：

          1、 imgVersion(int)：当前image的版本信息

          2、namespaceID(int)：用来确保别的HDFS instance中的datanode不会误连上当前NN。

          3、numFiles(long)：整个文件系统中包含有多少文件和目录

          4、genStamp(long)：生成该image时的时间戳信息。

二 、如果加载目录，包含以下信息：

          1、path(String)：该目录的路径，如”/user/build/build-index”

          2、replications(short)：副本数（目录虽然没有副本，但这里记录的目录副本数也为3）

          3、mtime(long)：该目录的修改时间的时间戳信息

          4、atime(long)：该目录的访问时间的时间戳信息

          5、blocksize(long)：目录的blocksize都为0

          6、numBlocks(int)：实际有多少个文件块，目录的该值都为-1，表示该item为目录

          7、nsQuota(long)：namespace Quota值，若没加Quota限制则为-1

          8、dsQuota(long)：disk Quota值，若没加限制则也为-1

          9、username(String)：该目录的所属用户名

          10、group(String)：该目录的所属组

          11、permission(short)：该目录的permission信息，如644等，有一个short来记录。

三、如果加载文件，则还会额外包含如下信息：

          1、blockid(long)：属于该文件的block的blockid，

          2、numBytes(long)：该block的大小

          3、genStamp(long)：该block的时间戳

    当该文件对应的numBlocks数不为1，而是大于1时，表示该文件对应有多个block信息，此时紧接在该fsimage之后的就会有多个blockid，numBytes和genStamp信息。

    因此，在namenode启动时，就需要对fsimage按照如下格式进行顺序的加载，以将fsimage中记录的HDFS元数据信息加载到内存中。

BlocksMap

    最初我们提到过FSImage中没有block到机器列表的映射关系的原因。每一个DataNode启动的时候会通过BlockReport将当前机器所有block信息汇报给NameNode。汇报的相关信息就是维护在BlockMaps中的，

    BlocksMap结构如下：

 

 

    我们前面提到，FSImage中维护的是文件和block的关系，那么block和机器的关系便是从BlocksMap中获取的。

    BlocksMap维护了三种关系：

          １、file-blcoks

           2、block-datanodelist

           3、datanode-blocks

从上图中我们也可以看到，BlocksMap中的BlockInfo中维护了包括：

          1、blockid，块ID。

          2、块大小。

          3、块的修改时间戳。

          4、块对应的文件。

          5、块对应的机器列表信息。 

DataNode列表

    在上图中已经看到，每一个BlockInfo上都有一个DN1，DN2，DN3其实就是一个block在三台机器上的备份。每一个DataNode对应的是一个Object[]的三元数组，prev表示当前block在该机器上的上一个block，next表示当前block在该机器上的下一个数组。目的很简单，查询一个DataNode上的所有BlockList需求非常少。这样做一来可以节省大量的内存（我们说过，内存会成为NameNode的瓶颈哦），二来直接根据next的指向就可以获取一个DN上的所有blocklist数据。

CorruptReplicationMap 

    简单来理解，在DN上有问题的block（磁盘坏，校验不对）都会在这里，下一次DN做心跳的时候有问题的block会返回给DN并删除。

UnderReplicationMap

    默认的block副本数目是3，没有达到这个数目(磁盘坏了，DN挂了)的都会在这里，并且离的越远，数据迁移优先级会越高。

PeddingReplicationMap

    block坏了，咱要做数据拷贝吧，在迁移中的5分钟没有成功的就认为失败，则添加到neededReplicationBlocks中，以便下次再做数据拷贝。

    本篇文章，我们简单的介绍了NameNode的基本数据结构，但是对于NameNode的单点问题，checkpoint的问题，包括文中提到的SecondaryNameNode等并没有做详细的介绍。

下一篇：

HDFS读书笔记-如何让NameNode高可用（三）