炼数成金 门户 大数据 Hadoop 查看内容

Hadoop 对象存储 Ozone

2019-10-25 16:56| 发布者: 炼数成金_小数| 查看: 17125| 评论: 0|原作者: Yan Liu|来自: 大头数据

摘要: Apache Hadoop 项目至今已经有十多年的历史了,作为大数据的基石,自从投放之社区之后就引来了不少的眼球,进而也孕育出了众多的Apache项目,例如HBase,Hive , Spark 等等这些优秀的数据存储和处理等项目,从而构造 ...

存储 Hadoop 大数据 集群 运维

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目前的问题有以下几个方面:
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目前的各种痛点。

由 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系列的下一篇文章中会讲到。

结束语
大头作为一个社区粉丝,还是要敬仰并感谢这些社区贡献人员不断的为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

声明:本文版权归原作者所有,文章收集于网络,为传播信息而发,如有侵权,请联系小编及时处理,谢谢!

欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括:Java,C/C++,Python,PHP,Ruby,shell等各种语言开发经验交流,各种框架使用,外包项目机会,学习、培训、跳槽等交流
QQ群:26931708

Hadoop源代码研究群
兴趣范围包括:Hadoop源代码解读,改进,优化,分布式系统场景定制,与Hadoop有关的各种开源项目,总之就是玩转Hadoop
QQ群:288410967 
1

鲜花

握手

雷人

路过

鸡蛋

刚表态过的朋友 (1 人)

相关阅读

最新评论

热门频道

  • 大数据
  • 商业智能
  • 量化投资
  • 科学探索
  • 创业

即将开课

 

GMT+8, 2019-11-19 23:00 , Processed in 0。183195 second(s), 25 queries 。

幸运飞艇合法吗 幸运飞艇手势图 幸运飞艇胆码 幸运飞艇精准 揭秘幸运飞艇 幸运飞艇大群 幸运飞艇是啥 幸运飞艇正规吗 幸运飞艇带打 幸运飞艇彩专家