PolarDB 弹性并行查询（ePQ）技术解密

背景

经过长期的统计观察，云原生关系数据库整体的资源利用率普遍偏低，大量计算资源处于闲置状态。这对于用户而言，一方面造成了分析型查询的高延迟，另一方面也导致了计算资源的浪费。特别是在当今强调降本增效的环境下，迫切需要一种技术来有效利用闲置的计算资源，以加速大型查询的执行。

并行查询技术能够有效地利用多核CPU进行查询加速，是提升关系型数据库查询性能的一种非常有效的手段。许多传统数据库，如Oracle、SQL Server和DB2等，都已具备成熟的并行查询解决方案。

PolarDB弹性并行查询（ePQ）是PolarDB MySQL版推出的企业级查询加速功能。它同时支持单机并行和多机并行两种模式：单机并行通过利用单个节点内的计算资源来实现查询加速，而多机并行则能够利用集群内任意节点的闲置资源进行并行加速，具备分布式执行能力。这样不仅可以突破单机计算的瓶颈，还能有效提升整个集群的资源使用率。

产品特性

开箱即用

性能提升

自适应弹性调度

100%兼容MySQL

稳定可靠

如果您已经是PolarDB MySQL版的用户，并且业务在某些查询存在性能瓶颈，或者在SQL洞察中发现有慢查询需要优化，同时集群的资源利用率并未长时间保持在高水平，那么开启PolarDB的ePQ功能将是一个理想的选择。在集群地址的配置页面，您只需点击开启并行查询，并配置适当的并行度，应用程序无需进行任何改动，便可以享受到并行查询带来的显著加速效果。

并行查询的并行度一般建议初始设置为CPU核数的1/4，观察集群资源负载一段时间（比如7天），若集群仍有较多空闲资源，可适当逐步提升并行度。

开启ePQ后，PolarDB优化器将根据查询的代价以及查询数据量的大小，自动决定是否进行并行加速。同时，优化器还会实时考虑当前集群的负载情况。您只需要进行少量配置，即可体验一体化的查询加速能力。当然，如果您希望进行更精细的控制，我们也提供了一系列参数供调整，例如records_threshold_for_parallelism和cost_threshold_for_parallelism，可以用来设定并行执行的阈值。具体细节请参见并行查询参数说明。

为了验证PolarDB ePQ在分析类查询场景中的加速效果，我们使用了TPC-H基准测试。TPC-H是业界广泛认可的一套基准测试标准，由TPC委员会制定并发布，旨在评估数据库的分析型查询能力。TPC-H基准包含8张数据表和22条复杂的SQL查询，大多数查询涉及多个表的连接、子查询以及Group By聚合等操作。

说明

• 本文的TPC-H的实现基于TPC-H的基准测试，并不能与已发布的TPC-H基准测试结果相比较，本文中的测试并不符合TPC-H基准测试的所有要求。

• 如上所示的TPC-H测试数据中，仅对数据库表添加了主外键约束，没有建立其他任何二级索引。具体的测试方法请参见PolarDB 性能白皮书。

根据以上测试结果，TPC-H中的22条SQL查询均实现了加速。并行查询在单节点上的平均加速比达到17倍，最高可达56倍；在跨4节点并行处理时，平均加速比提升至59倍，最高可达159倍。通过对比分析，我们发现ePQ展现出良好的线性加速能力——即随着节点数量的增加，加速效果呈线性提升。这意味着通过升级集群规格或增加节点数量，用户可以获得更显著的性能提升。

自动弹性扩缩容和Serverless是云原生数据库PolarDB的核心能力，能够根据集群资源动态调整，以适应客户业务负载的变化。相较之下，原生MySQL采用的是单线程执行模式，无法通过垂直扩展（Scale Up）或水平扩展（Scale Out）来加速复杂的分析型查询。这是由于单个查询只能在一个线程中执行，最多只能利用一个CPU进行计算。

PolarDB的ePQ（增强并行查询）功能支持自适应弹性调度，能够根据集群的实时负载情况动态调整查询执行的并行度，并选择适合的节点进行运行。当集群进行规模扩大（Scale Up）或横向扩展（Scale Out）时，ePQ能及时识别出集群中新增的计算资源，自动提高并行度，或将排队中的查询分配到新扩展的计算节点上。这一机制有效降低了分析类查询的延迟，提高了查询性能。

如图所示，PolarDB的ePQ（增强并行查询）自适应弹性调度不仅能够有效加速查询过程，还能实现负载均衡，避免某些节点因负载过高而影响正常业务。

PQ架构与传统MPP架构的比较

• 架构相似性：

  二者都通过将查询的子任务分发到多个节点进行并发计算。

• 计算与存储：

  • 传统MPP架构：

    • 计算与存储是耦合的。

    • 查询的子任务需发送到数据所在的节点进行本地化计算。

    • 因此，子任务的拆分受到数据分布的影响。

  • PolarDB架构：

    • 基于云端基础设施实现了计算与存储的分离。

    • 任何节点均可访问全量数据，增强了调度灵活性。

    • 集群规格可以根据负载需求随时扩展或缩减，且无需迁移数据。

• 无状态并行任务：

  PolarDB支持无状态的并行任务，理论上可调度到任意节点上执行，提升了任务调度的自由度。

并行查询执行引擎是嵌入在PolarDB MySQL计算引擎中的内核扩展特性。它与原有系统共享同一套SQL解析器和优化器，确保了SQL语法、数据类型和行为与MySQL的100%完全兼容。

PolarDB并行查询作为PolarDB MySQL版的核心企业级查询加速功能，自产品诞生之初便作为关键技术方向持续投入研发。自2019年首个版本发布以来，经过多年的技术迭代与优化升级，该功能已在云环境中为上千家企业客户提供稳定可靠的服务支持。无论是查询性能的显著提升，还是系统运行的稳定表现，均已达到企业级应用的高标准要求，充分证明了其在生产环境中的成熟度和可靠性。

技术架构

整体架构

PolarDB ePQ的目标是打通集群计算层的计算资源，基本原理是将一个复杂查询任务拆分为多个子任务，子任务可以被派发到同集群内的任意节点执行计算，有效利用集群内其它节点空闲计算资源（CPU、 内存等）来加速查询。PolarDB ePQ功能属于内核特性，任意节点都可以提供完整的服务。

如下图是从内核视角看到的弹性并行查询的架构图：

• 并行优化器（PQ Optimizer）：在串行计划的基础上进行信息提取，利用代价评估方法枚举出最优的子计划切片（Plan Slices）。

• 全局资源视图（Global Resource View）：维护集群内所有节点的实时负载信息，方便协调器快速识别出具备空闲计算资源的节点。

• 任务协调器（Coordinator）：根据实时资源负载情况，从任务队列中调度执行任务。

• 弹性并行执行器（Parallel Execution Engine）：负责将被调度的子计划切片（Plan Slices）转化为对应的物理计划（Physical Plan），并将其交给执行模块（Executor）进行执行。如果需要在远程节点执行，还需将物理计划序列化，通过内部网络传输至目标节点。

• 资源管理器（Resource Manager）：提供对并行查询所使用资源上限的限制能力，例如当CPU使用率超过70%时，将不再选择并行执行。

• 基于共享存储的跨机并行架构：能够保证查询结果的实时性，并在跨节点一致性视图机制的保障下，确保子任务在任意节点执行时能够读取到正确的数据。

从用户的角度来看，PolarDB ePQ 通过集群地址（Endpoint）对外提供服务。各个节点被分组构成集群分组，用户可以根据不同的业务场景选择配置不同的分组，并为其配置合适的并行策略，以实现业务的隔离。以下为ePQ的步骤架构图：

并行优化器

并行优化器（PQ Optimizer）：在串行优化计划的基础上进行信息提取，进而基于代价评估拆分出最优的子计划切片（Plan Slices）。基本流程是在MySQL完成串行优化后，再进一步进行并行拆分。在这一过程中，部分读者可能会疑惑为什么不如Oracle或Greenplum那样统一在优化流程中考虑串行与并行的执行策略。

其原因在于MySQL的优化流程中，各个子步骤之间并没有明确的边界。此外，深度递归的连接排序（Join Ordering）算法和嵌入的半连接优化（Semi-Join）策略等因素使得代码逻辑与结构更加复杂。在不大量干扰原生代码的前提下，实现一体化优化变得十分困难。如果对社区代码造成严重破坏，将无法跟进社区后续的版本迭代，进而失去享受社区红利的机会。

因此，我们采取了两步走的优化流程，这也是业界的常用手段。例如Spark、CockroachDB、SQL Server PDW和Oceanbase等系统都采取了类似的方案。

• 代价模型的增强

  基于成本（cost）的优化过程中，必然需要获取各个算子并行执行的代价信息。为此，PolarDB进行了大量统计信息增强的工作：

  • 统计信息自动更新。

  • 在串行优化流程中，为并行执行提供补强，例如修正表扫描方式。这也是上述性能数据中Q6/Q12出现超线性加速比的原因。

  • 全算子统计信息推导与代价计算，补充了一系列的成本公式（cost formula）和基数估算（cardinality estimation）推导机制。

    

• 自适应执行策略

  在早期版本中，串行优化与并行优化，以及并行优化与并行计划生成之间存在一定的耦合性。这种耦合导致系统在开始并行优化后无法退回到串行模式。如果系统中存在较多此类查询并发，将会同时占用大量工作线程（worker），进而导致CPU过载。新的并行优化器成功解决了这一问题。

  

  • 串行优化与并行优化解耦，后者将重新构建抽象算子树，并以此为输入开始枚举过程（enumeration）。

  • 并行优化与并行计划生成解耦，优化结果为计划子片段的抽象描述，并将其输出到计划生成器（plan generator）。

  • 这样可以提升执行策略的灵活性，使其能够在资源不足的情况下，选择退回到串行执行、降低并行度，或是进入调度队列以待分配资源。

• 基于代价的穷尽式枚举

  并行优化是一种自底向上的基于动态规划的穷尽式枚举过程，其实现思路参考了SQL Server PDW paper的相关论文。在这个过程中，我们将针对每个算子枚举可能的并行执行方式和数据分发方式，并基于输出数据的Physical Property（Distribution + Order）构建物理等价类，从而进行局部剪枝，获取局部子问题的最优解，并将其向上层传递，最终到达根操作符以获取全局最优解。

  以下是针对算子t1 NLJ t2枚举过程的一个简要示例：

  

  在整体枚举完成后，计划空间中会生成一系列带有数据分发的Exchange Enforcer的物理算子树。通过对这些树进行代价评估，我们可以选择出最优的树形结构。随后，以Enforcer作为子计划的切分点，我们能够构建出一系列执行计划的抽象描述，并将其输出到计划生成器（plan generator）中。

• 并行计划生成

  从工程实现的角度来看，并行计划生成是整个组件中复杂度最高、Bug最多的部分。为了解决这一问题，我们采用了物理计划克隆机制（physical plan clone），根据优化器生成的并行计划描述，从原始的串行计划中克隆出各个计划片段的物理执行计划。

  那么，为什么要采用这种方式呢？这与MySQL本身的机制密切相关。MySQL的优化和执行是耦合在一起的，并没有清晰的边界，这意味着在优化过程中会构建相关的执行结构。因此，我们无法根据一个独立的计划描述直接生成各个物理执行结构，只能从串行计划中进行克隆，这实际上是导致复杂度增加的根源。

  此外，MySQL的执行结构本身非常复杂，像表达式（Item）与查询块（SELECT_LEX）之间的交叉引用以及内外层查询的关联（Item_ref）等，都使得这项任务的难度显著增加。然而，在这个不断填补漏洞并不断完善的过程中，团队对MySQL的优化执行结构有了深入的理解，并且发现了很多社区中的Bug。

  

  示例

  SELECT t1.a, sum(t2.b) sumb
  FROM t1 join t2
  ON t1.c = t2.c
  GROUP BY t1.a
  ORDER BY sumb;

  尽管社区版对执行器进行了基于迭代器模型（Iterator model）的重构，但本质上，物理执行计划仍然是由QEP_TAB组成的序列，其中GROUP BY和聚合操作通过临时表tmp table1来完成，而ORDER BY则由临时表tmp table2来处理。

  在进行计划生成（plan generation）时，主要有两个核心操作：

  • 克隆（clone）：根据串行物理计划和子片段的描述，将相应的结构克隆到各个工作线程（worker）中。如上图右下部分所示，将在工作线程（worker）上执行的t1 JOIN t2及下推的聚集操作进行克隆。

  • 重构（refix）：原始的串行计划需要转换为领导者计划（leader plan），因此需要去掉不必要的执行结构并调整相关的引用关系。如上图右上部分所示，由于 t1 JOIN t2和部分聚集操作已经被下推，领导者上需要移除多余的结构，并替换为从一个收集表（Collector table）中读取工作线程（worker）传递上来的数据。同时，需要将后续步骤中对t1/t2表的引用结构转换为对Collector表对应结构的引用。

分布式执行引擎

执行引擎主要负责任务的派发、执行和状态管理。接收客户查询的线程称为领导者线程（leader thread），它负责将并行查询任务派发到各个节点上。每个远程节点则会有一个移民领导者线程（migrant leader），远程节点的工作任务由各自的移民领导者进行管理。领导者线程负责管理移民领导者和本地的工作线程（workers），这种两级分组式管理模式的好处在于能够最大限度地减少远程信令控制通道的传输内容和频率。

引擎中的通信通道有两种：一种是负责任务派发和工作线程状态收集的信令控制通道，它是一个双向的异步消息通道；另一种是仅负责传输工作线程结果数据的数据通道，它是一个单向传输通道。尽管数据传输方向是单向的，但它需要支持多种数据重新分配（shuffle）方式，如重新分区（repartition）和广播（broadcast），同时还需支持本地和远程跨机两种模式。

引擎的数据驱动模型采用的是拉取（Pull）模式，这样可以灵活地嵌入到MySQL的火山执行引擎中。此外，拉取模式的优势在于数据的实时性较高，能够实现更高效的流水线处理。

基于全局负载的自适应调度

由于采用共享存储架构，理论上可以将并行任务调度到任意节点执行。然而，并行查询的目标是利用空闲计算资源加速处理，同时又不能对客户线上业务产生负面影响。

全局资源视图模块主要负责维护实时的节点负载信息。每个节点负责采集自身的工作负载信息，包括CPU、IO和内存等指标，并通过UDP协议将这些负载信息广播给其他所有节点。通过两两互相广播后，所有节点都能维护一份各个节点的资源视图列表。

为了避免资源争抢，我们采用了一种自适应可用因子（Adaptive Available Factor）机制。该机制为每个节点设置了一个可用比率因子。假设某个节点的剩余可用资源为 100，初始的因子为一个保守值，比如20%。这样，该节点在初始阶段最多只会使用空闲资源的20%。如果检测到连续N秒内资源使用率仍未超过阈值，则会逐渐提升该因子的比率；反之，若发现该节点的资源使用超过预期，则会快速降低因子值。该机制实现了一个慢启动快回调的自适应调整策略，以尽量保持动态平衡。

Workers分配原则是在已知的资源列表中，合理地分配并行查询中的多个工作线程（workers）：

• 最小跨机传输原则，因为工作线程（worker）和工作线程（worker）之间数据交互，尽量减少工作线程（workers）之间的数据交互所需的跨机传输。

  

• 同节点内的多个工作线程（workers）尽量访问连续的数据分片，连续的数据分片可以获得更好的缓存（Cache）亲和性，从而实现更优的性能表现。

  

典型加速场景

PolarDB ePQ适用于绝大多数SELECT语句，几乎所有算子都可以实现并行加速，包括大表扫描、多表 JOIN、聚合、分组、排序、窗口函数以及子查询等。不论查询语句的复杂程度如何，通常都可以通过上述基本算子的组合来表达。本章将通过示例详细讲解一些典型场景的加速原理和性能提升情况，旨在帮助您基于这些测试场景和SQL 组合模式来估算真实业务在PolarDB ePQ中的性能表现。

# TPCH - Q1
SELECT
        l_returnflag,
        l_linestatus,
        sum(l_quantity) AS sum_qty,
        sum(l_extendedprice) AS sum_base_price,
        sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
        sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
        avg(l_quantity) AS avg_qty,
        avg(l_extendedprice) AS avg_price,
        avg(l_discount) AS avg_disc,
        count(*) AS count_order
FROM
        lineitem
WHERE
        l_shipdate <= date '1998-12-01' - interval '81' DAY
GROUP BY
        l_returnflag,
        l_linestatus
ORDER BY
        l_returnflag,
        l_linestatus
limit 1;

# TPCH - Q3
SELECT
        l_orderkey,
        sum(l_extendedprice * (1 - l_discount)) AS revenue,
        o_orderdate,
        o_shippriority
FROM
        customer,
        orders,
        lineitem
WHERE
        c_mktsegment = 'HOUSEHOLD'
        AND c_custkey = o_custkey
        AND l_orderkey = o_orderkey
        AND o_orderdate < date '1995-03-03'
        AND l_shipdate > date '1995-03-03'
GROUP BY
        l_orderkey,
        o_orderdate,
        o_shippriority
ORDER BY
        revenue DESC,
        o_orderdate limit 10;

SELECT * FROM lineitem
WHERE
	l_shipdate <= date '1998-12-01' - interval '81' DAY
ORDER BY
	l_returnflag,
	l_linestatus
limit 1000, 10;

SELECT o_orderpriority, count(*) AS order_count
FROM orders
WHERE o_orderdate >= '1995-01-01'
	AND o_orderdate < date_add('1995-01-01', INTERVAL '3' MONTH)
	AND 20 < (
		SELECT avg(l_quantity)
		FROM lineitem
		WHERE l_orderkey = o_orderkey
			AND l_commitdate < l_receiptdate
	)
GROUP BY o_orderpriority
ORDER BY o_orderpriority;

SELECT l_partkey, quantity
FROM (
	SELECT l_partkey
		, CASE 
			WHEN L_QUANTITY < 0.2 * avg(L_QUANTITY) OVER (PARTITION BY l_partkey) THEN L_QUANTITY
			ELSE NULL
		END AS quantity
	FROM lineitem
	WHERE l_partkey < 100000
) v
WHERE v.quantity IS NOT NULL
ORDER BY v.quantity
LIMIT 10;

加速效果

查询加速比是评估并行查询性能的重要指标。它反映了在相同计算资源条件下， 并行查询相较于串行查询的性能提升。以下是TPC-H 100GB数据量的加速比测试结果：

测试集群配置为集群版16核128 GB的主从2节点，并开启了ePQ。在这一环境下，TPC-H中的22条SQL语句均可实现并行加速，平均加速比达到22.5倍。由于ePQ支持分布式多机并行，并且能够通过水平扩展节点进一步实现线性加速，下面将测试更大的数据量（TPC-H 1TB）在水平扩展场景下的线性加速能力。

在这次测试中，22条SQL语句全部支持多机并行，其中17条在水平扩展的情况下仍然可以实现线性加速。

未来规划

PolarDB ePQ的未来规划包括横向支持多种异构引擎，如行存引擎、列存引擎、X-engine高压缩引擎以及OSS冷存储引擎等。同时，纵向上也将支持各种访问介质和执行形态（如一写多读和多写多读），以成为PolarDB MySQL引擎（英文为PolarDB for MySQL） Lego体系中计算层的重要基础能力，为客户创造更大的价值。

其中，支持行列引擎混合执行，打造极致的 HTAP 产品形态，是重点发展的方向。PolarDB MySQL引擎（英文为PolarDB for MySQL）存储引擎同时支持行存索引和列存索引，目前查询执行采用二选一模式，即要么使用行存索引，要么使用列存索引。我们的目标是实现一个查询中，根据不同算子的特点，适合使用行存索引的算子在行存引擎中计算，而适合使用列存索引的算子则在列存引擎中计算，以支持行列引擎的混合执行能力。