Hadoop 对象存储 Ozone
Posted 大头数据
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Hadoop 对象存储 Ozone相关的知识,希望对你有一定的参考价值。
审阅:Xiaoyu Yao
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过高等等问题。
社区的一些改进
大体上讲,HDFS目前的问题有以下几个方面:
超大规模的扩展能力问题;
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面临的诸多问题:
多层目录结构的设计方案使得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
大头数据
技术宅改变世界
长按二维码关注
以上是关于Hadoop 对象存储 Ozone的主要内容,如果未能解决你的问题,请参考以下文章