在大数据领域，如何实现存储计算分离？

导读

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

HDFS痛点

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

1. HDFS相关背景

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

NameNode存储元数据，包含DataNode和Block的信息，元数据全部存储在内存中，元数据的访问速率很快。
所有的DataNode需要向NameNode进行心跳汇报；集群扩展很容易，仅需要增加DataNode节点即可。
但是这样的架构在集群达到一定规模时会显现出明显的不足：

元数据是全部存储到内存后，NameNode GC压力很大，从而导致元数据访问的延时存在波动。
以Block为单位上报状态，会形成汇报风暴，汇报量的增加也会导致NameNode启动时间增加。
基于以上的问题，HDFS社区有两个探索方向：Federation和Scaling HDFS。

2. Federation：从ViewFs到RBF

在Federation的设计中，存在两个阶段： 

基于ViewFs：即每个客户端都拥有更高维度的视角，可以关联到所有的NameNode，这种架构下扩展集群仅需要增加NameNode即可。但是这样的设计需要修改客户端的配置，不利于客户端的升级。
基于RBF：即引入新的服务Router（路由组件），在这个服务中进行集中化的配置管理，客户端对底层的配置和变化无感知。这个方案较于ViewFs更成熟，当前业务选用也更多。
总结而言，Federation的设计思路都是通过扩展NameNode的个数来达到提升集群的数据存储上限的效果。

3. Scaling HDFS：Ozone

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

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

Ozone架构上的优势

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

1. Ozone架构设计

相比于原生的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进行访问

 

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的总体分层设计：

OM：Volume、Bucket、Key的元数据管理。
SCM：Container的元数据管理。
DataNode：维护Container，以及Container下的多个具体的block文件。
多层的设计核心目标就是为了提升原数据的上限，增加可扩展性。 

Ozone新特性

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

1. Ozone FS

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

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

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

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

优化二：优化OM的表设计
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的读写过程已经完成。
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实例数（不会超过数据目录个数）。

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