前面提到Ozone的原创团队对大规模Hadoop集群运维和优化有着丰富的经验，所以Ozone的设计中也体现了很多HDFS的优点，并屏蔽了一些HDFS的性能瓶颈。

HDFS目前的瓶颈主要在NN上，NN内存中维护着两个大对象，一个是NameSpace，另一个是BlocksMap，这两个是常驻内存而且随着集群存储的文件数和规模成线性增长，这就造成NN的内存占比越来越大，成为HDFS扩展的瓶颈。

那么Ozone是如何解决这些瓶颈呢？

NameSpace扩展性

Ozone使用Ozone Manager的服务来管理namespace，其并不会把整个namespace存储在一个节点的内存中，而是只将一些正在使用的集合存储在内存中。(因为namespace具有本地引用性，所以可以这么搞)

Block Map扩展性

这部分解决起来比较难，因为其不像namespace一样具有本地引用性，因为block map是dn周期性的把每个块的信息汇报给nn而来的。Ozone将此问题委托给名为Hadoop Distributed DataStore(HDDS)的共享通用存储层来解决

接下来主要谈下Ozone中的container，全称为Storage Container。Container类似于HDFS中block的概念，都是最小的容错单元，但Container并不是最小的写入单元，Container中包含若干个block，block为最小的写入单元。
有点像在block上又加了一层索引，由原来的file->blocks变为file->containers->blocks，这样blocks map就会少了一个量级，更方便维护，而且Ozone还为Container提供了一个专门的服务用与管理，这个服务是Storage Container Manager(SCM)。(SCM与Container两者的关系是Container对外提供块服务，SCM由底层存储向外提供服务，可以支持不同的上层系统。)

上面提到Container是最小的容错单元，是因为Ozone是把Container利用Raft进行3副本达到容错的效果，这样的话HDFS原先block副本的代码可以复用，基于pipeline方式进行写入。

个人感觉如果HDFS Federation是HDFS的2.0时代的话，我感觉Ozone就是HDFS的3.0时代，是对HDFS的又一次扩展。