Alluxio S3 写缓存介绍

对于许多客户而言，Alluxio 通常被用作云对象存储之上的分布式、兼容 S3 的读缓存，并通过穿透写语义确保数据持久性。我们曾在《 Alluxio + S3：面向低延迟、语义丰富的分层架构》一文中详细探讨过其在读密集型负载下的性能与架构设计。

现代 AI 与数据分析工作流正日益呈现出读写混合或写入密集型的特征，使得后端对象存储的性能特性，尤其是写入延迟和突发请求处理能力，成为了端到端运行时的主要制约因素。例如，在预处理大规模数据集后向 S3 对象存储写入数百万文件的工作流中，即使不考虑尾部延迟，中等并发条件下对 10KB 对象的 PUT 请求通常也达到 30-40 毫秒的延迟。在更高并发场景下， PUT 请求可能因速率限制而受限或失败。因此，任务运行时，写入时长及恢复时间往往受限于对象存储行为，而非可用计算或本地 I/O 能力。

Alluxio S3 写缓存除现有穿透写模式外，还新增了可供用户选择配置的写回（write-back）模式。这些新模式允许通过计算侧存储本地处理 PUT 请求，同时异步执行对象存储持久化操作，或在合适的场景下跳过该步骤。

以上功能的引入意义深远。借助 Alluxio S3 写缓存，小对象 PUT 延迟降至约 4-6 毫秒，提升幅度达到 5-8 倍；而大对象写入在低延迟且稳定状态下，每个 Alluxio worker 可持续保持 6GB/s 以上速度，随着 Alluxio worker 的增加，性能几乎呈线性扩展。

本文将深入阐述为什么对象存储提供的写入功能在高写入负载的情况下会暴露出根本的性能瓶颈，以及 Alluxio S3 写缓存如何通过改变写入与写后即读（read-after-write）的延迟模型在实践中突破这些限制。

真实案例：处理大规模突发性PUT请求

以一个快速增长的To C的app客户为例，用户持续将文件（如图像）上传至基于云的对象存储。在稳定状态下，系统每秒在其存储桶中处理约 10,000 个 PUT 请求，平均对象大小为 1MB。在高峰事件期间（如热门内容传播或促销活动），上传流量可在数分钟内激增 3 至 10 倍。

此场景中，如果直接使用对象存储会凸显出多项核心瓶颈问题:

1、写入延迟主导请求路径：每次文件上传都必须同步穿越网络并等待对象存储服务的确认，使得写入延迟成为端到端请求时间的关键组成部分。

2、后端速率限制引发用户应用端报错：即使平均吞吐量未超限制，峰值流量仍可能压垮存储后端，导致限流、重试、尾部延迟上升或瞬态错误。

3、为应对流量峰值而超额配置：为应对峰值流量，团队不得不按最高负载配置存储后端，造成成本上升但平时利用效率低。该架构中，客户通过轻量级的 S3 兼容网关访问对象存储，没有缓冲或流量整形机制。突发场景下，后端无法吸收并发写入的激增请求，导致用户上传出现失败。因此，客户需要在其速率受限的对象存储前端部署一个分布式写缓存，该缓存需具备以下能力：
1、在高峰时段吸收突发性上传流量，待流量回落后将数据持久化存储至对象存储；
2、支持写后即读（read-after-write）访问；
3、所有能力都需在保持兼容 S3 语义的前提下实现，且对现有数据工作流进行极少或零改动。

在对象存储前端部署透明写缓存

Alluxio S3 写缓存运行于计算侧（通常位于应用程序与 S3 协议兼容的对象存储之间），旨在降低写入和写后即读的延迟，同时保持应用程序与 S3 的交互方式不变。从应用程序的视角来看，接口完全保持不变：
1、可以继续使用 boto3 或 AWS SDK；
2、可以继续与 S3 协议兼容的服务端进行交互。

无需新增 API、无客户端逻辑，应用层也无需感知缓存或持久化行为。启用 Alluxio S3 写缓存后：

1、PUT 请求由 Alluxio worker 处理并存储于本地 NVMe；

2、数据可跨 workers 复制以增强可靠性（可选）；

3、突发性的高并发写入由 Alluxio 分布式缓存层吸收；

4、数据以可控、可持续的速率异步持久化至对象存储；

5、持久化后自动回收缓存空间以为新的数据写入腾出容量。

在保持完全兼容 S3 协议的同时，这本质上是将前端写入性能与后端对象存储限制进行了解耦。

图1：Alluxio S3 写缓存改变了写入和写后即读的延迟模型。应用程序可继续使用标准的 S3 API。
PUT 请求在由本地 NVMe 承载的 Alluxio worker 上完成，数据可立即读取，向对象存储的持久化操作则在后台异步进行。

这实现了：

1、达到集群本地存储速度的低延迟写入：写入请求首先存储在 Alluxio worker 所在的 NVMe 上。突发的高并发写入可被吸收，不会压垮后端存储。

2、快速、可预测的写后即读：写缓存的数据可被立即读取。写后读取行为类似本地存储而非远程对象存储，这对 checkpoint 和多阶段工作流至关重要。

3、S3 作为异步持久化系统：对象存储仍是持久化后端。但通过异步写回机制，写入性能与持久化实现解耦，在实现高速写入的同时提供了最终一致性保障。

4、基于径配置的精准加速：写入加速仅作用于关键场景。不同数据类型（checkpoint、临时数据、归档数据）可遵循差异化的写入方式与生命周期语义。

基准测试

为了解 Alluxio S3 写缓存如何改变写入及写后即读的行为，我们使用 Warp 运行了一组基准测试，将 Alluxio S3 写缓存与写入 AWS S3 进行对比。

测试场景：

1、工作负载：对小对象（10 KB）执行 PUT/GET 操作；

2、基准：AWS S3；

3、Alluxio 配置：启用写缓存，单副本；

4、场景：

1 台 Alluxio Worker 节点：i3en.metal
1 台 Warp 客户端：c5n.metal

所有测试均在同一 AWS 区域内运行，以最大限度减少跨区域的影响。

测试 1：PUT延迟（10KB ）

结论：在多数并发级别下，Alluxio 的 PUT 始终保持在个位数的毫秒延迟，而 S3 的延迟则维持在数十毫秒，且随并发上升明显恶化。

图2：并发场景下小对象PUT延迟降低7-8倍

此测试考察了当并发数从 1 增加到 256 时，10KB 对象的 PUT 延迟变化情况。请注意，并发数代表 Warp 客户端发出的未完成 PUT/GET 请求数量。

1、使用 Direct S3 时，低并发下 PUT 延迟维持在 30-35 毫秒，高并发下急剧上升，256 个并发写入时超过 70 毫秒。

2、使用 Alluxio S3 写缓存时，低至中等并发下 PUT 延迟保持在 4-6 毫秒区间，延迟仅在极高并发时才逐渐增加。

关键意义：

对于以小对象写入为主的工作负载（如元数据更新、 checkpoint 或任务输出），这不仅意味着峰值吞吐量会提升，更体现为更短的作业运行时长和更快的恢复速度。关键差异不仅在于平均延迟的降低，更在于并发场景下延迟的可预测性显著增强。

测试 2：写后即读的延迟（10KB）

要点：写后即读的操作从对象存储操作转变为贴近计算的存储操作。

图3：并发场景下，写后即读的速度提升了10倍

本测试考察了对相同 10KB 对象进行写入（PUT）操作后立即进行读取（GET）的延迟。

1、使用 S3 时，读取延迟维持在 ~25–50 毫秒之间，这反映了对象存储的访问语义特性。在本次测试中，由于后端的预热效应，S3 在高并发下读取延迟略有改善。测试通过反复读取相同对象，使 S3 能够对热数据采用内部优化。此行为符合预期，且不影响 S3 与 Alluxio 之间的相对延迟差距。
2、采用 Alluxio 时，低并发场景下写后即读的延迟仅为 1-2 毫秒，即使随着并发量增加，延迟仍能稳定控制在 10 毫秒以下。

关键意义：

对于依赖即时数据的工作流（如训练 checkpoint 或多阶段 ETL），写后即读的延迟往往会成为影响端到端执行时间的主要因素。Alluxio 则彻底消除了这种对对象存储的依赖。

测试 3：通过采用多worker来扩展写入和写后即读的吞吐量

要点：总写入和写后即读的吞吐量可随着 Alluxio worker 数量线性扩展，这意味着可通过扩展计算层而非对象存储来提升容量。

除单节点外，我们还评估了集群中部署更多 Alluxio worker 的吞吐量（针对 10KB 对象 PUT 和 GET 操作的 IOPS）变化。本测试通过增加客户端并发数，对比单 worker 集群与 3 个 worker 所在集群的性能表现。

该图展示了随着客户端并发数增加，写入吞吐量（PUT 10 KB）和写后即读吞吐量（以 IOPS 为单位）的变化趋势

对于写入和写后即读两种工作负载，在相同并发条件下， 3 个 worker 始终能提供约 3 倍于单个 worker 的总吞吐量。吞吐量随着 worker 数量呈线性增长，直至受限于客户端并发能力或后台持久化存储的容量。至关重要的是，由于写入操作由 Alluxio 层吸收并暂存，这种扩展的实现避免了将额外的突发负载直接推送到对象存储。

关键意义：

对于写入密集型和易突发的工作负载，通过增加 Alluxio worker 来扩展写入能力。该方式可将瓶颈从存储后端转移至计算层，从而使得系统能够处理更高写入速率和并发访问模式，同时避免触发对象存储限流或尾部延迟放大。

基准测试结果摘要

1、小对象 PUT 延迟从 ~30-40 毫秒（标准 S3 PUT）降至 ~4-6 毫秒（使用 Alluxio）；

2、写后即读的延迟从对象存储级缩短至本地存储级（单毫秒量级）；

3、Alluxio 在并发场景下显著增强了延迟衰减曲线的平滑性；

4、通过增加 worker 实现吞吐量的水平扩展，从而避免存储后端过载。

综合来看，这些测试结果表明 Alluxio S3 写缓存主要优化了高写入负载场景的延迟模型与可预测性，而非单纯追求峰值带宽。

最终结论

Alluxio 写缓存与直接写 S3 对比

👋 欢迎获取 Demo 演示 👋

当您的工作负载具备以下特征时，Alluxio 写缓存将发挥卓越效能：

1、对写入或先写后读的延迟敏感；

2、高并发且突发性强的写入操作；

3、本地 NVMe 存储可用，但相较于整个数据集容量有限；

4、S3 或其他对象存储作为持久化数据源；

您已准备好消除管道中的 S3 写入瓶颈了吗？了解更多信息及功能使用方式，请联系小助手获取 Demo 演示。

快速计算丨在混合云上使用Alluxio可为您节省的基础设施投入成本

按场景

AI 机器学习

数据分析

统一命名空间

按行业

自动驾驶

AI 制药

010-82449668