现实汽车是中国新能源汽车制造商，设计、研发、制作和销售奢华智能电动汽车，于 2015 年 7 月创建，总部位于北京，已投产的自有生产基地位于江苏常州，通过产品翻新及技术研发，为家庭用户提供平安及便捷的产品及服务。
在中国，现实汽车是胜利实现增程式电动汽车商业化的先锋，首款及目前惟一一款商业化的增程式电动汽车车型现实 ONE 是一款六座中大型奢华电动 SUV（运动型多用途汽车），装备了增程零碎及先进的智能汽车解决方案，于 2019 年 11 月开始量产，并于 2021 年 5 月 25 日推出 2021 款现实 ONE。截至 2021 年 12 月 31 日，现实汽车已交付达 124,088 辆现实 ONE。
背景
依据国家相干法规和规范，新能源汽车行驶过程中须要将外围组件的信号数据进行收集并上报到政府建设的新能源汽车数据平台中，这些数据的起源有发动机、电池等核心部件。同时监管部门也要求汽车厂商存储这些数据撑持后续的售后保护、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。
欢送关注咱们我的项目 Juicedata/JuiceFS 哟！(0ᴗ0✿)