百亿小文件存储，JuiceFS 在自动驾驶行业的实践

原创

于 2021-11-02 15:13:36 发布 · 602 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#自动驾驶 #人工智能

本文介绍了一种使用JuiceFS在自动驾驶领域高效管理数十亿小文件的解决方案，通过独特的元数据管理和缓存机制，实现了高并发、低延迟的数据访问，有效提升了模型训练效率。

自动驾驶是最近几年的热门领域，专注于自动驾驶技术的创业公司、新造车企业、传统车厂都在这个领域投入了大量的资源，推动着 L4、L5 级别自动驾驶体验能尽早进入我们的日常生活。

自动驾驶技术实现的核心环节是自动驾驶模型的训练，训练数据是由汽车实际采集回来的真实道路驾驶视频，数据规模有数 PB 到数十 PB 之多。在模型训练之前，先要对这些原始视频进行处理，截取其中的关键帧保存为照片。然后再由专业数据标注团队在图片上标记关键信息，比如红绿灯、道路标记等。最终经过标记的数十亿图片和标记数据成为真正要「喂给」训练框架的内容。

熟悉分布式系统和分布式存储的朋友一定知道，LOSF（Lots of Small Files，海量小文件）是存储领域的大难题。而在人工智能 CV（Computer Vision）领域中基于 LOSF 的训练又是刚需，包括自动驾驶、人脸识别、物体检测等细分领域。

本篇文章来自 JuiceFS 某自动驾驶行业客户的架构实践，在百亿规模小文件训练场景下进行了一系列成功的探索，希望能为相关行业的应用带来一些参考和启发。

百亿小文件管理的极致挑战

自动驾驶系统的训练数据集大多有数十亿到数百亿小文件（小于 1MiB 的文件），一次训练通常需要数千万到数亿文件。而且训练 worker 每一次生成 mini-batch 都需要频繁访问存储系统，其中大部分是对元数据的请求，因此，元数据性能直接影响模型训练的效率。

这就要求存储系统不仅要具备管理百亿文件的能力，还必须在高并发请求下，保持低时延、高吞吐的元数据性能。

在存储系统选型中，对象存储是能够承载百亿规模文件的，但是缺少原生目录支持、缺少完整 POSIX 语义支持、元数据性能弱这三方面的问题让对象存储并不适合海量小文件训练场景。

在一些常见的分布式文件系统架构设计中，HDFS 并不适合存储小文件，虽然可以采用 Scale-Up NameNode 和联邦（federation）的方式容纳一定规模的数据，但要存储百亿级小文件依然是一件非常困难的事情；CephFS 的 MDS 虽然有 Scale-Out 能力，但单进程的并发处理能力不高，随着 MDS 集群规模的增长进程间协调开销增大，使得整体性能达不到线性增长。

虽然在 TensorFlow 中支持将多个小文件合并成大文件的 TFRecord 格式来降低训练过程中对存储系统的元数据负载压力，但是在自动驾驶领域，这种方案降低了数据集随机取样的精度，而且其它训练框架（如 PyTorch）也不兼容，造成很多不便。