Ozone的元数据系统架构演进和优化

对象存储是一种云存储服务，具有海量、安全、低成本和高可靠性的特点，适合存放任意类型的文件。‌它提供了容量和处理能力的弹性扩展，用户可以根据需求选择不同的存储类型，已经逐渐成为云计算、大数据分析和数据备份等领域的首选存储解决方案。

在对象存储领域，Ozone 是一个备受关注的开源项目。Ozone 旨在提供一个可扩展、高性能、持久性和多租户的对象存储系统。它采用了一种分层的存储架构，可以轻松地扩展到成百上千的节点，并具有优秀的容错性和数据安全性。

而在对象存储内部，元数据管理十分地重要，凡是涉及到对象存储的数据访问，都会经过元数据的查询或更新操作，如果元数据操作出现性能瓶颈，将会严重影响存储系统的性能表现。随着AI时代的快速发展，对存储技术提出了更高的要求，尤其在大规模、高性能和低成本方面。Ozone作为一款为大数据场景打造的对象存储系统，必然面临海量文件元数据管理的挑战。本文介绍了360基于Ozone的元数据系统架构演进，以及遇到的挑战与作出的优化。

1

Ozone概述

Ozone 是一个分布式、多副本的对象存储系统，同时针对大数据场景进行了专门的优化。Apache Spark、Hive 和 YARN 等应用无需任何修改即可使用 Ozone。Ozone 提供了 Java API、S3 接口和命令行接口，极大地方便了 Ozone 在不同应用场景下的使用。

Ozone 的管理由卷、桶和键组成。卷的概念和用户账号类似，只有管理员可以创建和删除卷。卷用来存储桶，桶的概念和目录类似，用户可以在自己的卷下创建任意数量的桶，每个桶可以包含任意数量的键，但是不可以包含其它的桶。键的概念和文件类似，用户通过键来读写数据。

下图展示了Ozone的核心组件：

Ozone 通过对命名空间与块空间的管理进行分离，大大增加了其可扩展性，其中命名空间由存储卷组成，统一由 Ozone Manager （OM）管理，块空间由 Storage Container Manager（SCM）管理，数据由Datanode节点存储，数据之间的复制使用raft协议。

SCM+Datanode 的组合可以提供块接口，对其抽象出一层，称之为Hadoop Distributed Data Store(HDDS)。

2

元数据系统的架构演进

社区版Ozone Manager使用 RocksDB 在本地持久化元数据（卷、桶和键）。使用 Apache Ratis（一种 Raft 协议的开源实现）来同步 Ozone Manager 的状态和元数据，这为 Ozone 提供了高可用保证。

但是这种方案也存在问题：

1）随着元数据体量逐渐增加，单机RocksDB容量成为瓶颈，元信息存储上限受限于单机磁盘的大小，无法满足海量数据规模的存储需求；

2）元信息基于raft协议复制到follower节点，需要引入snapshot等功能保证元信息在所有OM节点的一致性，复杂度偏高。

基于此我们决定将OM元数据存储到分布式KV中，一方面om leader无需再向Follower节点同步数据，只需要同步状态即可；另一方面可以去掉快照snapshot的逻辑，元数据的一致性由分布式KV保证。

分布式KV的选型这里考虑了以下三点：

• om的元信息通过double buffer flush将多次db操作合并为一次，数据库需要支持多表多行batch操作的原子性；

• 数据需要按照key名有序存储，便于实现s3的object list等操作；

• 规模可以水平扩展，依赖组件少。

在对业界的分布式KV数据库进行一系列调研后，我们选择使用Apache Cassandra作为元数据系统存储底座。

• 多种数据分区策略，支持ByteOrderedPartitioner，与rocksdb排序规则相同；

• 支持多表多行batch操作的原子性；

• 无中心节点架构，可调节的一致性模型，规模可水平扩展；

• 支持多数据中心部署，可保证元数据的异地容灾；

• 方便与计算引擎结合，进行分布式的元信息分析（如spark-cassandra-connector）。

3

元数据系统的挑战与优化

3.1 元数据读写分离

随着对象存储承接的请求越来越多，主节点的RPC压力也越来越大，而且大文件因元信息过大，在反序列化时会产生临时的大对象，频繁读取大文件的元数据，很容易触发OM的java垃圾回收从而影响整体服务质量。基于此我们考虑实现元数据读写分离，一方面可以减轻主节点RPC压力和GC压力，另一方面也缩短了元数据的读取路径，降低读取时延。

由于已经将元数据存储至分布式KV，不存在OM Follower节点与Leader节点数据同步有延迟的情况，所以这里使用客户端直接连接分布式KV读取元信息。

客户端会实现类似于OM的ContainerLocationCache，缓存container的位置信息，如果是List/Head Object 请求则直接从KV读取元信息；如果是Get Object请求，则除了从KV读取元信息以外，还需要从客户端的container location cache获取container位置信息，如未获取到则从om端获取。

3.2 元信息处理能力无限扩展

元数据存储需要极高的扩展性来支持数据的大量存储和快速增长。一组OM的RPC处理能力其实是有上限的，一个OM Leader节点的硬件条件根本无法支撑超大规模的元数据读写场景。目前社区版本只能通过拆分桶到其它集群来突破其处理上限，为了满足更高的扩展性，我们在一个Ozone集群中扩展了多组OM，通过hash分区打散RPC请求到多组OM，解决主节点的单点瓶颈问题。

将元信息存储到分布式KV，意味着我们具备了共享元信息的能力，可以很方便的扩展多组om去连接同一个分布式KV，数据一致性由分布式KV保证。

这里在OzoneClient端实现一个TokenMap，如图所示，通过hash算法将请求路由到多组OM上。多组OM是无状态的，每组OM逻辑上可以处理所有的元数据请求。

3.3 元数据分区管理

在大数据场景下，由于桶和桶之间的对象数量有可能差距很大，存储元数据的节点可能会存在非常大的数据倾斜问题。元数据集中在部分存储节点，极端情况下，所有负载可能会压在一个节点，其余节点空闲，系统瓶颈就落在这最忙的“热节点”上，这会对单机的性能造成较大压力，影响服务稳定性。

为了解决这个问题，我们优化了数据分布的策略。使用复合分区，先hash分区，再range分区。具体就是在元数据最前面增加一个hash产生的shardKey，不同shardKey的数据间隔放置，同一个shardKey下的数据顺序放置，这样元信息“热节点”数据就可以被分散到多个节点上。

推荐阅读：

云舟观测：Arkit数据解析插件详解

iOS屏幕共享技术实践

更多技术和产品文章，请关注👆

如果您对哪个产品感兴趣，欢迎留言给我们，我们会定向邀文~

360智汇云是以"汇聚数据价值，助力智能未来"为目标的企业应用开放服务平台，融合360丰富的产品、技术力量，为客户提供平台服务。
目前，智汇云提供数据库、中间件、存储、大数据、人工智能、计算、网络、视联物联与通信等多种产品服务以及一站式解决方案，助力客户降本增效，累计服务业务1000+。
智汇云致力于为各行各业的业务及应用提供强有力的产品、技术服务，帮助企业和业务实现更大的商业价值。
官网：https://zyun.360.cn 或搜索“360智汇云”
客服电话：4000052360