2199078Z空间(1392202Z空间)

导读:在过去十几年的发展中,HDFS以其高容错性、高吞吐量等特性,成为分布式大数据体系的核心组件,稳坐分布式大数据存储的第一把交椅。随着各行各业对大数据技术的利用率提升,在面对不断扩张的大数据集群规模、不断增长大数据存储量级时,原生的HDFS架构设计在支撑能力上显露不足。虽然社区提出了Federation等概念,但依旧无法解决因单点元数据暴增带来的NameNode GC压力、DataNode的心跳汇报风暴等问题。此外对于海量小文件的处理一直也是HDFS的短板。因此,Apache Ozone应运而生。

今天的介绍会围绕下面三点展开:

  • HDFS痛点
  • Ozone架构上的优势
  • Ozone新特性

01

HDFS痛点

首先和大家分享下HDFS当前面临的问题。

1. HDFS相关背景

199078Z空间(1392202Z空间)"

从上述架构图上我们可以看到:

  • NameNode存储元数据,包含DataNode和Block的信息,元数据全部存储在内存中,元数据的访问速率很快。
  • 所有的DataNode需要向NameNode进行心跳汇报;集群扩展很容易,仅需要增加DataNode节点即可。

但是这样的架构在集群达到一定规模时会显现出明显的不足

  • 元数据是全部存储到内存后,NameNode GC压力很大,从而导致元数据访问的延时存在波动。
  • 以Block为单位上报状态,会形成汇报风暴,汇报量的增加也会导致NameNode启动时间增加。

基于以上的问题,HDFS社区有两个探索方向:Federation和Scaling HDFS。

2. Federation:从ViewFs到RBF

199078Z空间(1392202Z空间)"

在Federation的设计中,存在两个阶段:

  • 基于ViewFs:即每个客户端都拥有更高维度的视角,可以关联到所有的NameNode,这种架构下扩展集群仅需要增加NameNode即可。但是这样的设计需要修改客户端的配置,不利于客户端的升级。
  • 于RBF:即引入新的服务Router(路由组件),在这个服务中进行集中化的配置管理,客户端对底层的配置和变化无感知。这个方案较于ViewFs更成熟,当前业务选用也更多。

总结而言,Federation的设计思路都是通过扩展NameNode的个数来达到提升集群的数据存储上限的效果。

3. Scaling HDFS:Ozone

199078Z空间(1392202Z空间)"

与Federation不同的是,Scaling HDFS的总体思路是提升单个NameNode节点的元数据上限,从而提升整个集群的数据存储上限。

这个想法自2014年下半年在HDFS社区开始提出,2015年正式启动。因为Ozone的发展节奏太过迅速,远超HDFS的版本迭代节奏,2020年Ozone正式从Hadoop的社区剥离,成为单独的项目,也就是现在的Apache Ozone。这个项目的核心目标是解决HDFS的NameNode扩展问题,解决其小文件导致的存储瓶颈问题,并希望能支持100+亿的文件处理。

02

Ozone架构上的优势

接下来和大家分享下Apache Ozone的架构设计。

1. Ozone架构设计

199078Z空间(1392202Z空间)"

相比于原生的HDFS,Ozone做了以下的架构调整:

  • 元数据存储:拆分NameNode,引入第三方存储。将NameNode元数据管理功能拆分成OM(Ozone Manager,用于存储文件的元数据)和SCM(Storage Container Manager,用于存储Container的元数据)。另外,元数据不再是all in memory的,我们引入了RocksDB替代原先的内存存储。通过引入持久化和元数据管理的分层,进而提升了原数据的上限。
  • 增加Container抽象:引入Container作为一组block的抽象逻辑,心跳汇报以Container为单位,降低汇报量,也减少SCM的元数据存储量。
  • 增加对象语义:支持文件协议和S3协议。Ozone的对象路径分为三层,分别为Volume、Bucket和Object (key)。如果需要访问某个Object,可以通过OM地址,找到对应的volume、对应的bucket,再取到对应的key进行访问(http://hostname/volume/bucket/key)
199078Z空间(1392202Z空间)"

2. Ozone DataNode设计

199078Z空间(1392202Z空间)"

Ozone DataNode将block分组,将每个组作为Container进行管理,DataNode仅收集Container的状态,并且以Container作为数据备份的单元。值得注意的是,Container内部的对于block的原数据管理也是使用Rocks DB。

Container存在OPEN和CLOSE的状态。当Container处于OPEN状态是,支持对其下的Block的数据进行写入,但是删除操作并非即时生效,会延后处理;当Container处于CLOSE的状态时(例如写满5GB的数据),不再接受新数据的写入,此时开始处理之前删除的block数据。

3. Ozone SCM设计

199078Z空间(1392202Z空间)"

Ozone的SCM,类似于HDFS NameNode的Block管理模块。SCM负责所有的数据节点管理,Container的生命周期管理,以及备份的管理,比如备份数不足的Containers补足备份,备份数超过既定数的Containers清除多余备份。Ozone是依赖Apache Ratis进行一致性保证的,所以SCM中维护了很多Ratis Pipeline,SCM也负责对这些Pipeline进行管理。

4. Ozone 架构总结

下面这张图从更高的视角展现了Ozone的总体分层设计:

199078Z空间(1392202Z空间)"

  • OM:Volume、Bucket、Key的元数据管理。
  • SCM:Container的元数据管理。
  • DataNode:维护Container,以及Container下的多个具体的block文件。

多层的设计核心目标就是为了提升原数据的上限,增加可扩展性。

03

Ozone新特性

接下来,就Ozone最新的一些特性进行说明。

1. Ozone FS

199078Z空间(1392202Z空间)"

Ozone是对象存储。虽然在使用中用户会发现和HDFS的文件系统使用方式一样,但其实是利用对象存储的API模拟出来的。这就导致一个问题,在一些特殊操作中,例如Delete、rename时,其效率远远比不上真正的文件系统。为此,腾讯和Ozone社区针对这个问题进行了不同方向的优化设计。

  • 优化一:引入NameNode替代OM

来源于社区的一个思路,即不使用OM进行对象存储语义的处理,直接移植NameNode作为SCM的上层语义解析,原生态支持文件系统的语义,提升效率。

199078Z空间(1392202Z空间)"

经过内部测试,这样的移植提升了整体处理性能,并提供了完整的文件语义支持,并且原先依赖HDFS的应用迁移时,无需额外代码调整,减少运维变化。

腾讯内部已经完成了这个思路的改造,因为不确定这样的改造是贡献给Hadoop还是Ozone,这个优化方案尚未正式开源。

  • 优化二:优化OM的表设计

OM在处理一些操作慢的主要原因是Rocks DB 的KV结构在处理like这类事件时,导致的全表扫描效率极低(因为key是完整的路径,如果要删除某一个bucket底下的数据,无法精准获取key,只能使用like这类模糊查询的语义)。所以优化二的主体思路就是调整Rocks DB的表设计,提升查询效率。

199078Z空间(1392202Z空间)"

优化二将最初的一张表设计,拆成两张表(文件表和目录表)。考虑到文件目录数量远远小于底层文件的数量,将文件目录和底层文件单独存储。比如进行rename操作时,不再需要遍历修改所有的key,只需要更新目录表中的某一条即可,整个时间复杂度为O(1)。同样进行delete操作时,仅需要删除目录表中的某一条即可,文件表中的key后台会异步清除,整个时间复杂度也是O(1)。

根据社区的测试,从性能的量级上可以和HDFS原生文件系统的性能量级达到一致。

2. Ozone Streaming

199078Z空间(1392202Z空间)"

Ozone是利用Apache Ratis进行写入的一致性保证的,但是这个项目的引入其实降低了Ozone的写效率。举个例子,针对一个128M的Block的写入,被分成32个4M的Chunk,每个Chunk都会产生写的动作,每个Chunk对应的RaftLog也会产生“写”的动作,导致相对于HDFS,“多写了”32次。

我们正在通过Ozone Streaming对Ozone的写进行效率的优化,包括参考HDFS的写的过程,考虑落盘时不再依赖RaftLog,异步刷盘等。经过我们内部测试,当前即将开放的1.3版本的Ozone写的效率基本能达到HDFS的90%左右,相比于两年前的1.0的版本60%,已经有了显著的提升。

3. Ozone EC

Apache Ozone的设计目标就是针对超大规模的数据量级的存储,机器数量增加,成本也是需要慎重考虑的地方,因此Ozone EC(全称Erasure Coding,纠删码技术)也一直是我们关注的重点。

199078Z空间(1392202Z空间)"

目前Ozone EC的开发进度来看:

  • EC的读写过程已经完成。
  • EC的编解码方式而言,RD和XOR的算法支持了,但是基于ISA-L的硬件编码加速还没有实现,计划参考Hadoop进行补充实现。
  • EC的策略与HDFS类似。
  • 支持EC文件在在线修复,但是离线修复和副本文件的相互转化还没有实现。

现在EC的开发分支已经merge到master了,用户可以预览EC的功能。不过需要等离线修复功能开发完毕才能生产可用。

4. Ozone merge Rocks DB

因为Ozone默认是每个Container对应一个RocksDB的实例。我们在Ozone落地时发现,随着DataNode上数据量变多,会产生大量的RocksDB实例,会导致DataNode性能越来越差。因此我们优化了这部分的实现,让DataNode每块盘对应一个RocksDB实例,这样能极大减少RocksDB实例数(不会超过数据目录个数)。

199078Z空间(1392202Z空间)"

从内部测试的情况来看,除了delete Container操作上效率有所降低,其他的操作效率都得到了显著提升。目前该功能已经开发完成并且已经merge到master。


今天的分享就到这里,谢谢大家。

阅读更多技术干货文章、下载讲师PPT,请关注微信公众号“DataFunTalk”。


分享嘉宾:赵明超 腾讯 高级工程师

编辑整理:李铭 多点dmall

出品平台:DataFunTalk


分享嘉宾:

199078Z空间(1392202Z空间)"


活动推荐:

199078Z空间(1392202Z空间)"


关于我们:

DataFun:专注于大数据、人工智能技术应用的分享与交流。发起于2017年,在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会,已邀请超过2000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章700+,百万+阅读,14万+精准粉丝。


欢迎转载分享评论,转载请私信。

本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 1553299181@qq.com 举报,一经查实,本站将立刻删除。
如若转载,请注明出处:https://www.pop371.cn/6948.html