在介绍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高可用的实现