4. 自动驾驶数据管理
自动驾驶的数据量级远超传统互联网业务：一辆测试车每天可产生数 TB 的摄像头、激光雷达、毫米波雷达、CAN 总线与定位数据。这些数据既要长期留存以满足合规回溯，又要在模型训练时被高频、随机、低延迟地读取。因此，数据管理不是简单的"存文件"，而是一套围绕数据湖、版本控制、索引与检索构建的工程体系。本节将拆解这四者的分工与协作方式。
一、数据湖：原始数据的统一着陆区
数据湖是自动驾驶数据管理的底座，负责以低成本、可扩展的方式承接多源异构的原始数据。它的核心设计原则是"先原样落地，再按需加工"，避免在采集阶段就做不可逆的清洗。
- 分层结构：通常划分为原始层（Raw）、清洗层（Cleaned）、特征层（Feature）与服务层（Serving）。原始层只做完整性校验与格式封装，保留全部信息。
- 存储格式：传感器原始数据用 rosbag、mcap 或自定义二进制格式；结构化元数据用 Parquet、ORC 等列式格式，便于后续扫描与聚合。
- 对象存储：底层多采用 S3、OSS、Ceph 等对象存储，通过分片、生命周期策略与冷热分层控制成本。
- 元数据分离：数据本体与元数据解耦，元数据进入数据库或数据目录，本体留在对象存储，这是实现高效检索的前提。
二、数据版本控制：让数据集可复现
模型效果不可复现，往往不是算法问题，而是数据版本漂移。数据版本控制的目标是：任意一次训练都能精确还原当时使用的数据集合。它与代码版本控制思路相似，但对象是海量二进制文件，因此不能简单套用 Git。
主流做法是内容寻址 + 清单文件：对每个数据分片计算哈希，形成不可变的指纹；数据集版本则由一份清单（manifest）描述，清单中记录分片哈希、路径、标签与切分信息。版本切换只需切换清单，无需复制数据本体。
dataset_version: autopilot-city-v3.2
created_at: 2025-03-11T09:20:00Z
splits:
train: 128400 clips
val: 16050 clips
test: 16050 clips
manifest_hash: 9f2c7a1e...
parent_version: autopilot-city-v3.1
changes:
- 新增夜间雨天场景 4200 clips
- 剔除标注置信度低于 0.6 的 830 clips
版本控制还需处理血缘关系：某次训练用了哪个数据版本、哪个标注版本、哪套预处理脚本，都应可追溯。这样当线上出现回归时，才能快速定位是数据问题还是模型问题。
三、数据索引：把"找得到"变成"查得快"
索引是数据湖与检索之间的桥梁。自动驾驶数据的检索维度非常丰富，包括时间、地理位置、传感器类型、场景标签、目标类别、天气、光照、标注质量等。索引的本质是把这些维度组织成可快速过滤的结构。
- 元数据索引：将 clip 级、帧级、目标级的属性写入 Elasticsearch、ClickHouse 或向量数据库，支持组合条件查询。
- 空间索引：用 GeoHash 或 H3 将轨迹点映射为网格编码，实现"某路口 500 米内所有数据"的快速召回。
- 时间索引：按采集时间分区，支持时间范围扫描与增量同步。
- 向量索引：对图像或场景做嵌入，用 FAISS、Milvus 等实现"以图搜图"式的相似场景检索。
四、数据检索策略：从需求到结果
检索策略决定了数据能否被高效转化为训练价值。常见策略包括：按场景标签精确召回、按长尾条件组合筛选、按相似度做主动学习采样，以及按时间窗口做回归验证集构建。
下图展示了从数据湖到检索结果的完整链路，以及索引、版本控制在其中的位置：
五、案例与场景：长尾场景挖掘
假设要训练一个"夜间雨天路口左转"的感知模型。检索流程如下：先用场景标签过滤出夜间与雨天，再用 GeoHash 限定路口区域，接着用向量索引召回与目标场景相似的片段，最后锁定数据版本并导出训练清单。整个过程从数 PB 数据中召回数千个高价值 clip，耗时从数天缩短到分钟级。
| 管理维度 | 核心目标 | 关键手段 | 常见指标 |
|---|---|---|---|
| 数据湖 | 统一存储、低成本留存 | 分层目录、对象存储、列式元数据 | 存储成本、写入吞吐 |
| 版本控制 | 可复现、可追溯 | 内容寻址、manifest、血缘记录 | 版本切换耗时、复现一致率 |
| 数据索引 | 多维快速过滤 | 元数据/空间/时间/向量索引 | 查询延迟、召回率 |
| 数据检索 | 高效转化为训练价值 | 标签召回、相似采样、主动学习 | 有效样本率、标注成本 |
六、误区与复盘
误区一：只存不索引。数据湖建好了，但没有元数据与索引，检索只能靠文件名遍历，效率极低。
误区二：版本用文件名区分。如 dataset_v2_final_new，无法保证内容一致，也无法追溯血缘。
误区三：索引与数据不同步。新数据入库后索引未更新，导致检索结果缺失，训练集与预期不符。
误区四：忽视冷热分层。所有数据都放高性能存储，成本失控；全部放冷存储，训练读取又过慢。
复盘建议：把数据管理当作产品来运营，建立数据目录、质量看板与检索 SLA；每次训练都强制绑定数据版本与血缘；索引更新纳入数据入库流水线，做到"入库即可查"。只有湖、版本、索引、检索四者协同，自动驾驶数据才能真正从成本中心转变为模型迭代的加速器。