腾讯赵明超：Apache Ozone下一代大数据存储解密
|
导读：在过去十几年的发展中，HDFS以其高容错性、高吞吐量等特性，成为分布式大数据体系的核心组件，稳坐分布式大数据存储的第一把交椅。随着各行各业对大数据技术的利用率提升，在面对不断扩张的大数据集群规模、不断增长大数据存储量级时，原生的HDFS架构设计在支撑能力上显露不足。虽然社区提出了Federation等概念，但依旧无法解决因单点元数据暴增带来的NameNode GC压力、DataNode的心跳汇报风暴等问题。此外对于海量小文件的处理一直也是HDFS的短板。因此，Apache Ozone应运而生。 今天的介绍会围绕下面三点展开： 01 HDFS痛点 首先和大家分享下HDFS当前面临的问题。 1. HDFS相关背景
从上述架构图上我们可以看到： 但是这样的架构在集群达到一定规模时会显现出明显的不足： 基于以上的问题，HDFS社区有两个探索方向：Federation和Scaling HDFS。 2. Federation：从ViewFs到RBF
在Federation的设计中，存在两个阶段： 总结而言，Federation的设计思路都是通过扩展NameNode的个数来达到提升集群的数据存储上限的效果。 3. Scaling HDFS：Ozone
与Federation不同的是，Scaling HDFS的总体思路是提升单个NameNode节点的元数据上限，从而提升整个集群的数据存储上限。 这个想法自2014年下半年在HDFS社区开始提出，2015年正式启动。因为Ozone的发展节奏太过迅速，远超HDFS的版本迭代节奏，2020年Ozone正式从Hadoop的社区剥离，成为单独的项目，也就是现在的Apache Ozone。这个项目的核心目标是解决HDFS的NameNode扩展问题，解决其小文件导致的存储瓶颈问题，并希望能支持100+亿的文件处理。 -- 02 Ozone架构上的优势 接下来和大家分享下Apache Ozone的架构设计。 1. Ozone架构设计
相比于原生的HDFS，Ozone做了以下的架构调整：
2. Ozone DataNode设计
Ozone DataNode将block分组，将每个组作为Container进行管理，DataNode仅收集Container的状态，并且以Container作为数据备份的单元。值得注意的是，Container内部的对于block的原数据管理也是使用Rocks DB。 Container存在OPEN和CLOSE的状态。当Container处于OPEN状态是，支持对其下的Block的数据进行写入，但是删除操作并非即时生效，会延后处理；当Container处于CLOSE的状态时（例如写满5GB的数据），不再接受新数据的写入，此时开始处理之前删除的block数据。 3. Ozone SCM设计
Ozone的SCM，类似于HDFS NameNode的Block管理模块。SCM负责所有的数据节点管理，Container的生命周期管理，以及备份的管理，比如备份数不足的Containers补足备份，备份数超过既定数的Containers清除多余备份。Ozone是依赖Apache Ratis进行一致性保证的，所以SCM中维护了很多Ratis Pipeline，SCM也负责对这些Pipeline进行管理。 4. Ozone 架构总结 下面这张图从更高的视角展现了Ozone的总体分层设计：
多层的设计核心目标就是为了提升原数据的上限大数据存储，增加可扩展性。 -- 03 Ozone新特性 接下来，就Ozone最新的一些特性进行说明。 1. Ozone FS
Ozone是对象存储。虽然在使用中用户会发现和HDFS的文件系统使用方式一样，但其实是利用对象存储的API模拟出来的。这就导致一个问题，在一些特殊操作中，例如Delete、Rename时，其效率远远比不上真正的文件系统。为此，腾讯和Ozone社区针对这个问题进行了不同方向的优化设计。 来源于社区的一个思路，即不使用OM进行对象存储语义的处理，直接移植NameNode作为SCM的上层语义解析，原生态支持文件系统的语义，提升效率。
经过内部测试，这样的移植提升了整体处理性能，并提供了完整的文件语义支持，并且原先依赖HDFS的应用迁移时，无需额外代码调整，减少运维变化。 腾讯内部已经完成了这个思路的改造，因为不确定这样的改造是贡献给Hadoop还是Ozone，这个优化方案尚未正式开源。 OM在处理一些操作慢的主要原因是Rocks DB 的KV结构在处理like这类事件时，导致的全表扫描效率极低（因为key是完整的路径，如果要删除某一个bucket底下的数据，无法精准获取key，只能使用like这类模糊查询的语义）。所以优化二的主体思路就是调整Rocks DB的表设计，提升查询效率。
优化二将最初的一张表设计，拆成两张表（文件表和目录表）。考虑到文件目录数量远远小于底层文件的数量，将文件目录和底层文件单独存储。比如进行rename操作时，不再需要遍历修改所有的key，只需要更新目录表中的某一条即可，整个时间复杂度为O(1)。同样进行delete操作时，仅需要删除目录表中的某一条即可，文件表中的key后台会异步清除，整个时间复杂度也是O(1)。 根据社区的测试，从性能的量级上可以和HDFS原生文件系统的性能量级达到一致。 2. Ozone Streaming
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，纠删码技术）也一直是我们关注的重点。 目前Ozone EC的开发进度来看： 现在EC的开发分支已经merge到master了，用户可以预览EC的功能。不过需要等离线修复功能开发完毕才能生产可用。 4. Ozone merge Rocks DB 因为Ozone默认是每个Container对应一个RocksDB的实例。我们在Ozone落地时发现，随着DataNode上数据量变多，会产生大量的RocksDB实例，会导致DataNode性能越来越差。因此我们优化了这部分的实现，让DataNode每块盘对应一个RocksDB实例，这样能极大减少RocksDB实例数（不会超过数据目录个数）。
从内部测试的情况来看，除了delete Container操作上效率有所降低，其他的操作效率都得到了显著提升。目前该功能已经开发完成并且已经merge到master。 （编辑：520站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
