打造 AI 存储底座，贝壳找房将 OceanBase 作为 JuiceFS 元数据引擎的建设实践

作者｜王天庆，贝壳计算存储方向容器引擎团队负责人，目前工作聚焦于云原生和 AI 基础设施的架构设计和建设实施，为公司提供高效可靠的基础设施并帮助大模型在企业内部快速落地。

从 AI 大模型爆火到成为技术领域新的应用方向，许多企业将 AI 列入战略规划。贝壳找房作为国内先进的居住产业数字化服务平台，也加大了对 AI 技术设施的投入。而其底层的数据库产品选用蚂蚁集团自主研发的单机分布式一体化数据库 OceanBase，那么，数据库在 AI 基础设施建设过程中能起到什么样的核心作用？本文通过分享贝壳找房在 AI 存储底座的实践，展开这一话题的讨论。

贝壳找房 AI 基础设施建设背景

贝壳找房是中国最大的居住服务平台之一，业务包括二手房交易、新房交易、租赁、家装、家居、家服等，作为居住产业数字化服务平台，贝壳是最早将 VR、AI 等新技术应用于居住服务的企业，其致力于推进居住服务的产业数字化、智能化进程。

自 AI 大模型爆火后，贝壳找房很快加大了对 AI 的投入。目前我们团队有三大模块致力于 AI 的发展：一是机器学习平台，帮助算法工程师做模型训练和模型推理；二是在机器学习平台下层有两套内部的基础设施提供高性能存储服务；三是内部的云原生基础设施。

在 AI 基础设施建设的过程中，由于数据的快速增长和对算力的不断调整，存储架构不断演化，在各阶段面临不同的挑战。

分层存储架构演化

贝壳找房 AI 基础设施建设始于几年前，受 AI 技术发展态势迅速变化的影响，至今已历经四个阶段的演化。

在非大模型时代，算法工程师训练模型特别简单，只需要一台 GPU 和一块硬盘，即单机单卡。训练模型逐渐变大，超出了一台机器能够承载的范围。随即便出现了多机多卡的场景，其本质上不会脱离机房，但该场景下无法再使用一块磁盘解决问题，需要网络共享存储。彼时，常用的共享存储开源方案是基于 NFS。

2023 年大模型的火爆促使模型训练对 GPU 算力需求及资源使用方式发生巨大变化，我们也从多机多卡单机房结构变成平台化的交付方式，完全云原生化。底层也使用统一文件系统存储千亿规模的文件。

随着算力资源因供不应求导致的稀缺，我们的算力分布在多家公有云的多个地域，包括北京、上海、天津等地，算力的供给多样性给数据集合模型管理带来了更多的技术挑战。

同时，大模型的发展使存储系统存在着两大技术挑战，一类是模型训练过程中的存储瓶颈，随着 AI 模型的参数量越来越大，文件系统的数据传输能力和 Checkpoint 的写入效率很容易成为模型训练过程中的性能瓶颈，因此要求存储底座需要具备极高的并发、吞吐的能力。另一类是数据流转的效率。数据集对于大模型工程体系来说，贯穿了整个生命周期。在传统场景中，不同的场景都存在独立的存储介质来满足业务场景，但在大模型的迭代过程中，为了提高 GPU 资源的使用效率，我们需要尽量减少数据在流转过程中消耗的存储成本和时间成本。

数据流转周期牵涉整个贝壳找房 AI 工程，从用户端的数据采集到数据处理，再到转化成数据集，最后流转到 GPU 支撑模型训练。该流程最理想的形式是以文件系统卷的形式挂载。对于整个数据流转来说，无论是数据流入、数据处理、模型训练还是生成模型文件来做模型推理，整个数据的存在形式都是以同一个共享卷的方式存在的话，能极大的减少数据复制带来的时间消耗。

贝壳在此理念的基础上，开发并设计了符合贝壳当下物理环境的分层存储底座来满足数据流转的效率。

分层存储技术选型

分层存储架构分为存储编排和文件系统存储两部分。我们选择了开源的 Fluid 作为数据编排部分，其具备云原生的数据编排以及缓存加速的能力。

底层的文件存储选用开源分布式文件系统 JuiceFS，这是一款面向云原生设计的高性能分布式文件系统，提供 POSIX、HDFS 和 S3 协议的接入方式，其高性能特性比较依赖于高性能的元数据引擎和对象存储服务。

目前贝壳内部还存在着一些其他的文件系统，比如 CubeFS，为了更好的提高数据流转的效率，我们通过整合多种底层存储并围绕着 JuiceFS 我们打造了混合云存储底座。

第一层就是接入层，满足各类场景的数据写入/读取的需求，包括云原生场景下、HDFS 协议或者直接使用 S3 协议来对文件进行操作。

第二层是数据编排层，主要是解决跨地域数据流转和数据就近访问的能力。因为数据可能在北京区被生产，但是在上海区被消费，所以需要把数据传输到离算力最近的地方。

第三、四层组成了基于 JuiceFS 的完整的文件系统底座。JuiceFS 依赖元数据和对象存储服务的能力。需要一个高效的元数据引擎和能够满足我们多地域需求的对象存储服务。

然而，元数据引擎的技术选型是非常困难的，如果基于高性能的 Redis，存在数据丢失的风险，可能是文件系统的灾难，我们无法容忍。如果是全靠自研，人力投入和时间成本过高，短期内无法落地。综合考虑下，我们确定首要需求是稳定且不丢数据，其次是承载我们数据流转、跨地域的需求。

将 OceanBase 作为 JuiceFS 的元数据引擎

在调研了目前市面上的多种元数据引擎存储系统后，我们最终选择将 OceanBase 作为元数据引擎的技术方案和存储底座。主要原因如下：

1. 对于整个数据流转系统而言，OceanBase 可以提供高可用和容灾能力，解决数据流转中跨地域数据同步的问题。

a) OceanBase 的每个数据分片都有多个副本，分布在不同的物理节点上，当某个节点出现故障时，系统可以自动切换到其他副本，保证服务的连续性。

b) 通过配置数据副本的存储位置，可实现机架级、机房级、城市级容灾，帮助金融机构应对容灾挑战。

2. 我们有很多机房，算力分散在不同区域，我们需要把数据充分地利用起来，就需要元数据能够在各区域飘来飘去，在离算力最近的地方读到元数据可以保证文件系统的读取效率。OceanBase 的多活能力可以解决这个问题。

3. 我们是云原生和 AI 基础设施建设的团队，不太擅长数据库运维，上文也提到数据流转涉及整个企业的多个业务模块，因此我们需要存储底座具备资源隔离能力和较高的可运维、可管理能力。OceanBase 提供了强大的运维管理平台 OCP 对数据库进行 7*24 小时监控，安全可靠。

4. OceanBase 的原生多租户架构和租户级资源隔离能力，可以满足我们的需求。同时，其性能均衡，能支持百亿到千亿量级数据。

举个例子，下图是京津区算力中心和上海区算力中心的元数据传输的架构解决方案。可以看到整体的算力资源分为 IDC 和公有云，且拥有多家公有云供应商。我们在 IDC 内尤其是同区的机房内，使用 OceanBase 多 zone 的能力，通过 OBProxy 分别转化到不同的副本中。针对跨云甚至跨区的场景，以腾讯云为例，我们巧妙借助了腾讯云 MySQL 的能力，当 IDC 的数据飘在上海时，先把数据基于 OMS 同步到京津区腾讯云的数据库，再通过云上的 DTS 工具同步到上海区的数据库，由上海区的数据库提供元数据的处理能力。

为什么出现这么复杂的架构，而非利用 OceanBase 在上海区整体做同步？

这是出于物理限制，我们测试过一些场景，如果让 OceanBase 在上海区同步数据，受限于云联网和带宽会出现极高的同步延迟。而目前的方案可以保证最低的数据延迟，我们只需解决数据流转在 2w TPS 时从京津区写入上海区在秒级内完成，这个速度在整体数据生产过程中可以满足大部分业务场景需求。另外，IDC 和其他算力中心基本都在 OceanBase 的多 zone 管理模式下，数据流转速度更快。

OceanBase 作为 JuiceFS 的元数据引擎，在同机房访问文件系统场景下，表现也很出色。在单客户端场景下，文件规模在 2000 万左右时，Oceanbase 的响应时间可以控制在 1~2ms 之间，只有在一些大量 list 删除时才会偶有抖动，耗时基本能控制在 2~10ms 之间。

将 OceanBase 作为对象存储服务的元数据引擎

贝壳找房内部自研了一套对象存储服务，作为 JuiceFS 的数据持久化层。由于我们存在跨区读取数据的场景，比如对象存储数据存储在北京区，但是需要从上海区读取，甚至我们还面临着跨公有云的情况。

因此，我们希望对象存储服务具备跨区甚至是跨云数据复制的能力，可以把一份数据同步到不同公有云的不同地区，离算力更近一些。为此我们自研了一套对象存储系统 KOS 来满足我们的需求。该系统本质上并不提供真实的存储能力，而是一层 S3 协议代理层，最终数据都在落在公有云的对象存储上，比如腾讯云 COS 上。我们的对象存储系统只解决一个问题——访问加速。对象存储系统的部署形式是在京津区和上海区部署我们 KOS 服务，通过跨区复制能力，保证上海区、京津区之间 KOS 文件复制的实时同步。

对象存储本身也是有元数据的，在海量数据的场景下，对象存储元数据访问的性能也会极大的影响对象存储的整体性能，尤其是在文件系统这类需要频繁查询文件元信息的情况下。因此，我们使用 OceanBase 作为 KOS 的元数据的底座，以推动整个对象存储服务加速。如下图所示，对象存储系统分三个组件：

• KOS-Proxy 协议代理层：主要用于实现 S3 接口协议，该组件是完全无状态服务，元数据主要从 KOS 控制面中获取。

• KOS-Cache 数据缓存层：主要功能是从底层真实的对象存储中缓存数据到本地磁盘中，并且可以分布式部署形成缓存集群来提高对象存储的吞吐能力。

• KOS-Meta 元数据层：主要对对象存储服务提供元数据能力，以 OceanBase 为底层元数据引擎，提供就近获取到对象存储元数据信息的能力。

在这个流程中，对于文件的读取，会优先判断文件是否启用了数据缓存，如果存在缓存的话会优先从缓存节点 KOS-Cache 读取数据，否则降级到远端的对象存储读取。为了保证数据一致性，所有归属于同一组的缓存节点都会以哈希环的形式分布好，每个 cache 服务通过 etcd 对外分享自己在环中持有的 Token 信息和位置信息。数据的读写都会通过一致性 hash 算法写入到指定节点，保证数据的一致性。最终元数据加速的原理是通过 S3 协议在对象存储文件生命周期过程中，生成文件对应的元信息并写入 OceanBase 中，同时 OceanBase 做好多 AZ 和多地域的同步支持，此时就可以通过 OceanBase 实现支持海量数据的对象存储服务。

拥有对象存储能力后，我们访问云上的对象存储都会转化为本地机房访问的对象存储，实现了加速。访问文件系统时非常高效。下图展示了本地访问与云上访问的性能对比数据。

从图中可见，对于大量小文件加速效果比较明显，强依赖 OceanBase 提供的强大性能。在跨机房场景下，性能提升比较明显，有效提升读场景下的吞吐上限。不过，该方案对于对象存储的写场景提升效果不明显。

对象存储服务优化后，我们考虑怎么把 JuiceFS 用起来。在用户侧，数据要先在京津区计算后再拷贝到上海区，然后从上海区拉取数据进行训练。这个流程中要么存在带宽小、专线贵的问题，要么会遇到部分小文件场景难以优化吞吐导致延迟较高的问题。

一种优化思路是做镜像文件系统。首先用户在京津区创建一个普通卷，该卷的自动接入会连接到京津区的元数据引擎和对象存储服务。然后用户在上海区创建一个京津区卷的镜像卷，用户使用该卷的时候，自动接入会自动识别并接入到上海区的元数据引擎和对象存储服务。该思路减少了数据流转的时间，从传统的数据生产到数据清洗、数据复制、训练，到优化为数据生产、进行数据清洗、再训练，可以降低数据复制的时间成本。数据量较小时可秒级完成。对于不需要所有的数据都多地区多写的情况，还可以通过镜像文件系统的能力，进行跨地区预热，将数据同步到其他地区，JuiceFS 的文件块大小对于公有云对象存储的数据同步比较友好，同步效率会更高。进而还能帮助省钱，因为在 AI 领域有一个共识——GPU 很贵，闲着就是烧钱，所以一定要保证数据同步效率跟得上算力的速度。

OceanBase 应用场景探索

除了将 OceanBase 作为 AI 基础设施的存储底座外，我们在其他的场景中，也对 OceanBase 的应用进行了探索。

场景一：可观测性。

在维护数千台服务器和 KOS 集群时，我们面临的最大挑战是系统的可观测性。传统的可观测性系统，如日志系统 Loki、Prometheus 等无时无刻都在采集各个系统的日志、指标数据，这些数据庞大繁杂其缺乏实时分析的能力，对运维人员而言是一种困扰，当遇到故障需要快速定位分析的时候，往往无法快速的检索出重要的指标数据。所以我们基于云原生标准，结合 OceanBase 的能力补齐了可观测的领域实时分析的能力。

这套系统的核心是将可观测数据经过过滤、分组、提取、转化及路由，汇聚到不同的存储系统中，对于海量偏归档类数据，我们会写入到比较廉价的存储系统中，比如对象存储。对于使用频率高以及重要巡检的可观测数据时，经过数据清洗后日志和指标数据会流入 OceanBase 以借助实时分析的能力能够更快速的定位异常。以域名类场景为例，当出现报警时，我们会面临额外的风险，比如外部攻击、爬虫等，我们需要尽快排查风险的 IP 来源，以及每一个 IP 的增长趋势。OceanBase 的实时分析能力能够帮助我们快速定位异常，增加报警解决的效率。

场景二：探索 OBKV 作为元数据引擎。

最后简单分享一下，也算是贝壳后续对 OB 的探索，这个比较简单，因为这个也是最近开始尝试，基于 OBKV 在文件系统层面的尝试，我们内部现在只是做了第一版的基于 OBKV 的元数据引擎的实践，整体从 SQL 引擎切到 OBKV 上，因为文件元数据结构相对简单，对应的表结构也比较简单，本质上并不需要 SQL 的形式，KV 的方式就能满足我们全部功能需求，并且抛开掉 SQL 解析的时间消耗，也能够提升元数据引擎的整体性能，所以我们做了一些尝试和探索。

近期我们针对该探索进行压测发现整体效果非常理想，OBKV 场景下，百万级的文件读写的响应时间提升 2~4 倍，原来的 2~10ms 变为 1ms 甚至更低，偶尔在抖动情况下也会稳定在 5ms 左右。OBKV 少一层 SQL 解析，理论性能更高。另外，由于 OceanBase 具备多模 KV 能力，支持 HBase 和 Redis 协议，且拥有丰富的工具体系，我们可以直接复用 OceanBase 的运维能力。

场景三：引入 ob-operator 提高集群快速交付能力。

在贝壳我们也在尝试引入和使用 ob-operator。因为我们团队是容器团队，有相对完善的本地盘的存储方案以及完善的容器基础设施，很多基础组件运维过程中存在着大量的数据库需求，所以通过 operator 的方式按需做集群交付可以最大程度复用我们的容器基础设施，一定程度上也能够实现 OceanBase 集群的快速交付，相对裸金属的形式更具有灵活性。