Alluxio分布式缓存架构：AI时代的去中心化数据加速层

Alluxio 是一款云原生数据加速层。随着当今计算性能已远超数据访问能力，Alluxio 旨在弥合高性能 GPU 计算与分布式云存储之间的鸿沟，解决现代 AI 基础设施面临的关键 I/O 和数据搬运挑战。

去中心化对象存储库架构 DORA（Decentralized Object Repository Architecture）通过完全去中心化的元数据和缓存设计，消除了集中式元数据管理瓶颈，在大规模多云环境中实现了亚毫秒级延迟、TB/s 吞吐量以及 97%-98% 的 GPU 利用率。

图1：DORA架构图

GPU 云环境中的性能测试结果显示，Alluxio 每台服务器可达到 10GiB/s 的传输带宽（100Gbps网卡），延迟低于 1 毫秒，且能以三分之一的成本达到 FSx 级别的性能。“无论何时，在何种云环境，Alluxio 助力将您的数据靠近计算。”

需求与挑战

在数千块GPU组成的大规模训练集群中，数据读取的峰值吞吐需求可达TB/s级别。一旦数据传输跟不上，GPU就会处于闲置状态，动辄造成上千万元的计算资源浪费。吞吐瓶颈，千万算力空转待“粮草”，文件海啸，元数据服务难承其重：多模态大模型所需的数据集往往由数十亿个文件构成，对应的元数据条目规模同样惊人。传统的分布式文件系统通常依赖集中式元数据服务，在面对如此海量文件时，极易成为性能瓶颈与系统扩展的“天花板”，甚至引发单点故障。面对这些挑战，业界亟需一套简洁、高速、可扩展的数据访问方案——让开发者能更专注于AI模型本身的研发、部署与运维，而无需反复纠结于底层数据的配置与搬运。

破局之道：呼唤“简单、快速、可扩展”的数据访问层：

为此，Alluxio 提供了一套高效的解决方案。它让研究人员和工程师能够在计算节点所在的位置，无缝访问到分布各处的数据——用户只需将云存储桶像本地文件夹一样挂载，即可享受到接近本地NVMe的访问性能，无需任何数据迁移，立即可用。

现有解决方案的不足之处

AI 生态系统中有许多数据解决方案，但没有一种能同时满足可扩展性、简洁性和云上移动性这三个维度的需求：
1、单节点 CLI 工具（如 s3fs、gcsfs）：便于在单节点上挂载对象存储，但缺乏跨集群的分布式能力、共享能力和并发处理能力。
2、HPC（高性能计算）存储系统（如 Lustre、GPFS、VastData、Weka 等）：它们性能出色，但操作和运维复杂，且较易成为成本高昂的数据孤岛，无法解决数据引力或跨云访问问题。
3、托管云缓存（如 AWS FSx for Lustre、GCP Anywhere Cache）：在性能和目标用户体验上与 Alluxio 趋同，但需要专用配置，绑定于单一云环境，且缺少轻量级纯软件部署模式。

而 Alluxio 采用的是软件定义的云原生数据加速层方案，它并非替代现有对象存储，而是对其进行补充。它能在任何位置的现有存储桶之上，提供高性能、缓存和丰富的语义支持能力。

Alluxio的定位

Alluxio 专注的三大主流工作负载：

1、大规模模型训练与部署：为分布式 AI 工作负载提供高吞吐量、基于 POSIX 标准的数据访问能力。

2、云上超低延迟特征存储/智能体记忆（Agentic Memory）：直接在云存储上对 Parquet 格式数据和 PB 级数据湖实现亚毫秒级速度访问。

3、多云数据共享与同步：跨区域和跨云环境的统一命名空间与缓存能力。

Alluxio的有所为与有所不为

定位：不做“全能选手”，只为 AI 而生：Alluxio 生来就不是一个通用文件系统，因此它不追求支持所有传统文件系统功能。它的能力清单经过精心裁剪，只保留 AI 负载最需要的关键部分。根基：数据“安家”云端，Alluxio 加速访问：Alluxio 自身并不承载数据的最终持久化使命。它默认数据已安全地存放在底层云存储中，自身则专注于在数据之上构建高速访问层。

去中心化架构概述

Alluxio 企业版采用去中心化对象存储库架构DORA。DORA 的核心目标是提供现代 AI 工作负载所需的极致可扩展性、高可用性和顶级性能。

中心化与去中心化元数据服务

2013年 Alluxio 开源项目启动时，系统遵循经典的 HDFS/GFS 主从（Master-Worker）架构，专为大数据工作负载设计。在该架构中，Master 维护全局元数据目录（包括索引节点树及其日志（编辑日志）），而 Worker 以分布式的方式存储缓存数据块。这种架构适用于 Spark、Presto、Hive 等分析框架，这些框架的工作负载通常涉及数亿个文件，且 I/O 模式以读取足够大的文件（数十至数百兆字节）为主。随着工作负载从大规模批处理分析转向 AI 训练和多模态数据处理，I/O 访问模式发生了巨大变化。AI 工作负载的 I/O 具有以下特点：

1、数十亿个小文件，例如单个样本、嵌入向量或特征分片。

2、由并行 GPU 或分布式数据加载器（data loader）驱动的高度并发且突发性的读取操作。

3、简化的访问语义，以“ open-read-checkpoint ”为主，而非复杂的 rename、update 或 append 操作。

这些访问模式的转变暴露了集中式元数据服务设计的局限性：

1、元数据集中化：单个 Master 通常维护整个索引节点树和日志。当命名空间规模超过数亿个文件时，Master 就会成为瓶颈，重启或重放数十亿日志条目可能需要数小时。

2、I/O 路径低效：每次元数据查询都需经过 Master，这种方式增加了网络的跳转和往返的延迟。在高并行 GPU 训练工作负载下，这种集中式路由层也会迅速限制吞吐量。

3、故障转移的复杂性：即使采用基于 RAFT 协议的复制日志等高可用（HA）机制，leader 选举和日志重放会导致数分钟的停机时间——这对延迟敏感的AI业务场景来说是不可接受的。

与此同时，AI 的 I/O 语义简化（跨文件一致性要求较低的读密集型工作负载）带来了新的需求：系统不再需要集中式 Master 来协调每个操作。并行性的增加与协调需求的降低，使得完全去中心化架构既必要又可行。这些发现最终促成了 Alluxio 去中心化对象存储库架构 DORA 的设计。

拥抱 AI 时代，拥抱去中心化

基于这些需求与挑战，Alluxio 进行了根本性的架构重塑：从集中式、基于 Master 编排的系统，转变为将数据和元数据都完全去中心化的无状态缓存层架构。在 Alluxio 企业版 3.0 及以上版本中，不再存在 Master。取而代之的是所有 Worker 参与一个一致性哈希环，每个 Worker 均作为其在哈希环上所分配的片段内文件的数据缓存和元数据缓存。Client 无需首先联系 Master 获取文件元数据，再从 Worker 获取数据，而是可以基于文件路径通过一致性哈希直接连接到相应的 Worker。集群协调和成员管理由轻量级服务注册中心（如 ETCD ）负责，而非 Master。

Alluxio 主要组件如下：

1、Client：嵌入应用程序或框架中。采用一致性哈希算法，基于文件路径直接定位负责的 Worker，消除集中式路由或查表。

2、Worker：基本存储和缓存单元。每个 Worker 在本地 NVMe 存储上同时存储数据和元数据，支持细粒度页缓存，并使用 RocksDB 管理持久性。Worker 独立运行，可动态加入或退出集群。

3、Service Registry：维护集群成员信息和服务发现。默认实现采用 ETCD，跟踪活跃 Worker 及其分配的数据分片。它不在 I/O 路径上，确保关键路径无额外开销。

4、Coordinator：通过轻量级无状态调度服务，管理后台分布式任务（如预取、异步加载和复制）。提供可观测性，并具备自定义任务调度的扩展性。

这些组件共同构成了去中心化的自平衡架构，消除了单点故障，同时可随数据量和计算规模变化实现线性扩展。

I/O 流程

图 1 展示了 Alluxio 中典型的 I/O 请求流程：

1、应用程序 – Worker RPC：当应用程序（如GPU服务器上的训练任务）执行文件操作（如打开或读取）时，Client会查询一致性哈希环以定位负责的 Worker；哈希函数则会确保即使有 Worker 加入或离开集群，映射关系仍保持稳定。

2、本地缓存访问：选定的 Worker 首先检查其本地 NVMe 缓存（称为页存储），查找请求的数据块或页面，而同一对象的元数据也共存于该 Worker 的 RocksDB 中，以确保持续查找，且不依赖任何外部元数据服务。

3、缓存未命中与数据获取：若缓存未命中，Worker 通过 Range GET 请求直接从底层对象存储获取数据。检索到的页在后台会异步缓存，以供后续访问，从而最大限度地减少 Client 的等待时间。

4、通过这一流程，数据会始终从哈希环上的 Worker 获取（缓存命中时从本地缓存获取，未命中时从远程存储获取）。

核心设计原则

DORA 架构体现了三大核心设计原则：

1、可扩展性：通过一致性哈希实现元数据和数据的完全去中心化，消除了全局锁和集中式所带来的瓶颈。每个Worker 可独立管理数千万个文件，支持近线性水平扩展。

2、高可用性：无单点故障（SPOF），不存在 Master 或日志等易引发单点故障的组件。通过 ETCD 进行集群协调，确保节点故障时服务持续运行。

3、极致性能：Client 与 Worker 的直接访问以及基于哈希的分片机制，使分布式 GPU 集群能够实现亚毫秒级延迟和 TB/s 级吞吐量。

缓存引擎

每个 Alluxio Worker 在 DORA 架构中扮演着基础存储和缓存引擎的角色。每个 Worker 维护唯一的 Worker ID，并持久化存储在本地磁盘上。当启动或重启时，Worker 使用该 ID 向 ETCD 重新注册，以收回其在一致性哈希环上的对应位置。根据分配的片段，Worker 负责该片段内的所有元数据和缓存数据对象。每个 Worker 管理部分本地存储容量，理想情况下使用 NVMe SSD，以实现高吞吐量和低延迟。对于其在哈希环上分片内的文件，数据和元数据均本地持久化，确保节点重启后缓存不会丢失。

细粒度缓存

Alluxio Worker 采用细粒度缓存（而非整个对象缓存）。每个缓存对象被分割为页（page），通常大小 ≤4MB。更小粒度的缓存虽可减少读放大，但也会增加管理开销；当存在强空间局部性的小规模或部分读取时（常见于读取 Parquet 等文件时，其中页脚和索引的访问频率远高于文件其余部分），更大的页可能造成空间浪费。实践证明，4MB 的页大小能在缓存效率和管理开销之间达到最佳平衡。

缓存淘汰

页也是最小的缓存淘汰单位。每个 Worker 维护 LRU（最近最少使用）队列来管理页的生命周期。当本地存储容量已满时，按照 LRU 规则淘汰冷页面，为新数据腾出空间。

文件级元数据缓存

除数据页外，每个 Worker 还会缓存文件级元数据，如大小、修改时间和权限。因此，fstat 等元数据操作可以直接从Worker 侧缓存响应，避免向任何中央服务发起 RPC 请求。

零拷贝数据传输

Client 与 Worker 之间的控制路径使用 gRPC 处理元数据和协调操作，但数据路径不使用 gRPC。对于数据读写，DORA 采用基于 Netty 的零拷贝 I/O 管道，绕过 gRPC 序列化和用户空间缓冲。这减少了上下文切换和 CPU 开销，与传统基于 RPC 的数据传输相比，吞吐量提升了 30%-50%。总之，每个 Worker 是一个独立的缓存节点，集成的能力包括：

1、基于哈希命名空间分片的可扩展性

2、基于页级缓存和元数据共存的高效性

3、持久化本地存储，确保重启后的数据持久性

4、基于零拷贝网络传输带来的出色性能

底层文件系统（UFS）：持久层

Alluxio 通过底层文件系统（UFS）抽象，与各类现有存储系统（包括云存储和本地存储）无缝集成。这些连接器使 Alluxio 能够在异构存储（如 S3、OSS、HDFS和NAS）之上，充当数据加速和统一层，而无需对现有数据或基础设施做任何修改。每个 DORA Worker 直接与其分配的UFS交互，进行数据获取和持久化。首次访问数据时，Worker 从 UFS 检索数据并缓存到本地 NVMe，以便后续高速访问，同时保持与原始数据源的命名空间一致性。

支持的存储系统

Alluxio 为所有主流云对象存储提供原生集成，包括 Amazon S3、Google Cloud 存储、Azure Blob 存储、阿里云 OSS、腾讯云 COS 等，同时支持本地存储系统，如 HDFS、MinIO、Ceph 和 NFS。通过 UFS 层，Alluxio 将暴露统一的文件和对象接口，自动适配后端语义，如最终一致性、分片上传和认证模型。这种设计使企业能够将多个后端（如跨区域S3存储桶和本地 HDFS 集群）整合到单一 Alluxio 命名空间下。

UFS 作为最终可信数据源和一致性模型

在 DORA 架构中，Alluxio 充当无状态加速层，而底层文件系统（UFS）充当持久化层——所有数据的最终可信数据源（source of truth）。Alluxio 的缓存提供高速、临时的访问，而UFS会保证数据的持久性和长期一致性。Alluxio 通过为性能关键型AI工作负载优化的验证和同步机制，维护缓存一致性：

1、Read-Through：首次访问文件时，Worker 直接从 UFS 检索数据，并将数据和元数据缓存到本地。除非 UFS 中的数据版本发生变化，后续的读取将由缓存提供。

2、写入与同步行为：根据配置，写入操作遵循 write-through 或 write-back（beta版）策略：

– Write-through：立即将更改持久化到UFS，确保完全持久性。- Write-back：批量、异步地刷新更新到UFS，以获得更高性能，适用于临时或中间结果.两种策略下，UFS始终是唯一的可信数据存储。

3、可配置的 TTL 与刷新：用户可定义生存时间（TTL）来控制缓存数据在被重新验证之前的受信任时长。较短的 TTL值可确保更强的一致性，而较长的 TTL 对于稳定或只读数据集（如模型检查点和训练数据快照）可以将性能最大化。

该模型在正确性和性能之间提供了灵活的平衡，使 Alluxio 能够安全地加速读密集型AI工作负载（数据集不变或极少更新），同时为写密集型应用程序保持一致性。简而言之，UFS 充当持久化的最终可信数据源，而 Alluxio 的缓存层通过验证、TTL 刷新和策略驱动的同步机制来保持数据的一致性。

关键要点

1、无缝集成：Alluxio 通过 UFS connector 可与所有主流云存储和本地存储系统对接。

2、持久化可信层：UFS 维护耐久、一致的数据存储，而 Alluxio 专注于数据本地性与加速。

面向用户：多协议访问

Alluxio 提供针对多种应用程序的数据访问接口，确保与各类现有工具和框架的兼容性。同时，它还提供了强大功能用于优化性能和确保高可用性。以下为主要的数据访问方式及相关特性。应用程序和用户可通过以下几种方式与 Alluxio 管理的数据交互：

1、通过 FUSE 提供的 POSIX API：将 Alluxio 挂载为本地文件系统，使任何应用程序或命令行工具（如ls、cat、cp）能够通过标准文件操作与 Alluxio 交互。这是与现有应用程序无缝集成的最常用方法，尤其适用于机器学习 /AI 训练工作负载。

2、S3 API：暴露兼容 S3 的端点，使基于 AWS S3 SDK（如 Python 的 boto3 或 Java S3 客户端）构建的应用程序能够连接 Alluxio。这非常适合已与 S3 集成的数据科学和机器学习工作负载。

3、通过 FSSpec 提供的 Python API：为使用 Pandas、PyArrow和Ray 等库的开发人员提供 Python 风格的文件系统接口（alluxiofs）。它在 Python 生态系统中提供了与 Alluxio 交互的原生高效方式。

容错

Alluxio 的设计具有高度的故障恢复能力。它具备多种机制，确保即使在以下组件不可用的情况下，I/O 操作仍能平稳继续：

网络分区

如果Client 尝试从某个 Worker 读取数据，但该 Worker 因网络问题不可用，Client 可自动降级到直接从底层文件系统读取数据。这将确保即使 Alluxio 集群无响应，应用程序的读取请求仍能成功完成，不会中断。

重启

Worker 可能因硬件升级或维护需要重启。重启后，该 Worker 会重新加载持久化的 Worker ID，并收回其在哈希环上的片段。由于元数据和数据页面均存储在本地持久化存储（NVMe + RocksDB）中，缓存数据会自动被重新发现及复用——无需冷启动重建。

硬件故障

如果某个 Worker 在配置的超时时间内仍无法访问，ETCD 会将其标记为非活跃状态。哈希环随后自动重新平衡：后续映射到该片段的请求会重新路由到相邻的 Worker 上。这些请求会从底层对象存储进行冷读取，但 Client 不会遇到可见错误或需要重试。

总结

Alluxio 已从“大数据加速层”演进为“ AI 原生数据访问平台”。通过其去中心化的 DORA 架构、页级缓存和云原生编排能力，将助力客户实现性能、可扩展性和成本效益的多重收益。借助 Alluxio：

1、数据将始终靠近计算。

2、GPU 将不再等待数据。

3、AI 工作负载可无缝运行于任何环境。

按场景

AI 机器学习

数据分析

统一命名空间

按行业

自动驾驶

AI 制药

010-82449668