01 一句话结论

AVS 的核心判断很直接：自动驾驶车每天可能产生 14TB 级别的多模态数据，持续上传原始日志不现实；但如果只依赖传统 datalogger 或 rosbag，又很难同时满足实时写入、低延迟检索和长期保留。

所以论文把“存储系统”提升成自动驾驶栈的一等公民：在车端引入一个独立的 storage sidecar，对相机、LiDAR、雷达、GNSS/CAN 等数据做按模态降冗余、压缩、热冷分层、元数据索引和检索服务。

02 为什么需要车端数据资产层

传统车辆数据更多是闭环控制：传感器输出直接服务当前驾驶决策，历史数据只在事故记录器里保留很短窗口。但自动驾驶进入规模化运营后，历史数据开始有新的价值。

• 安全与取证：需要回溯特定时间窗口的多传感器证据。
• 地图与基础设施：道路变化、施工区域、标志标线更新都依赖长期观测。
• 车辆生命周期：电池、传感器、底盘与计算平台的健康分析需要长周期数据。
• AI 数据闭环：长尾场景挖掘、数据集构建、模型回归测试都需要可查询历史数据。

03 AVS 的系统架构

AVS 的设计比较务实：不去侵入实时自动驾驶主计算，而是在旁路设备上运行。它通过以太网交换机接收传感器流，先在 ingest 阶段做轻量计算，再把近期数据放在 SSD 热层，把归档数据迁移到 HDD 冷层。

它的关键模块可以拆成三层：

• 实时接入层
  ：按消息周期完成降采样、去重、压缩和落盘，目标是不影响 10Hz/50Hz 等传感器节奏。
• 热冷存储层
  ：SSD 承担近期高速写入和低延迟查询；HDD 承担长期归档，并按日期组织大文件。
• 元数据索引层
  ：记录时间戳、路径、GPS、归档位置等，让“查过去某段时间的某类数据”成为可执行查询。

04 数据不只是压缩，而是按业务降冗余

论文在 LiDAR 和图像上分别做了两类处理。LiDAR 侧使用体素网格降采样：把空间划分成小体素，每个体素只保留代表点，从而降低点云密度。

图像侧则用感知哈希 pHash 判断相邻帧是否视觉相似。车停在红灯、低速跟车或停车时，连续帧高度重复，保留每一帧并不总能带来额外业务价值。

这里最值得注意的不是“压得越狠越好”。论文反复强调任务效用：降采样和去重必须尽量保持下游定位、检测、跟踪或回放质量。也就是说，AVS 不是盲目删数据，而是把“保留价值”绑定到下游任务。

05 文件系统和索引选型：小问题，其实很工程

车端存储的麻烦在于 I/O 形态很混合：实时 ingest 是高频小文件和 fsync；回放查询是时间窗口内的小随机读；归档迁移又偏大文件顺序扫描。论文因此比较了 EXT4/XFS、SQLite/RocksDB 等基础选型。

论文结论不是简单宣布“某个组件最好”，而是给出设计倾向：SSD 热层更关注写入尾延迟、写放大和查询新鲜度；HDD 冷层更关注顺序吞吐、碎片和长期归档效率。SQLite 虽然查询略慢于 RocksDB，但资源占用和实现复杂度低，更贴近轻量车端原型。

06 Prototype and Implementation：系统到底怎么落地

这篇论文比较有意思的一点，是它没有停留在“应该怎么设计”的层面，而是给了一个可运行原型。硬件上，AVS 跑在 Raspberry Pi 5 上，配 256GB NVMe SSD 和 1TB HDD；系统上，SSD 被划成系统分区和 100GB 热数据分区，HDD 作为冷归档层。

从 Figure 9 可以看到，AVS 的实现逻辑很清楚：相机和 LiDAR 数据先进入 subscriber pipeline，在 SSD 侧保存近期可查数据；查询服务负责从热层读近期窗口；归档服务按日期把图片、点云和 GPS 数据迁移到 HDD，并保持元数据一致。

Figure 10 则把这种管理方式落到了表结构上：热层的 avs_images / avs_lidar 记录传感器、数据类型、时间戳、路径和覆盖区域；avs_gps 记录经纬高、航向和协方差；冷层的 archive_* 表记录归档日期、tar 路径、起止时间、文件数和哈希。它让 AVS 从“存储文件”升级为“维护一套可查询的数据目录”。

07 原型结果：AVS 牺牲一部分计算，换来数量级存储收益

AVS 原型部署在 Raspberry Pi 5 上，配 8GB RAM、256GB NVMe SSD 和 1TB HDD，并连接真实 L4 自动驾驶平台。论文用三天城市路线片段验证记录、归档和检索。

结果很有系统论文的味道：AVS 的 CPU 和 RSS 更高，因为它在写入前做了更多计算；但落盘数据量从 ros2bag raw 的 30GB 级降到约 4GB 级，平均相对 raw ros2bag 小 8.4×，相对 zstd ros2bag 小 5.0×。

检索方面，论文报告图像、LiDAR、GPS 的 time-to-first-byte 分别约为 29ms、23ms、0.6ms，说明通过时间索引查询近期历史数据是可行的。归档方面，约 12.55GB 数据平均归档延迟 144s，适合放到夜间或低负载窗口执行。

08 这篇论文真正的启发

如果把自动驾驶系统看成“车端模型 + 云端训练 + 运营闭环”的组合，那么 AVS 对应的是中间缺失的一层：车端先做第一轮数据治理，把原始传感器洪流变成更可管理的数据资产，再决定哪些留在车上、哪些传回云端、哪些进入训练样本池。

这对行业的意义在于，未来的竞争不只在模型参数和传感器配置，也在数据基础设施。谁能更低成本地保留关键历史、检索长尾场景、追溯决策证据，谁的数据闭环就更稳。

09 局限与后续方向

论文仍然是技术报告性质，实验规模偏小：三天路线、Raspberry Pi 5 原型、以 KITTI 和真实 L4 片段为主，距离量产车队的多车型、多地域、多月级运行还有距离。

还有几个问题值得继续追：

• 小文件高频 fsync 会带来写放大，后续可能需要 group commit 或 log-structured 布局。
• pHash 去重对行人等小目标更敏感，需要更强的任务感知阈值。
• 当前更像单车存储系统，车队级数据调度、隐私合规、云边协同还没有展开。
• 论文未给出代码仓库链接；可公开访问的主要资源是 arXiv 论文页和 DOI。

10 适合谁读

这篇更适合做自动驾驶系统、数据闭环、车端计算、数据平台和基础设施的人读。它不是追逐 SOTA 的模型论文，而是在提醒一个更朴素但关键的问题：当车每天产生 TB 级数据，模型之前，先得有一套能把数据接住、管住、查出来的系统。

11 结论

AVS 最值得记住的判断是：自动驾驶的数据闭环，不能只靠云端大平台，也不能只靠车上把日志“先存下来再说”。真正可持续的路线，是在车端先建立一层轻量、可查询、可归档的数据资产层。

• AVS 的价值不在于把日志压小，而是把车端数据从“临时记录”提升为可查询、可归档、可复用的数据资产。
• 车端数据生命周期管理会成为自动驾驶闭环的基础层：热层负责即时检索，冷层负责长期沉淀，索引负责把数据重新变成业务可用的证据。
• 真正的系统难点不是某个压缩算法，而是在实时性、存储成本、设备磨损、任务效用之间找到可持续的工程边界。

从这个角度看，AVS 做的不是一个更省空间的 datalogger，而是在给自动驾驶补上一层“车端数据操作系统”：它决定哪些数据被保留、如何被组织、什么时候迁移、以及未来能不能被训练、取证和运营系统重新调用。