当前位置:   article > 正文

Hadoop分布式文件系统(HDFS)会不会被淘汰?_大数据时代开始采用hadoop分布式组件时,业界甚至认为“数据库已死”,会被淘汰。

大数据时代开始采用hadoop分布式组件时,业界甚至认为“数据库已死”,会被淘汰。

首先我们应该更具体的理解这样一个现象,为什么流行的技术框架会被淘汰。谈到淘汰,常见两种情况:

第一:应用模式被淘汰了,例如:BB机,功能机,最终被智能机淘汰,胶卷被数码相机淘汰,即便诺基亚的功能机做得再完美,也会被淘汰。软件方面例如:终端的字处理,邮件收发等应用软件被视窗应用软件淘汰。

第二:技术升级,新技术弥补了老技术的缺陷,并且引入了更多有优势的功能。例如:Springframework的横空出世,配合Hibernate,在具有同样功效的情况下,解决了EJB的部署复杂,体态臃肿,计算效率低,用灵活性,面向程序员的友好性,淘汰了曾经企业级经典的EJB。

那么对于Hadoop分布式文件系统(HDFS),我们要讨论它的淘汰可能性,淘汰时间,首先我们就要看它为什么要被淘汰的因素。从模式上,分布式文件系统是大数据存储技术极为重要的一个领域,我们还看不到分布式文件系统有被淘汰的任何理由,那么我就再看技术升级是否有淘汰它的可能性。

谈技术升级,首先要看HDFS的缺点,然后再看这种缺点的解决办法,是否会带来新的技术框架,然后让HDFS埋进历史的垃圾堆。

01 部署复杂

HDFS为集中式协调架构,namenode若是单节点,部署并不复杂,但是namenode作为单节点无法可靠的运行在生产环境,必须对namenode实现双机HA,那么部署复杂度就变得极高,这时候需要在namenode,datanode的基础上再引入namenode active,namenode standby的概念,需要引入QJM的元数据共享存储并基于Paxos做一致性协调,另外需要引入ZKFC和ZooKeeper,解决主备选举,健康探测,主备切换等操作。

图片

复杂的HDFS HA架构

因此HDFS的部署复杂度完全是因为namenode HA导致的。这是集中式管理的分布式架构一个原生问题,如果在这个地方进行优化的话,那么就是简化QJM,ZKFC,ZooKeeper的多组服务,用一组服务来代替,但是namenode和datanode的分布式数据块的读写,复制,恢复机制,目前看非常成熟,高效,这是核心问题,并不是缺点,不需要更具颠覆性的优化。

02 元数据的内存瓶颈

由于namenode在内存中记录了所有数据块(block 默认128M)的信息,索引了数据块与datanode的关系,并且构建了文件系统树,因此可想而知namenode的元数据内存区是大量占用内存,这是没有上限的。对于较大型数据存储项目,例如上百个datanode节点和上千万个数据块的容量来说,元数据在namenode的内存大概能控制在32G以内,这是还没问题的,但是对于构建海量数据中心的超大型项目,这个问题就好像达摩克斯之剑,首先堆内存超过临界范围导致的内存寻址性能问题不说,一旦namenode内存超限到单机内存可承载的物理上最大承受范围,整个hdfs数据平台将面临停止服务。

这个问题的本质还是Google设计GFS时候采用粗放的实用主义,先把元数据都交给主节点在内存中节制,超大问题以后再解决。目前Google的GFS2设计上,已经将元数据在内存中迁移至了BigTable上,那么问题就来了:“BigTable基于GFS,而GFS2的元数据基于BigTable”?有点鸡生蛋还是蛋生鸡的自相矛盾。是的,看似矛盾实质上是架构的嵌套复用,可以这么去解读:GFS2是基于<基于GFS的BigTable的元数据存储>的下一代GFS架构。用BigTable的k-v存储模型放GFS2的元数据,虽然没有内存高效,但是够用,而且可以无限存储,用BigTable专门存储元数据形成的k-v记录最终保存成GFS数据块,因此在GFS的元数据内存中只需少量的内存占用,就能支撑天量的真正应用于数据块存储的GFS2元数据。

基于GFS2的设计思想,我相信下一代HDFS应该也是这样的方案去解决元数据的内存瓶颈问题,也就是基于<基于HDFS的HBase的元数据存储>的下一代HDFS架构。那么HDFS的元数据瓶颈问题将被彻底解决,很难看到比这更具优势的替代性技术框架了。

如下图所示:

图片

GFS V2假想图

03 默认副本数占用空间

副本数默认为3最大的问题就是占空间,这几乎是所有传统分布式文件系统(DFS)的通病。因此HDFS集群的默认空间利用率只有33.3%,这么低的利用率显然不符合一些场景,例如长期的冷数据备份,那么有没有更好的方式呢?是有的,目前比较成熟的方案就是纠删码技术,类似raid5,raid6,HDFS 3.0版本以后支持这种模式,叫做Erasure Coding(EC)方案。

HDFS是怎么通过EC方案解决磁盘利用率的问题呢?我们先聊点比较硬的原理,说说EC方案之一的条形布局:

首先数据文件写的时候会向N个节点的块(Block)依次写入,N个Block会被切成多组条(stripe 1... stripe n),如果分布式环境有五个存储节点(DataNode),那么就把stripe切成3个单元(cell),然后再根据这3个cell计算出2个校验cell,然后这5个cell(3个data+2个parity)分别写入5个Block中。数据条就这么依次轮巡的方式,将校验块的位置轮换存储在不同Block上,直至写满,这样校验块的分布可以更均匀。

图片

HDFS EC Striping Layout

其次再说取数据,取数据每次只从3个DataNode中各取出1个cell,如果这3个cell都是数据cell,那么就成功拿到一组数据条stripe,如果有一个cell是校验cell,那么就能通过校验cell和另外2个数据cell计算出第3个数据cell,完成数据条stripe的组合。这种情况下,即便是5个datanode节点有2个datanode宕机了,另外3个datanode也能通过校验码计算完成剩余2个节点的数据,这就是利用纠删码技术实现数据冗余的原理。

通过这种方式,我们就比传统2副本50%,3副本33.3%的多副本模式要省空间,EC中2+1可以达到66.7%的磁盘利用率,例子是3+2可以达到60%的磁盘利用率

但是其问题是特别消耗CPU计算,上面那种读取情况,五分之三的读取数据条时间都要进行校验码计算。因此可以利用Intel CPU推出的ISA-L底层函数库专门用于提升校纠删码算法的编解码性能。通常情况下,纠删码用于冷数据的冗余,也就是不经常访问,但又必须联机存储以备查询的数据。除了磁盘利用率,多副本方式用空间换效率的方式肯定是最好,没什么问题。


守护石 「技术创作」
关注领域:大数据技术、分布式架构 | 技术管理icon-default.png?t=LA92http://www.readbyte.com/

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/我家小花儿/article/detail/199511
推荐阅读
  

闽ICP备14008679号