背景

根据国家相关法规和标准，新能源汽车行驶过程中需要将核心组件的信号数据进行收集并上报到政府建设的新能源汽车数据平台中，这些数据的来源有发动机、电池等核心部件。同时监管部门也要求汽车厂商存储这些数据支撑后续的售后维护、OTA 升级，车辆的健康状况检测、早期预警、以及维修保养等。为了更好的服务用户，理想汽车开始自建数据平台。

致力于创造移动的家，成为全球领先的智能电动车企业的理想汽车，其所要管理的数据，规模是非常庞大的。在今天这篇文章中讨论的还仅仅是理想汽车产生的时序信号数据。汽车数据平台的架构中，全量的时序信号数据存储在 HDFS 中，同时也使用 Hadoop 技术栈根据业务需求完成各种复杂的计算和分析任务。

2021 年 12 月，理想汽车交付 14,087 辆理想 ONE，同比 2020 年 12 月增长 130.0%。2021 年 1 月至 12 月，理想 ONE 总计交付 90,491 辆，同比 2020 年增长 177.4%。自交付以来，理想ONE 累计交付量已达 124,088 辆。可想而知，数据平台管理的车辆数据的增长也是极快的，这对数据平台的敏捷性和弹性都提出了非常高的要求。玩转大数据的老司机都知道，HDFS 的扩容费时费力，有时甚至难以跟上业务的增长速度。面对业务快速发展和不那么弹性的 HDFS，维护数据平台的工程师们有时只好删除无效、冗余数据，平衡各数据节点的数据，来缓解业务对于敏捷性的高要求和 HDFS 不那么弹性的矛盾。另外，由于 Hadoop 是存储和计算耦合的设计，增加存储空间的同时也需要增加计算，而往往存储和计算的匹配是错位的，不匹配的扩容也会也会带来很多算力冗余，制造不必要的浪费。

业务发展持续向好，也给数据平台带来了甜蜜的烦恼，在 2020 年，数据平台开始着手解决业务变化快和 HDFS 不够弹性的矛盾。当时选型的标尺是：

• 尽量少修改现存的 ETL 流程和计算逻辑，换言之有极好的 HDFS 兼容性
• 弹性极佳
• 透明加速，不能有性能瓶颈
• 稳定性至少要对齐 HDFS

一开始，测试的是云厂商提供的 Hadoop SDK 集成方案，但是由于只实现了有限的 Hadoop API 而且没有缓存，稳定性和性能远远不及 HDFS，这个问题的解决迟迟没有进展。

2021 年初恰逢 JuiceFS 开源，数据平台的同事了解到 JuiceFS 云服务，JuiceFS 在完全兼容 HDFS API 的同时兼具弹性和缓存，初步判断可以解决选型标尺中的前三个问题。我们抱着试一试的心态，第一时间试用了。这里也要感谢 JuiceFS 小伙伴们的大力帮忙，让 JuiceFS 社区版在理想汽车顺利上线，解决了 HDFS 容量紧张的问题，还顺带实现了 Hadoop 存储计算分离的架构升级，最重要的还是满足了业务的敏捷性要求。

JuiceFS 介绍

JuiceFS 是一个面向云环境设计的高性能开源分布式文件系统，完全兼容 POSIX、HDFS、S3 接口，适用于大数据、AI 模型训练、Kubernetes 共享存储、DevOps、海量数据归档等场景。

使用 JuiceFS 存储数据，数据本身会被持久化在对象存储（例如 Amazon S3），而文件系统对应的元数据可以存储在 Redis、MySQL、TiKV 等多种数据库引擎中。同时 JuiceFS 客户端具有缓存能力，为上层应用提供智能 I/O 加速。

应用场景

目前经过半年的使用和迭代，JuiceFS 已经用在理想汽车多个业务场景中。下面分享几个典型的业务场景，希望对 JuiceFS 社区用户有借鉴意义，也欢迎大家提出你们的想法和问题。

JuiceFS 支持核心数仓存储

场景

目前车辆数据分析场景每天新增数据 2TB。数据通过 Spark 直接读写 JuiceFS 进行 ETL 加工。因为 JuiceFS 对 HDFS API 进行了完整兼容，业务上只需要将表路径指定到 JuiceFS 的目录即可。切换上是无感的。

收益

切换到 JuiceFS 后，存储空间一下就从 HDFS 有限的磁盘变成了容量无限的对象存储，同时也实现了 Hadoop 集群的存储计算分离，现在存储使用 JuiceFS 可以弹性伸缩，计算集群也可以根据业务量独立扩缩容。这样，数据平台可以更敏捷的支持业务增长和需求变化。

改进计划

上半年业务上线时，JuiceFS 使用公有云托管的 Redis 存储元数据。因为需要 Redis 的事务 API，无法使用 Redis 集群模式，这样单个 Redis 实例的扩容瓶颈就带来了单个 JuiceFS 文件系统文件数量的限制，暂时没有把所有表都迁移到 JuiceFS。现在 JuiceFS 支持了 TiKV 存储元数据，接下来准备测试并将全部数据迁移到 JuiceFS，空闲出来的本地物理磁盘作为缓存盘。

用 JuiceFS 支持时序数据库 MatrixDB 分级存储

场景

在理想汽车 MaxtrixDB 集群中，即使经过压缩处理，每天仍有将近 500G 的增量数据，这类时序型的数据时效性很强，时间越久需要查看的频次就越低。矛盾的地方在于，即使是历史数据也有低频查询需求，不能对历史数据进行删除；然而 MaxtrixDB 在架构设计上采用本地存储，不能弹性扩缩容。

看了 JuiceFS 在 ClickHouse 上的数据分层实践后，我们推荐给了 MatrixDB 团队，很快 MaxtrixDB 支持了自动分级存储机制，成功实现将温冷数据由本地磁盘自动转移到 JuiceFS，满足查询需求。

收益

在用户使用基本无感知的情况下，降低了近 50% 的存储成本。

使用 JuiceFS 实现时序数据库 MatrixDB 的数据分层存储，热数据写入本地 SSD，通过生命周期策略自动转移到 JuiceFS。整个过程仅需简单配置，自动透明，不再需要频繁的手工扩容，还能大幅节省存储成本。空余的 SSD 容量可以做温冷数据的缓存加速，偶尔使用通过缓存加速也能保持很好的性能。

跨平台数据交换

场景

数据平台是 Hadoop 技术栈，算法平台使用 Kubernetes 做资源管理，两个平台在很多业务中都是上下游关系，数据平台负责准备数据，然后给到算法平台完成算法模型的训练。我们解决数据交换的方式是数据平台将数据直接写入到 Hive 表中，Hive 表底层使用 JuiceFS 存储。算法平台启动 Pod 时自动以 POSIX 方式挂载同一个 JuiceFS 文件系统，Pod 中的应用就可以像访问本地目录一样，读取到特征数据了，训练好的结果也同样以 POSIX 方式写入 JuiceFS，数据平台的同学也可以方便的使用算法同学提供的结果。

收益

数据工作流越来越长，越来越复杂，工作任务需要在不同平台、不同团队中协作完成，以前数据总是要在不同存储系统中搬来搬去。拷贝的时间，检查正确性的时间，这些等待和重复的工作非常影响效率，现在 JuiceFS 作为统一数据湖，可以在不同平台、应用中共享各种类型的数据，不用再等待，效率提高很多。

改进计划

目前数据平台使用多租户方式进行数据 ETL 操作。算法平台拉起的 Pod 默认是 root 用户，算法同事回写结果数据到 JuiceFS 后只有 root 用户拥有写权限，而数据平台的 Hive 组件在新增分区时因为没有写权限会导致新增分区失败。最近社区有了一种新的解决方案，是把 Hive 组件的用户加到 Hadoop 的 supergroup 里，这样也就和 root 用户一样拥有了写权限。这个方案我们会在近期新版发布后和算法平台一起测试一下。

平台共享文件

场景

过去整个数据平台使用 HDFS 来共享文件。平台前端应用通过后端服务接口直接将数据上传到 HDFS 上。一方面存在安全隐患，一方面也会出现凌晨任务集中执行时间从 HDFS 下载大文件失败情况，影响任务稳定性。目前已经将实时开发平台的文件共享切换到由 JuiceFS POSIX 方式来提供共享文件的支持。后面计划将所有需要共享文件的平台都收口到 JuiceFS 统一管理。

收益

POSIX 访问方式可以让应用开发更简单，更高效。同时 JuiceFS 也提供了相比 HDFS 峰值时更稳定的吞吐。

展望

经过近一年的使用，我们一直跟进 JuiceFS 社区的迭代，对 JuiceFS 也有了更多的了解，使用遇到的问题可以及时得到社区中的反馈，问题解决也挺快的，感谢社区伙伴的大力支持，我们也一直跟着社区的 release 持续升级（JuiceFS 的升级很简单 👍）。明年的工作规划中，一方面场景会继续扩展和深入，我们计划在公司自动驾驶的大量图片检索场景进行验证和推广。另一方面我们也开始对 JuiceFS 做一些开发，验证后也会和社区讨论反馈到上游代码中。

首先，2022 年的目标是弱化直至去掉 HDFS，后期会使用对象存储作为整个数据湖的底层存储。并希望打通数据湖和数据仓库层面的数据共享。由于对象存储需要网络开销，扩展性好的同时损失了一些效率，JuiceFS 提供了本地缓存来提升性能，理想汽车存储团队目前在着手准备开发增加缓存命中率的功能，例如本地 P2P 读等。

第二，我们整个平台是在多租户环境下运行的，JuiceFS 目前是针对单个文件系统设计，还没有多租户方面的功能。我们也准备开发类似 Apache Ranger 的管理工具，提供用于安全策略的集中管理和对用户访问监控用来管理 JuiceFS 中的数据安全。

第三，目前 JuiceFS 使用 POSIX 挂载时需要直接传递 meta 信息，我们计划将 JuiceFS 社区版进行一定程度的服务化封装，一方面方便用户创建和管理自己的 JuiceFS Volume，集成内部用户认证系统，提升用户体验。另一方面可以隔离集群的部署细节，方便平台团队维护。

第四，数据湖场景计划使用 TiKV 做元数据存储，但是在个别场景中 TiKV 又不如 Redis 来的快一些。所以考虑有些对元数据性能要求高但是数据量可控的场景继续使用 Redis。这样就存在需要维护多套 JuiceFS 的需求。就好像每个 JuiceFS 都是一个目录。用户看到的是一个文件系统一样。类似 Hadoop 的多 NameNode 的 ViewFS。