Ozone感悟

前面提到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的又一次扩展。

您的肯定,是我装逼的最大的动力!