九识智能 Zelos 是一家专注于自动驾驶与无人配送技术的高新技术企业，具备自动驾驶系统及 AI 芯片的自主研发与规模化落地能力。公司核心产品已在全国 200 多个城市广泛部署，整车销售市占率超过 90%，在中国 L4 城配自动驾驶领域持续领先。
随着业务迅速扩展，公司数据体量从 TB 级快速增长至 PB 级，原有基于 Ceph 的存储方案面临高昂成本与维护压力，同时在处理小文件、元数据、高并发及延迟等方面逐渐出现性能瓶颈，影响仿真和训练效率。
此外，随着算法迭代加速和跨地域业务部署，多云环境下的数据流转与资源调度需求日益频繁，但存在数据分散、迁移成本高和调度复杂等问题。部分存储工具社区支持有限、响应慢，进一步增加了运维难度。
面对这些挑战，九识智能亟需构建一套具备高性价比、强扩展性和易运维能力的云原生存储架构。在系统评估了 Alluxio、CephFS 等方案后，最终选择采用 JuiceFS 作为统一的存储基础设施。目前，九识已将生产、仿真、训练与推理等核心业务数据全面迁移至 JuiceFS，构建起一个高效、灵活、统一的存储底座，全面支撑自动驾驶多场景下的海量数据处理需求。
01 自动驾驶训练流程与存储挑战
九识智能目前致力于 L4 级别自动驾驶技术的研发，主要聚焦于城市智能配送物流场景的应用。在自动驾驶模型的训练过程中，会产生大量数据，并涉及复杂的处理流程。以下为我们自动驾驶训练的基本步骤：
- 数据采集与上传：在车辆上开展标定工作以采集数据，随后将采集到的数据上传。
- 算法处理：算法部门提取相关数据用于模型训练或算法改进，之后将结果交由仿真环节进行打分。
- 仿真验证与修改：若仿真失败，返回算法部门进行修改；若仿真成功，则进入模拟环境验证阶段。
- 测试车辆验证：在模拟环境验证通过后，在测试车辆上进行测试。若测试失败，再次返回修改环节；若测试成功，则发布到 OTA。
在整个流程中，数据量急剧增长。每辆车每日约上传十几 GB 数据，随着车辆规模扩大，总数据量已达 PB 级别，尤其在模型训练阶段需高效提取和使用海量数据，对存储系统的性能、扩展性和稳定性提出了极高要求。
为满足自动驾驶研发全流程对数据的需求，九识智能需要建立一个具备以下特性的存储平台：
- 高性能 I/O：能够在训练和仿真阶段支撑海量数据的高并发读取与低延迟访问。
- 弹性扩展性：可随着车辆规模扩大灵活扩展至 PB 级甚至更高的数据存储需求。
- 跨云兼容性：支持多云与自建环境的统一接入，保障数据在不同环境间的流转与一致性。
- 易运维性：提供简化的管理与监控能力，降低运维复杂度，确保系统长期稳定运行。
- 成本效益：在保证性能和稳定性的同时，控制总体存储成本，实现资源利用最大化。
02 存储选型：JuicsFS、Alluxio、 CephFS
我们曾尝试使用多种存储方案，包括 Alluxio、JuiceFS 和 CephFS。
Alluxio 通过 Master 来进行元数据管理，熟悉难度较高。需要单独部署 Master、Worker 集群，运维复杂度高，且在社区版使用中遇到了诸如卡死、I/O 异常等问题。
CephFS 方面，其元数据存储在自有 MDS 中，而数据则存放于 RADOS 中，相比之下， JuiceFS 支持多种后端存储（如 S3、OSS 等），元数据可依托外部数据库（如 Redis、TiKV）管理，架构更为灵活。
此外，CephFS 的部署和调优极为复杂，需专业团队深度参与。我们在自建 Ceph 集群时发现，扩展 OSD 及数据再均衡耗时漫长，小文件写入性能较差，出现写入速度低下等问题，且因其架构复杂，调优困难，最终决定放弃该方案。
JuiceFS 能够将各类对象存储接入本地，并支持跨平台、跨地域的多主机同时读写。采用数据与元数据分离存储的设计，文件数据经切分后存储于对象存储，而元数据可保存在 Redis、MySQL、TiKV 或 SQLite 等多种数据库中，用户可根据实际场景和性能需求灵活选择，并且极大简化了运维工作。
相比之下，JuiceFS 在多方面表现更为出色。尤其在小文件高并发读取场景中，性能符合我们的需求，因此约一年前我们全面转向 JuiceFS，并在多云架构中广泛应用。
03 JuiceFS 在多云环境中的应用与实践
JuiceFS 采用元数据与数据分离的存储架构：元数据层支持多种数据库引擎，包括 Redis、MySQL、TiKV、SQLite 等，用户可根据业务规模与可靠性需求灵活选择；数据层则基于主流对象存储，实现与不同存储系统的无缝对接。
目前，我们的系统部署覆盖联通、电信、火山、移动、AWS 等多个云平台，均采用 JuiceFS 作为核心存储组件。在不同环境中，我们灵活搭配后端存储与元数据引擎。在自建 IDC 机房中，采用 MinIO 作为对象存储，配合 Redis 管理元数据；在公有云环境中，则使用 OSS 与 Redis 组合。这一架构不仅提升了系统灵活性，而且在一年多来的实际运行中表现稳定，完全满足业务需求，具备良好的可用性和用户体验。
在 Kubernetes 集群中，我们基于 JuiceFS 提供的 CSI 驱动进行了部署，整体方案与Kubernetes 兼容性良好。我们直接使用官方提供的 Helm Charts 来创建和管理 JuiceFS 存储卷，并根据不同业务的需求，配置了对应的 Chart，分别对接后端的 Redis 及 OSS 存储。
在节点本地，我们为 JuiceFS 缓存分配了 NVMe 高速固态硬盘，将其挂载至 /data 目录。用作缓存层，可显著提升读取性能：一旦数据被缓存，后续读取同一文件的请求可直接从本地 NVMe 盘中获取，读写效率极高。
实践1-JuiceFS 在训练平台的应用：面向上亿规模文件的高并发访问与弹性扩展
我们的训练平台架构整体分为多层。底层为基础设施层，涵盖存储资源、网络资源、计算资源以及若干数组服务机和硬件设备。其上为容器化层，基于 Kubernetes 集群构建，用于支撑各类服务。平台提供深度 GPU 计算支持、多种开发语言环境及主流深度学习框架。
在深度学习平台中，用户可通过 Notebook 或 VR 界面提交训练任务。任务提交后，系统将通过 Training Operator 进行资源调度与分配。存储方面，我们基于 PVC（Persistent Volume Claim）预配置了存储资源，并借助 JuiceFS 实现底层存储的自动关联与供给。
我们将 JuiceFS 集成于 Kubeflow 机器学习平台中，用于模型训练任务。在 Notebook 环境中创建训练任务时，系统会自动关联至后端 JuiceFS 提供的 StorageClass，实现存储资源的动态分配与管理。同时，集群中部署了监控系统，对存储性能进行实时观测。目前监测到读取吞吐约在 200MB/s 左右，写入请求量较低，这与我们训练推理场景中读多写少的 I/O 特性较为吻合------读取操作远高于写入。
在性能调优过程中，我们参考了JuiceFS 社区的相关分享，对比了 Redis 与 TiKV 作为元数据引擎的表现。测试结果显示，TiKV 在读密集型场景下性能显著优于 Redis。因此，我们计划将部分训练集群的元数据引擎逐步迁移至 TiKV，以进一步提升读取效率。
目前，我们一个存储桶中已存有约 700TB 的数据，文件数量达 6 亿个。其中存在大量小文件，典型于 AI 训练任务中常见的数据组织形式。在实际使用中，JuiceFS 在面对高并发的小文件读写时表现稳定出色，未出现任何异常，完全满足生产需求。
在仿真场景中，数据规模已达到 PB 级别，存储桶以大文件为主。底层存储资源依托于移动云对象存储，主要用于仿真数据的集中存放。在实际使用过程中，该存储方案同样表现稳定，能够支撑大规模仿真任务的持续运行。
实践2：JuiceFS 在多云环境中的数据同步
为实现多云环境下的数据同步，我们在多个云服务商之间部署了多条专线，并预先完成了跨云网络打通。对于需要在不同云中保持一致的训练数据，我们自主开发了同步工具，该工具底层集成 JuiceFS Sync 命令，能够高效地将同一份数据同步至多个云环境中。此外，尽管支持跨云挂载，但由于其高度依赖网络稳定性，我们并不推荐该方式。跨云数据同步的核心挑战在于网络可靠性，一旦出现网络波动，同步过程易受影响，因此需谨慎使用。
04 小结
在生产、仿真、训练和推理等关键环节中，JuiceFS 依托灵活的元数据引擎选择、多样化的对象存储对接方式，以及与 Kubernetes、Kubeflow 的良好兼容性，有效支撑了小文件高并发访问、跨云数据流转和性能扩展等场景需求。在大规模数据场景下，JuiceFS 运行稳定，显著降低了运维复杂度和总体成本，并在系统扩展性方面满足了当前业务规模。
未来，随着 TiKV 等元数据引擎的逐步应用以及跨云同步机制的持续优化，JuiceFS 的整体性能和适应性仍有提升空间，将为九识智能在自动驾驶研发中的海量数据处理提供持续支撑。
我们希望本文中的一些实践经验，能为正在面临类似问题的开发者提供参考，如果有其他疑问欢迎加入 JuiceFS 社区与大家共同交流。