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面临的诸多问题:
  • 多层目录结构的设计方案使得Ozone可以提升到百亿级别的文件Key;
  • OM和SCM是可以横向扩展的,并不会出现RPC集中在单点的问题;
  • 使用Offheap来减少GC,通过FSCK服务来自动化的维护集群;
  • 通过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项目主页:
Ozone设计方案:
Ozone Jira:
尝鲜Ozone:
Ozone Docker Volume(Quadra / cBlock):