PieCloudDB Database 新一代优化器「达奇」：专为云原生和分布式场景而打造

近日，PostgreSQL 中国技术大会在杭州拉开帷幕。作为 PostgreSQL 技术领域的年度盛会， PostgreSQL 中国技术大会已经连续 12 年，为所有热爱数据库技术的小伙伴们提供了一个开放合作、共享互助的平台。而本届大会，围绕着安全可靠、突破、进化等主题，召集众多业内大咖和技术高手在这里进行技术切磋与思想碰撞。  

作为国内云上数据和数据计算领域的 Day-1 准独角兽，拓数派技术专家郭峰受邀出席本次大会发表主题演讲。 

在演讲中，郭峰介绍了 PieCloudDB Database 打造的全新优化器 ——「达奇」。「达奇」名称起源于一款深受年轻人喜爱的游戏：《荒野大镖客》。游戏中一位名为「达奇」的 NPC 人物的口头禅正是「I have a plan」，和优化器的主要作用 “不谋而合”。

优化器是数据库系统中的一个重要组件，它 “负责” 对用户的查询请求进行解析、优化和执行计划的生成，使得查询结果能够以最快速度和最高效率得到返回。优化器通过生成最优的查询执行计划，来达到优化查询性能的目的。而执行计划的好坏往往会造成成百上千的性能差异。PieCloudDB 打造的优化器「达奇」实现了大量的优化特性，作为数据库系统的 “智囊团”，助 PieCloudDB 提升性能。

和 PostgreSQL 类似，PieCloudDB 查询优化的处理过程一般被分为四个阶段：预处理阶段，扫描 / 连接优化阶段，扫描 / 连接之外的优化阶段，后处理阶段。「达奇」在这四个处理阶段均做了大量优化。 

在预处理阶段，优化器「达奇」会通过逻辑上的等价变化，将查询树转换为更加简单高效的等式。由于还未获得一些统计信息来帮助计算代价信息，本阶段一般会通过一些被证明的规则来进行分发约束条件，简化表达式和连接树消除无用连接等操作。 

• 把 IN, EXISTS 等类型的子查询转换为半连接 

PieCloudDB 会基于子查询所在的位置和作用的不同，将子查询分为子连接（SubLink）和子查询（SubQuery）。子连接由于出现在 WHERE/ON 等约束条件中，常伴随着 ANY/ALL/EXISTS 等谓语动词。如果执行器按照子连接的方式处理，会对查询效率造成影响。且由于会产生子计划（SubPlan），优化空间有限。因此，在查询优化的预处理阶段， PieCloudDB 会尽可能地把子连接转为 semi-join 或 anti-join，从而具有更大的优化空间。 

以下面一段的 SQL 查询为 例：

SELECT … FROM foo WHERE EXISTS (SELECT 1 FROM bar WHERE foo.a = bar.c);

其中 EXISTS 里是一个子查询，PieCloudDB 会在预处理阶段将其变成一个 Semi-Join：​​​​​

SELECT ... FROM foo *SEMI JOIN* bar ON foo.a = bar.c;

• 提升子查询 

出现在 FROM 关键字后的子句是子查询语句。如果不进行提升优化，在对这类子查询做执行时，会先做一个单独的计划，生成一个 Sub-query scan，再与 Parent Query 做连接，常常无法找到最优解，造成较大的查询代价。 

以下面的例子为例，如果不做任何提升优化，会将 bar 和 baz 先做 JOIN 连接，由于没有连接条件，会直接将 bar 和 baz 做笛卡尔乘积，再和外面的 foo 做 JOIN 连接：

​​​​​​​​​​​​​​SELECT * FROM foo JOIN (SELECT bar.c FROM bar JOIN baz ON TRUE) AS sub ON foo.a = sub.c;

而做完提升后，bar 和 baz 就在同一层面上，可以先生成 foo 和 bar 的 join，再与 baz 做 join 连接，从而实现了代价更小：​​​​​​​

SELECT * FROM foo JOIN (bar JOIN baz ON TRUE) ON foo.a = bar.c;

• 把外连接转换为内连接 / 反连接 

外连接对谓词下推以及连接顺序搜索等都会有很多限制，因此「达奇」在预处理阶段会尽可能将外连接转换为内连接（Inner Join）或反连接（Anti Join）。 

在下面的 SQL 语句中，LEFT JOIN 的结果会产生一些以 NULL 结尾的 tuple，而 WHERE 条件中的等号为严格约束条件，意味着输入如果为 NULL，输出也必须是 NULL 或 FALSE。如果 bar 上的 column 为 NULL 值，则 bar.d = 42 的过滤结果为 FALSE。也就是说，LEFT JOIN 产生的以 NULL 填充的 tuple 会被 WHERE 条件过滤掉，此时，LEFT JOIN 就从语义上变为了 INNER JOIN。​​​​​​​

SELECT ... FROM foo LEFT JOIN bar ON (...) WHERE bar.d = 42;

在这样的情况下，PieCloudDB 「达奇」优化器自动识别此类查询，并利用这样的优化机会，将外连接转为内连接。​​​​​​​

SELECT ... FROM foo INNER JOIN bar ON (...) WHERE bar.d = 42; 

对于某些情况下的外连接，PieCloudDB 优化器会在预处理阶段将外连接转换为反连接。以下面的 SQL 语句为例：​​​​​​​

SELECT * FROM foo LEFT JOIN bar ON foo.a = bar.c WHERE bar.c IS NULL; 

同前例，LEFT JOIN 也会产生很多以 NULL 填充的 tuple 的结果集，此时 WHERE 条件限定只取 bar.c 为 NULL 的结果，此时的语义上 LEFT JOIN 就是一个反连接。PieCloudDB 会在预处理阶段自动检测到这种优化机会，并会将外连接转为内连接：​​​​​​​

SELECT * FROM foo *ANTI JOIN* bar on foo.a = bar.c; 

除了这些优化，在预处理阶段，优化器「达奇」还实现了多个优化，包括： 

• 分发约束条件

• 构建等价类 

• 收集外连接信息 

• 消除无用连接 

• 简化表达式 

      等…

扫描 / 连接优化阶段可谓是优化器处理过程中最复杂的阶段。在这一阶段，优化器「达奇」会以代价驱动，处理查询语句中的 FROM 和 WHERE 部分，同时会考虑到 ORDER BY 的信息。 

在这一阶段，优化器「达奇」的处理主要可以分为两步。首先会为基表生成扫描路径，并计算扫描路径的代价和结果集大小，从而获得后面连接操作的代价。第二个步骤中，「达奇」会搜索整个连接顺序空间，为连接操作生成最优的连接路径。这一步骤的复杂度非常高（n！级别），PieCloudDB 采用了动态规划和遗传算法两个算法来进行处理，并根据 GUC 值进行算法选择。如果查询语句中涉及外连接，考虑到外连接对连接顺序的限制，无法像内连接那样随意切换连接顺序，会加大这一步骤的复杂度。 

相对于第二阶段，这一阶段虽然处理的事情很多，但复杂度相对较低。在这一阶段，「达奇」会先处理 Group By、聚集、窗口函数、DISTINCT，再对集合操作进行处理，最后再处理 ORDER BY。以上的每一步操作都会产生一个或多个路径，「达奇」会对这些路径根据代价大小进行筛选，并为筛选出的路径添加 LockRows，Limit，ModifyTable。 

经过前面三个阶段，「达奇」已经生成了一个大概的查询计划。在后处理阶段，「达奇」会把选出的最优路径转换为查询计划，并对最优计划进行一些调整。 

除了上述的优化特性，针对用户对于云上数据查询性能需求，PieCloudDB 优化器「达奇」对复杂查询场景做了大量的优化和改进，实现了众多高阶的分布式与云原生特性。 

在以上优化特性的基础上，「达奇」优化器拓展了众多针对分布式的优化特性。首先「达奇」引入了 Motion 的概念，使数据可以在不同的执行节点（Executor）之间移动。利用 Motion，「达奇」可以产生分布式的查询计划。这些查询计划会被分为更小的单元，并被分发到不同的执行节点中并行执行。有了并行执行，很多复杂查询都能进行进一步的优化，例如对于聚集操作，利用分布式的优势，在执行节点之间可以通过多阶段聚集来提升性能。 

以这段查询为例来讲解一下多阶段聚集，针对这段 SQL 查询，「达奇」会生成这样的查询计划：

由于存在一个去重的操作，「达奇」会进行三个阶段的聚集，在第一个阶段，PieCloudDB 会在每个执行节点上，以 a，b 为 group key 先做一个局部的聚集，这里就完成了一个局部去重的操作。接着，利用 Motion 做一次 Reshuffle 的操作，此时再进行一次聚集操作，完成全局去重。最后再根据 group key 完成最后的聚集操作，得到查询结果。 

由于 PieCloudDB 的存储引擎「简墨」采用的是对象存储的设计，结合这一设计，PieCloudDB 优化器「达奇」实现了更多高阶的优化，包括聚集下推、Block Skipping、预计算等。这里将对聚集下推进行介绍，关于「达奇」的其他云原生特性，欢迎关注即将陆续推出的其他内容。 

PieCloudDB 实现了聚集下推（Aggregate Pushdown），可以在查询执行计划中有效地减少数据的传输和处理，提高查询效率。在分析型场景中，SUM、AVG、MAX、MIN 等聚集操作是常见的操作，可以用来对数据库表中的数据进行聚合计算。大部分数据仓库在处理聚集操作时，通常需要先完成对表的扫描和连接操作，之后再计算聚合函数。在数据量非常大的 情况下，这样的查询性能会比较低。 

而 PieCloudDB 优化器「达奇」实现的聚集下推优化策略，通过把聚集操作下推到连接操作之前去执行，可以极大地减少连接操作需要处理的数据量，经测试，在某些情况下，性能会得到成百甚至上千倍的提升。 

以下面的 SQL 查询为例，这段查询需要对 t1 表和 t2 表进行连接操作，在此基础上，根据 t1.a 做分组，来获得 t2.c 的平均值。在不进行聚集下推优化的情况下，会先完成 t1 和 t2 的连接操作，再按 t1.a 的分组进行聚集操作。此时，如果 t1 和 t2 表都很大的话，进行连接操作的代价很高，会对性能产生一定影响。而在进行聚集下推的优化下，会在连接之前先做聚集操作，此时如果 t2.b 非常有聚集性，数据量会减小很多，此时再进行连接操作，性能会大幅提高。

查询优化器是数据库系统最重要、也是最复杂的组件之一。PieCloudDB 作为一款云原生虚拟数仓，将不断对优化器「达奇」进行打磨，在确保数据库系统的高效和稳定运行的前提下，不断驱动性能的提升。 

3 月 14 日，基于新一代云原生数仓虚拟化打造的 PieCloudDB「云上云」版已正式发布，欢迎大家登录 www.openpie.com 免费试用。