Ozone Datanode的分布式元数据管理

前言

---

众所周知，当元数据空间达到一个比较庞大的规模量级的时候，HDFS会遇到一定的扩展性问题。首先HDFS将这些元数据INode信息都load在内存中进行管理，而且还有附属相关的mapping信息，这些庞大的信息被HDFS的NameNode所管理。相应地，NameNode也将会面临更大规模量级的请求处理。从更本质的层面上来说，这是集中中心管理式服务会遇到的一个问题。不同于HDFS的集中纯内存元数据管理方式，本文将介绍另外一种扩展性更强的Ozone分布式元数据管理方式。

Ozone的分布式元数据

---

首先，这里有个概念，何为分布式元数据？简单地来说，就是系统的元数据分散地存储于各个节点上。那么有人肯定会有疑问了，那我们如何做具体元数据的位置查询呢？难道不是应该有个更加集中式的管理服务来查询这些元数据的关系吗？

这里其实有个问题，如果我们还需要有个集中式的管理服务来管理这些分布式元数据，那这样的设计模式又退化到和集中式管理服务一样的模式了。

在Ozone的每个Datanode中，存储有上面所有block对chunk文件的信息。而另外一半的block在什么节点上这样的信息，是由另外的服务来告诉client的。也就是说，client只要知道它所请求的文件block信息在这个节点就可以了，后面这个block具体对应的chunk物理文件在什么位置，查询Datanode的本地db文件即可。在HDFS中，像这种大量的具体block对文件的映射信息都是集中被NameNode所管理，在Ozone中，这样的集中元数据变成了分布式元数据的模式了。

Ozone Datanode数据的layout

---

既然Ozone的元数据是分布式地存储于各个Datanode节点之上的，下面我们来具体看看Datanode实际的数据layout，包括用户数据以及元数据，比HDFS Datanode多了元数据目录。

笔者在测试Ozone集群内，创建了一个测试volume，buckt，然后put了一个测试文件。通过查询文件所属的Container的实际位置，就能找到它所在的实际节点位置了。

Datanode的Container目录格式如下所示：

<<dfs.datanode.dir>>/hdds/<>/current/

笔者测试集群的一个实际目录如下：

[hdfs@lyq ~]$ ls -l /tmp/hadoop-hdfs/dfs/data/hdds/762187f8-3d8d-4c2c-8659-9ca66987c829/current/
total 4
drwxr-xr-x 3 hdfs hdfs 4096 Dec 24 07:56 containerDir0

这里的containerDir0是Container按照Container Id做partition的，分partition目录是为了防止一个目录下游过多的文件。然后紧接着partition目录的是Container Id目录。

[hdfs@lyq ~]$ ls -l /tmp/hadoop-hdfs/dfs/data/hdds/762187f8-3d8d-4c2c-8659-9ca66987c829/current/containerDir0/4/
total 8
drwxr-xr-x 2 hdfs hdfs 4096 Dec 24 07:56 chunks
drwxr-xr-x 3 hdfs hdfs 4096 Dec 24 07:56 metadata

以上2个目录中，chunks代表的即Co