自动驾驶数据平台为什么需要 search + vector + OLAP
自动驾驶的数据闭环系统是一个有意思的技术场景。这里不展开自动驾驶本身的问题，只聊数据平台的技术选型逻辑。
场景特点
自动驾驶的数据处理有几个显著特点：
数据规模大。每一辆车每秒产生 GB 级别的传感器数据，包括摄像头、雷达、激光雷达、GPS 等。
数据类型多。结构化的轨迹数据、非结构化的图像和视频、日志文件、标注数据…
查询模式多样：
- 精确查询：查找特定时间、车辆、场景的数据
- 语义查询：在海量数据中找到”类似弯道”、“行人突然出现”的场景
- 分析查询：统计某种场景的出现频率、corner case 分布
时效性要求不同：
- 实时处理：碰撞检测、异常告警
- 近实时：模型更新、数据质量监控
- 离线分析：场景挖掘、长尾分布分析
为什么需要组合
单一的数据系统很难同时满足所有需求：
Search（Elasticsearch/Solr）：处理精确的结构化查询，适合日志检索、事件查询。
Vector（Milvus/Pinecone）：处理语义相似性查询，用于场景检索、图像/视频相似搜索。
OLAP（Doris/ClickHouse）：处理大规模分析查询，支持实时分析、聚合统计。
一个完整的数据闭环平台往往需要三者配合：
- 原始数据入湖/湖仓
- 结构化数据进 Search 系统支持精确查询
- embedding 后的数据进向量数据库支持语义检索
- 指标类数据进 OLAP 系统支持分析
技术整合的挑战
不同系统的数据同步、一致性保证、查询路由…这些都是工程上需要解决的问题。
有兴趣再单独写一篇聊具体实现。