智能辅助驾驶业务遭遇大表瓶颈，小鹏汽车如何破局？-阿里云开发者社区

智能辅助驾驶业务遭遇大表瓶颈，小鹏汽车如何破局？

2024-05-13 80497

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

云原生数据库 PolarDB PostgreSQL 版，标准版 2核4GB 50GB

云原生数据库 PolarDB MySQL 版，通用型 2核4GB 50GB

简介： 小鹏汽车在智能辅助驾驶业务中遇到数据库性能挑战，如大表查询慢、频繁更新和存储空间快速膨胀。他们原使用的是社区版PostgreSQL，但随着数据量增长，性能瓶颈日益凸显。为了解决这些问题，小鹏汽车采用了阿里云的PolarDB-PG。PolarDB-PG 的存储具备弹性扩容的能力，最大可支持 100 TB 存储空间。它的大表优化和弹性跨机并行查询（ePQ），成功解决了社区 PostgreSQL 针对大表的查询和并发更新慢的问题。在小鹏汽车的智能辅助驾驶业务上，实现了每日 TB 级大数据表的 7000 万行更新和大数据表秒级分析查询。

作者：渊云、晋北

客户推荐语录

PolarDB-PG 的存储具备弹性扩容的能力，最大可支持 100 TB 存储空间。它的大表优化和弹性跨机并行查询（ePQ），成功解决了社区 PostgreSQL 针对大表的查询和并发更新慢的问题。在小鹏汽车的智能辅助驾驶业务上，实现了每日 TB 级大数据表的 7000 万行更新和大数据表秒级分析查询。

——小鹏汽车 SRE 负责人

客户介绍

1.1 关于小鹏汽车

小鹏汽车是中国领先的智能电动汽车公司，致力于为对技术充满热情的消费者设计、开发、制造和营销智能电动汽车。公司的核心使命是通过科技驱动智能电动汽车的变革，引领未来的出行方式。为了提升客户的驾驶体验，小鹏汽车投入了大量资源自主研发全栈式智能辅助驾驶技术、车载智能操作系统，以及涵盖动力总成和电子电气架构的车辆核心系统。

1.2 业务场景

智能辅助驾驶是小鹏汽车的重点技术方向，每天有海量的图片、视频数据采集上传。有海量的数据存储在对象存储中，同时还需要在关系数据库中针对每个文件生成一条“目录”，以便批量地查找和管理文件，记录文件的位置、属性、指标等。这就导致了这个“目录”要覆盖到全量的数据文件，即数据库的超大单表，并且随着指标的变化要经常进行表的全量数据更新。

遭遇瓶颈——海量数据的考验

小鹏汽车原先使用的数据库是社区 PostgreSQL，随着智能辅助驾驶业务的快速增长，系统面临数据处理的三重挑战：

2.1 大表查询慢

面对海量数据，单机并行处理能力已经达到极限，无法应对 TB 级大表的查询，小鹏汽车的智能辅助驾驶分析业务承受前所未有的压力。小鹏汽车数据中心最庞大的数据表体量已攀升至 7 TB，而超过 TB 级别的数据表数量更是多达四张。当大表的分析查询时间达到数十分钟甚至数小时时，这一数据处理瓶颈已成为制约智能辅助驾驶业务的关键难题，迫切需要一种新的技术解决方案来破解。

2.2 大表频繁更新

在小鹏汽车的标注业务中，面临着一个日益严峻的问题：TB 级大数据表每天的更新量高达 7000 万行。这一庞大的数据流量引发了一系列的问题，尤其是在 TB 级大表更新过程中，过多的文件校验作业导致了文件系统的 IOPS 达到极限，进而导致了系统性能的急剧下降。最终，这种过载使得单行数据更新耗时达到分钟级，进而触发数据库雪崩，对公司的业务运营构成了直接的威胁。

2.3 存储空间快速增长

数据库总容量飙升至 30 TB 并且以每月 2 TB 的惊人速度持续增长。社区版的 PostgreSQL 数据库面临着一个严峻挑战：它无法实现自动化的扩容。这样迅猛增加的存储需求正急剧逼近系统的极限，成为了一个亟待解决的难题。

突破僵局——PolarDB的方案

随着数据量越来越大，社区版 PostgreSQL 遇到性能瓶颈，数据处理链路产生堆积，尤其是数据批量更新更是成为卡点，影响智能辅助驾驶研发效率。针对现状和 PostgreSQL 生态兼容性考虑推荐客户测试 PolarDB-PG （PolarDB PostgreSQL 版，简称为 PolarDB-PG），在兼容现有业务代码的同时，解决单机数据库的性能瓶颈，提高研发效率：

3.1 ePQ 加速 TB 级大表分析查询

ePQ 是 Elastic Parallel Query（弹性并行查询）的缩写。PolarDB-PG 通过 ePQ 优化器，生成能够被多个计算节点并行执行的执行计划。ePQ 的执行引擎将在多个计算节点上协调执行该计划，同时利用多个节点的CPU、内存、I/O带宽来扫描和计算数据。PolarDB-PG ePQ 的架构示意图如下所示：

基于此架构，PolarDB-PG 的 ePQ 相较于社区 PostgreSQL 有如下优势：

极致的分析查询性能：1TB TPC-H 测试平均提升 23 倍性能，性能可随并行度、节点数线性提升。
业务完全透明：无须修改任何业务代码，仅需在控制台打开 polar_enable_px开关即可使用 ePQ。
一体化存储：TP/AP 共享一套存储数据，减少存储成本。TP 高压力写入下，AP 引擎提供毫秒级数据新鲜度。

3.2 大表优化解决大表频繁更新问题

客户业务问题

在小鹏汽车的场景下，单表的大小达到 TB 级别，最大可达到 7 TB。业务侧采用短连接 + 高并发（> 400）更新的方式来访问 TB 级大表。在这种情况下，大表的文件访问操作（例如 open/lseek）会将整个数据库的 IOPS 打满，IO 时延飙升，触发数据库雪崩。

原因分析

在社区 PostgreSQL 中，每张表的文件都是以 Segment 为单位来进行存储，每个 Segment 大小为 1GB。在如下三个场景需要使用 open/lseek 文件访问操作来获取文件大小：

刷脏操作：在脏页写入情况下，需要定位每一个脏页需要写入的具体位置。这个时候，需要打开写入页面前所有的 segment 文件，通过 lseek 获取所有 segment 文件大小并求和，最终，check 脏页写入位置正确。
DML 引发的表扩展：在 Insert/Update 过程中，如果找不到空闲页面，会进行表扩展。表扩展的时候需要获取当前表的大小用来定位表扩展后的位置，获取当前表大小需要逐个 open/lseek segment 文件。
优化器进行代价估计：优化器在对普通表进行代价估计的时候，需要获取表大小用来判断采用 seqscan 还是 indexscan。获取当前表大小需要逐个 open/lseek segment 文件。

小鹏汽车智能辅助驾驶场景下， 7 TB 的大表意味着 7000 个 Segment 文件，每次对大表进行刷脏或者表扩展的时候，单次文件写入操作会被放大成 7000 个 Segment 文件长度校验。同时业务侧还是采用短连接 + 高并发的方式访问大表，意味着文件句柄无法缓存，只能采用文件操作（open/lseek）来访问 Segment 文件长度，最终大表的海量文件访问将整个数据库的 IOPS 打满，IO 时延飙升，触发数据库雪崩。

解决办法

PolarDB-PG 用如下三个方法解决了大表写入问题：

二分查找获取表大小：在文件扩展或者优化器代价估计。社区 PostgreSQL 获取表文件大小，需要逐个获取每个 segment 大小，复杂度为 O(N)；PolarDB-PG 优化过后，按 2 的倍数依次打开 segment 文件（例如 0、1、2、4、16、32....），直至文件不存在，锁定文件大小区间，例如 [64,128)。然后在 [64,128)二分查找 segment N 存在并且 N+1 不存在，最终文件的大小锁定为 (N-1)*segment_size + 第 N 个 segment 大小（segment_size 为 1GB）。经过优化后，表文件大小获取的复杂度由 O(N) 降低至 O(logN)。
减少冗余文件校验：社区 PostgreSQL 在刷脏写入一个页面的时候，需要逐个打开之前所有 Segment 文件计算页面写入位置信息，检查页面写入位置信息正确。PolarDB-PG 优化过后，在保证数据正确性的基础上，减少冗余的文件校验，仅获取 SegN-1和SegN两个文件大小。
表大小缓存（Relation Size Cache）：PolarDB-PG 设计的表大小缓存，会在优化器进行代价估计的时候优先采用缓存，而不是通过 IO 获取文件大小。

3.3 存算分离实现弹性扩容

客户业务问题

小鹏汽车的 PolarDB-PG 实例数据量达到 30 TB，并且以平均每月 2 TB的速度在增长。基于 ECS 自建的 PostgreSQL 数据库已无法应对数据增长的需要。

解决办法

PolarDB-PG 基于存储计算分离的架构，PolarStore 存储集群可独立扩展，支持弹性扩容，存储按量进行计费，最大支持 100 TB 存储，PolarStore 存储集群的读写带宽稳定在 1.6 GB/s 以上。大容量 + 高带宽确保 PolarDB-PG 的 IO 和存储空间不成为瓶颈。

迎接转机——系统性能的蝶变

4.1 大表分析查询速度提升3.6倍

以数据统计业务为例，大表（这里简称为 xxx）的表大小为7.6 TB，通过如下语句查询：

select count(1) as cnt from xxx where create_time>='2024-03-19 01:00:00' and create_time<'2024-03-19 02:00:00';

未使用 ePQ 查询，采用原生单机并行查询，并行度为 6，执行时间为 66 秒。

采用 ePQ 2个 RO 节点，24 并发查询，执行时间可降低至 18 秒。

采用 ePQ 跨机并行查询相较于单机并行查询速度可提升 3.6 倍，能达到查询性能随并行度线性提升。再增加只读节点，查询速度仍可继续提升。

4.2 数据等待事件降低至几乎为0

下图展示了文件系统 seek 和 open iops 的变化，红线左侧是优化前的表现，红线右侧是优化后的表现。

优化前：整体的 open/seek iops 达到 30000 ～ 40000。
优化后：整体的 open/seek iops 达到 5000 左右，减少 80% 的 iops 数量。

如下图所示，图中的每一项表示数据库在运行过程中的等待事件总量。由原来平均 600+ 的 FileOpen/FileSeek 等待事件，优化到后面几乎没有 FileOpen/FileSeek 等待事件( < 1)。

优化前：

优化后：

4.3 存算分离实现弹性扩容

下图展示了小鹏客户的总数据量和 7 天内数据增长量。总数据量达到 37 TB 级别，数据增长量峰值达到每 7 天 1.5 TB，平均以每月 2TB 的速度增长。但 PolarDB-PG 的存储空间不成为瓶颈。

下图展示了小鹏汽车智能辅助驾驶业务在业务高峰期的 IO 读写带宽，稳定在 1.6 GB/s 以上。PolarDB-PG 的高读写带宽确保智能辅助驾驶业务在高峰期正常运行。

总结

PolarDB-PG 的自动弹性扩容、大表优化和弹性跨机并行查询已经成为小鹏汽车智能辅助驾驶业务应对 TB 级别大表标注、分析查询的"利器"。同时，PolarDB-PG 针对大表的高性能解决方案也可以更好地满足类似汽车领域内智能辅助驾驶业务的数据库访问需求：

支持 TB 级别大表的秒级分析查询；
支持 TB 级别大表每日 7 千万的频繁标注更新；
提供 100 TB 的存储空间、存储弹性自动扩容、按量付费方式；
所有大表优化对业务完全透明，无需业务修改，省去开发和运维负担。