复杂存储过程学习_对象存储在无人驾驶高精度地图的场景实践

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

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

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

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

• 如激光传感器检测效果稳定&＃xff0c;但在面对大范围的尘土时&＃xff0c;其检测效果大幅降低&＃xff1b;

• 高分辨率摄像机能检测图像中的物体&＃xff0c;窄视场的摄像机可以检测很远的距离&＃xff0c;但是面对暴雨、大雪等恶劣天气&＃xff0c;其很难检测到正确的车道线和障碍物等信息&＃xff1b;

• 传感器是很难判断车辆所处位置是高速公路上还是处在普通城市道路上的&＃xff0c;车速最高可以开多快&＃xff0c;前方道路的曲率&＃xff0c;所处路段的 GPS 信号强弱都会影响检测结果&＃xff1b;

• 额外传感器遇到检测盲区&＃xff0c;更加无法实时捕获的道路与环境信息。

这些问题&＃xff0c;在有了高精度地图后都迎刃而解。

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

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

高精度地图包含为两类数据&＃xff1a;

• 第一类为道路数据&＃xff0c;如车道线的位置、类型、宽度、坡度和曲率等车道信息&＃xff1b;

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

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

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

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

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

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

QingStor^®️对象存储在高精地图场景应用

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

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

在这之前&＃xff0c;采集到的海量数据需要存储在 QingStor^®️对象存储中&＃xff0c;训练完成之后的数据&＃xff0c;同样需要写回到 QingStor^®️对象存储中做长期留存。

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

目前 QingStor^®️对象存储在该场景中的整体数据存储规模已达 10 个 PB&＃xff0c;未来三年的总体规模将会达到 40PB 左右。

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

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

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

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

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

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

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

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

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

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

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

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

第三&＃xff0c;数据类型的多样性带来的挑战。

地图采集场景的数据类型丰富&＃xff0c;如图片、视频、其他传感器数据等&＃xff0c;数据类型和大小差异较大&＃xff0c;但是对存储效率要求一致。存储引擎层常规都会对数据进行固定的分片之后再做存储&＃xff0c;数据过大或数据过小都会带来不同的问题&＃xff0c;分片一定程度上会影响存储的效率。

QingStor^®️对象存储从架构设计上不假设用户数据的具体场景、文件类型和文件大小&＃xff0c;文件大小在 4M-5GB 的范围内&＃xff0c;将自由度交付给用户&＃xff0c;允许用户根据实际场景的文件大小进行副本的生成&＃xff0c;存储引擎层不做额外的处理&＃xff0c;从而保证不同类型和大小的文件存储效率依然较高。

第四&＃xff0c;数据交互平台多样带来的接口适配挑战。

前面我们提到&＃xff0c;对象存储在使用上具有一定的对接复杂度&＃xff0c;更通俗的说&＃xff0c;对象存储是给程序使用的。地图制作的过程中&＃xff0c;涉及到多个地图制作的平台和软件&＃xff0c;如地图信息数据输入平台、标注平台、深度学习一体机等&＃xff0c;涉及多种语言接口。

目前&＃xff0c;QingStor^®️对象存储在 SDK 的支持上基本覆盖主流的语言&＃xff0c;在 API 的支持上&＃xff0c;支持完善的 S3 接口&＃xff0c;此外还支持功能更多的青云QingCloud 自有 API 接口。

当前的场景中&＃xff0c;还会涉及到多种平台的数据迁移、导出等需求&＃xff0c;对象存储还必须具备多种数据迁移工具来实现自动化的数据迁移。

目前 QingStor^®️对象存储支持本地文件系统、多种公有云对象存储、Hadoop 平台、HDFS 文件系统等平台之间的数据流转。

客户收益

下面总结一下海量地图场景中&＃xff0c;使用QingStor^®️对象存储所带来的收益与价值。

第一点&＃xff1a;较高的 ROI 回报&＃xff0c;分层架构的设计让存储可以根据业务的需求进行定向定量扩容&＃xff0c;减少资源浪费。

第二点&＃xff1a;成熟的技术架构&＃xff0c;高精地图场景对可用性和数据可靠性的要求是苛刻的&＃xff0c;选择经过大规模公有云验证的平台是风险较低的一种选择&＃xff0c;用户只需专注在业务上而无需过多关注底层的承载平台。

第三点&＃xff1a;较高的性价比&＃xff0c;目前 QingStor^®️对象存储在该客户中&＃xff0c;不仅只用在高精地图场景&＃xff0c;还在大数据分析的应用场景中使用&＃xff0c;实现了一套平台多种用途&＃xff0c;降低整体 TCO。

第四点&＃xff1a;极低的运维成本&＃xff0c;QingStor^®️对象存储稳定可靠&＃xff0c;且有完善的服务支持&＃xff0c;目前在这样的规模量级&＃xff0c;只有一名运维人员即可管理&＃xff0c;极大地降低了运维成本。

我们来总结 QingStor^®️对象存储的产品优势&＃xff0c;类似图片处理、数据生命周期管理、开放的 API 等功能性不再进行重点介绍&＃xff0c;在这里想重点介绍三点&＃xff0c;分别是分层设计、公私一体与丰富的生态。

• 分层设计可以满足超大规模的应用&＃xff0c;同时规避了分布式存储的重构和再均衡问题&＃xff1b;

• 公私一体化保障了产品的稳定性&＃xff1b;

• 丰富的解决方案生态让 QingStor^®️对象存储可以为最终用户的提供更多的应用价值。

QingStor^®是青云QingCloud 自主研发的企业级分布式存储产品线&＃xff0c;依托于 QingCloud 公有云将近7年的技术迭代和规模化应用&＃xff0c;提供全形态软件定义存储产品的私有化部署&＃xff0c;作为软件定义存储的主流国产品牌&＃xff0c;旗下包括&＃xff1a;

• QingStor^®NeonSAN^®(块存储)

• QingStor^®对象存储

• QingStor^®文件存储

• QingStor^®融合存储

基于一套架构支撑多业务场景&＃xff0c;在一个界面实现异构数据的全生命周期管理。

QingStor^®企业级分布式存储历经多年发展&＃xff0c;广泛服务于金融、能源、制造、医疗、传媒等行业的数字化转型 2.0&＃xff0c;用数据驱动企业决策&＃xff0c;以更敏捷、易用、低成本的方案引领数字业务创新。