突破大表瓶颈|小鹏汽车使用PolarDB实现百亿级表高频更新和实时分析

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介: PolarDB已经成为小鹏汽车应对TB级别大表标注、分析查询的"利器"。

客户推荐语录

阿里云瑶池旗下的云原生数据库PolarDB PostgreSQL版的存储具备弹性扩容能力,最大可支持100TB存储空间。它的大表优化和弹性跨机并行查询(ePQ),成功解决了社区PostgreSQL针对大表的查询和并发更新慢的问题。在小鹏汽车的智能辅助驾驶业务上,实现了每日TB级大数据表的7000万行更新和大数据表秒级分析查询。

——小鹏汽车智能辅助驾驶SRE负责人


1、客户介绍

1.1 关于小鹏汽车

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

1.png

1.2 业务场景

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


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

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


2.1 大表查询慢

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


2.2 大表频繁更新

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


2.3 存储空间快速增长

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


3、突破僵局——PolarDB的方案

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

2.png

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

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

3.png

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

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


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

4.png

▶︎ 客户业务问题 📂

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


▶︎ 原因分析 🤔️

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


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


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


▶︎ 解决办法💡

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


  1. 二分查找获取表大小:在文件扩展或者优化器代价估计。社区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)。
  2. 减少冗余文件校验:社区PostgreSQL在刷脏写入一个页面的时候,需要逐个打开之前所有Segment文件计算页面写入位置信息,检查页面写入位置信息正确。PolarDB-PG优化过后,在保证数据正确性的基础上,减少冗余的文件校验,仅获取 SegN-1和SegN两个文件大小。
  3. 表大小缓存(Relation Size Cache):PolarDB-PG设计的表大小缓存,会在优化器进行代价估计的时候优先采用缓存,而不是通过IO获取文件大小。


3.3 存算分离实现弹性扩容

5.png

▶︎ 客户业务问题 📁

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


▶︎ 解决办法 💡

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


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

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

以数据统计业务为例,大表(这里简称为 xxx)的表大小为7.6TB,通过如下语句查询:

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秒。

6.png

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

7.png

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


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

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


优化前:整体的open/seek iops达到30000 ~ 40000。

优化后:整体的open/seek iops达到5000 左右,减少80%的iops数量。

8.png

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

优化前:

9.png

优化后:

10.png

4.3 存算分离实现弹性扩容

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

11.png

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

12.png


5. 总结

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

  1. 支持TB级别大表的秒级分析查询;
  2. 支持TB级别大表每日7千万的频繁标注更新;
  3. 提供100 TB的存储空间、存储弹性自动扩容、按量付费方式;
  4. 所有大表优化对业务完全透明,无需业务修改,省去开发和运维负担。
相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
11天前
|
SQL 存储 监控
|
11天前
|
监控 关系型数据库 MySQL
|
1月前
|
监控 关系型数据库 分布式数据库
【PolarDB 开源】PolarDB HTAP 实践:混合事务与分析处理的性能优化策略
【5月更文挑战第21天】PolarDB开源后在HTAP领域表现出色,允许在同一系统处理事务和分析工作负载,提高数据实时性。通过资源分配、数据分区、索引优化等策略提升性能。示例代码展示了创建和查询事务及分析表的基本操作。PolarDB还提供监控工具,帮助企业优化系统并应对业务变化。其HTAP能力为开发者和企业提供了强大支持,推动技术进步,加速数字化时代的业务发展。
395 1
|
11天前
|
SQL 监控 安全
|
29天前
|
关系型数据库 Serverless 分布式数据库
【PolarDB 开源】PolarDB Serverless 模式:自动扩缩容与成本效益分析
【5月更文挑战第25天】PolarDB Serverless 提供自动扩缩容功能,适应动态工作负载,降低成本。在业务高峰期增加资源保障性能,低谷期减少资源实现成本优化。通过对比传统模式下的成本浪费,示例说明了Serverless如何节省开支。代码演示了连接与查询PolarDB Serverless数据库的基本操作。要充分利用该模式,需合理规划业务、监控性能并结合其他云服务。PolarDB Serverless是弹性、经济的数据库选择,未来将持续创新,助力企业高效发展。
376 1
|
29天前
|
关系型数据库 分布式数据库 数据处理
【PolarDB 开源】PolarDB 在大数据分析中的应用:海量数据处理方案
【5月更文挑战第25天】PolarDB是解决大数据挑战的关键技术,以其高性能和可扩展性处理大规模数据。通过与数据采集和分析工具集成,构建高效数据生态系统。示例代码显示了PolarDB如何用于查询海量数据。优化策略包括数据分区、索引、压缩和分布式部署,广泛应用于电商、金融等领域,助力企业进行精准分析和决策。随着大数据技术进步,PolarDB将继续发挥关键作用,创造更多价值。
171 0
|
30天前
|
关系型数据库 分布式数据库 数据库
【阿里云云原生专栏】云原生时代的数据库选型:阿里云RDS与PolarDB对比分析
【5月更文挑战第24天】阿里云提供RDS和PolarDB两种数据库服务。RDS是高性能的在线关系型数据库,支持MySQL等引擎,适合中小规模需求;而PolarDB是分布式数据库,具备高扩展性和性能,适用于大规模数据和高并发场景。RDS与PolarDB在架构、性能、弹性伸缩、成本等方面存在差异,开发者应根据具体需求选择。示例代码展示了如何通过CLI创建RDS和PolarDB实例。
589 0
|
1月前
|
存储 关系型数据库 MySQL
TiDB与MySQL、PostgreSQL等数据库的比较分析
【2月更文挑战第25天】本文将对TiDB、MySQL和PostgreSQL等数据库进行详细的比较分析,探讨它们各自的优势和劣势。TiDB作为一款分布式关系型数据库,在扩展性、并发性能等方面表现突出;MySQL以其易用性和成熟性受到广泛应用;PostgreSQL则在数据完整性、扩展性等方面具有优势。通过对比这些数据库的特点和适用场景,帮助企业更好地选择适合自己业务需求的数据库系统。
|
1月前
|
关系型数据库 分布式数据库 PolarDB
电子书阅读分享《PolarDB开发者大会:PolarDB在线数据实时分析加速》
电子书阅读分享《PolarDB开发者大会:PolarDB在线数据实时分析加速》
211 3
|
19天前
|
关系型数据库 分布式数据库 数据库
数据库内核那些事|PolarDB IMCI让你和复杂低效的子查询说拜拜
PolarDB IMCI(In-Memory Column Index)确实是数据库领域的一项重要技术,特别是当它面对复杂和低效的子查询时,表现尤为出色。以下是关于PolarDB IMCI如何助力解决

相关产品

  • 云原生数据库 PolarDB