转载

对象存储在无人驾驶高精度地图的场景实践

在自动驾驶领域有这样一个说法：关注自动驾驶的进展，就看高精地图的动态，因为他们才是加速自动驾驶汽车落地的幕后推手。本文介绍了QingStor:registered:对象存储的种种优势以及许多针对该场景的特性，分享了对象存储在高精度地图场景中的最佳实践。

大家都对无人驾驶和地图比较熟悉，但是大家相对较少听到高精地图这个名词，简单地说，高精地图是给自动驾驶的汽车使用的，与日常使用的二维平面地图有比较大的差异，包含的信息也会更加复杂。

无人驾驶与高精地图关系概述

对象存储在无人驾驶高精度地图的场景实践

对于无人驾驶而言，主要分为四个阶段。在感知阶段中，车辆核心依靠车载传感器获取具体的道路与环境信息，然而在实际情况中，由于天气、环境等不确定性，仅仅依赖传感器是无法实现自动驾驶的，每一种传感器都有各自的感知缺陷和限制：

如激光传感器检测效果稳定，但在面对大范围的尘土时，其检测效果大幅降低；
高分辨率摄像机能检测图像中的物体，窄视场的摄像机可以检测很远的距离，但是面对暴雨、大雪等恶劣天气，其很难检测到正确的车道线和障碍物等信息；
传感器是很难判断车辆所处位置是高速公路上还是处在普通城市道路上的，车速最高可以开多快，前方道路的曲率，所处路段的 GPS 信号强弱都会影响检测结果；
额外传感器遇到检测盲区，更加无法实时捕获的道路与环境信息。

这些问题，在有了高精度地图后都迎刃而解。

在无人驾驶的第二阶段定位和第三阶段车辆行驶决策阶段，都需要依赖高精度地图来共同完成决策。

在当前，L3 以上的驾驶级别都无法离开高精度地图的支撑。高精度地图包含哪些具体信息，可以支撑车辆实现自动化驾驶？

高精度地图包含为两类数据：

第一类为道路数据，如车道线的位置、类型、宽度、坡度和曲率等车道信息；

第二类为车道周边环境信息，如交通标志、交通信号灯、车道限高、下水道口、障碍物、高架物体、防护栏、道路边缘类型与路边地标等基础设施信息。

对象存储在无人驾驶高精度地图的场景实践

由于地图采集设备的精度不同产生的数据大小也不同，由此可见在高精度地图的场景中，第一个场景特点是数据体量极为庞大，到底会产生多少数据呢？

举个列子让大家有个直观的印象，一辆标准的数据采集车大概有 4-5 个传感器，每天可完成的采集路程在百公里左右，产生约 1TB 数据。

对于高精度地图而言，采集和制图如果说是 10% 的工作量，那后期地图长期的更新可能需要占 90% 的工作量。

关于地图的更新模式，车队学习网络的分包式地图的更新模式可能会成为一种主流，车队学习网络非常类似迅雷的 P2P 下载，资源使用者同时也是资源分享者，特斯拉即采取这种模式，每一辆量产车都是地图数据的贡献者。

从这个场景我们发现，不仅仅地图前期的采集数据量和数据存储量庞大，在后期地图的更新中同样面临着庞大数量的采集车带来的数据并发与更新压力。

QingStor:registered:对象存储在高精地图场景应用

对象存储在无人驾驶高精度地图的场景实践

高精度地图的制作过程主要分为四个步骤。

首先是地图采集和预处理，经过预处理的数据会写入到QingStor:registered:对象存储中进行保存；之后，由 QingStor:registered:对象存储将数据输出到 AI 训练一体机如英伟达 DGX-1，由于 AI 训练一体机需要对地图做复杂的点云和视频数据、图片数据融合处理，单位时间所能处理的数据量是有限的。

在这之前，采集到的海量数据需要存储在 QingStor:registered:对象存储中，训练完成之后的数据，同样需要写回到 QingStor:registered:对象存储中做长期留存。

在这个场景中，QingStor:registered:对象存储贯穿了整个高精度地图的全部制作过程，负责了海量地图数据的转储与最终地图数据的长期存储。

目前 QingStor:registered:对象存储在该场景中的整体数据存储规模已达 10 个 PB，未来三年的总体规模将会达到 40PB 左右。

对象存储在无人驾驶高精度地图的场景实践

这是 QingStor:registered:对象存储在该场景的数据流架构图，数据采集之后，通过程序接口（当前主要为S3和青云自己的API接口）以及多语言 SDK 完成数据接口的接入，并将数据写入到 QingStor:registered:对象存储中；再由 AI 学习一体机 DGX1 获取 QingStor:registered:对象存储中的数据进行处理，处理完成的数据再回写到对象存储中。

在这个场景部署单一全局统一命名存储空间的 QingStor:registered:对象存储集群,使用了与 QingCloud 公有云对象存储完全一致的架构，采用接入服务器与存储服务器分层部署的架构来进行海量数据的承载。从功能架构上看并不复杂，在使用对象存储的使用场景中，业务部门要有一定的接口开发与对接能力。

高精地图场景挑战及最佳实践

对象存储在无人驾驶高精度地图的场景实践

QingStor:registered:对象存储在场景中具体面对哪些挑战，以及如何在产品架构设计与功能特性上去解决这些问题，下面做个简单的总结。

首先是对性能和空间需求的不确定性挑战。

在地图的前期制作过程中，采集车的数量是相对固定的，数据生成量也同样相对固定，也就是说并发压力相对固定，后期因为地图需要持续更新，使用这种分包模式的地图更新方式，成千上万辆采集车都在每天 24 小时更新地图，从而带来的并发访问压力与数据写入压力成百上千倍地增加，数据量与存储量也难以预估规模。

面对这样的情况，QingStor:registered:对象存储采用分层设计来解决这个问题，整体架构分为负责会话接入和索引的接入层和负责具体数据存储的存储层，这样的设计可单独根据并发压力和存储空间的实际需求，进行单独的扩展，且不同角色的服务器节点还可以使用不同的配置，降低成本的同时也不浪费资源，最终实现的效果就是可单独根据并发数和存储空间的实际需求进行分层单独扩容，让存储匹配业务的规模和压力，从而实现使用最低的投入去满足业务的需求，获取较高的 ROI。

对象存储在无人驾驶高精度地图的场景实践

其次是业务对数据安全和服务可靠性提出的挑战。

在车辆行驶过程中对高精度地图的高度依赖造成车辆对地图数据的访问可靠性要求极高，对服务可用性要求较高。

对于分布式存储而言，拿社区主流的分布式存储 Ceph 来说，集群故障、扩容，都必须面对数据重构和平衡问题，这本身是个非常好的设计出发点，可以实现存储节点的负载均衡与数据存储的分布均衡，但是在一个超大规模存储系统中，数据在局部的新增或删除，尽量不要扩散到整个集群，甚至需要刻意抑制这种大范围的数据均衡，QingStor:registered:对象存储是如何解决这个难题，可以参考右边的逻辑架构图。

首先，将庞大的存储集群分成若干个存储小组来缩小故障域，不同的存储组之间毫无关系无任何关联，节点故障后副本修复的影响范围只在本存储组内的三台节点中，从而解决节点宕机后触发整个集群数据再分布的问题。

QingStor:registered:对象存储对不同的存储组设置不同的存储权重，权重是根据存储组的可用存储空间、inode 可用数量等因素共同构成的优先级权重，扩容之后优先将数据写入到权重值较大的存储组中，其他存储组的数据不会做任何变动，从而规避集群在超大规模时扩容服务器带来的集群内部数据的均衡问题。

对象存储在无人驾驶高精度地图的场景实践