碧茂科技 | Hadoop 对象存储 Ozone

Hadoop 对象存储 Ozone
+ 查看更多

发布日期：2020-04-09 11:22

0、Hadoop HDFS的现状

Apache Hadoop 项目至今已经有十多年的历史了，作为大数据的基石，自从投放之社区之后就引来了不少的眼球，进而也孕育出了众多的Apache项目，例如HBase，Hive , Spark 等等这些优秀的数据存储和处理等项目，从而构造成了一个庞大的生态圈。参考了世界级标准的，也就是 Hadoop的HDFS，一直在跟IEEE的POSIX文件系统API标准靠拢，因此我觉得，HDFS是长久的，因为它的API足够的标准化。API足够的标准化也就意味着照着实现的东西考虑的是很全面的。但是这并不代表HDFS本身的设计不存在问题或缺陷。

Current HDFS High Level Design

通常我们见到的一个HDFS集群，普通用户的上限是2亿个Block，有些能力特别强的用户群体，能做到4亿到6亿个Block。如果按照这个理想状态每个Block的元数据占位都对应有128MB的数据块，那么理论情况下的存储上限是75 PB。这个存储上限其实已经非常高了，对比今日甚至未来几年的需求，除了云服务提供商，几乎不会有其它的企业想去存储75PB的可用数据。

虽然这个上限非常的高，但并不代表它的设计架构就可以一直这样保持下去，作为一个理想的文件系统，不应该对上层的应用有挑剔。可是至今为止，我们见到HDFS对上层的应用挑剔性还是比较大的。例如微服务的应用，目前就没办法运行在HDFS之上。同时，实时类的应用，例如Apache Kafka ，也没有办法运行在HDFS之上。究其原因，还是数据的写入速度不够快，同时存在唯一的目录元数据，文件越多越可能导致RPC过高等等问题。

1、社区的一些改进

大体上讲，HDFS目前的问题有以下几个方面：

超大规模的扩展能力问题；

运维的复杂性问题；

应对云和实时的问题；

小文件问题。

举个例子，即便是大型互联网公司，比如eBay, 也有每两周一次的HDFS健康检查日，如此可见HDFS的运维是需要不断的Review和修复的。不过，为了解决这些问题，社区是有一些方案的，例如，NameNode Federation和Route Based Federation等。但是这些方案都没有办法很好的解决HDFS目前面临的所有问题。

HDFS NameNode Federation High Level Design

HDFS Route Based Federation High Level Design

正如上面的图里所显示的，NNF是将Namespace做了拆分，DataNode不需要拆分，而RBF是将数个HDFS集群通过Router抽象合并。这两个实现方案都有各自的优点和缺点，但是都不能完整的解决HDFS目前的各种痛点。

2、由 HDFS 转变为 HDDS

为了把HDFS做的更加的通用和标准化，Hadoop社区由Anu Engineer带队，着手设计Apache Hadoop的对象存储方案，也就是今天人们熟知的Hadoop Ozone。为了实现Ozone，还需要实现一个自通信数据一致性方案，于是这个大团队又着手研发了Apache Ratis。关于Apache Ratis是什么以及什么原理，我们可以后续讨论（主要是PAXOS理论实在太晦涩了，即便是简版的RAFT理论也很难讲出来），当前这篇文章还是主要以Ozone为主。

HDDS High Level Design

Ozone Manager：用来负责管理和分配文件名；

Storage Container Manager：用来分配Block的位置和物理服务器；

Container: 这个是我曾经和研发Team吐槽过的一个点，大部分用户看到Container都会联想到K8S的应用容器。而这个Container，如果用JAVA的名词概念来解释的话，实际上就是把一堆Bean(极小的Block)放到Jar（Container）里，然后再放一个RocksDB来告诉打开罐子的人，这个罐子里每一个Bean的具体位置。另外,特别小的文件（<1MB）甚至直接可以放在RocksDB里。

这样的设计吸收了HDFS本身的优秀的一面，同时也解决了HDFS面临的诸多问题：