JuiceFS Blog

浅析 Amazon S3 Files：工作机制、性能边界与 JuiceFS 对比

Tue, 14 Apr 2026 08:29:00 +0000

4 月 7 日，AWS 官方发布了一项新服务——Amazon S3 Files，允许用户无需搬迁数据，即可将 S3 存储桶作为高性能共享文件系统挂载到计算节点上。

这不是业界第一次尝试让 S3 以文件系统方式被访问：从早期的 s3fs，到 AWS 后来推出的 Mountpoint for Amazon S3，再到今天的 S3 Files，S3 “像文件系统一样被访问”这条路，其实已经走了很多年。区别在于，前两者更多是在访问层做文章，而这一次，AWS 终于把共享访问、文件系统语义和托管高性能层真正捏成了一个原生方案。

这也让 S3 Files 成为一个值得单独分析的新选项。对于希望以文件方式访问现有 S3 数据的业务来说，它提供了原生、轻量的方案；但放到 AI 模型训练、大数据分析等更复杂的场景中，它的实际表现究竟如何，仍需要结合其底层实现与运行机制来看。

本文将围绕 S3 Files 的底层实现、性能边界以及与 JuiceFS 的差异展开分析。

01 S3 Files ：以 EFS 为高性能层的 S3 原生文件系统方案

从底层实现看，S3 Files 使用 Amazon EFS（Elastic File System）作为托管的高性能存储层，用来承接需要低延迟访问的数据和相关元数据，并在此基础上为 S3 提供完整的文件系统语义，包括一致性、文件锁和 POSIX 权限。

可以把它理解为：AWS 在对象存储之上增加了一层基于 EFS 的文件系统访问面，使原本只能通过对象接口访问的数据，也能以目录、文件和挂载点的形式被计算节点直接使用；而文件系统与 S3 之间的数据变化，则由服务在后台自动同步。

基于这种架构，S3 Files 并不会搬迁全量数据，而是只将当前工作集中的一部分数据按需放到高性能层中；而数据的“Source of Truth”依然保留在 S3 中。

02 S3 Files 如何工作：挂载、导入与同步机制

对 S3 Files 来说，挂载只是开始，真正影响体验的是挂载之后的数据路径：作用域如何确定，首次访问会导入什么，哪些请求会进入高性能层，写入后又会如何同步回 S3。这些机制，也直接决定了后文要讨论的性能边界与成本结构。

image: S3 Files 挂载架构
caption: S3 Files 挂载架构示意图

以 EC2 挂载现有 S3 bucket 为例，真正需要看清的不是挂载命令本身，而是挂载之后数据会如何被导入、访问与同步。下面是几个关键的技术细节与步骤。

a) 先确定作用域：导入全量 S3 桶，还是指定部分目录

两者皆可。 S3 Files 支持将整个 S3 存储桶作为文件系统挂载，也支持通过 Prefix（前缀）限制作用域，

例如只挂载 s3://my-bucket/data/ml/ 目录下。对于包含数千万个对象的庞大 S3 桶尤为重要，因为过大的作用域会增加元数据同步的负担。

在计算节点上使用 S3 Files 时，AWS 提供了定制的挂载客户端 amazon-efs-utils。挂载时使用的并不是存储桶名称，而是 AWS 为 S3 Files 分配的 file system ID。

创建一个本地挂载目录，并使用专用的 s3files 文件系统类型进行挂载：

sudo yum -y install amazon-efs-utils
sudo mkdir /mnt/s3files
sudo mount -t s3files fs-1234567890abcdef0:/ /mnt/s3files

如果只希望访问某个子目录，也可以在挂载路径中进一步指定。但从实践上看，更推荐在创建 S3 Files 时就把作用域限定到明确的 prefix，而不是在一个过大的存储桶上再做后置控制。

b) 首次访问时会发生什么：导入触发方式与大小阈值

S3 Files 并不会在挂载后立即把整个数据集搬入高性能层。它的数据导入由访问事件触发，默认模式是 ON_DIRECTORY_FIRST_ACCESS：当你第一次访问某个目录时，系统会导入该目录下文件的元数据，并将符合条件的小文件数据异步导入 EFS 高性能层。

如果配置为 ON_FILE_ACCESS，则首次遍历目录时只导入元数据，只有在文件第一次被实际读取时，数据才会进入高性能层。这种方式更节省空间和导入成本，但首读延迟也会更高。

这里最关键的控制参数是 sizeLessThan。默认情况下，只有小于 128 KB 的文件才会在导入时进入高性能层；更大的文件通常只导入元数据，内容仍然主要通过 S3 获取。换句话说，S3 Files 优先优化的是小文件和低延迟访问，而不是把所有数据都预热到高性能层中。对于 AI 训练这类以 10 MB 级图片、音视频文件为主的数据集来说，这一点尤其关键：即使完成了目录遍历，这些大文件在默认配置下也未必会真正进入高性能层。

c) 同步周期与冲突解决机制

S3 Files 会在后台自动维护文件系统与 S3 之间的双向同步。S3 侧发生变化后，文件系统视图会随之更新；而在计算节点上的写入，则会先落到 EFS 高性能层，再由后台批量同步回 S3。默认情况下，系统会对修改进行一段时间的聚合，再执行回写。

冲突处理的原则也很明确：S3 始终是 Source of Truth。 如果文件系统侧的修改尚未同步回 S3，而对应对象已经在 S3 中被其他应用更新，系统会以 S3 中的最新版本为准，并将冲突文件移入 .s3files-lost+found-* 目录。

03 S3 Files 的性能边界与成本结构

上一节解释的是 S3 Files 如何运行，这一节进一步讨论的，则是这种运行方式会带来怎样的性能边界与成本结构。高性能层占用、大文件读取路径、写入流转，以及局部更新和目录操作带来的放大效应，是实际选型中最需要重点考量的四个方面。

a) EFS 高性能层的占用、回收与成本

S3 Files 的高性能层并不是按容量上限做 LRU 淘汰，而是按访问时间进行生命周期管理。 默认情况下，已同步到 S3 且 30 天未被读取的数据会从 EFS 高性能层中移除；这一时间由 daysAfterLastAccess 控制，可配置范围为 1–365 天。

这意味着，它的成本取决于有多少数据需要驻留在 EFS 中，以及驻留多久。 如果工作集很大且长期保持活跃，相关费用就会持续上升。

b) 大文件直读与随机读：其实是客户端在“穿透”读取

S3 Files 对大文件的处理，并不是把所有读取都留在 EFS 高性能层中完成。默认情况下，sizeLessThan 的值为 128 KB，它决定的是哪些文件会在导入时把数据放入高性能层；而对于已经同步到 S3 的数据，128 KB 及以上的读取会直接从 S3 流式返回。

image: S3 Files 基于 128 KB 阈值的数据路由机制
caption: S3 Files 基于 128 KB 阈值的数据路由机制

也就是说，S3 Files 的优化重点更偏向小文件和低延迟访问，而不是让大文件读取长期稳定命中高性能层。

这条直读路径依赖于计算资源本身具备读取源存储桶的权限。AWS 官方文档明确要求相关角色拥有 s3:GetObject 和 s3:GetObjectVersion 等权限；否则，客户端就无法直接从 S3 读取数据。

c) 顺序写的代价：大规模写入会引入额外流转成本

S3 Files 的写路径并不是直接落到 S3。所有写操作都会先进入 EFS 高性能层，再由后台同步回 S3。

这意味着，如果你的场景会持续产生大量结果数据，例如顺序写入数百 TB 的训练产物或分析结果，那么这些数据在流经 S3 Files 时，会额外引入两类成本：

数据流转成本：写入先进入高性能层，随后再同步回 S3。相比直接写入 S3，这条路径会多出一层中间流转开销。
短期驻留成本：数据同步完成后，并不会立刻从高性能层中移除，而是要等到满足过期条件后才会清理。默认情况下，这意味着大批量写入产生的临时数据，可能在一段时间内持续占用 EFS 容量。

以某一区域当前价格为例，写入 EFS 约为 $0.06/GB，后台同步回 S3 的读取约为 $0.03/GB，仅数据流转这一层，每 1 TB 写入就大约会多出 $90 的附加成本。如果这些数据在同步完成后仍然继续驻留在 EFS 中，还会进一步产生对应的高性能层存储费用。

这也是为什么，S3 Files 更适合读取现有数据，而不适合长期承接大规模、持续性的结果写入。

d) 局部更新与目录操作：对象模型带来的放大效应

S3 Files 底层不对数据进行切块，而是尽量保持文件与 S3 对象之间的直接映射。这带来的代价是：一旦涉及大文件的局部随机写或追加写，应用层看起来只是一次很小的更新，底层同步回 S3 时却更容易放大为显著的对象写入与版本开销。

例如，用户通过 S3 Files 在一个 100 GB 的 lmdb 文件中追加了一条 100 KB 的图片 key，应用侧看到的只是一次很小的写入；但这类修改并不会立刻回写到 S3，而是会在大约 60 秒内先做聚合，再同步回存储桶。它不会像块存储那样只改动一个离散块，而更可能放大为对象写入、同步时延和版本存储成本。 文件越大、修改越频繁，这种代价就越值得警惕。

目录重命名同样受 S3 扁平命名空间限制。S3 本身没有传统文件系统中的目录元数据，因此执行 rename 或 mv 时，S3 Files 不能只改一条元数据，而是必须在 S3 侧为目录中的每个文件写入新对象并删除旧对象。对于拥有千万级对象的目录，这会显著拉长同步时间，并增加 S3 请求成本；在同步完成前，文件系统视图与 S3 视图之间还可能暂时不完全一致。

总体来看，S3 Files 的优势在于原生接入、零数据迁移，以及对现有 S3 资产的良好兼容。它的代价则在于：一旦场景转向大文件读取、持续写入、频繁局部更新或大目录操作，性能和成本都会更快被放大。也正因为如此，S3 Files 的优势更适合发挥在轻量共享访问场景中；而在训练、数据生产和大规模分析等重负载场景下，它的代价往往会更早暴露出来。

04 JuiceFS vs S3 Files：两种不同的架构思路

前一节已经看到，S3 Files 的很多边界并非偶然，而是这类方案的共性结果。无论是早期的 s3fs、主打高吞吐读取的 Mountpoint for Amazon S3，还是今天的 S3 Files，它们都尽量保持文件与 S3 对象之间的直接映射，以换取对现有 S3 数据的透明访问能力。

这条路线的优势是透明和低改造，代价则是先天受制于 S3 的对象模型。 这也是为什么目录操作更容易退化为对象级请求，大文件的局部更新也更容易演化为写放大、同步延迟和额外成本。

也正因为如此，JuiceFS 与这类方案的差异，并不是某个功能点或单项指标的差别，而是两条架构路线的根本区别。JuiceFS 不是“把 S3 挂出来用”的访问层，而是构建在对象存储之上的云原生分布式文件系统。 它采用数据与元数据解耦的架构：文件数据存放在底层对象存储中，元数据则由高性能键值数据库独立管理，因此更适合承接训练、分析和数据生产等更重的生产型负载。

image: 1JuiceFS 架构图.drawio
caption: JuiceFS 社区版架构图

为了让大家能更直观地进行架构选型，我们从底层架构到高阶特性，将 JuiceFS 与 S3 Files 进行了全方位对比：

对比维度	JuiceFS	Amazon S3 Files
整体架构	数据与元数据分离，文件切块后写入对象存储	基于 EFS 代理，数据不切块，1:1 动态根据设置的文件大小来映射对象（默认<128KB）
核心成本	软件开源免费，主要成本来自对象存储、元数据引擎和缓存资源	除 S3 存储外，需额外支付 EFS 存储费($0.30/GB)及数据读写 Sync 费
读写放大(随机写)	部分场景极低。数据切块后，局部随机写通常只更新受影响的数据块，无需重写全量数据	数据生产场景会很高，大文件随机修改会导致整个对象的重传重写
冷热分层策略	基于容量与访问热度，将热数据自动预热至计算节点的本地盘/内存缓存中	基于文件大小与访问时间。小文件(<128K)热数据缓存在 EFS，大文件绕过 EFS 直接读写 S3
小文件性能	依赖全内存的独立元数据引擎(Redis/TiKV 等)，更适合大量小文件与元数据操作	依赖 EFS 性能与 NFS 协议
大文件吞吐	可结合本地 NVMe / 内存缓存提升吞吐	依赖 EFS 网关或 S3 直连性能，大规模并行吞吐与容量配额绑定
缓存一致性	强一致性 (Close-to-open)。由独立元数据服务统一仲裁	NFS Close-to-open。但遇到底层 S3 和文件系统并发修改冲突时，本地 EFS 数据会被丢弃至 lost+found，S3 强行作为 Truth
POSIX 兼容性	几乎 100% 兼容。支持 Hard Links、原子级 Rename、各类锁语义	支持 NFSv4.1/4.2 子集。不支持硬链接(Hard links)、不支持原子重命名
权限管理	支持标准 POSIX 权限、ACL、Extended ACL 等多种鉴权	支持标准 POSIX 权限、ACL、Extended ACL 等多种鉴权
加密与安全	传输加密、静态加密、并提供国密支持	传输级 TLS 加密、静态 SSE-KMS 密钥加密
AI 场景优化	深度优化了 LMDB、Safetensors 等 AI 常见格式的 mmap 读取与本地预热机制	无专门针对 AI 格式的底层优化，依赖基础文件流式读取

05 小结

没有绝对完美的银弹，只有最适合特定场景的方案。

S3 Files 的面世，填补了 AWS 官方生态中“无缝、免搬迁将 S3 原生转换为文件系统”的空白。它的设计非常明显：S3 对象生态的 100% 格式透明，并针对性优化 AI 场景的小文件（<128KB）的读写性能。

什么时候选择 S3 Files？

如果核心诉求是在不改动现有架构的前提下，让旧应用、Shell 脚本或传统软件直接以文件方式访问现有 S3 数据；或者需要一个通用的共享文件空间，且以只读、小文件、顺序读写为主，那么 S3 Files 会是更自然的选择。它的原生托管、即插即用和零数据迁移能力，可以显著降低接入门槛（但是为了这个便利性可能需要付出高昂的 EFS 存储和同步成本来交换）。

什么时候选择 JuiceFS？

如果业务面向 AI 模型训练、数据生产、高性能计算（HPC）或大数据分析，面临千万级小文件、TB 级大文件随机读写，或对 mmap、缓存命中率和整体吞吐有更高要求，那么 JuiceFS 会更适合。相比 S3 Files，JuiceFS 的数据切块、独立元数据引擎和更灵活的缓存体系，更适合承接重负载和长期运行的生产型和 AI 训推文件系统场景。

一文解锁 JuiceFS 在 AI 场景中的性能优化

Fri, 03 Apr 2026 02:50:00 +0000

大模型训练的算力规模持续扩张，GPU 算力不断提升的同时，数据访问瓶颈对系统整体性能的影响愈发突出。本地存储性能优异但扩展性有限，对象存储在成本与扩展性上具备优势，却在海量小文件、高并发场景下面临吞吐不足的问题，团队往往需要在二者之间艰难取舍。

为此，分布式文件系统成为平衡高性能与可扩展性的关键方案。JuiceFS 已在多行业 AI 场景中广泛落地，其分布式架构能够在大规模数据访问场景下，同时兼顾高性能、强扩展与低成本。本文将从性能角度介绍 JuiceFS 的架构设计，分析不同访问模式下的核心性能瓶颈与优化方法。文中关键知识点均附对应详情链接，为用户理解 JuiceFS 性能机理、掌握常见调优方向提供参考。

image: JuiceFS 在 AI 场景中的应用
caption: JuiceFS 在 AI 场景中的应用

01 从架构看 JuiceFS 的性能基础

JuiceFS 分为社区版与企业版，二者整体架构一致，均采用元数据与数据分离的存储架构。客户端采用富客户端设计，承载包括部分元数据处理在内的多项核心逻辑，并同时提供元数据缓存与数据缓存能力，各模块协同工作以实现数据的高效定位与访问。底层数据存储基于对象存储构建，并可借助本地缓存进一步提升访问性能。对外接口上，JuiceFS 支持多种接入方式，其中 FUSE 最为常用，同时也兼容各类 SDK 与 S3 网关。

社区版定位为通用文件系统，用户可根据需求选择不同的元数据引擎。小规模部署可选择 Redis，实现轻量、高响应的数据管理；大规模文件场景可选择 TiKV，以获得良好的横向扩展能力。（参考：JuiceFS 元数据引擎选型指南）

企业版面向复杂高性能场景，相较于社区版，最大的差异有两方面：企业版采用自研多分区元数据引擎，基于 Raft 构建纯内存集群，延迟低且横向扩展能力强，可支持 5,000 亿文件规模。相比社区版需多次 KV 请求完成的操作，企业版通常仅需一次或两次，并可在元数据集群内部处理复杂逻辑。其次，企业版支持分布式缓存共享：同组客户端可在同一区域内互访本地缓存，基于一致性哈希实现，提高缓存命中率和访问效率。在多节点高并发场景下，缓存空间可横向扩展，任务执行前可预热大部分所需数据，从而加速 AI 训练与推理，提高系统性能和稳定性。（JuiceFS 企业版 5.3 特性详解：单文件系统支持超 5,000 亿文件，首次引入 RDMA）

image: JuiceFS 社区版和企业版架构
caption: JuiceFS 社区版和企业版架构

数据分块设计

JuiceFS 将数据切块后存储于对象存储，这一设计是其提升性能的关键，将影响数据读取效率、缓存命中率及高并发访问下的吞吐能力。

JuiceFS 会将文件拆分为多个 chunk。在每个 chunk 内部，系统维护管理结构 slice，用于跟踪数据写入和更新。当文件发生写入时，新数据不会覆盖已有 slice，而是以新的 slice 追加到 chunk 上层。

image: chunk
caption

理想情况下，每个 chunk 最终只应包含一个 slice。每个 slice 由若干 4 MB 的 block 组成，这些 block 是最终存储到对象存储的最小单元。默认情况下，缓存系统也以 block 为单位进行管理。

image: block
caption

从右上方示意图可以看出，文件更新采用追加式写入：红色部分为已有 slice，新数据以新的 slice 叠加。读取时，系统组合各层 slice 形成当前视图；碎片过多时，再通过 compaction 合并，以优化访问性能。更多关于数据分块的细节可参考文档。

缓存体系

相较于直接访问对象存储，JuiceFS 的性能提升在很大程度上得益于其缓存体系。JuiceFS 客户端配备了高性能的本地缓存模块，与之相关的配置项如下：

cache-dir：用于指定缓存目录；
cache-size：用于设定用于缓存的空间大小；
prefetch：这是缓存模块中的一个参数，负责预取功能。当某一请求命中某个 block 时，会启动一个后台线程，将整个块完整拉取下来；
write back 相关配置：用于提高写 IOPS，将需要上传至对象存储的数据块，先写入本地缓存，再异步上传至对象存储。

企业版还具备一些进阶配置，例如通过 cache group 指定一批客户端，将它们的本地缓存配置为同一个分布式缓存组，实现缓存数据的共享。此外，no sharing 是与缓存组相关的配置，启用 no sharing 后，客户端仅从指定的缓存组读取数据，但不作为缓存组成员提供数据读取服务。如此一来，便形成了两级缓存：第一级是本地缓存，第二级是缓存组中其他节点上的缓存。

另一个提升性能的机制是内存 buffer（读 buffer），具有以下作用：

合并 IO 请求：可内存层面合并多个连续的 IO 请求。例如，系统发出三个 IO 请求，经内存缓存处理后，实际发出的可能仅有一个；
自适应预读功能：在大文件顺序读取场景下，自适应预读功能通过预读来提升请求并发度，从而充分利用缓存和对象存储资源，提高整体 I/O 性能。

企业版还有一些进阶配置：

max read ahead：用于设定预读的最大范围。
initial read ahead：用于设置开启预读时的预读窗口大小，默认以 4MB 块为单位。
read ahead ratio：是去年新增的配置，用于控制大文件随机读取时的预读比例，减少读放大导致的带宽瓶颈。过于激进的预读可能对随机读取性能产生负面影响，read ahead ratio 可用于缓解该问题。在 AI 场景中，遇到大文件顺序或随机访问导致的带宽或 IOPS 瓶颈时，可通过调整这些参数优化整体性能。

02 JuiceFS 基准 I/O 测试与瓶颈分析

在介绍 JuiceFS 在常见 AI 场景下的性能调优之前，先通过连续读和随机读基准测试观察系统在理想条件下的 I/O 表现，以理解不同访问模式下的吞吐量与延迟，为后续 AI/ML 场景的读写模式提供参考。

连续读性能

在 JuiceFS 中，连续读的性能通常主要受带宽因素影响。在冷读场景下，性能主要受对象存储带宽约束；而在分布式缓存场景下，网络带宽可能成为瓶颈。例如，一台配备 40 Gbps 网卡的机器，其实际可用带宽可能不足 5 Gbps。此外，FUSE 层的用户态与内核态转换开销也会限制单线程吞吐，经测试单线程读取文件的带宽约为 3.5 Gbps。要突破此限制，需要采用多线程或多并发策略以充分利用存储与网络资源。

threads	bw(GB/s)	bw/threads
1	3.5	3.5
2	6.3	3.15
3	9.5	3.16
4	9.7	2.43
6	14.0	2.33
8	17.0	2.13
10	18.6	1.9
15	21	1.4

在性能测试中，单线程连续读带宽约为 3.5 Gbps，随着线程数增加，整体吞吐量可逐渐接近网络带宽上限。为了方便评估自身环境的性能上限，JuiceFS 提供了 bj bench 子命令，可用于测试对象存储带宽。

在实际业务中，缓存往往比直接访问对象存储更常见。此时，可通过增大 buffer size 提高后台预读请求数，从而提升并发度并改善整体吞吐。例如，将 buffer size 调整至 400 MB（对应 100 个 4 MB 块的后台预读请求）后，并发度显著提升，整体吞吐量随之增强。

随机读性能

低并发随机读

在低并发且非异步访问场景下，每个请求需等待前一个完成后才能发出，因此延迟对整体性能的影响尤为显著。I/O 延迟可能来源于多方面，包括元数据查询延迟、对象存储访问延迟，以及本地缓存或分布式缓存读取延迟。在分析随机读性能时，需要重点关注这些延迟因素。

在 4 KB 随机冷读场景下，若 IOPS 仅为 8，且对象存储延迟约 125 毫秒，则可计算出系统并发度约为 1（8 IOPS × 125 ms ≈ 1000 ms）。

这表明当前处于近似单并发、请求串行阻塞的状态。在这种情况下，优化重点通常不在于进一步提升并发，而在于缩短访问路径、降低单次请求延迟，例如将数据预热至本地缓存。完成预热后，随机读路径可由对象存储切换至本地缓存，IOPS 可提升至约 12,000，接近本地磁盘的 I/O 水平。

image: juicefs stats 命令查看性能
caption: juicefs stats 命令查看性能

image: 预热后性能
caption: 预热后性能

高并发随机读

高并发随机读通常发生在并发数较高或采用异步 I/O 的场景下，其性能瓶颈主要体现在 IOPS 限制上。IOPS 包括元数据 IOPS、对象存储 IOPS 以及缓存 IOPS。通过 JuiceFS，可以观察这些指标，从而确定性能瓶颈所在。此外，客户端机器的资源（如 CPU 和内存）也可能对性能产生影响，但这类瓶颈相对容易监测。

在冷读场景下，以通过 Libaio 发起的随机读为例，对象存储侧的 IOPS 上限接近 7,000/s。若启用缓存并完成数据预热，访问路径将由对象存储切换至缓存层，IOPS 可进一步提升至 20,000 以上，说明高并发随机读的瓶颈会随访问路径变化而发生转移。

image: 预热前
caption: 预热前

image: 预热后
caption: 预热后

有兴趣深入了解 JuiceFS 的完整数据访问链路，请参考博客：一文详解 JuiceFS 读性能——预读、预取、缓存、FUSE 和对象存储。

03 常见 AI 场景下的 I/O 特性与性能调优

大文件顺序读场景

大文件顺序读取的典型应用场景之一是模型加载，例如通过 Pickle 序列化保存的 PT 文件。在此过程中，性能受到两方面限制：一方面，Pickle 的反序列化效率决定了数据处理速度；另一方面，数据读取通常为单线程，受 FUSE 带宽上限和 CPU 性能约束。为提升吞吐量，可通过增加并发度实现多线程或分片加载，从而充分利用 I/O 能力。在大文件顺序读取的场景下，若能够将数据集完全缓存至本地，可获得最佳性能；若仅需按需读取数据，则实现相对简单。

关于大文件顺序读场景性能优化，可参考如何构建 70GB/s 吞吐的缓存池

海量小文件场景

在计算机视觉和多模态任务中，训练数据集通常由大量单独文件组成，例如单张图片、视频帧或文本标注文件。这类海量小文件场景对元数据服务的压力较大。

海量小文件场景下，元数据性能影响显著。一方面，每个文件的数据量较小；另一方面，存放大量小文件的目录元数据访问效率较低。对于只读负载，可通过开启客户端元数据缓存并延长缓存周期来提升性能。此外，数据读取层的 IOPS 压力也更大，因为小文件无法充分利用预读机制，导致请求更加碎片化。常用的优化措施包括增加本地缓存容量，对于商业版本可进一步采用横向扩展的分布式缓存集群。由于小文件难以受益于预读机制，其延迟表现也相对较高。

该场景性能优化可参考：海量小文件 + 多云协同：地瓜机器人 JuiceFS 存储优化之路

大文件随机读场景

此类场景在 AI 训练中较为常见，例如按样本随机访问 TFRecord、HDF5 或 LMDB 格式的数据集等。以模型加载为例，若数据集格式为随机读且每次读取的大小为数据集样本大小（如 1MB 至 4MB 的图片或短视频），则预读机制可能导致带宽浪费。此类场景通常可通过多并发加载来突破 IOPS 瓶颈，可采取以下措施：

增加数据加载的 reader 线程数。
使用异步 IO 提高并发度，尽量打满 IOPS。
完善缓存体系，如提前将数据映射至缓存以提高底层 IOPS 性能。
调整 read ahead ratio 参数（如设为 0.5），以降低预读带来的带宽浪费。例如，原本 4MB 的顺序读会预读 4MB 数据，调整后仅预读 2MB 数据。

本文从性能角度分析了 JuiceFS 的架构设计、基准 I/O 测试以及在典型 AI 场景下的调优方法，为读者提供关于系统性能的入门参考。JuiceFS 已在大量生产环境中得到应用，其分布式架构在性能与成本之间提供了可行的平衡方案。

欢迎在评论区分享或讨论实际使用中的经验与策略。

ARM 架构 JuiceFS 性能优化：基于 MLPerf 的实践与调优

Fri, 27 Mar 2026 07:05:00 +0000

随着国产芯片与 ARM 生态的快速发展，如何在 ARM 平台上构建高性能存储基础设施成为技术焦点。Linaro 是一个专注于 Arm 生态和开源软件的国际化技术组织，联合产业链上下游厂商解决共性问题，并协助企业客户在开源基础上完成产品化落地。Linaro 团队在 MLPerf Storage 测试中，对 JuiceFS 社区版（元数据采用 Redis）进行了系统压测，覆盖多种典型机器学习训练负载。

测试结果显示，系统性能在很大程度上受内存带宽和元数据访问效率影响，JuiceFS 的吞吐能力直接决定 GPU 利用率及训练效率。通过 UNet3D、ResNet-50 和 CosmoFlow 等负载的测试，分析发现：单机场景下，GPU 利用率主要受内存拷贝延迟限制；在双机或多机场景下，元数据访问和节点间同步成为主要瓶颈。文章同时提供了针对这些瓶颈的调优思路与实践结果。

总体来看，大规模 AI 训练性能调优是一个系统工程，需要从存储系统、内存带宽、CPU 调度、缓存策略等多方面协同优化，才能在 ARM 平台上实现高效的深度学习训练数据供给。

01 Arm64 与 x86_64 架构差异与并发特性概述

相比 x86，Arm 的应用范围不断扩大，已从移动端延伸至 IoT、可穿戴设备、PC、汽车和服务器，其高能效比（performance per watt）是广泛采用的关键原因。

从架构设计上看，Arm 属于 RISC（Reduced Instruction Set Computer，精简指令集计算机），x86 属于 CISC（Complex Instruction Set Computer，复杂指令集计算机）。这种设计差异也影响了处理器的执行方式。Arm64 的指令长度固定为 4 字节，而 x86 指令长度可变，大约在 1–15 字节之间，因此 x86 往往需要更复杂的译码器。相比之下，Arm 的指令更简洁，也更依赖编译器和代码生成阶段对指令的有效组织，所以需要更长的编译时间。

从工程师可感知的角度来看，还有一些架构差异会直接影响程序行为。很多在 x86 上看起来符合直觉的代码，在 Arm 上未必如此，后面要讲到的几个容易踩坑的点，基本都与这些底层差异有关。

其中一个典型问题是原子操作对地址对齐有要求。无论是 LL/SC（Load-Link/Store-Conditional），还是 LSE（Large System Extensions），在执行原子加减等读改写操作时，通常都要求访问地址满足对齐条件。较新的 LSE2 对这一限制有所放宽，开始支持 16-byte window 内的非对齐访问。数据对齐对于 x86 来说不是必须的，但保持良好对齐有助于提升性能。参考文档: Arm Architecture Reference Manual for A-profile architecture

另一个需要重点关注的特点是，Arm 采用的是弱内存序模型（weakly ordered / relaxed memory model），差别体现在对内存访问顺序的约束强弱不同。在多线程场景下，同样的读写操作，在 x86 上通常更容易表现为接近程序书写顺序，而在 Arm 上则允许更多重排序，因此其他线程观察到的读写顺序可能与源码顺序不一致。在 Arm 上出现的异常需要特别考虑内存序的影响。更多细节可参考 Arm 白皮书：Synchronization Overview and Case Study on Arm Architecture。

02 JuiceFS 与 MLPerf 概述

JuiceFS 是一款开源高性能分布式文件系统，基于对象存储构建，在充分利用对象存储低成本优势的同时，提供接近传统文件系统的使用体验。它支持 POSIX、HDFS SDK、Python SDK 以及 S3 兼容接口，并能适配不同类型的应用和数据处理框架；同时支持云原生扩展、数据安全与压缩，可广泛应用于 AI 训练、推理、大数据处理等场景。

image: 1JuiceFS 架构图.drawio
caption: JuiceFS 社区版架构图

为评估 JuiceFS 在 AI 训练等高负载场景下的数据供给能力，可采用 MLPerf Storage 基准测试。该测试由 MLCommons 开发，重点衡量存储系统能否持续高效向计算侧提供数据。

2.0 版本将测试分为训练负载和检查点负载两类，其中训练负载包括 3D U-Net、ResNet-50 和 CosmoFlow，三者在样本大小和访问特征上存在显著差异，并设置了最低 GPU 利用率要求：3D U-Net 与 ResNet-50 为 90%，CosmoFlow 为 70%。

image: MLPerf Storage 2.0 训练负载
caption: MLPerf Storage 2.0 训练负载

在测试流程中，数据首先从存储系统读入主机内存，再进入计算阶段。训练耗时由模拟方式复现，以模拟真实训练场景的数据流，从而无需实际部署 GPU，降低实验门槛并提升操作便利性。

image: MLPerf Storage 数据流
caption: MLPerf Storage 数据流

03 MLPerf Storage v2.0 测试原理与调优

在介绍具体的模型测试结果之前，需要先了解分布式训练的数据访问原理，有助于读者明白 GPU 利用率、存储吞吐和性能瓶颈的成因，从而更好地理解后续的测试结果和调优策略。

分布式机器学习通常采用数据并行方式，即多个并行进程共享同一数据集，每个进程分别负责读取和处理对应的训练批次。

image: 分布式训练数据访问原理示意图
caption: 分布式训练数据访问原理示意图

MLPerf Storage 的训练测试也遵循这一思路，每个训练进程按批次从存储系统读取数据，并通过模拟计算来评估存储系统的持续供数能力。

image: MLPerf Storage 训练数据流示意图
caption: MLPerf Storage 训练数据流示意图

为了理解测试中性能表现的来源，还需要理解 JuiceFS 客户端的数据处理链路。使用 JuiceFS 进行测试时，如图所示，其执行流程大致可分为三部分。

image: JuiceFS 客户端线程与数据流示意图
caption: JuiceFS 客户端线程与数据流示意图

左侧：应用侧 I/O 线程，例如 fio 或 MLPerf Storage 的 DataLoader 线程，负责发起 read/write 请求并等待请求完成。
中间：FUSE 守护进程中的请求处理主 goroutine，负责接收并处理来自内核态的 FUSE 请求，将文件数据放入内存缓冲区和缓存，并触发后端元数据与对象存储访问。
右侧：Meta client 和 ObjectStore client 的异步 goroutine，负责与后端 MetaDB 和 ObjectStore 集群进行数据与元数据交互。

从性能分析的角度看，这条链路需要重点关注两类问题。第一类是数据拷贝，对应图中的 2.1、3、4、5、6 等步骤，这些位置都会带来额外的内存复制开销，因此往往是分析延迟和 CPU 开销时的重点。

第二类是同步与异步边界。从图中可以看出，1、2、3、4、5、6 这些步骤总体属于同步路径，也就是请求发起后，需要等待当前阶段完成才能继续向下推进；而 7 属于异步路径，由后台 goroutine 负责与后端存储交互。

测试 1：Unet 3d

在这个测试中，样本为 146 MiB 的图像文件，我们主要关注大块数据的读取性能。测试结果显示：

单机环境下最高可稳定运行 5 块 GPU，GPU 利用率约为 50%，
而双机场景可支持 10 块 GPU，GPU 利用率同样约为 50%。

为了提升数据读取效率，对训练参数进行了优化：将 reader 并发线程数从 4 调整为 16，以加快数据生成速度，并将数据读取方式改为 direct I/O，以减少缓冲区和内存拷贝开销。

业务指标显示，当单机挂载 6 块 GPU 时，GPU 利用率仅为 83%，对应带宽约为 15.1 GB/s，未达到预期的高利用率目标。进一步使用 FIO 对存储侧进行测试后发现，其带宽同样约为 15.1 GB/s，说明此时系统瓶颈已经落在 JuiceFS 客户端带宽上，而不是 GPU 计算侧本身。

优化分析 1：绑定 CPU

为了深入分析客户端带宽受限的原因，我们对进程进行了 CPU 绑定，将其固定在 CPU1（NUMA 2、3 节点）运行。通过工具观察，48 个 CPU 核心几乎全部占满，进一步分析 top-down、memory 和 miss 指标发现，系统表现出明显 Memory Bound，主要耗时集中在内存拷贝上。这说明，在 CPU 绑定场景下，JuiceFS 性能瓶颈主要来自 CPU 处理能力和跨 NUMA 节点内存拷贝带来的额外延迟。

优化分析 2：不进行 CPU 绑定

为了理解系统在更通用条件下的带宽限制，我们进一步观察了不绑定 CPU 的情况。通过观察可以看到，CPU 并未被完全用满，但 devkit tuner numafast 指标显示，系统中的 remote 内存访问比例高达约 80%。这意味着，大量内存访问已经跨越本地 NUMA 节点，甚至可能跨越 CPU socket，从而引入了显著的带宽损失和访问时延。

从硬件带宽特性看，跨片内存访问本身就存在明显限制。例如，在 Arm 平台上，跨 socket 的理论物理带宽约为 60 GB/s；进一步通过实测，跨片 copy 带宽在 Arm1 上约为 48 GB/s，而在两组 x86 平台上分别约为 37 GB/s 和 28 GB/s。

这说明，在不绑定 CPU 的情况下，虽然计算核表面上没有被完全耗尽，但大量跨节点、跨 socket 的远端内存访问已经成为新的主要开销来源。因此，可以推测，此时 JuiceFS 带宽无法继续提升，很可能并不是单纯受限于 CPU 算力，而是受限于跨片内存访问的带宽与时延。换言之，系统瓶颈已经从“本地 CPU 忙不过来”转移为“远端内存访问代价过高”。

综合来看，在两种场景下，JuiceFS 带宽无法提升的原因并不相同：

绑定 CPU 时，主要受限于 CPU 资源消耗以及大量内存拷贝带来的访问开销；
不绑定 CPU 时，主要受限于高比例非本地内存访问，尤其可能是跨 socket 访问带来的带宽和时延损失。

测试 2：Resnet50

ResNet-50 测试的单个样本较小，单个样本大小约为 150 KiB，每个 batch 包含 400 个样本，每个 batch 的总数据量约 58.5 MiB。本次 I/O 测试关注 GPU 高并发下的数据加载效率及训练吞吐。测试显示系统可在大规模 GPU 下维持较高利用率：

单机：50 块 GPU，GPU 利用率 95%，带宽约 9.2 GB/s
双机：96 块 GPU，GPU 利用率 90%，带宽约 16.9 GB/s

在测试过程中，我们将关键参数 reader.read_threads 从 8 调整为 1，对于该模型（中等大小的图像模型），单线程即可满足数据供给需求。

优化分析 1：单机性能瓶颈与内存带宽影响

在单机配置 55 块 GPU 时，GPU 利用率下降至 86%，带宽仍为 9.2 GB/s，表明系统瓶颈已转移至 JuiceFS 客户端带宽。

进一步分析发现，ResNet-50 测试采用 Buffer I/O 模式，除了读取数据外，处理数据集时的内存拷贝会消耗一部分内存带宽。

系统内存拷贝带宽受内存通道数、内存频率及 CPU 频率影响。通过对多台配置不同的机器进行 stream 测试，得到的单机顺序读带宽与系统内存带宽测得的可比带宽一致，表明读数据吞吐能力在很大程度上取决于系统内存带宽。对于需要高吞吐、高 GPU 利用率的训练任务，建议优先选择内存带宽较高的机型，可显著提升数据供给能力和训练效率。

	单 CPU 内存拷贝带宽数据	JuiceFS 单机部署读带宽
Arm3	Arm3: 171 GB/s	25.3 GiB/s
Arm2	114 GB/s	21.6 GiB/s
Arm1	106 GB/s	18.3 GiB/s
x862	90 GB/s	17.9 GiB/s
x861	82 GB/s	16.6 GiB/s

优化分析 2：双机扩展瓶颈与分布式限制

在多节点部署中，除了单机性能限制外，跨节点内存访问、网络传输和元数据延迟会成为新的瓶颈，因此在单机分析之后进行双机测试，有助于识别这些分布式约束并指导系统优化。

在双机场景下，理论上可以支持 100 块 GPU，但实际测试中只能达到 96 块 GPU。通过分析发现，每个操作的读取延迟有所增加。尽管文件数据已缓存在本地盘上，元数据访问延迟仍然成为主要限制因素。

为解决这一问题，对系统进行了多方面优化：

将 CPU 核心分组，保证训练线程与 I/O 线程在同一 NUMA 节点上运行。
将纯数据处理和元数据访问分别分配到不同 CPU 核心和存储路径上。
调整 Redis 缓存和本地缓存策略，减少高并发访问元数据时的延迟。

经过上述调优后，双机场景能够稳定支撑 100 块 GPU 运行，GPU 利用率达到预期水平。

测试 3：cosmoflow

与之前的模型相比，这个模型的单样本数据量更小，这也意味着对 I/O 和元数据访问的要求更高。在单机和双机场景下，CosmoFlow 测试显示：

单机：最高稳定 10 块 GPU（偶尔可撑到 12 块 GPU），GPU 利用率约 75%，带宽约 5.6 GB/s
关键参数调整：将 reader.read_threads 从 4 调整为 1，每次读取 batch 数据量为 2 MiB，单线程即可满足数据供给需求。

优化分析 1：单机瓶颈：内存拷贝限制 GPU 利用率

当尝试增加 GPU 数量超过 10 块时，发现 GPU 利用率下降。分析日志和性能数据后发现：

数据读取时间增加，而元数据访问延迟变化不大。
文件数据已缓存在本地盘上，磁盘队列未满，延迟也不高，因此瓶颈不在存储设备。
使用性能分析工具观察发现，关键瓶颈操作主要集中在内存拷贝（memcopy），数据读取流程中多次拷贝操作的延迟累积，导致整体读取时间增加。

由此推测，当系统使用更多内存带宽时，内存拷贝延迟成为限制读取性能和 GPU 利用率的主要因素。

优化分析 2：双机瓶颈：分布式同步与元数据延迟

在双机场景下，尝试 20 块 GPU 时，第一轮测试 GPU 利用率明显偏低。进一步分析发现：

一台机器已开始训练，而另一台机器仍在进行 Dataset 预处理，包括读取文件列表和分片操作。
由于 CosmoFlow 数据量较大，高索引文件的读取耗时较长，导致两台机器未能同步开始训练，第一轮 GPU 利用率下降。

为解决该问题，在代码中加入同步机制，确保所有节点在开始训练前完成 Dataset 预处理。经过该调整后，双机测试能够稳定支撑 20 块 GPU，GPU 利用率达到预期水平。

04 总结

首先，MLPerf Storage 通过不同样本、文件和 batch 大小的组合，考察文件系统的各项能力，包括大中小块顺序读能力、文件并发性能、总读带宽、元数据访问时延、文件读取时延以及文件操作的稳定性。在只读文件场景下，充分利用高速近端缓存（包括原数据和元数据缓存）可以显著提升读取性能。需要注意，文件越小，对 IOPS 和延迟的要求越高。

其次，我们发现系统的内存和带宽对性能影响显著。在 Memory copy 密集型的应用中，内存拷贝不仅消耗内存带宽，同时也占用 CPU，表面上会出现“CPU 忙”的假象，实际上 CPU 大部分时间是在等待数据。测试结果显示，系统内存带宽对 JuiceFS 的吞吐能力有决定性影响，这也为选择服务器提供了参考标准：内存带宽越高的系统，其存储吞吐性能也越好。

第三，Go 运行时对 NUMA 的感知有限，对于大规模 CPU 核心运行场景，性能可能不如小规模核心运行。对于多 NUMA 系统，应尽量避免跨 NUMA，尤其是跨 CPU socket 的访问，因为跨 socket 内存带宽通常较低（约几十 GB/s），会增加延迟并影响整体性能。因此，实际部署时只需要分配足够的 CPU 核心即可，无需过度使用全部核心，以避免额外的内存访问延迟。

第四，在系统层面还有一些潜在优化点。例如，对于 Memory copy 密集的操作，部分 Arm 新系统提供了针对内存访问的指令优化，我们与 Arm 社区合作，将配置提升推送到社区中，新系统可以显著提升内存拷贝效率，在部分场景中带宽提升可达数十个百分点。

此外，对于涉及大量内核与用户态交互的操作，例如文件读写和元数据处理，可以通过优化用户态与内核态的交互，减少不必要的调用次数，从而降低延迟。实践中也发现，将文件处理尽量集中在同一生产节点内，避免跨 NUMA 或跨 socket 的访问，可以进一步提升性能和稳定性。

最后，系统配置优化也体现在缓存策略上。例如，在单机高负载场景下，通过调整 JuiceFS 的内存缓存策略，减少无效内存带宽占用，可以有效提高 GPU 利用率和存储吞吐。整体来看，MLPerf Storage Benchmark 是一个系统工程，需要文件系统、内存带宽、CPU 调度和缓存策略等多方面配合，才能达到最优性能。关于此次测试详细信息，可查看文档。

韩国国民搜索 NAVER：使用 JuiceFS 打通 Hadoop 与 Kubernetes 存储实践

Thu, 12 Feb 2026 02:40:00 +0000

NAVER 是韩国领先的互联网科技公司，运营着韩国最大的搜索引擎，并在人工智能、自动驾驶等高科技领域积极布局。作者 Nam Kyung-wan 来自 NAVER Infra 团队，自 2023 年参与 JuiceFS 社区代码贡献 (GitHub: kyungwan-nam)，为 Hadoop 场景提出了多项改进。本文是作者继“ 为 AI 平台引入存储方案 JuiceFS”后的第二篇博客。

NAVER Infra 团队负责运营公共 Hadoop 集群，使用 Spark、Hive、MapReduce 等 Hadoop 应用处理数据，并将数据存储在 HDFS 中。HDFS 在 Hadoop 生态系统中通过数据本地性支持高性能，具备优异的容错性和可扩展性。

随着人工智能服务的普及，数据规模急剧增长，对多样化数据存储的需求也日益增加。同时，如何高效地共享 Hadoop 集群外部 AI 平台（如 Kubernetes）中的数据，成为了一项重要挑战。在这一背景下，NAVER 探讨了对象存储是否可以替代 HDFS，并明确了 JuiceFS 结合对象存储的适用场景。

01 HDFS 的局限

存储成本上升

AI 开发需要以高效且经济的方式存储不断增长的数据，并在某些情况下长期保留原始数据，以便进行模型改进和重新训练。

然而，Hadoop 的计算和存储是紧密耦合的，导致存储扩展难以独立进行。当没有计算需求时，仅为扩展存储空间而增加节点会造成不必要的成本。此外，HDFS 默认保留三重副本，进一步增加了存储成本。

文件数量限制

AI 开发涉及数千万个小文件，如图像、音频和文本等。HDFS 存在著名的小文件问题，因为所有文件和块的元数据都存储在 NameNode 的内存中。例如，管理 1000 万个文件大约需要 3GB 的内存。因此，HDFS 可管理的文件数量受到单个 NameNode 内存容量的限制。

数据中心容灾能力弱

HDFS 通常由单个数据中心的节点组成。为应对数据中心故障或灾难，需使用额外方案将数据复制到其他数据中心，从而产生增加成本。

运营成本增加

NAVER 由专业人员运营公共 Hadoop 集群，负担相对较小，但通常 Hadoop 集群的构建和运营非常复杂且成本高昂。若要单独构建和运营稳定的 Hadoop 环境，需要专业知识和较高的维护成本。

Kubernetes 中的生态兼容性差

NAVER AI 平台基于 Kubernetes 构建，并利用 Kubeflow、KServe 等多种 AI 开源工具及 GPU 支持。但 HDFS 不支持 POSIX API 和 CSI 驱动，无法作为 Kubernetes 常规存储方式（即 PersistentVolume）使用。因此，在 Kubernetes 中使用 HDFS 需在容器中准备 Hadoop 包、配置和认证信息，并编写 HDFS API 代码，非常繁琐且会降低 AI 开发效率。

02 对象存储的优势与劣势

Hadoop 通过数据本地性提供高性能，但由于 HDFS 与计算节点耦合，计算和存储资源难以独立扩展。因此，扩展存储空间时，仍需增加额外的计算节点。

相比之下，云环境支持计算和存储的独立扩展。通常，数据存储在对象存储中而非 HDFS，计算可以通过托管服务（如 AWS EMR、Google Dataproc）或基于 Kubernetes 的数据处理引擎进行，数据则存储在 S3、GCS 等对象存储中。这种架构支持灵活扩展计算和存储资源。

image: n1
caption

此外，Hadoop 社区和云供应商提供了 S3A、Azure Blob、Aliyun OSS 等 HDFS 兼容文件系统，使得对象存储可以像 HDFS 一样使用。

image: n2
caption

对象存储作为远程存储，虽然难以实现数据本地性，但具有以下优势：

存储成本降低：计算和存储分离，可独立扩展。对象存储通常成本较低，并能根据需要选择不同的存储类别。例如，对于访问频率低但需长期保留的数据，可使用低成本存储类别（如 S3 Glacier）。
出色的扩展性和弹性：对象存储设计上支持近乎无限的扩展。对象数量和容量无限制，可根据工作负载变化轻松扩展或缩减。
数据中心灾难恢复支持：S3 等对象存储提供跨区域复制功能，可防止数据中心故障或灾难导致的数据丢失。
运营成本降低：避免 Hadoop 集群的构建和运营负担，从而降低运营成本。

但对象存储替代 HDFS 是好的选择吗？

不支持目录：
在文件系统中，文件通过目录进行组织，列出目录下的文件是一项基本操作，通常速度较快。
而对象存储没有目录的概念，所有对象是独立的扁平结构。列出文件时需要通过对象前缀搜索，速度较慢。此外，为模拟目录结构而临时创建的 Directory Marker 对象也会影响性能。

image: n3
caption

不支持重命名：
在文件系统中，重命名是基本操作，以 O(1) 级别的原子事务快速执行。但对象存储不支持重命名，需通过复制全部数据再删除原数据的方式处理，导致速度非常慢且可能中途失败。

这一问题对于 MapReduce 和 Spark 等大数据框架影响尤为明显(Apache Hadoop Amazon Web Services support – Committing work to S3 with the S3A Committers)。文件输出操作通常依赖重命名来保证一致性，FileOutputFormatCommitter 就是基于重命名实现的。因此，在对象存储中直接使用 FileOutputFormatCommitter 会显著降低性能。

为了解决这一问题，可以使用 Magic Committer，它避免了重命名操作，并针对对象存储进行了优化。

image: n4
caption

来源: Improve s3 write performance with magic committer in Spark3

不支持文件权限：
HDFS 支持 POSIX 权限体系，可以设置文件和目录的所有者、组以及其他用户的权限。而对象存储不提供此功能，因此文件的所有者和组通常被视为当前用户，所有文件和目录的权限默认为 666 和 777（即文件可读写，目录可读写并可执行）(参考: Object Stores vs. Filesystems).。
数据访问速度慢：
对象存储作为远程存储，无法保证数据本地性，并且每次访问都涉及网络传输，因此相较于 HDFS，其数据访问速度较慢，性能受到网络延迟和带宽限制的影响。
Kubernetes 中的低可用性：
一些工具，如 Mountpoint for Amazon S3 和 s3fs，支持通过 POSIX API 将对象存储挂载为类似本地文件系统的方式。AWS S3 还通过 Mountpoint for Amazon S3 CSI 驱动支持将对象存储作为 Kubernetes 卷使用。

然而，由于对象存储与传统文件系统存在根本差异，它无法完全兼容 POSIX API，且性能较低。因此，在使用这些工具时，需要充分了解它们的工作原理和局限性。最终，即使在 Kubernetes 环境中使用对象存储，低可用性问题仍然无法解决。

S3 兼容对象存储的 API 兼容性：
S3 已成为对象存储的事实标准，被多种应用广泛支持。因此，许多云供应商和开源项目提供 S3 兼容对象存储。然而，S3 兼容对象存储并不完全等同于原生 S3 服务。在使用时，需要确认其是否与 S3AFileSystem 或其他应用所使用的 S3 API 兼容。

image: n5
caption

综上，对象存储可以像 HDFS 一样使用，但需要充分理解其局限性。现有 Hadoop 应用难以直接迁移，仍需额外的开发和适配工作。对于直接使用 HDFS API 编写的代码，需要避免重命名操作，并减少文件列表操作，以适应对象存储的特性。为避免现有 Spark 应用性能下降，需考虑使用 Magic Committer，但它并非总是有效，特别是在不支持 Spark 动态分区覆盖的情况下。

此外，虽然 Spark 和 Hadoop 社区持续改进对象存储相关问题，但更新软件包版本和解决问题仍然面临挑战。使用 S3 兼容的对象存储时，还需验证其与 S3 API 的兼容性。

03 在 Hadoop 中使用 JuiceFS

JuiceFS 是一款分布式文件系统，架构由客户端、元数据引擎和数据存储组成。对象存储仅用于存储数据块，而文件系统所需的元数据则由数据库管理。

需注意 JuiceFS 是与 HDFS 类似的分布式文件系统。因此，与直接使用对象存储不同，JuiceFS 能完美支持 HDFS API、POSIX API 和 Kubernetes CSI 驱动。

image: JuiceFS 架构图（第四版）-第 2 页-winfsp (2)
caption: JuiceFS 社区版架构

为了在速度慢且修改困难的对象存储上实现分布式文件系统，JuiceFS 引入了 chunk、slice 和 block 概念。

chunk（64MB）：将文件分割为 64MB 单位，支持基于偏移的并行处理。
slice：chunk 内的修改单位，写入时创建新 slice 并优先使用最新版本。
block（默认 4MB）：实际存储在对象存储中的最小单位，通过并行处理缩短上传时间。

image: n6
caption: 来源: JuiceFS Document Center - Architecture

此外，从远程对象存储读取数据较慢，JuiceFS 支持多级缓存，以此弥补此性能不足。

image: n7
caption: 来源: JuiceFS Document Center - Cache

NAVER 内部 AI 平台已使用 JuiceFS。更多关于 JuiceFS 的详细信息及 AI 平台引入过程可参考为 AI 平台引入存储方案 JuiceFS。

JuiceFS 支持 Hadoop SDK，通过配置 JuiceFS 后，用户即可在 Hadoop 环境中使用它。

配置 JuiceFS

为使 Hadoop 识别 JuiceFS 文件系统，需在 core-site.xml 文件中添加以下内容。其中 fs.jfs.impl、fs.AbstractFileSystem.jfs.impl 和 juicefs.meta 是必需的。

<!-- Configure JuiceFS to be available via jfs:// -->    
  <property>  
    <name>fs.jfs.impl</name>  
    <value>io.juicefs.JuiceFileSystem</value>  
  </property>  
  <property>  
    <name>fs.AbstractFileSystem.jfs.impl</name>  
    <value>io.juicefs.JuiceFS</value>  
  </property>  
<!-- juicefs meta url -->    
  <property>  
    <name>juicefs.meta</name>  
    <value>redis://:password@addr</value>  
  </property>  
<!-- In this example, grant access permissions to all users to avoid permission issues. -->    
  <property>  
    <name>juicefs.umask</name>  
    <value>000</value>  
  </property>  
<!-- Cache up to 100 GiB. -->    
  <property>  
    <name>juicefs.cache-size</name>  
    <value>102400</value>  
  </property>  
<!-- Cache under the temporary path of YARN containers, so the cache is removed when the container terminates.    
Since it's a shared Hadoop, caching is temporary only during job execution. -->  
  <property>  
    <name>juicefs.cache-dir</name>  
    <value>${env.PWD}/tmp</value>  
  </property>  
<!-- Prometheus remote write configuration for metrics collection -->    
  <property>  
    <name>juicefs.push-remote-write</name>  
    <value>http://host:port</value>  
  </property>  
  <property>  
    <name>juicefs.push-remote-write-auth</name>  
    <value>username:password</value>  
  </property>  
<!-- Additionally collect Hadoop user and YARN container ID.    
For shared Hadoop to distinguish users and applications. -->  
  <property>  
    <name>juicefs.push-labels</name>  
    <value>user:${env.USER};container_id:${env.CONTAINER_ID}</value>  
  </property>

以上为单文件系统的默认配置，但也可根据需要配置多个文件系统同时使用。
更多配置选项可参考“客户端配置”。

Hadoop SDK

Hadoop SDK 的 JAR 文件可以通过下载预编译客户端或自行编译源代码获取。为了简化部署，通常可以在所有 Hadoop 节点的 Hadoop 发行版安装路径中预先安装。然而，在大规模 Hadoop 集群中，这种方法操作繁琐，尤其是对于公共 Hadoop 环境，它会限制所有用户使用特定版本。

大多数 Hadoop 应用支持将所需 JAR 文件部署并添加到 classpath 中，用户可根据实际需要选择部署方式。以下是 HDFS CLI、MapReduce 和 Spark 中的具体部署方法。

HDFS CLI

配置完上述 core-site.xml 文件后，需要在 HADOOP_CLASSPATH 环境变量中设置 Hadoop SDK 文件路径。完成此设置后，您可以使用 hdfs 命令操作 hdfs:// 和 jfs:// 文件系统。

$ export HADOOP_CLASSPATH=/home/juicefs/juicefs-hadoop-1.2.3.jar  
$ hdfs dfs -ls hdfs://home/foo  
Found 6 items    
...  
drwx------   - foo users          0 2022-10-14 20:55 hdfs://home/foo/.Trash    
drwx------   - foo users          0 2022-01-06 10:18 hdfs://home/foo/dfsio    
drwx------   - foo users          0 2025-01-22 17:54 hdfs://home/foo/tpcds

$ hdfs dfs -ls jfs://default/  
2025-08-25 19:15:43,964 INFO fs.TrashPolicyDefault: Namenode trash configuration: Deletion interval = 60 minutes, Emptier interval = 60 minutes.    
Found 8 items    
...  
drwxrwxrwx   - 10000 hadoop-admins       4096 2025-06-10 18:06 jfs://default/nyc    
drwxrwxrwx   - 10000 hadoop-admins       4096 2025-05-15 19:42 jfs://default/subdir

MapReduce

MapReduce 在 Hadoop 的多个节点上并行运行，因此所有分配任务的节点都需要部署 JAR 文件。推荐的方法是通过分布式缓存进行部署。使用此方法时，任务执行时会自动将 mapreduce.application.framework.path 中设置的 MapReduce 框架部署到任务节点。

以下是 mapred-site.xml 文件的示例配置：

mapreduce.application.framework.path：指定包含 Hadoop SDK 的 MapReduce 框架的 HDFS 路径。
mapreduce.application.classpath：配置为包含 Hadoop SDK 的路径。

<property>  
   <name>mapreduce.application.classpath</name>  
   <value>$PWD/mr-framework/hadoop/share/hadoop/mapreduce/*:$PWD/mr-framework/hadoop/share/hadoop/mapreduce/lib/*:$PWD/mr-framework/hadoop/share/hadoop/common/*:$PWD/mr-framework/hadoop/share/hadoop/common/lib/*:$PWD/mr-framework/hadoop/share/hadoop/yarn/*:$PWD/mr-framework/hadoop/share/hadoop/yarn/lib/*:$PWD/mr-framework/hadoop/share/hadoop/hdfs/*:$PWD/mr-framework/hadoop/share/hadoop/hdfs/lib/*:$PWD/mr-framework/hadoop/share/hadoop/tools/lib/*</value>  
 </property>  
 <property>  
   <name>mapreduce.application.framework.path</name>  
   <value>hdfs://mapred/framework/hadoop-mapreduce-3.1.2-juicefs-1.2.3.tar.gz#mrframework</value>  
 </property>

Spark

Spark 的基本配置文件是 spark-defaults.conf。在该文件中，可以替代 core-site.xml 进行如下设置：

任意 Hadoop 设置可以通过 spark.hadoop.key=value 形式添加。
spark.jars：指定要部署到 Spark driver 和 executor，并包含在 classpath 中的 JAR 文件。

spark.hadoop.fs.jfs.impl io.juicefs.JuiceFileSystem    
spark.hadoop.fs.AbstractFileSystem.jfs.impl io.juicefs.JuiceFS    
spark.hadoop.juicefs.meta redis://:password@addr    
spark.hadoop.juicefs.umask 000    
spark.hadoop.juicefs.push-remote-write http://host:port    
spark.hadoop.juicefs.push-remote-write-auth username:password    
spark.hadoop.juicefs.push-labels user:${env.USER};container_id:${env.CONTAINER_ID}    
spark.hadoop.juicefs.cache-size 102400    
spark.hadoop.juicefs.cache-dir ${env.PWD}/tmp    
spark.jars hdfs://juicefs/juicefs-hadoop/juicefs-hadoop-1.2.3.jar

04 JuiceFS 改进事项

JuiceFS 提供多种接口，支持跨平台的数据共享。例如，在 Hadoop 中使用 MapReduce 或 Spark 处理的数据存储到 JuiceFS 后，可以轻松在 Kubernetes 环境中访问和使用这些数据。

为使 NAVER 公共 Hadoop 和基于 Kubernetes 的 AI 平台顺畅共享数据，需要进行一些改进。（已经全部贡献到社区版。）

支持 all-squash 挂载（#5394）

NAVER 公共 Hadoop 与 LDAP 集成管理用户账户，因此 Hadoop 中创建的数据由相应用户的 LDAP UID 和 GID 所有。然而，在 Kubernetes 中，容器可以使用任意 UID 和 GID 运行，这可能导致访问 Hadoop 创建的数据时产生权限问题。

为了解决这个问题，我们增加了挂载选项 --all-squash。该选项使得访问挂载路径时，操作不会以当前账户的 UID 和 GID 进行，而是使用指定的 UID:GID。因此，设置 Hadoop 用户的 LDAP UID 和 GID 后，Kubernetes 中的容器可以无权限问题地访问数据。

改进 juicefs.users 和 juicefs.group 设置方式（#4723）

如前所述，在 Hadoop 集群中执行任务时，数据归 Hadoop 用户的 LDAP UID 和 GID 所有。但在 Hadoop 集群外部使用 Hadoop SDK 时，数据归任意 UID 和 GID 所有。例如，在 Docker 容器中使用 HDFS 命令存储数据时，所有者为容器内部账户的 UID 和 GID。

为了解决这个问题，用户需要通过 juicefs.users 和 juicefs.groups 设置指定所需的 UID 和 GID。之前，这要求用户编写 <用户名>:<UID> 和 <组名>:<GID> 格式的文件，并设置文件路径，这个过程非常繁琐。现在，我们增加了直接通过配置值来指定 UID 和 GID 的功能，简化了操作。

支持 subdir（#6096）

在基于 Kubernetes 的 AI 平台中，JuiceFS 以动态供应方式使用。创建 PersistentVolumeClaim（PVC）时，会在 JuiceFS 文件系统内生成与该卷对应的子目录。若要在 Hadoop 中共享该 PVC，需仅安全地共享该卷对应的目录。

然而，Hadoop SDK 并不提供类似 --subdir 的挂载选项，无法限制 Hadoop 仅访问 JuiceFS 的特定子路径。为了解决这个问题，我们在 Hadoop SDK 中增加了 juicefs.subdir 设置，使用此设置可以限制仅访问指定路径。

通过 hdfs 命令查看配额（#5937）

JuiceFS 可以为整个文件系统或特定目录设置配额。在 Kubernetes 中，PVC 的 spec.resources.requests.storage 值将设置为该目录的配额。

在 Hadoop 与 PVC 共享时，也需要查看配额信息。然而，原有的 HDFS 命令 hdfs dfs -count -q 无法查看 JuiceFS 的配额。为了解决这个问题，我们对该功能进行了改进，现在可以通过相同的命令查看 JuiceFS 的配额信息。

支持 Prometheus remote_write 协议（#6295）

使用 JuiceFS Hadoop SDK 时，可以将指标发送到 Pushgateway 和 Graphite。但 Pushgateway 需要定期清理指标，且 Graphite 格式独特，使用起来较为困难。

许多系统支持 Prometheus remote_write 协议。为了解决这个问题，我们在 JuiceFS 中增加了通过该协议发送指标的功能。通过 juicefs.push-remote-write 和 juicefs.push-remote-write-auth 设置，用户可以指定 VictoriaMetrics vmagent 或 Prometheus。这一功能不仅整合了跨平台数据，还能整合监控系统。

05 JuiceFS 的优势

优势 1：通过并行处理和缓存克服对象存储的性能瓶颈

JuiceFS 需要通过网络与远程对象存储交换数据块，因此在性能上难以超越具有数据本地性优势的 HDFS。然而，通过将数据分块并行处理以及缓存已读取数据，可以克服这一性能瓶颈。我们通过性能测试验证了 HDFS 和 JuiceFS 在不同场景下的表现。

DFSIO

使用 10 个 map task，针对 100GB 文件测量 HDFS 和 JuiceFS 的顺序数据写入和读取的吞吐量。数值越高性能越好。为适应顺序写入/读取，将 JuiceFS 的块大小设为 16MB。

写入：JuiceFS 的吞吐量是 HDFS 的 1.7 倍。这是因为数据被分割成小块并行上传。
读取：JuiceFS 的吞吐量是 HDFS 的 0.75 倍。但如果数据已缓存，预期性能与 HDFS 相似。

image: n8
caption

TPC-DS

使用 Spark SQL 测量对存储在 HDFS 和 JuiceFS 的 100GB 规模表的查询响应时间。数值越低性能越好。

JuiceFS 的响应时间是 HDFS 的 1.8 倍，这是由于数据本地性差异所致。
已缓存的 JuiceFS 表现出与 HDFS 相似的性能。

image: n9
caption

优势 2：与 HDFS 完全兼容，无需修改现有 Hadoop 应用即可使用

NAVER 拥有稳定运营的公共 Hadoop 集群，运行着多种服务的 Hadoop 应用。如果仅将不常用的数据存储在对象存储中以降低存储成本，可能会出现问题。正如前所述，对象存储不是文件系统，无法保证现有 Hadoop 应用的性能和运行。为此，需要重写代码或检查数据处理引擎是否支持对象存储。此外，还需根据存储类型单独运行和管理 Hadoop 应用，增加了管理负担。

与之相反，使用 JuiceFS 可以保持现有 Hadoop 应用不变。用户只需将输入输出路径指定为 hdfs:// 或 jfs://，即可以相同方式运行应用。

image: n10
caption

HDFS 基于数据本地性保证高性能，而对象存储则在低成本和扩展性方面具有优势。两者各有所长，难以完全替代，需要根据需求选择。使用 JuiceFS 可以在不修改现有 Hadoop 应用的情况下，同时利用 HDFS 和对象存储的优势。

优势 3：支持多种接口，可作为跨平台集成存储

NAVER 使用多种平台进行服务开发和运营。例如，在开发/运营 AI 服务时，需要在数据处理平台中清洗数据，在 AI 平台中训练模型，并通过容器平台提供服务。

在 NAVER，各个平台提供独立的存储，平台内部易于使用，但难以访问其他平台的存储。不同平台的存储隔离导致了数据孤岛现象，并容易造成数据重复和资源浪费。

image: n11
caption

JuiceFS 不仅支持 HDFS，还完美兼容 POSIX 和 Kubernetes CSI 驱动，适合作为跨平台的集成存储。通过在多个平台间顺畅使用 JuiceFS 共享数据，可大幅提升 AI 服务开发效率，实现数据统一管理。

image: n12
caption

06 结语

本文探讨了 JuiceFS 在 Hadoop 环境中的使用方法及其优势，而在部分业务场景下，直接采用 HDFS 或对象存储会是更适配的选择。例如，当业务需要依托数据本地性实现高效快速处理时，建议将数据存储于 HDFS 中；此外，针对访问频率较低的数据，或采用 Iceberg 等专为对象存储优化的数据格式时，直接使用对象存储则更为简便。

而在以下场景中，JuiceFS 会是更优选择：

需在 Kubernetes 与 Hadoop 环境之间实现数据共享时；
希望在不修改现有 Hadoop 应用代码的前提下，与 HDFS 并行部署使用时；
处理存在重复读取行为、可通过缓存显著提升效率的数据作业时；
业务所用 S3 API 无法被底层 S3 兼容存储良好支持时。

本文介绍了在 NAVER 内部本地环境中的应用案例，但在 AWS、Google Cloud 等公有云环境中同样适用。希望对有类似困扰的读者有所帮助。

原文链接：https://d2.naver.com/helloworld/5215257

海量小文件 + 多云协同：地瓜机器人 JuiceFS 存储优化之路

Fri, 06 Feb 2026 06:41:58 +0000

地瓜科技成立于 2024 年，由地平线机器人事业部拆分组建，专注于消费级机器人底层计算平台的研发；此外，地瓜科技在 2025 年还发布了具身智能基座模型。

在机器人数据管理和训练推理中，数据量庞大，使用对象存储时面临小文件、多云数据管理等挑战，在尝试了百度云 BOS、阿里云 CPFS 和将私有 MinIO 替换为 SSD 存储后，方案在应对上述挑战时仍然面临困难。地瓜机器人最终选择了 JuiceFS 作为核心存储解决方案。

JuiceFS 对跨云业务的天然适配能力，能够高效支持多云环境中的数据共享需求。在训练场景中，JuiceFS 针对小文件数据设计的缓存机制，能够有效替代传统缓存方案，同时在成本和效率之间实现高性价比，完全满足存储性能的需求。目前，地瓜机器人的文件管理规模已达到千万级别。

本文将详细介绍我们的业务背景、存储痛点、方案选型、落地实践与生产调优经验，希望对同行业的技术实践与方案选型提供参考与借鉴。

01 机器人行业的存储痛点

云平台作为地瓜机器人的技术核心中枢，承担仿真环境搭建、数据生成与模型训练、模型轻量化部署及可视化验证等关键业务职能。平台所涉及的数据类型多元，主要包括传感器图像数据、激光雷达点云数据、模型权重与配置数据、电机运行数据及地图构建数据等。

对象存储虽能满足海量数据的基础存储需求，但在机器人业务高频出现的海量小文件处理场景中，性能短板尤为突出。地瓜机器人的存储系统面临四大核心挑战：

海量小文件的元数据性能瓶颈：机器人模型训练环节涉及千万至亿级规模的传感器图像、激光雷达数据与模型文件，传统对象存储（如标准 S3）在处理该规模数据时，元数据操作性能存在显著瓶颈，文件列表检索、属性获取等常规操作的固定 API 延迟通常为 10–30 ms，直接制约训练与推理环节的 QPS 表现，影响整体研发效率。

多云协同与数据流通效率低下：当前机器人企业普遍采用多云架构开展研发与生产业务，如何保障数据在不同云平台及地域间高效同步与共享，成为行业普遍面临的核心问题。传统存储方案跨云数据流通效率偏低，且大多与单一云服务商深度绑定，易形成技术依赖，难以实现灵活的跨云业务部署与数据协同。

性能、成本与运维的 “不可能三角”：高性能并行文件系统可提供高吞吐、低延迟的存储服务，但通常依赖全闪存阵列或专用硬件设备，前期硬件投入与后期运维成本高昂，且部署运维流程复杂。低成本对象存储虽具备良好的弹性扩展能力，却难以支撑 AI 训练场景下 GPU 集群所需的高吞吐 I/O 负载。行业常规方案是将 S3 数据同步至高速文件系统作为缓存使用，但额外的数据同步流程大幅降低业务易用性，无法实现存储与计算的高效协同。

数据集版本管理困难：机器人模型迭代速度快，需对多版本数据集进行高效、精细化管理。若采用物理拷贝的方式实现数据集版本控制，会直接导致底层存储容量成倍消耗，显著推高存储成本，同时多版本数据的检索、复用与维护难度也会大幅上升。

image: 1云平台
caption: 地瓜科技云平台架构图

02 存储选型：JuiceFS vs. MinIO/S3 vs. PFS

为解决上述存储痛点，地瓜机器人确立了明确的选型评估标准，围绕存储架构、协议兼容性、元数据性能、扩展性、多云适配能力、成本效率、运维复杂度七大核心维度，对行业主流存储方案开展全面对比测试。

image: 选型对比
caption

基于上述对比结果，JuiceFS 在核心性能、扩展性、多云适配与成本效率等多个关键维度均展现出显著优势，成为地瓜机器人统一存储解决方案的首选。

同时，JuiceFS 在智能驾驶领域已实现广泛落地，地平线等行业头部企业已通过 JuiceFS 完成千 PB 级别的数据承载，具备成熟的大规模场景应用经验。

针对地瓜机器人业务场景，JuiceFS 的核心技术优势主要体现在以下四大方面：

解耦架构：JuiceFS 采用元数据与数据分离的架构设计，将数据持久化存储在低成本对象存储（如 S3、OSS），元数据则托管于 Redis 或 TiKV 等数据库组件。这种解耦架构实现了存储的弹性扩展，避免对单一云服务商的依赖。
分块与缓存机制：JuiceFS 使用 Chunk、Slice、Block 三级分块机制，有效提高了小文件读取效率，并提升了并发读写能力。此外，结合多级缓存（内存、本地 SSD、分布式缓存），可降低热数据访问延迟，满足高吞吐训练需求。

image: 分快存储
caption

云原生适配性：通过提供 CSI 驱动，JuiceFS 在 Kubernetes 环境中提供与计算节点解耦的持久化存储，支持容器无状态化部署和跨云迁移。它支持数据共享，提升应用的高可用性和灵活性，并适配多种 Kubernetes 部署方式。
AI 训练全链路支持：JuiceFS 完整支持 POSIX、HDFS 和 S3 API，兼容主流 AI 框架（如 PyTorch、TensorFlow），无需修改代码即可接入，降低技术门槛。
支持多云：其跨云能力和高性能元数据引擎确保数据流转高效，完美契合了我们“算力随需而动”的战略。

从成本维度来看，JuiceFS 在初期小规模部署时成本优势不突出，但当数据规模突破 PB 级，尤其达到 10PB、100PB 级别并与全闪存方案对比时，其依托对象存储的低成本架构优势将全面凸显。此外，JuiceFS 的运维成本极低，地瓜机器人当前仅需一名工程师即可负责整个云平台与存储系统的运维工作，远低于传统方案所需的人员投入。

03 从社区版到企业版，应对更大规模场景需求

随着业务的不断扩展，我们在使用 Redis 作为元数据引擎时，发现物理内存容量限制了数据的扩展。当文件数量接近亿级时，元数据查询的延迟显著增加，进而影响了训练任务的并发效率。在使用 clone 功能后，元数据的量大幅增加，另外我们在跨云场景中对元数据同步和镜像文件系统的能力提出了更高要求。同时，我们还希望在目录级别进行更细粒度的容量限制和权限管理。

考虑到这些需求，以及希望利用 GPU 机器本地 SSD 构建分布式缓存层来提升性能，我们决定并行部署 JuiceFS 企业版，将超大规模目录管理、多机协同训练等核心场景迁移至该版本。通过这种场景化拆分，我们有效提升了整体存储系统的适配性，并为未来的业务增长提供坚实的基础。以下是我们在实际场景中应用的企业版关键特性。

特性 1- 高性能元数据引擎：解决超大规模目录检索瓶颈
针对亿级文件目录下的遍历、深分页查询等高频操作，我们曾遇到传统存储方案 “越查越慢” 的问题 —— 单目录文件量突破千万后，分页查询偏移量超过 10 万条时，响应延迟会从百毫秒级飙升至秒级，严重影响数据筛选效率。

切换至 JuiceFS 企业版后，其元数据的原生目录树形存储架构发挥了关键作用：不同于扁平化 KV 对文件元数据的无序存储，这种树形结构可直接定位目录层级，减少元数据扫描范围。我们实际测试中，单目录 1.2 亿文件的深分页查询（偏移量 50 万条），延迟从原来的 3.8 秒降至 210 毫秒，完全满足大规模数据集的检索需求；同时，该引擎支持单卷千亿级文件存储，目前我们已基于此支撑 3 个 PB 级训练数据集的稳定管理，匹配业务增长预期。

特性 2- 企业级分布式缓存：提升多机多卡训练数据共享效率
在多机多卡训练场景中，我们曾面临 “缓存命中率低、跨节点带宽拥堵” 的问题 —— 开源版仅支持节点本地缓存，当多节点同时拉取同一数据集时，每个节点都需要访问对象存储，导致单节点带宽占用率超过 90%，训练任务启动延迟平均达 20 分钟。借助 JuiceFS 企业版的分布式缓存功能，我们通过 3 行命令在 12 台训练节点组成的局域网内搭建了分布式缓存，数据集只需要从对象存储拉取一次，并缓存在节点本地 SSD 组成的缓存池中。多机协同训练的缓存命中率从原来的 45% 提升至 92%，跨节点带宽占用率降至 15% 以下，训练任务启动时间缩短至 3 分钟内，大幅提升了算力利用率。

特性 3- 增强型跨云协同：构建低运维成本的跨云数据底座
由于我们的研发环境分布在阿里云、百度云两个平台，此前存在 “跨云数据同步慢、运维成本高” 的痛点 —— 通过传统同步工具实现两地数据一致，需配置 8 个定时任务，同步延迟平均达 4 小时，且需专人每周排查同步失败问题。基于 JuiceFS sync 工具，结合内部 AI 运维工具实现了同步策略自动化配置：系统可根据数据热度自动调整同步优先级，跨云数据延迟控制在 10 分钟内；同时，同步任务的失败重试、日志告警等均实现自动化，无需专人值守，运维投入减少 70%，目前已稳定支撑两个云平台多个训练项目共享同一套数据集。后续，将使用企业版的镜像文件系统功能来应对跨云数据协同。

04 JuiceFS 调优攻略

客户端缓存与写入性能调优实践
需重点关注缓存策略与 Kubernetes 资源限额之间的兼容性问题。如使用内存作为本地缓存路径，配置不合理可能引发 Mount Pod 内存异常增长，或因资源配额预留不足，导致长周期训练任务出现检查点丢失、文件句柄写入异常等情况。

在写入性能调优方面，开启 writeback 模式可在一定程度上提升小文件写入吞吐，但结合生产环境对数据一致性的要求，我们仍采用 write-through 同步写入模式，以降低极端宕机场景下的数据风险。建议仅在对数据可靠性要求较低的临时计算、离线数据清洗等场景中，根据实际需求谨慎启用 writeback 模式以提升写入效率。

部署与网络拓扑优化
为获得更稳定的性能表现，在部署时强烈建议将元数据引擎与计算节点规划在同一 region 区域内。实际运行中观察到，跨 region 部署会使元数据操作延迟出现数倍至十倍的上升，对数据解压等 I/O 密集型操作的效率影响较为明显。将元数据服务与 GPU 计算资源部署在同一 region 内，有助于在保障性能的同时控制网络传输成本，提升整体资源利用效率。

数据预热与缓存优化策略
在万兆网络环境下，可充分利用 JuiceFS 的数据预热机制，结合业务场景合理调整数据块大小，以更好地发挥网络带宽能力，提升读吞吐量。配合分布式缓存架构，可有效改善多机并发场景下的数据共享效率，提升高并发读取时的缓存命中率，从而优化大规模 AI 训练任务的整体运行表现。

资源配额与高可用保障策略
企业级多角色运维、存储职责分离场景下，为规避配置不一致的运行风险，建议精细化管控 K8s 环境中 JuiceFS CSI 驱动的资源配额。通过合理设置 Mount Pod 的 CPU 与内存 Request/Limit，可减少因资源抢占导致的 Pod 重启或节点异常，实际使用中可根据集群负载动态调整资源预留比例。

同时，对业务连续性要求较高的场景，可开启 Mount Pod 的挂载点自动恢复功能，实现存储服务的自动化故障恢复，进一步保证底层存储的稳定性。

多租户实践
我们为大型企业客户提供独立文件系统和存储桶，并通过子目录级别的目录隔离和权限管控实现中小型企业客户与终端用户的隔离。大型企业客户可以灵活扩展吞吐量和容量，避免共享存储桶带来的性能瓶颈。对于中小型企业和终端用户，我们通过子目录隔离和权限管控确保数据安全与独立性，同时实现精确计量与计费。这一架构在保障租户隔离的同时，也能灵活调配资源，提高系统管理效率。

版本管理
通过 juicefs clone 命令，可以快速创建原始数据集的副本，并独立修改，而不影响原数据。克隆操作仅复制文件的元数据，数据则只额外存储变更部分，节省底层存储空间。此功能支持管理多个版本，便于回滚和恢复，确保数据的安全性和版本控制。

05 小结与展望

JuiceFS 在元数据性能、扩展能力、跨云适配性与综合成本效率等方面的特性，支撑其成为我们构建统一存储层的选择。目前地瓜科技采用 JuiceFS 社区版与企业版并行部署的模式，适配不同业务场景下的差异化存储诉求。

未来，我们计划将 JuiceFS 进一步落地至具身智能领域，针对性解决该场景下的专属存储需求，包括时序数据高吞吐处理、多模态数据精准对齐、边缘与云端协同存储及仿真与真实场景数据的融合管理等。后续积累更多实践经验后，我们将持续分享具身机器人场景下的存储实践心得。关于 AI 场景的存储实践与技术探索，欢迎评论区一起交流探讨。

JuiceFS 企业版 5.3 特性详解：单文件系统支持超 5,000 亿文件，首次引入 RDMA

Thu, 29 Jan 2026 10:25:33 +0000

JuiceFS 企业版 5.3 近日发布，单文件系统支持超 5,000 亿文件，实现里程碑式突破。此次升级针对元数据多分区架构进行了多项关键优化，并首次引入 RDMA 技术，以提升分布式缓存效率；此外，5.3 版本还增强了可写镜像，为跨桶导入的对象提供数据缓存等多项功能，旨在支持高性能要求及多云应用场景。

JuiceFS 企业版专为高性能场景设计。自 2019 年起开始应用于机器学习领域，现已成为 AI 行业核心基础设施之一。商业客户涵盖大模型公司：MiniMax、智谱 AI、阶跃星辰；AI 基础设施及应用如 Fal.ai、HeyGen 等；自动驾驶领域的 Momenta、地平线等，以及众多应用 AI 技术的各行业领先科技企业。

01 单文件系统支持超 5,000 亿文件

多分区架构是 JuiceFS 应对千亿文件规模的关键技术之一，保证了系统的高扩展性和高并发处理能力。为了继续满足如自动驾驶场景业务增长的需求，5.3 版本对多分区架构进行了深入优化，将分区数量限制提高到 1,024 个，单文件系统能够存储和访问至少 5,000 亿个文件。（每个分区可存储 5 亿个文件，最大支持 20 亿）。

image: 企业版架构
caption: JuiceFS 企业版架构图，左下角为单个分区示意图

这一突破对系统性能、数据一致性、稳定性要求提出了几何级的难度，背后是一系列繁杂的底层优化与研发工作。

关键优化 1 - 分区间热点均衡：自动监测和热点迁移；提供手动运维工具

在分布式系统中，热点问题是常见的挑战，特别是当数据被分布到多个分区时，某些分区的负载可能比其他分区更高，这种不均衡会引发热点问题，影响系统的性能。

当分区数量达到数百时，热点问题变得更加普遍。尤其是在数据集较小、涉及的文件数量较多的情况下，读写热点问题会加剧，进一步增加延迟波动。

我们引入了自动化的热点迁移机制，将访问频繁的文件迁移到其他分区，从而分担负载并降低特定分区的压力。然而在实际环境中，我们发现仅依赖自动迁移并不能完全解决所有问题。特别是在某些特殊场景或极端情况下，自动迁移工具可能无法及时应对。因此，我们在自动监测和迁移的基础上，增加了手动运维工具，允许运维人员在遇到复杂场景时介入，进行人工分析并实施优化方案。

关键优化 2 - 大规模迁移：提升迁移速度，少量多次并发迁移

面对热点过高的分区，早期的迁移操作比较简单，但随着系统规模扩大，迁移效率逐渐降低。为此，我们引入了“少量多次并发迁移”的策略，将高访问量的目录分解成多个小块，并行迁移到多个负载较低的分区，从而迅速分散热点，恢复业务的正常访问体验。

关键优化 3 - 强化可靠性自检：自动修复与清理迁移中间态文件

在大规模集群中，分布式事务的失败概率显著上升，特别是在大量迁移过程中。为应对这一问题，我们增强了可靠性检测机制，增加了后台周期性的检查功能，定期扫描跨分区文件的状态，特别关注中间状态问题，并自动进行修复和清理。

此前，系统曾遇到过中间状态数据残留的问题，虽然短期内未影响系统运行，但随着时间推移，这些残留数据可能导致错误。通过增强的自检机制，我们确保了后台能够定期扫描并及时处理中间状态问题，从而提升了系统的稳定性和可靠性。

除了上述三项关键优化外，我们还在控制台进行了多项改进，以更好地适应更多分区的管理需求。我们优化了并发处理、运维操作和查询展示，提升了整体性能和用户体验。特别是，在 UI 设计方面，我们做了优化，以便更好地展示大规模分区环境下的系统状态。

千亿文件性能压测：稳定性与资源利用良好

我们在谷歌云上使用自定义的 mdtest 测试工具进行了大规模测试，部署了 60 个节点，每个节点的内存超过 1 TB。在软件配置方面，我们将分区数增加至 1,024 个。部署方式与之前类似，为了降低内存消耗，我们选择仅部署一个服务进程，另两个作为冷备。

image: 压测
caption: JuiceFS 企业版 5.3 测试

测试持续时间：大约 20 小时
写入的文件总数：约 4,000 亿个文件
每秒写入速度：500 万个文件
内存占用：约 35% 到 40%
硬盘使用： 40% 到 50%，主要用于元数据的持久化，使用情况良好

根据我们的经验，如果采用一个服务进程、一个热备进程和一个冷备进程的配置，内存占用会增加 20% 到 30%。

由于云端资源有限，本次测试只写到 4,000 亿文件。在压测过程中，系统表现稳定，且硬件资源尚有富余。后续，我们会继续尝试更大规模的测试。

02 首次支持 RDMA：带宽上限提升，CPU 占用降低

在此次新版本中首次支持了 RDMA（Remote Direct Memory Access）技术，它的基本原理架构如下图所示。RDMA 通过允许直接访问远程节点的内存，绕过操作系统的网络协议栈，显著提高了数据传输效率。

image: rdma
caption: RDMA 原理架构图

RDMA 的主要优点包括：

低延迟：通过直接从内存到内存的传输，绕过操作系统的网络协议层，减少 CPU 的中断和上下文切换，从而降低延迟。
高吞吐量：RDMA 通过硬件直接传输数据，能够更好地发挥网卡（NIC）的带宽。
减少 CPU 占用：在 RDMA 中，数据的拷贝几乎全部由网卡完成，CPU 仅用于处理控制消息。这样，网卡负责硬件传输，释放了 CPU 的资源。

在 JuiceFS 中，客户端与元数据服务之间的网络请求消息都较小，现有的 TCP 配置已能满足需求。而在分布式缓存中，客户端与缓存节点之间传输的是文件数据，使用 RDMA 可以有效提升传输效率，降低 CPU 消耗。

image: 网络对比
caption: CPU 占用对比：TCP vs RDMA

我们使用了 160 Gbps 网卡进行 1MB 随机读测试，比较了 5.1、 5.2（使用 TCP 网络）和 5.3 版本（RDMA），并观察了 CPU 占用情况。测试表明，RDMA 有效降低了 CPU 占用。在 5.2 版本中，CPU 占用了近 50%；而在 5.3 版本中，通过 RDMA 优化，CPU 占用降至约 1/3。客户端和缓存节点的 CPU 占用分别降至 8 核和 5 核，带宽达到了 20 GiB/s。

在以往的测试中，我们发现 TCP 在 200G 网卡下虽然稳定运行，但要完全拉满带宽仍有困难，通常只能达到 85-90% 的带宽利用率。对于需要更高带宽（如 400G 网卡）的客户，TCP 无法满足需求，而 RDMA 能够更容易地发挥硬件带宽上限，提供更优的传输效率。

如果用户的硬件支持 RDMA 且存在高带宽需求（如网卡大于 100G），同时希望降低 CPU 占用，那么 RDMA 是值得尝试的技术。目前，我们的 RDMA 功能处于公测阶段，尚未在生产环境中广泛部署。

03 可写镜像增强

最初，镜像集群主要用于企业产品中的只读镜像。随着用户提出在镜像中写入临时文件（如训练数据）等需求，我们为此提供了可写镜像功能。

image: 企业版镜像系统
caption: JuiceFS 企业版镜像文件系统架构

镜像客户端在实现时采用了读写分离机制。客户端在读取数据时优先从镜像集群获取，以降低延迟；而写入数据时，仍然需要写入源集群，以确保数据一致性。通过元数据版本号的记录与对比，我们确保了镜像客户端和源集群客户端看到的数据保持强一致性。

为了提升可用性，我们在 5.3 版本引入了回退机制，即当镜像不可用时，客户端的读请求能自动回退到源集群，从而保证业务连续性，避免镜像集群故障导致的业务中断。我们还优化了多镜像环境的部署。原先，镜像端需要部署两个热备节点以确保高可用性。现在，通过改进的回退功能，部署一个镜像节点也能实现类似的效果，确保业务连续性并降低成本，尤其适用于需要多个镜像的用户。

通过这一改进，我们不仅降低了硬件成本，还在高可用性和低成本之间找到了平衡。对于那些在多个地点部署镜像的用户，减少元数据副本的同时进一步降低了总体成本。

04 简化运维管理，提升灵活性：为导入对象提供跨桶数据缓存

在 JuiceFS 中，用户可以使用 import 命令将对象存储中的现有文件导入并统一管理。这对于已经存储大量数据（如几十 PB）的用户来说十分便捷。但在之前版本中，这一功能仅支持为同一数据桶中的对象提供缓存，意味着导入的对象必须与现有文件系统数据处于同一个桶内。这一限制在实际使用中带来了一定局限性。

在 5.3 版本中，我们对该功能进行了改进。现在，用户可以为任何导入的对象提供缓存能力，无论这些对象是否来自同一数据桶。这样，用户可以更加灵活地管理不同数据桶中的对象，避免了对数据桶的严格限制，从而提升了数据管理的自由度。

此外，以前如果用户将数据分布在多个桶中，想要为这些桶中的数据提供缓存能力，需要为每个桶新建一个文件系统。而在 5.3 版本中，用户只需创建一个文件系统（volume），便可统一管理多个桶的数据，并为所有桶提供缓存能力。

05 其他重要优化

Trace 功能

我们新增了 trace 功能，这是 Go 语言本身提供的一个特性。通过这个功能，资深用户可以进行追踪和性能分析，获得更多信息，帮助我们快速定位问题。

回收站恢复

在之前的版本中，特别是在多分区的情况下，有时回收站记录的路径不完整，导致恢复时出现异常，未能恢复到预期位置。为了解决这个问题，在 5.3 版本中，在删除文件时，我们会记录文件的原始路径，确保恢复时能够提供更可靠的恢复能力。

Python SDK 改进

在前几个版本中，我们发布了 Python SDK，它提供了基础的读写功能，方便 Python 用户与我们的系统对接。在 5.3 版本中，我们不仅加强了基础读写功能，还增加了对运维子命令的支持。例如，用户可以直接通过 SDK 调用 juicefs info 或 warmup 等命令，而不需要依赖外部系统命令。这不仅简化了编码工作，并且避免了频繁调用外部命令时可能产生的性能瓶颈。

Windows 客户端

我们在之前版本中推出了 Windows 客户端 Beta 版本，并已获得不少用户反馈。经过改进，当前版本在挂载的可靠性、性能以及与 Linux 系统的兼容性上都有了显著提升。未来，我们计划进一步完善 Windows 客户端，为依赖 Windows 的用户提供更接近 Linux 的体验。

06 小结

相较于昂贵的专用硬件，JuiceFS 通过灵活地利用云上或客户现有的存储资源，帮助用户在应对数据增长时平衡性能与成本。在 5.3 版本中，通过优化元数据分区架构，单文件系统可支持超过 5,000 亿个文件。首次引入的 RDMA 技术显著提升了分布式缓存带宽和数据访问效率，减少了 CPU 占用，进一步优化了系统性能。此外，我们还优化了可写镜像、缓存等多项功能，提升了大规模集群的性能和运维效率，优化用户体验。

云服务用户现已可以直接在线体验 JuiceFS 企业版 5.3，私有部署用户可通过官方渠道获得升级支持。我们将继续专注于高性能存储解决方案，和企业一起应对数据量的持续增长所带来的挑战。

如果你在存储架构设计、成本控制或性能优化中遇到过问题，或有相关实践心得，欢迎在评论区留言。

仅两台缓存节点，如何支撑 1.45TB/s 大吞吐业务 #JuiceFS 优化实践

Fri, 16 Jan 2026 03:28:23 +0000

随着面向大规模并发读取与数据分发的业务需求增加，如影视渲染等场景，传统存储方案（如 NAS）在并发客户端数量增加时，往往需要投入更多缓存资源；为了提升响应时效，通常还需提前进行数据预热，不仅带来额外的时间开销，也进一步加重了资源负担。

JuiceFS 作为一种基于对象存储的分布式文件系统，通过其高性能架构，利用分布式缓存聚合吞吐量并降低延迟，能够在大规模客户端并发读取时提供高效支持。本文分享的是我们近期在实际测试中的一个案例，展示如何利用 4,000 台业务节点成功聚合了 1.45TB/s 的带宽，并在此过程中通过引入二级缓存池，保障了系统的稳定性。

通过这篇文章，我们希望为高并发、大吞吐需求场景中的存储瓶颈提供一个切实可行的解决方案，并借此抛砖引玉，欢迎大家共同探索存储优化的思路与方法。

01 传统 NAS：节点越多，存储越慢

该客户为影视渲染农场用户，日常作业中会同时启动数千台 Windows 节点进行渲染。

业务特点：每台节点在渲染时需同时读取一批文件（大部分为重复素材）到本地。
原有痛点：原公有云 NAS 存储（SMB 挂载）在节点数增多时，不得不不断增加后端 SMB 服务节点来应对激增的流量和 IOPS，导致管理复杂度和成本直线上升。当并发节点超过 1,000 台时，存储系统往往不堪重负。
核心需求：迫切需要一种在存储底座之外，能够分担业务吞吐压力的能力。

image: 多节点 NAS 架构
caption: 多节点 NAS 架构

在 SMB 服务模式下，每个客户端都需要从 SMB 存储读取全量数据。导致服务端流量长期高位，管理员需要持续监控 SMB 服务的健康状况，一旦接近最大负荷，就需要及时进行扩容，提供与集群规模匹配的存储能力，运维压力显著增加。

02 闲置资源利用：用大量业务节点做分布式缓存

JuiceFS 在社区版 1.3 及企业版 5.2 之后发布了全新的 Windows 客户端，支持通过 .exe 进程将文件系统挂载为本地盘，使用方式与 Linux 类似。

但在海量客户端场景下，如果仅将业务切换为标准的「JuiceFS 挂载点 —— 分布式缓存 —— 对象存储」链路，流量会集中打到独立缓存层，可能成为新的性能瓶颈。与其不断扩容专用的缓存节点，不如转换思路：利用海量业务节点自身的闲置带宽和磁盘，将它们池化为一个巨大的分布式缓存池。

JuiceFS 分布式缓存模式（P2P 模式）：同一份文件只需在集群内读取一次，后续其他节点直接从 P2P 缓存池的邻近节点获取。
对象存储侧：回源流量极低，文件首次冷读后，后续流量几乎全由缓存池承担。
资源要求：无需专用缓存硬件，仅需每个业务节点贡献部分磁盘和带宽。

在这个方案中，我们没有配置任何一台独立缓存节点。所有的业务节点既是消费者，也是提供者（P2P 模式）。

image: JuiceFS 分布式缓存部署架构
caption: JuiceFS 分布式缓存部署架构

03 实测案例：4,000 台业务节点聚合到 1.45TB/s 的巨大吞吐

测试任务：每台 Windows 机器在无预热（冷读）的情况下，读取 16 个 2GB 的大文件。统计所有节点读完的总耗时，并观察各节点的耗时方差，以及是否存在长尾效应。

配置策略：将 4,000 个节点拆分为多个子组（每组 500 个节点）。16 个 2GB 的数据块会散列分布在组内节点中，避免所有节点同时回源对象存储，造成拥塞。

那么现在 JuiceFS 客户端的冷读流程就变为：

Windows 客户端读取 16 个 2GB 的文件，通过一致性哈希拓扑定位这些数据块在 500 个缓存组内的负责节点，向其发起请求。
缓存节点收到了数据块请求后，发现本地未命中缓存（冷读），则回源对象存储拉取数据块，拉取完成后将数据返回给客户端，并且写入本地缓存，供后续请求复用。
当客户端从所有缓存服务节点获取完整数据块后，测试结束，统计所有客户端读完的耗时分布（最大值、最小值），用于评估方差与长尾情况。

下面是不同客户端节点数量读取这批 16*2GB 大文件的时间结果：

客户端台数	聚合吞吐最高	总耗时（范围/平均）
2,000 台	729GB/s	92s~136s 平均 107s
2,500 台	921GB/s	87s~109s 平均 98s
3,000 台	1.11TB/s	93s~121s 平均 106s
3,500 台	1.34TB/s	89~112s 平均 100s
4,000 台	1.45TB/s	92s~115s 平均 101s

不同数量客户端，JuiceFS 聚合吞吐表现

image: IO 聚合表现
caption: IO 聚合表现

整体结果各方面都符合预期：

稳定性：无论是 2,000 台还是 4,000 台，读完数据的总耗时都稳定在 100 秒左右。
扩展性：4,000 台节点成功聚合出 1.45TB/s 的超大带宽，理论上，在元数据能够承载的前提下，该架构可实现持续的水平扩展，能够支持达到万台级别的缓存节点规模。

业务节点的挂载参数参考：

juicefs.exe mount juice-fs X: --cache-group=primary --buffer-size=4096 --enable-kernel-cache --as-root --subgroups=8

由此，我们未使用一台独立的缓存服务节点，仅靠用户的业务节点就聚合了 1.45TB/s 的读取能力。过客通户端节点组成的分布式缓存层，我们以零成本将绝大多数流量从对象存储中分流，减轻了底层存储的负担。

实际业务中，未必能达到如此高的吞吐能力，因为缓存效益通常与数据重复度相关。在实际场景中，每个节点读取的文件并不完全相同。尽管如此，这一方案仍然是有效的存储扩展方法，即使只有部分提升，也能带来非常可观的收益，且几乎不需要额外的成本投入。

04 稳定性增强：两级分布式缓存

缓存效果虽然炸裂，但客户对系统的稳定性提出了担忧。例如，在某些场景下，业务节点在完成任务后会立即销毁，而这些业务节点同时也是缓存节点。当大量业务节点突然下线时，原本存储在这些节点上的缓存也随之丢失，导致大量流量回源至对象存储，进而使对象存储成为瓶颈，影响整体稳定性。为了解决因业务节点波动引发的缓存性能问题，我们提出了两级分布式缓存方案，架构图如下：

image: JuiceFS 两级缓存架构图
caption: JuiceFS 两级缓存架构图

第二层缓存池（L2）位于第一层（L1）缓存池和对象存储之间。当 L1 未命中时，数据首先会从 L2 获取；如果 L2 缓存也未命中，则回源到对象存储。这样可以有效抵消 L1 缓存节点波动带来的影响。加入 L2 缓存池后，读取流程发生了以下变化：

在 Windows 客户端读取 16 个 2GB 的文件，通过一致性哈希拓扑确定数据块所在 L1 缓存组中的特定节点；并同时向 L2 缓存组请求数据。
由于是冷读，L2 缓存组中没有数据，L2 缓存节点会向对象存储发起请求并填充 L2 缓存池。
数据块从 L2 缓存池返回至 L1 缓存池并进行填充，然后由 L1 缓存池内的节点自行进行点对点（P2P）分发。
此时，大部分流量集中在 L1 缓存池，L2 只处理极少数回源对象存储的流量，因此即使 L2 只有少数几个节点，也不会成为性能瓶颈。L2 缓存池的作用是就近替代对象存储，降低延迟。

即使大量 L1 业务节点下线，缓存拓扑发生变化并需要重新下载数据块，数据仍可从 L2 缓存池就近获取。只要合理控制下线比例，业务几乎不受影响。

L2 缓存组挂载参数：

juicefs mount juice-fs /jfs-cache --cache-group=secondary --cache-size=-1 --cache-dir=/data* --free-space-ratio=0.01 --buffer-size=10240 --max-downloads=400

L1（业务节点）挂载参数：

juicefs.exe mount juice-fs X: --cache-group=primary --second-group=secondary --buffer-size=4096 --enable-kernel-cache --as-root --subgroups=8

此外，两级分布式缓存还非常适用于需要重复利用已有缓存池的场景。例如，我们有一批位于北京的缓存池业务，总容量为 2PiB，缓存池名为 cache-group-bj。突然，上海的业务也需要使用相同的数据，而这些数据与北京的数据几乎完全相同。如果不希望重新从北京的对象存储中预热这 2PiB 的数据，我们可以在上海的缓存组中配置 --second-group=cache-group-bj。这样，当上海的业务请求数据时，将优先通过专线从北京的缓存池读取数据，速度非常快且延迟稳定（在 2ms 以内），免去了重复预热数据的复杂过程，能够直接启动业务，极大地方便了操作。

05 小结

通过本次 4,000 节点的极限压测，我们成功将计算集群的大规模闲置资源转化为高达 1.45TB/s 的存储池；而二级缓存的引入，有效解决了“最后一公里”的稳定性顾虑。通过使用 JuiceFS 这套存储软件架构，可充分挖掘客户端集群的潜能，在不增加额外硬件成本的情况下，实现了性能的显著提升。

本方案适用场景：

高并发重复读取场景：如模型训推数据调用、容器镜像分发、影视渲染等，节点越多，P2P 缓存收益越大；
弹性计算场景：业务节点经常大规模扩缩容（如 Spot Instances），利用二级缓存架构可确保数据访问的连续性与稳定性；
混合云/多云架构：利用二级缓存机制可以复用异地缓存池资源，最大程度减少重复预热带来的对象存储调用和传输成本。

如果对方案的细节有疑问，欢迎在评论区留言，或分享您在类似场景中的架构设计与经验，与我们一起探讨最佳实践。

3D-AIGC 存储架构演进：从 NFS、GlusterFS 到 JuiceFS

Mon, 05 Jan 2026 06:27:14 +0000

光影焕像（Lightillusions）是一家专注于空间智能技术，结合 3D 视觉、图形学和生成模型技术，致力于打造创新的 3D 基础模型公司。公司由谭平教授领导，谭教授曾担任阿里巴巴达摩院实验室负责人，目前是香港科技大学的教授，同时担任冯诺伊曼人工智能研究室副院长，并是香港科技大学与比亚迪联合实验室的主任。

区别于二维模型，三维模型单个模型的大小可达几 GB，尤其是点云数据等复杂模型。当数据量达到 PB 级别时，管理与存储成为巨大的挑战。经过尝试 NFS、GlusterFS 等方案后，我们最终选择了 JuiceFS，成功搭建了一个统一的存储平台，为多个场景服务，并支持跨平台访问，包括 Windows 和 Linux 系统。该平台目前已管理上亿文件，数据处理速度提升了 200%~250%，还实现了高效的存储扩容，同时运维管理得到了极大简化，使得团队能够更专注于核心任务的推进。

01 3D-AIGC 存储需求

我们的研究主要集中在感知和生成两个方向。在三维领域，任务的复杂性与图像和文本处理有本质区别，这对我们的 AI 模型、算法以及基础设施建设都提出了更高的要求。

我们通过一个 3D 数据处理流程，来展示三维数据处理的复杂性。下图左侧是一个三维模型，包含纹理（左上角的折射纹理）和几何信息（右下角的几何结构）。首先，我们生成渲染图像。每个模型还附带文本标签，描述其内容、几何特征和纹理特征，这些标签与每个模型紧密相关。此外，我们还处理几何数据，如采样点以及从数据预处理过程中得到的必要数值（如 3DS、SDF 等）。需要注意的是，三维模型的文件格式非常多样，图片格式也各不相同。

image: 三维数据处理流程
caption: 三维数据处理流程

我们的工作场景涉及语言模型、图像/视频模型到三维模型，随着数据量的增长，存储负担也在不断增加。以下是这些场景中数据使用的主要特点：

语言模型的数据通常由大量小文件组成。尽管单个文本文件较小，但随着数据量的增加，文件数量可能达到数百万甚至数千万个，这使得管理如此庞大的文件数成为存储的一个主要难点。
图像和视频数据，尤其是高分辨率图像和长时间的视频，通常较为庞大。单张图像的大小通常在几百 KB 到几 MB 之间，而视频文件可能达到 GB 级别。在预处理过程中，如数据增强、分辨率调整和帧提取等，数据量会显著增加，特别是在视频处理中，每个视频通常会被拆解为大量的图像文件，管理这些庞大的文件集，带来了更高的复杂性。
三维模型，特别是点云数据等复杂模型，单个模型的大小可达几 GB。三维数据的预处理过程比其他数据更加复杂，涉及纹理映射、几何重建等多个步骤，这些处理不仅消耗大量计算资源，还可能增加数据体积。此外，三维模型通常由多个文件组成，文件数量庞大，随着数据量的增长，管理这些文件的难度也会增加。

image: 3D-AIGC 模型特点
caption: 3D-AIGC 不同模型数据处理特点

由上述环节的存储特点，我们希望构建的存储平台能够满足以下几项要求：

多样的数据格式与跨节点共享：不同模型的数据格式差异较大，特别是三维模型的格式复杂性和跨平台兼容问题，存储系统需要支持多种格式，并有效管理跨节点和跨平台的数据共享。
可以处理不同尺寸的数据模型：无论是语言模型的小文件、大规模图片/视频数据，还是三维模型的大文件，存储系统必须具备高扩展性，以应对快速增长的存储需求，并高效处理大尺寸数据的存储和访问。
跨云与集群存储的挑战：随着数据量的增加，特别是三维模型的 PB 级存储需求，跨云和集群存储问题愈加突出。存储系统需要支持跨区域、跨云的无缝数据访问和高效的集群管理。
方便扩容：无论是语言模型、图片/视频模型，还是三维模型，扩容需求始终存在，尤其是三维模型的存储和处理对扩容的需求更高。
简单的运维：存储系统应提供简便的管理界面和工具，尤其是对于三维模型的管理，运维要求更高，自动化管理和容错能力是必不可少的。

02 存储方案探索：从 NFS、Gluster、CephFS 到 JuiceFS

前期方案：NFS 挂载

最初，我们采用了最简单的方案——使用 NFS 进行挂载。然而，在实际操作中，我们发现训练集群和渲染集群需要各自独立的集群来进行挂载操作。这种方式的维护非常繁琐，尤其是当添加新的数据时，我们需要单独为每个新数据写入挂载点。到了数据量达到约 100 万物体级别时，我们已经无法继续维持这种方案，因此在早期阶段，我们就放弃了这一方案。

image: NFS 的存储架构
caption: 基于 NFS 的存储架构：扩容困难、运维复杂

中期方案：GlusterFS

GlusterFS 是一个相对易于上手的选择，安装配置简单，性能也能得到一定保障，且无需划分多个挂载点，只需增加新节点即可。虽然在前期使用时，GlusterFS 大大减轻了我们的工作量，但我们也发现它的生态系统存在一些问题。

首先，GlusterFS 许多执行脚本和功能需要手动编写定时任务。特别是在添加新存储时，它还会有一些额外要求，例如需要按特定倍数增加节点。此外，像克隆、数据同步等操作的支持也相对较弱，导致我们在使用过程中频繁查阅文档，且许多操作并不稳定。例如，使用 FIO 等工具进行测速时，结果并不总是可靠。

image: Gluster 的存储架构
caption: 基于 Gluster 的存储架构

更为严重的问题是，当存储的小文件数量达到一定规模时，GlusterFS 的性能会急剧下降。举个例子，一个模型可能会生成 100 张图片，若有 1000 万个模型，就会产生 10 亿张图片。GlusterFS 在后期的寻址变得极为困难，尤其是小文件过多时，性能会显著下降，导致系统崩溃。

最终选型：CephFS vs JuiceFS

随着存储需求的增加，我们决定转向可持续性更好的方案。在评估了多种方案后，我们主要对比了 CephFS 和 JuiceFS。虽然 Ceph 被广泛使用，但通过自己的实践和对比文档，我们发现 Ceph 的运维和管理成本非常高，尤其对于我们这样的小团队来说，处理这些复杂的运维任务显得尤为困难。

JuiceFS 有两个原生自带的特性非常符合我们的需求。首先是客户端数据缓存功能。对于我们的模型训练集群，通常会配备高性能的 NVMe 存储。如果能够充分利用客户端的缓存，便能显著加速模型训练，并减少对 JuiceFS 存储的压力。

其次，JuiceFS 对 S3 的兼容性对我们也至关重要。由于我们基于存储开发了一些可视化平台用于数据标注、整理和统计，S3 兼容性使得我们能够快速进行网页开发，支持可视化和数据统计操作等功能。

image: cephvsjfs
caption: CephFS vs JuiceFS （来源：JuiceFS 文档）

03 基于 JuiceFS 的存储平台实践

元数据引擎选择与拓扑

JuiceFS 采用的是元数据与数据分离的架构，有多种元数据引擎可供选择。我们首先快速验证了 Redis 存储方案，官方提供了详细的文档支持。Redis 的优势在于其轻量化，配置过程通常只需一天或半天时间，数据迁移也相对顺利。然而，当小文件数量超过 1 亿时，Redis 的速度和性能会显著下降。

image: JuiceFS 架构图（第四版）-第 2 页-winfsp (2)
caption: JuiceFS 社区版架构图

正如之前提到的，每个模型可能会渲染出 100 张图片，再加上其他杂项文件，导致小文件的数量急剧增加。虽然我们可以通过打包小文件来减轻问题，但一旦打包后进行修改或可视化操作，复杂性就大大增加。因此，我们希望能够保留原始的小图片文件，以便后续处理。

随着文件数量的增加，很快超出 Redis 的处理能力，我们决定将存储系统迁移到 TiKV 和 Kubernetes 组合上。TiKV 与 K8s 的组合能够为我们提供更高可用的元数据存储方案。此外，通过基准测试我们发现，尽管 TiKV 的性能稍逊一筹，但差距并不显著，且相较于 Redis，它对小文件的支持更好。我们也咨询过 JuiceFS 的工程师，了解到 Redis 在集群模式下的扩展性较差，于是我们准备切换到 TiKV。

image: 数据测试
caption: 使用不同元数据的读写性能测试

最新架构：JuiceFS + TiKV + SeaweedFS

我们使用了 JuiceFS 来管理对象存储。TiKV 和 K8s 来搭建元数据存储系统。对象存储部分使用了 SeaweedFS，这使得我们能够快速扩展存储规模，且无论是小数据还是大数据，访问速度都很快。此外，我们的对象存储分布在多个平台：包括本地存储、阿里云存储以及国外的 R2 和 Amazon 对象存储。通过 JuiceFS，我们能够将这些不同存储系统集成起来，并提供一个统一的接口。

image: JuiceFS + TiKV + Seaweed
caption: 存储架构： JuiceFS + TiKV + SeaweedFS

为了更好地管理系统资源，我们在 K8s 上搭建了资源监控平台。当前系统由大约 60 台 Linux 机器和若干 Windows 机器组成，负责渲染和数据处理任务。我们对读取稳定性进行了监控，结果显示，即使是多台异构服务器同时进行读取操作，整个系统的 I/O 性能依然非常稳定，基本能够充分利用带宽资源。

image: 资源监控
caption: 资源监控面板

实践中遇到的问题

在优化存储方案的过程中，我们最初尝试了 EC（纠删码）存储方案，旨在减少存储需求并提升效率。然而，在大规模数据迁移中，EC 存储的计算速度较慢，并且在高吞吐量和频繁数据变化的场景下，性能表现不佳，尤其与 SeaweedFS 结合时，存在性能瓶颈。基于这些问题，我们决定放弃 EC 存储，转而采用副本存储方案。

我们设置了独立服务器并配置了定时任务，以进行大数据量的元数据备份。在 TiKV 中，我们实现了冗余副本机制，采用了多个副本方案来确保数据的完整性。同时，在对象存储方面，我们采用了双副本编码来进一步提高数据可靠性。虽然副本存储能够有效保证数据冗余和高可用性，但由于处理 PB 级数据和大量增量数据，存储成本依然较高。未来，我们可能会考虑进一步优化存储方案，以降低存储成本。

另外，我们也发现当使用全闪存服务器 + JuiceFS 并未带来显著的性能提升。瓶颈主要出现在网络带宽和延迟上。因此，我们计划在后期考虑使用 InfiniBand（IB）连接存储服务器和训练服务器，以最大化资源利用效率。

04 小结

在使用 GlusterFS 时，我们每天最多只能处理 20 万个模型；而切换到 JuiceFS 后，处理能力大幅提升，日均数据处理能力增加了 2.5 倍，小文件吞吐能力也显著提高，特别是在存储量达到 70% 后，系统仍能保持稳定运行。此外，扩容也非常便捷，而之前的架构，扩容过程非常繁琐，操作起来比较麻烦。

image: NFS vs JuiceFS
caption: NFS vs JuiceFS

最后再总结一下 JuiceFS 在三维生成任务中表现出来的优势：

小文件性能：小文件处理能力是一个关键点，JuiceFS 依然提供了一个较好的解决方案。
跨平台特性：跨平台支持非常重要。我们发现有些数据只能在 Windows 软件中打开，因此需要同时在 Windows 和 Linux 系统上处理相同的数据，并在同一个挂载节点上进行读写。这种需求使得跨平台的特性尤为关键，JuiceFS 的设计很好地解决了这一问题。
低运维成本： JuiceFS 的运维成本极低。配置完成后，只需要进行一些简单的测试和节点的管理（例如，丢弃某些节点并监控鲁棒性）。我们在迁移数据时花费了大约半年的时间，到目前为止并未遇到太大的问题。
本地缓存机制：之前，如果想使用本地缓存，我们需要手动在代码中实现本地缓存逻辑，但 JuiceFS 提供了非常方便的本地缓存机制，通过设置挂载参数来优化训练场景的性能。
迁移成本低：尤其是在迁移小文件时，我们发现使用 JuiceFS 进行元数据和对象存储的迁移非常方便，节省了我们大量时间和精力。相比之下，之前使用其他存储系统迁移时，过程非常痛苦。

综上所述，JuiceFS 在大规模数据处理中的表现非常出色，提供了高效、稳定的存储解决方案。它不仅简化了存储管理和扩容过程，还大大提升了系统性能，让我们能够更加专注于核心任务的推进。

此外，官方提供一些工具也非常便捷，例如我们使用 Sync 在处理小文件迁移时，效率极高。在没有额外性能优化的情况下，我们成功迁移了 500TB 的数据，其中包含大量的小数据和图片文件，迁移时间不到 5 天，结果超出我们的预期。

JuiceFS 2025：迈入千亿文件规模，开源第五年持续高速增长

Wed, 31 Dec 2025 08:25:00 +0000

又到了给大家汇报全年社区工作的时候。2025 年， JuiceFS 企业版发布的第九年，社区版的第五年。这一年，我们专注一如既往，打造一款高效易用的文件系统。

各项使用指标延续了上一年的增长势头，社区版数据量增长 89%，超 1.3 EB；营收连续第三年 100% 增长，是我们持续投入社区的坚实保障。

2025 年，JuiceFS 社区版继续聚焦通用性，尤其在支持各类 AI 场景的需求。发布了 Python SDK、增强 Windows 客户端可用性，并加强了对云原生生态的支持；此外，元数据引擎 SQL 和 TiKV 也进行了针对性优化。今年，团队与社区成员一道推动了 JuiceFS 的持续迭代，共有 60 位贡献者参与，新增了 305 个 Issue，合并了 601 个 PR。

在企业版的开发过程中，团队今年面临的最大挑战来自于超大规模数据的管理。随着自动驾驶等 AI 技术逐渐融入日常生活，数据规模的增长是空前的，在千亿文件级别下，元数据管理、数据一致性等方面的管理复杂度指数级增加。为应对这些难题，企业版在元数据分区、网络性能等核心特性上进行了全面升级。上半年发布的企业版 5.2 已支持单卷千亿规模，即将发布的 5.3 版本更将支持 5,000 亿规模，让用户不必再为数据规模发愁，JuiceFS 的性能和稳定性也都能够稳妥保障。

01 社区版：支持 Python SDK、 Windows 客户端可用性大幅提升

JuiceFS 自开源以来已在企业生产环境中得到了长时间的验证，核心功能逐步趋于稳定。全年发布了 9 个版本，其中 1.3 版本是继 2021 年开源以来的第四个重要版本，并作为长期支持版本（LTS）。该版本的主要优化包括：

支持 Python SDK ，提升了 AI 和数据科学场景下的灵活性和性能；
Windows 客户端的优化，增强了工具支持和系统服务挂载能力；
备份机制优化，1 亿文件备份分钟级完成；
集成 Apache Ranger，JuiceFS 支持大数据场景中的细粒度的权限管理；
元数据引擎方面，SQL 和 TiKV 的性能提升，在超大规模场景下表现更加高效。

下半年，团队开始积极筹备 1.4 ，计划新增多个特性，包括用户和用户组 Quota 支持、Redis 客户端缓存支持、LRU 缓存支持、SMB/CIFS 支持、Hadoop Kerberos 支持、S3 Gateway 优化、Sync 工具断点续传，数据商业算法加密支持，预读策略优化、批量删除优化和周边工具优化等，以进一步提升系统的性能和稳定性。

image: 11
caption

JuiceFS CSI Driver 在过去一年发布了 18 个版本，持续优化 JuiceFS 在 Kubernetes 等环境中的存储效率和稳定性。新增功能包括卷路径健康状态检测、同一文件系统共享 Mount Pod 功能、支持 Kubernetes 原生 Sidecar，以及 Dashboard 的 CacheGroup 管理。此外，还进行了性能和可靠性优化，不仅提升了稳定性，同时改进了多 Pod 配置和容器化应用的兼容性。

JuiceFS Operator，新增了定时缓存预热功能，提升业务访问数据的性能；支持按副本部署的 CacheGroup，实现了缓存高可用性；并引入 Sync 功能，在 Kubernetes 环境中高效同步数据，确保一致性。

image: csi contributor
caption

02 企业版：单卷千亿规模文件，强劲性能与稳定性保障

2025 年上半年，JuiceFS 企业版 5.2 版本发布，单个文件系统突破千亿文件的规模，并显著提升了超大规模集群的稳定性和分布式缓存的网络性能。为了实现这一目标，团队投入了大量时间和精力进行优化，特别是在处理超大数据集和高并发访问时的性能提升。该版本已在多个企业的生产环境中得到验证，单卷千亿文件规模下保持 1 毫秒元数据时延水平。同时，分布式缓存网络性能优化，TCP 网络下大幅减少 CPU 开销，同时提升网络带宽利用率。在 100 台 GCP 100Gbps 节点的环境下，聚合读带宽达到 1.2 TB/s，接近满负荷利用 TCP/IP 网络带宽。

此外， Python SDK 实现了 fsspec 兼容、按需导入对象存储文件，可以更方便的访问对象存储存量数据、解决特殊场景中的读放大问题以及提升全局 QoS 能力，进一步增强了系统的灵活性和性能。

多分区架构是 JuiceFS 应对千亿文件规模的关键技术之一，保证了系统的高扩展性和高并发处理能力。下半年我们的核心工作集中在 5.3 版本，对多分区架构进行了全面优化，分区限制从 256 个提升至 1,024 个，可实现单卷超过 5,000 亿文件的存储和访问需求。

这背后是一系列复杂的工作，包括系统化整理跨分区链接实现，并实现后台自检机制，提升集群的可靠性与稳定性；开发热点监测与自动迁移工具，高效处理热点问题；优化分布式缓存管理，减少缓存冲突并提高并发性能；此外，为了进一步优化分布式网络的性能，在这个版本中首次引入了 RDMA 技术，目前处于实验阶段，测试结果显示其在稳定性和 CPU 使用率方面优于 TCP 协议。5.3 版本将于 1 月发布，更多细节，欢迎关注。

03 社区发展，第 5 年高速成长，数据总量超 1.3EB

目前，JuiceFS GitHub star 超 12.6K；JuiceFS 下载量突破了 5 万次，CSI Driver 的下载量超过了 500 万次；中文社区已经有 10 个微信群组，Slack 英文社区也达千人。

社区版开源的第 5 年，也是快速增长的第 5 个年头。用户上报数据显示，JuiceFS 的各项关键数据延续了增长趋势：

文件系统 590K+，增长 82%
活跃客户端 150K+，增长 46%
文件数量 4000 亿+，增长 43%
数据总量 1.3EiB+，增长 89%

image: 2025数据增长
caption

今年，我们在多个行业大会分享实践，KCD 、开源年会、CommunityOverCode Asia 等，感谢这些大会主办方对 JuiceFS 的认可；在海外行业会议也展露头脚，参与了 KubeCon+CloudNative Con North America、Opensource Summit Japan、SNIA Developer Conference 等。

为了更好地为用户提供支持，我们定期举办 Office Hours，介绍新功能、解答疑问；同时，举办了 11 场 Meetup，帮助不同行业的用户更有信心地将 JuiceFS 应用于生产环境。案例涵盖自动驾驶、生成式 AI、AI 基础平台、量化投资、生命医药等多个领域。（查看所有案例）

特别感谢以下今年参与分享的用户，他们的实践经验为社区提供了宝贵的参考：

丁聪，Lepton AI，加速 AI 训推：构建多租户、低延迟云存储平台
孙玮，中国科学院计算所，基于 JuiceFS 的大模型训推平台存储演进之路
郑泽东，百图生科，基于 JuiceFS 构建生命科学大模型存储平台，成本降 90%
吴松林，携程，稳定且高性价比的大模型存储：携程 10PB 级 JuiceFS 工程实践
唐义凡，合合信息，基于 JuiceFS 构建统一存储，支撑 PB 级 AI 训练
缪昌新，阶跃星辰，如何利用 JuiceFS 打造高效经济的大模型存储平台
可加，稿定科技，多云架构下的 AI 存储挑战与 JuiceFS 实践
邓君宇，九识智能，基于 JuiceFS 的自动驾驶多云亿级文件存储
高玉堂， Ariste AI，JuiceFS + MinIO：量化投资高性能存储实践
李威宇，光影焕像，基于 JuiceFS 搭建 3D AIGC 存储平台，数据性能 2 倍提升
刘道全，始智 AI，基于 JuiceFS 打造高性能、低成本 AI 模型管理存储平台
高杨，酷睿程，自动驾驶百 PB 级云原生存储案例
曾奥涵，智谱 AI，大模型训练基础设施落地实践

亲爱的社区伙伴们，我们一起度过了充实的一年。JuiceFS 从一个开源新秀，成长为今天 AI 业务中备受信任的选择，衷心感谢每一位社区成员的参与与支持，感谢你们在群里解答问题、分享实践、贡献代码！

新的一年里，JuiceFS 将继续为你的工作带来更高效、更轻松的体验。

JuiceFS + MinIO：Ariste AI 量化投资高性能存储实践

Mon, 08 Dec 2025 07:06:44 +0000

Ariste AI 是一家专注于 AI 驱动交易的公司，业务涵盖自营交易、资产管理、高频做市等多个领域。在量化交易研究中，数据的读取速度和存储效率，往往直接决定了研究迭代的速度。

Ariste AI 团队在构建量化研究基础设施的过程中，面对总规模超过 500TB，行情与因子数据，经历了从本地盘到最终选择在 MinIO 对象存储之上叠加 JuiceFS 文件系统的四个阶段。通过缓存机制与分层架构，团队实现了高频数据的快速访问与集中管理。这一实践验证了“缓存加速、弹性对象存储与 POSIX 兼容”三位一体方案在量化场景下的可行性，希望这一经验能为同行提供一些参考。

01 量化投资存储挑战：规模、速度与协作的平衡

量化投资流程依次包括数据层、因子与信号层、策略与仓位层及执行与交易层，构成从数据获取到交易执行的完整闭环。

image: 量化业务流程示意图
caption: 量化业务流程示意图

在整个过程中，存储系统面临多重挑战，主要体现在以下几个方面：

数据规模与增速：量化研究所需处理的数据总量较大，涵盖历史行情数据、新闻数据以及自行计算的因子数据等。目前，这些数据的总量已接近 500T。并且，企业每日新增的行情数据也达数百 GB。若采用传统磁盘进行存储，显然无法满足如此巨大的数据存储需求。
高频访问与低延迟要求：高频的数据访问依赖于低延迟的数据读取。数据读取的速率直接决定了研究效率的高低。若数据读取速度较快，研究进程便能迅速推进；反之，则会导致研究效率低下。
多团队并行与数据治理：在量化研究过程中，通常会有多个团队同时开展不同的实验。为确保各团队研究工作的独立性与数据安全性，需要进行安全的隔离，以避免数据混淆与泄露。

为应对上述量化全流程对数据存储的需求，打造面向未来的存储系统，我们的目标是实现：高性能、易扩展与可治理，三者有机统一：

高性能：单节点读写带宽突破 500MB/s，访问延迟低于本地磁盘感知阈值；
易扩展：支持存储与计算资源按需水平扩容，业务无需改造即可实现平滑弹性伸缩；
可治理：提供细粒度权限控制、操作审计与数据生命周期策略的一站式管理能力。

02 存储架构的演进

阶段一：本地盘极速起步

在项目初期，我们采用了 Quantrabyte 研究框架，该框架内置了 ETF 模块，可直接将数据存储在本地磁盘上，数据读取速度较快。研究员可根据自身需求，直接运行所需数据，迭代过程较为迅速。然而，这一阶段也存在一些问题：

重复下载造成资源浪费：多个研究员若使用相同数据，会进行多次下载。
存储容量不足：研究服务器的存储容量有限，仅约 15T，难以满足日益增长的数据存储需求。
协作困难：当需要复用他人的研究结果时，操作过程不够便捷。

阶段二：MinIO 集中管理的双刃剑

为解决第一阶段存在的问题，我们引入了 MinIO 进行集中管理。将所有存储数据集中在 MinIO 上，通过拆分出的模块将数据全部存入。同时，将具体因子数据也存入 MinIO，实现公共数据的统一下载。并通过权限隔离，实现多团队数据共享，提升存储空间利用率。

然而，这一阶段也出现了新的瓶颈：

高频随机读延迟大：在进行高频数据 I/O 操作时延迟较大，影响数据读取速度。
无缓存导致读写慢：由于 MinIO 社区版无缓存功能，读写高频公共数据时速度较慢。

阶段三：JuiceFS 引入缓存加速

为解决上述瓶颈，经充分调研，我们最终引入 JuiceFS 的缓存加速方案。该方案通过客户端本地 RAID5 存储进行挂载，借助高效的缓存机制，成功将读写性能提升约三倍，显著改善了高频共享数据的访问体验。

image: 2
caption

随着业务数据量突破 300TB，本地存储的扩容瓶颈逐渐显现。由于数据存储在本地，扩容需重新配置存储设备，而 RAID5 架构下扩容速度缓慢且风险较高，难以满足业务持续增长的需求。

阶段四：JuiceFS + MinIO 集群终局架构

为解决扩容难题，我们最终采用了JuiceFS+MinIO 集群架构。该方案具备以下优势：

持续高性能：JuiceFS 提供充足的缓存能力，充分满足高频数据访问场景的性能需求；
便捷集群扩展：基于集群化方案，可快速实现横向扩容，仅需添加同类型磁盘即可灵活提升存储容量，大幅增强系统扩展性。

image: 3
caption

通过四阶段演进，我们验证了缓存加速、弹性对象存储与 POSIX 兼容三位一体方案在量化场景的可行性。此方案可为同行业提供可复制、可落地的最佳实践范本，在性能、成本与治理之间取得了卓越平衡。

03 性能与成本收益

通过采用 JuiceFS 与 MinIO相结合的存储架构，系统带宽与资源利用效率得到质的飞跃，目前已完全满足研究业务对存储性能的需求。引入 JuiceFS 缓存层后，回测任务执行效率大幅提高，1 亿条 Tick 数据回测耗时由之前的数小时降至数十分钟。

image: 读写带宽变化
caption: 读写带宽变化

同时，基于我们完整的数据生命周期分层存储体系策略，实现存储单价由高到低的平滑过渡，整体存储成本下降40% 以上。

image: 数据生命周期分层存储策略
caption: Ariste AI 数据生命周期分层存储策略

04 运维实践与展望

多租户治理

在数据隔离与权限管理方面，我们建立了完善的管理体系：

通过命名空间实现逻辑隔离，采用类似 /factor/A、/factor/B 的路径规划，确保各业务数据边界清晰。在权限控制层面，支持用户、团队、项目三个维度的精细化管理，并与 POSIX ACL 权限体系无缝对接。同时建立完整的审计日志系统，实现访问行为的实时追踪与变更历史回溯，全面满足合规性要求。

可观测性与自动化运维

我们围绕四大核心指标构建了完整的监控体系：缓存命中率、I/O 吞吐量、I/O 延迟与写入重试率，系统在指标异常时可自动触发告警。

基于 Grafana 实现了运维闭环管理，持续监控节点健康状态与存储容量。在每次扩容前，会通过模拟压测验证系统承载能力，确保业务无感知。整体运维体系实现了自动化、可预测、可回滚的高标准运维目标。

回测系统中的数据更新设计

我们在回测系统设计中采用基于 DAG（Directed Acyclic Graph，有向无环图）的架构，以提升系统的计算效率与可维护性。该框架以计算节点和依赖关系为核心，将数据处理、特征计算、信号生成等环节抽象为节点，并通过依赖图统一管理。系统内置版本控制机制，当数据版本更新时，可依托依赖图自动识别受影响的节点，精确定位需重算部分，从而实现高效的增量更新与结果追溯。

image: 回测数据版本更新示意图
caption: 回测数据版本更新示意图

未来展望

在未来规划中，我们将从以下三个方向持续优化存储架构：

元数据高可用升级：计划将元数据存储从 Redis 迁移至 TiKV 或 PostgreSQL，以构建跨机房高可用架构，显著提升系统容灾与快速恢复能力。
混合云分层存储：通过对接公有云 S3 与 Glacier 存储服务，构建智能冷热分层体系，在实现存储容量无限弹性的同时，达成成本最优化目标。
研究数据湖统一治理：计划构建统一的研究数据湖平台，集成 Schema 注册、自动数据清洗与统一目录治理等核心服务，全面提升数据资产的发现与管理效率。

JuiceFS Blog

浅析 Amazon S3 Files：工作机制、性能边界与 JuiceFS 对比

01 S3 Files ：以 EFS 为高性能层的 S3 原生文件系统方案

02 S3 Files 如何工作：挂载、导入与同步机制

a) 先确定作用域：导入全量 S3 桶，还是指定部分目录

b) 首次访问时会发生什么：导入触发方式与大小阈值

c) 同步周期与冲突解决机制

03 S3 Files 的性能边界与成本结构

a) EFS 高性能层的占用、回收与成本

b) 大文件直读与随机读：其实是客户端在“穿透”读取

c) 顺序写的代价：大规模写入会引入额外流转成本

d) 局部更新与目录操作：对象模型带来的放大效应

04 JuiceFS vs S3 Files：两种不同的架构思路

05 小结

一文解锁 JuiceFS 在 AI 场景中的性能优化

01 从架构看 JuiceFS 的性能基础

数据分块设计

缓存体系

02 JuiceFS 基准 I/O 测试与瓶颈分析

连续读性能

随机读性能

低并发随机读

高并发随机读

03 常见 AI 场景下的 I/O 特性与性能调优

大文件顺序读场景

海量小文件场景

大文件随机读场景

ARM 架构 JuiceFS 性能优化：基于 MLPerf 的实践与调优

01 Arm64 与 x86_64 架构差异与并发特性概述

02 JuiceFS 与 MLPerf 概述

03 MLPerf Storage v2.0 测试原理与调优

测试 1：Unet 3d

优化分析 1：绑定 CPU

优化分析 2： 不进行 CPU 绑定

测试 2：Resnet50

优化分析 1： 单机性能瓶颈与内存带宽影响

优化分析 2：双机扩展瓶颈与分布式限制

测试 3：cosmoflow

优化分析 1：单机瓶颈：内存拷贝限制 GPU 利用率

优化分析 2：双机瓶颈：分布式同步与元数据延迟

04 总结

韩国国民搜索 NAVER：使用 JuiceFS 打通 Hadoop 与 Kubernetes 存储实践

01 HDFS 的局限

02 对象存储的优势与劣势

03 在 Hadoop 中使用 JuiceFS

配置 JuiceFS

Hadoop SDK

HDFS CLI

MapReduce

Spark

04 JuiceFS 改进事项

支持 all-squash 挂载（#5394）

改进 juicefs.users 和 juicefs.group 设置方式（#4723）

支持 subdir（#6096）

通过 hdfs 命令查看配额（#5937）

支持 Prometheus remote_write 协议（#6295）

05 JuiceFS 的优势

优势 1：通过并行处理和缓存克服对象存储的性能瓶颈

DFSIO

TPC-DS

优势 2：与 HDFS 完全兼容，无需修改现有 Hadoop 应用即可使用

优势 3：支持多种接口，可作为跨平台集成存储

06 结语

海量小文件 + 多云协同：地瓜机器人 JuiceFS 存储优化之路

01 机器人行业的存储痛点

02 存储选型：JuiceFS vs. MinIO/S3 vs. PFS

03 从社区版到企业版，应对更大规模场景需求

04 JuiceFS 调优攻略

05 小结与展望

JuiceFS 企业版 5.3 特性详解：单文件系统支持超 5,000 亿文件，首次引入 RDMA

01 单文件系统支持超 5,000 亿文件

关键优化 1 - 分区间热点均衡：自动监测和热点迁移；提供手动运维工具

关键优化 2 - 大规模迁移：提升迁移速度，少量多次并发迁移

关键优化 3 - 强化可靠性自检：自动修复与清理迁移中间态文件

千亿文件性能压测：稳定性与资源利用良好

02 首次支持 RDMA：带宽上限提升，CPU 占用降低

03 可写镜像增强

04 简化运维管理，提升灵活性：为导入对象提供跨桶数据缓存

05 其他重要优化

06 小结

优化分析 2：不进行 CPU 绑定

优化分析 1：单机性能瓶颈与内存带宽影响