当 AI 业务的数据规模从 PB 走向 EB，文件系统面对的就不再是单一的容量问题。文件数增长到千亿级，客户端从几千个扩展到几十万甚至百万个，训练吞吐持续提高，数据回收、跨云访问、多租户隔离和日常运维等压力也随之放大。这些压力最终落在元数据引擎、数据生命周期、数据路径以及客户端与控制面四条技术主线上。
上一篇介绍了地平线 AIDI 基于 JuiceFS 社区版的 EB 级实践。本文聚焦 JuiceFS 企业版，介绍这四条技术主线如何在 EB 级数据、千亿文件和百万级客户端的规模压力下持续演进。
1.元数据引擎：从单节点能力到千亿文件水平扩展
1.1 千亿文件规模下的元数据压力
文件数达到千亿级后，元数据访问会暴露三个问题。一是热点集中：训练高峰期，少量热点目录与高频操作会让单个元数据节点成为瓶颈。二是延迟放大：路径解析、属性查询、文件打开都要访问元数据，任何额外往返都会直接拖慢训练任务。三是规模压力：回收站等大目录可达数百亿个目录项，挂载配置、容量信息等全局数据被反复查询。
面向这类规模，企业版从元数据引擎本身入手，通过自研元数据服务打散热点、降低访问延迟，并支持水平扩展。
1.2 元数据引擎设计：全内存、无锁与多分区
企业版元数据引擎采用全内存 + 单线程无锁 + Raft 的设计。所有核心数据结构在单线程中处理，天然保证操作原子性，避免多线程锁竞争带来的延迟尖刺；全内存让请求不必回落磁盘，单请求处理时间维持在百微秒量级；Raft 负责多机复制与自动故障切换。在 30 GiB 内存下，单个元数据进程可以管理约 3 亿个文件。
但全内存也意味着内存用量直接决定硬件成本。在千亿文件规模下，单文件内存占用的微小差异会被放大成巨大的资源开销。通过内存池、手动内存管理、空闲目录序列化压缩、小文件紧凑格式等手段，企业版把文件元数据平均内存占用从最初近 600 字节降至约 100 字节——约为 HDFS NameNode 的 27%、CephFS MDS 的 3.7%。
| 系统 | 单文件元数据内存占用 | 说明 |
|---|---|---|
| HDFS NameNode | 约 370 B | 第三方技术博客 |
| CephFS MDS | 约 2,700 B | Ceph 集群监控（32 GB 内存 / 1,200 万文件） |
| Alluxio（堆内存模式） | 约 2,100 B | Alluxio 文档：64 GB 内存约 3,000 万文件 |
| JuiceFS 社区版 | 约 430 B | 社区版文档 |
| JuiceFS 企业版 | 约 100 B | 生产集群监控（30 GB 内存 / 3 亿文件） |
更高的内存效率意味着：同样的硬件可以承载更多文件，换句话说，千亿文件规模所需的元数据成本被显著压低。
在单进程之上，企业版通过多分区（Zone） 水平扩展：每个分区负责文件树的一部分，由客户端组装成单一命名空间；子树尽量保持完整，让绝大部分操作落在单一分区内，减少分布式事务；跨分区迁移通过链接与引用完成，对 POSIX 路径透明；超大目录还可以拆分为多个虚拟子目录，获得更细的迁移粒度，避免单个大目录长期压在某个分区上。每个 inode 的高位携带分区信息，客户端自动感知分区拓扑并连接所有分区——新增分区无需修改业务访问方式。
可靠性方面，每个分区由三个实例组成（服务 / 热备 / 冷备实例），服务与热备实例采用差异化的内存压缩策略，快照与变更日志持续落盘并可异地备份（见 2.2 节）。
1.3 版本演进与规模验证
v5.2 开始，企业版重点优化多分区稳定性和元数据内存占用，文件管理规模进入千亿级。生产环境中，单集群已管理超过 500 亿文件，元数据访问延迟维持在毫秒级。
到了 v5.3，分区上限提升至 1,024 个，单文件系统可支持超过 5,000 亿个文件。与此同时，系统开始支持热点自动迁移，并提供相应的运维工具：高访问目录可以拆分为更小的单元并发迁移，以更快地分散热点；周期性自检则用于发现并修复跨分区迁移过程中可能遗留的中间状态。
v5.4 进一步把扩展重点从文件数量延伸到客户端规模。元数据节点与网络代理可合并部署，客户端可以连接任一节点，跨分区请求由集群内部转发；配合连接复用，客户端接入规模提升到百万级，相关设计将在第 4 节展开。
2.数据生命周期：把删除、恢复与审计内建为系统能力
2.1 PB 级删除下的数据生命周期压力
PB 级删除不仅要求空间及时回收，还要兼顾误删恢复、删除追溯和遗漏对象审计。对象存储侧持续产生数十亿待回收对象，一次误删可能影响训练任务，而异常残留对象也需要被持续发现和确认。
2.2 回收站、后台任务与审计备份
回收站是企业版的默认能力：删除先进入回收站，保留期可配置（常见 7 天）；保留期内可通过控制台或恢复命令自助恢复，恢复是元数据操作，不复制数据本体。v5.3 起，多分区环境下的回收站会记录文件的原始路径，保证恢复位置可靠；v5.4 支持按删除时间窗口与关键词筛选，帮助业务在海量删除中定位误删目标。
空间回收由统一的「后台任务」体系完成：碎片合并、回收站清理、跨云复制等任务由元数据服务调度到全集群客户端并行执行。这套机制带来三个直接收益：删除能力随客户端数量扩展——要加快回收，增加挂载点即可；速率可控——可按访问令牌限制删除流量、关闭指定客户端的后台任务，碎片合并的执行时间窗则由元数据服务统一配置；执行可观测——碎片合并与删除任务都有监控指标可查。
审计与容灾同样内建：变更日志记录了每一次删除操作及其来源会话，配合审计日志可以定位「谁在什么时间删除了什么」；元数据快照与变更日志由控制台集中配置，默认每小时备份到异地对象存储，本地保留 2 天、建议备份至少 30 天。对象存储侧的遗漏对象由垃圾回收与一致性检查工具负责审计；v5.4 为这两个工具增加外部排序模式，用磁盘分担排序内存，检查亿级文件时内存占用可控（外排模式仅用于检查评估，不执行删除）。
2.3 数据洞察与数据集分支
删除决策需要数据支撑：控制台监控提供回收站文件数、待删除对象分片、碎片等指标；文件查找在元数据侧完成过滤，用于冷热与老化分析；目录 / 用户 / 组配额约束各业务的容量预算。
为训练准备数据集分支时，v5.4 的跨分区目录克隆在 1 亿文件规模下耗时约 1 分 40 秒，相当于每秒约 100 万个文件。
3.数据路径：用缓存、镜像兼顾性能与成本
3.1 EB 级数据访问：吞吐、存储成本与跨云访问
训练需要 TB/s 量级的吞吐：数据集加载是大量随机读，训练检查点写入则是大文件顺序写，两类负载对 IOPS 与写吞吐的要求不同；EB 级容量不可能全部放在热层；算力跨云部署还要求数据尽量就近访问。读性能、容量成本与数据位置，必须一起解决。
3.2 多级缓存与分布式缓存组
企业版把「客户端间共享缓存」做成了产品化的分布式缓存：多个客户端可以组成缓存组，基于一致性哈希共享数据块；节点故障会被自动摘除，未命中的请求穿透到对象存储，读服务不中断。业务客户端也可以配置为仅使用缓存、不对外提供缓存数据，由一组稳定节点组成专用缓存集群，专门服务训练热数据。读取路径同样是分级的：从缓存组取回的数据会继续缓存在客户端本地，重复访问不再经过网络。
围绕缓存组的运维与效率，企业版提供了一整套工具：数据预热、缓存组备份（提升成员变动期的命中率）、扩容保护（新节点未命中时先向旧节点取数，减少回源）、未命中不回填（保护热点数据）、缓存块合并（降低大缓存盘上的文件数量）、按字节区间精准预热。传输层则通过自研 IORPC 协议（v5.2）与 RDMA（v5.3 起）持续优化。
这条路径上的量化参考：v5.2 使用 100 台 100Gbps 节点，聚合读带宽达到 1.2 TB/s；v5.3 在 160Gbps 网卡、1MB 随机读场景下，CPU 占用降至 TCP 方案的约 1/3；v5.4 在 400Gbps 客户端和 800Gbps 缓存节点环境下，单客户端读带宽 45 GB/s、单缓存节点 90 GB/s、网卡利用率超过 90%，高并发随机读 IOPS 较此前提升一倍以上。
3.3 跨地域镜像与按需同步
要让数据贴近算力，企业版提供镜像文件系统：在镜像区域部署元数据副本，元数据持续同步；客户端优先读本地对象存储；写入采用读写分离，提交到源集群，保证跨区域一致性。v5.3 起，镜像不可用时读请求可回退到源集群；v5.4 进一步支持按需同步——只持续同步元数据，对象数据在首次访问时按需拉取并缓存在本地，避免为了少量访问同步整个数据集。如果只需要加速元数据读取，还可以直接部署只读元数据节点。
3.4 弹性与存量数据接入
数据底座是对象存储：容量按需扩缩，一个文件系统即可统一管理来自不同区域、不同供应商的多个桶，并为所有桶提供缓存能力。对于已经存在于对象存储中的存量数据，可以通过导入功能透明接入——只写元数据、不拷贝数据；v5.2 起支持按需导入（首次访问触发），v5.3 起任意导入对象都能获得缓存加速。热数据由缓存与镜像承载，冷数据留在对象存储，EB 级容量成本不再需要按峰值规划。
4.客户端与控制面：支撑百万连接下的隔离、观测与运维
4.1 百万客户端规模下的控制面压力
几十万客户端通过 K8s / CSI、S3 网关、SDK 等方式接入，同时活跃连接达到百万级：任何客户端都可能打爆共享的元数据集群；客户端各自产生数百项指标，直抓会带来时序爆炸；多租户的权限与资源预算必须清晰；升级还要尽量不影响训练任务。
4.2 连接复用：支撑百万客户端
v5.4 把客户端接入能力推进到百万级，核心做法是引入网络代理层（与元数据节点合并或分开部署均可）：客户端可以连接任一元数据节点，本分区请求直接处理，跨分区请求在内部转发；多个客户端会话共用节点间的物理连接。在压测中，10 个内部代理节点承接百万条客户端连接，到元数据服务节点仅需约 400 条后端物理连接。会话管理同步优化：索引定位代替全量遍历，分页查询、采样上报控制状态规模，过期会话分批清理。
4.3 多租户隔离、观测与运维
在多租户环境下，企业版通过令牌控制客户端的访问边界，包括 IP 范围、读写权限、可访问子目录，以及是否参与后台任务。v5.4 在原有单子目录限制的基础上增加白名单机制，可以为客户端配置多个一级子目录。
资源控制则覆盖上传、下载、删除和后台任务等不同流量，并支持会话级 CPU 配额，避免单一租户的负载持续挤占共享集群资源。v5.2 还对全局限速消息做了合并，减少限速状态同步本身带来的开销。
接入层同时保留多种形态，包括 POSIX（FUSE / CSI）、S3 网关、Hadoop SDK、Python SDK 和 Windows 客户端，适配不同训练和数据处理流程。观测侧，控制台集成 Prometheus 与 Grafana，覆盖文件系统、客户端会话和集群健康等指标，也可以接入已有的监控与告警体系。
在日常运维中，v5.2 起支持通过控制台统一升级客户端并收集诊断信息；元数据服务支持滚动、无缝升级。
5.小结
从 v5.2 到 v5.4，JuiceFS 企业版围绕超大规模场景持续演进的重点，并不是增加若干独立功能，而是让元数据、数据生命周期、数据路径和客户端控制面都能够随规模一起扩展。
- 元数据侧，通过全内存引擎、多分区和自动均衡，把单节点能力扩展到千亿乃至更大文件规模；
- 数据生命周期侧，将回收站、后台任务、审计与备份纳入统一机制；
- 数据路径侧，通过分布式缓存、RDMA、镜像和数据导入，让热数据更靠近算力，同时保留对象存储的容量弹性；
- 客户端侧，则通过连接复用、访问控制、限速和统一观测支撑几十万到百万级连接。
这些能力想解决的，是规模增长过程中逐步显现的共性问题：让文件系统自身承接更多基础能力，减少平台团队在文件系统之外额外维护的部分。JuiceFS 企业版目前已在 EB 级生产环境中使用，相关设计仍在持续演进。对于正在规划 AI 数据底座的团队，希望这些设计取舍能为正在规划 AI 数据底座的团队提供一些参考。如果有类似场景或挑战，欢迎在评论区交流。
