4. 数据回流架构设计
自动驾驶车队每天产生的数据量可达数十TB，但真正对模型迭代有价值的“高价值片段”往往不足总量的5%。如果采用“全量上传”策略，不仅带宽成本高昂，还会造成云端存储与标注资源的严重浪费。因此，数据回流架构的核心目标可以概括为一句话：在正确的时间，把正确的数据，以可接受的成本送到正确的位置。本章围绕车端、边缘端、云端三层架构，讲解分层职责、通信协议选型与带宽优化策略。
一、三层架构的核心原理
三层架构并非简单的物理位置划分，而是按照“数据价值密度”和“处理时效性”进行的分工。车端负责感知与初筛，边缘端负责汇聚与二次加工，云端负责全局存储、标注与训练闭环。
- 车端（On-Vehicle）：数据产生的源头。部署轻量级触发引擎，基于规则或模型置信度实时判断片段是否值得回流，同时完成脱敏、压缩与本地缓存。
- 边缘端（Edge）：通常部署在车队基地、充电站或区域机房。负责多车数据汇聚、断点续传、格式归一化、二次过滤与批量上传，是缓解云端入口压力的“缓冲池”。
- 云端（Cloud）：承担数据湖存储、版本管理、自动标注、模型训练与仿真回放，是数据价值最终释放的地方。
三层架构的关键设计原则：车端做“减法”（只留高价值数据），边缘端做“整形”（统一格式与补齐元数据），云端做“乘法”（通过标注与训练放大数据价值）。
二、通信协议选型
三层之间的通信协议需要根据数据特征分别选择。车端到边缘端以“小消息、高频率”为主，边缘端到云端以“大文件、低频率”为主。
| 链路 | 推荐协议 | 适用数据 | 关键参数 |
|---|---|---|---|
| 车端 → 边缘端 | MQTT over TLS | 触发事件、元数据、小片段索引 | QoS 1，心跳30s，主题按VIN分区 |
| 车端 → 边缘端 | HTTPS 分片上传 | 压缩后的图像/点云片段 | 分片8MB，并发4，断点续传 |
| 边缘端 → 云端 | S3 兼容对象存储 | 批量数据包、标注素材 | 分片64MB，生命周期策略 |
| 边缘端 → 云端 | Kafka | 数据到达通知、索引事件 | 分区数12，副本2，保留7天 |
三、带宽优化策略
带宽是数据回流最直接的瓶颈。以下策略通常组合使用，可将实际传输量降低60%以上。
- 触发式采集：只在满足条件时上传，例如AEB触发、接管、模型置信度低于阈值。避免“全程录像”式上传。
- 边缘预处理：在边缘端完成抽帧、去重、裁剪ROI，只上传有效区域。例如将1920×1080裁剪为感兴趣区域后，数据量可减少40%。
- 分级压缩：图像采用JPEG质量因子动态调整，点云采用量化压缩。质量因子可根据网络状况在60~90之间浮动。
- 错峰传输：利用夜间充电时段或WiFi热点进行大文件回传，避开5G流量高峰。
- 优先级队列：安全相关数据（碰撞、急刹）最高优先级，普通场景数据低优先级，队列满时丢弃低优先级数据。
# 车端上传调度配置示例（YAML）
upload:
trigger:
- type: "aeb_trigger" priority: 0
- type: "driver_override" priority: 1
- type: "low_confidence" priority: 2
network:
prefer_wifi: true
max_5g_mbps: 20
offpeak_window: "23:00-06:00"
compression:
image_quality: 75
pointcloud_quantize: 0.01
retry:
max_attempts: 5
backoff_seconds: [10, 30, 60, 300, 900]四、典型场景与误区复盘
场景：某车队在城区道路测试中，每天产生约8TB原始数据。采用三层架构后，车端触发引擎筛选出约400GB高价值片段，边缘端二次过滤后压缩至120GB，最终云端仅接收约80GB。带宽成本下降90%，而模型迭代所需的关键场景覆盖率反而提升。
常见误区：很多团队把“数据回流”简单理解为“把数据传上去”。实际上，回流架构的设计难点在于判断什么数据值得回流。如果触发规则设计不当，要么漏掉关键场景，要么上传大量重复数据。建议在车端和边缘端都保留可配置的触发规则，并通过影子模式持续评估规则命中率。
复盘要点：定期统计“上传数据中被标注使用的比例”。如果该比例低于30%，说明触发规则过于宽松；如果高于80%但模型仍有明显短板，说明触发规则可能遗漏了某些长尾场景，需要补充新的触发条件。
三层架构的落地不是一次性工程，而是需要根据车队规模、网络条件和模型迭代节奏持续调优。建议先在小规模车队验证触发规则与带宽策略，再逐步推广到全车队。