Ozone作为又一个全新的存储系统，它在底层存储结构上和HDFS有着不小的区别，用户往Ozone内读写数据的方式也有所不同。不过为了兼容目前Hadoop FileSystem的读写，Ozone实现了一个叫做OzoneFileSystem的功能。通过使用OzoneFileSystem，用户能够使用往常Hadoop FileSystem的通用接口进行Ozone内对象数据的读写。不过OzoneFileSystem的做法只是在Ozone读写外层包装处理了下，核心本质还是在读写基于K-V存储的Ozone对象数据。在某些例如rename,list,delete等等这些操作上需要进行整个db的scan，效率显然不会太高。基于OzoneFileSystem实现的操作效率问题，Ozone社区设计提出了全新的按照文件原生结构的FileSystem namespace的metadata结构。它能有效的解决现有OzoneFileSystem实现上的不足之处。
OzoneFileSystem是社区为了兼容，实现了基于Ozone存储架构之上的Hadoop兼容性文件系统。用户在配置了OzoneFileSystem配置后，就可以在无须动用现有Hadoop FileSystem读写代码的情况下，完成Ozone数据的读写。
但正如上面前言所述，OzoneFileSystem只是做了Ozone读写的包装处理，来达到兼容的效果。其核心本质依然是在读写基于K-V存储的Ozone db keyTable表的结构。
这里我们来看看目前Ozone key table的存储结构(实际Ozone对象存储的一张表)：
KeyNameKeyInfo/vol1/buck1/a/b/c/d/file1…/vol1/buck1/a/b/c/d/e/file1…/vol1/buck1/a/b/c/d/e/…在OzoneFileSystem的语义实现中，目录和文件都是以Key的形式存在上面的key表内。因为上述单一的表结构没有存储所谓的父级目录关系结果，导致如list，rename，delete的操作需要通过全表扫描的方式去查找相关的children list文件。OzoneFileSystem这种处理方式显然不是最高效的。
因此社区提出了一种全新的FS namespace的metadata结构，彻底对Ozone Key的存储进行了改造。
在新的metadata结构下，上述OzoneKey对象的数据按照目录和文件的将会被分别存放到目录表和文件表内，并且采用了复用前缀的方式的来存储目录数据。
Dir Table:
KeyNameObjectId/512512/a10251025/b10261026/d1027File Table
KeyNameKeyInfo1026/fileA…1027/fileB…在上述metadata结构下，我们找寻/a/b/fileA的顺序将会变为如下：
1） 从目录表查找/，然后找到Id为512。2） 然后继而查找/a就是，512/a得到新的id，直到找到最后一个目录1025/b，id为1026。3） 然后用1026/fikeA到文件表里查最终的KeyInfo信息。在新metadata结构模式里，查找的过程的确看似复杂了一些，需要在2个表里做查找（这点后续还将讨论到），但是此方案能带来以下两项显著的收益：
更为高效的rename，delete操作，比如对于rename一个目录而言，我们只需要更新一项目录entry就足够了。更节省的内存空间使用，因为我们用数字id来代替目前的前缀，可以大大缩小metadata总的空间使用。不要小看这一点优化，在亿万规模量级的对象下，这能省上GB级别的空间使用。这方面的空间省下来的话，我们能够cache更多的dir file 表数据在内存中了。进而我们能大大提高目录文件的查找速度了。OK，除开上面提到的两点收益，此方案一个最令人亟待解决的问题就是它的key查找行为，社区在设计这块时，同样进行了额外的设计考虑。
针对上述的问题，Ozone社区提出了基于目录cache的高效查找。简单说来就是我们将上述的目录表内的entry数据load到内存中做cache，然后供外部使用。并且在key entry写更新的时候，同时进行memory和db表数据的更新。
过程图如下所示：
到时在OM中，我们会维护和Dir Table内部数据结构完全一致的cache entries：
通过找到最好一个目录的Id后，我们就可以在File Table里进行最后一次精准的查找。所以目录cache是Ozone FS namespace首先需要去考虑和实现的一个优化改动。
当然后续，还可以进行更多别的关系cache，比如
<Dir, Children list>关系，方便list file的操作。<File, KeyInfo>，文件信息的cache，有了这层cache，可以完全读底层db的操作。有了Ozone FS cache层的优化改动外加原生FS namespace的metadata结构的特点，相信这套新的Ozone FS能够达到一个比较高效的FileSystem操作行为。另外，笔者之前写过关于Ozone FS namespace的另外一篇文章，感兴趣的同学可点击阅读Ozone FS Namespace的设计构想。
[1].https://issues.apache.org/jira/browse/HDDS-2939 [2].https://issues.apache.org/jira/browse/HDDS-4222
