Hadoop 对象存储 Ozone

Posted 2021-04-13 大头数据

审阅：Xiaoyu Yao

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目前的问题有以下几个方面：

1

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

2

 运维的复杂性问题；

3

 应对云和实时的问题；

4

 小文件问题。

    举个例子，即便是大型互联网公司，比如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面临的诸多问题：

1

 多层目录结构的设计方案使得Ozone可以提升到百亿级别的文件Key；

2

 OM和SCM是可以横向扩展的，并不会出现RPC集中在单点的问题；

3

 使用Offheap来减少GC，通过FSCK服务来自动化的维护集群；

4

 通过Apache Ratis来保障数据的强一致性等等。

    同时，这样的设计还更好的支持了K8S应用的部署，通过Quadra服务还可以创建和Mount与K8S应用对应的Storage Volume。关于K8S支持的技术细节，在Ozone系列的下一篇文章中会讲到。

3

结束语

大头作为一个社区粉丝，还是要敬仰并感谢这些社区贡献人员不断的为Hadoop注入新鲜的活力，以下是Ozone项目的不完全社区主要贡献人员列表。

Anu Engineer (Ozone Project Lead)

   Cloudera Principal Software Engineer

   Apache Hadoop Committer/PMC Member

   Apache Ratis Committer/PMC Member

Xiaoyu Yao

  Cloudera Principal Software Engineer

  Apache Hadoop Committer/PMC Member

Marton Elek

  Cloudera Principal Software Engineer

  Apache Hadoop Committer

  Apache Ratis. Committer/PMC Member

Nicholas Sze

  Cloudera Principal Software Engineer

  Apache Hadoop Committer/PMC Member

  Apache Ratis. Committer/PMC Member

 

Chen Liang

  LinkedIn Senior Software Engineer

  Apache Hadoop Committer

 

等等等等

Ozone项目主页：

https://hadoop.apache.org/ozone/

Ozone设计方案：

https://issues.apache.org/jira/secure/attachment/12724042/Ozone-architecture-v1.pdf

Ozone Jira：

https://jira.apache.org/jira/projects/HDDS/

尝鲜Ozone：

https://www.katacoda.com/elek/scenarios/ozone101

Ozone Docker Volume(Quadra / cBlock):

https://issues.apache.org/jira/secure/attachment/12837867/cblock-proposal.pdf

大头数据

技术宅改变世界

长按二维码关注