聊聊 GaussDB AP 是如何执行 SQL 的

本文分享自华为云社区《GaussDB AP是如何执行SQL的》，作者：yd_270088468。

前言

介绍 GaussDB AP 各组件是如何协调工作的，会着重介绍 SQL 引擎。

1、SQL 引擎组件和 SQL 生命周期

Parser: 词法/语法分析模块。词法分析会从 SQL 字符串中解析出一个个单词，作为语法分析的输入。语法分析可以想象成是一个"正则表达式"，但远比正则表达式复杂，它定义了所有 SQL 类型的语法规则以及操作符的优先级和结合律。语法分析结束后，会生成一个 Parse Tree，作为语义分析模块的输入。比如一个 SQL 是 SELECT id,data FROM tbl_a WHERE id < 300 ORDER by data;,语法解析生成的 Parse Tree 如下所示：

Analyzer: 语义分析模块。语义分析会访问数据库中的对象，检查表是否存在、列是否合法，并将表、排序列、投影列等转化为内部对象 ID。另外，它还会检查 SQL 语义是否正确合法，比如 Aggregate 函数在 where 子句中是不合法的。经过语义分析后，Parse Tree 会转化成 Query Tree，作为查询重写模块的输入。

Query Tree 的结构与 Parse Tree 有点类似，但在内容上更加丰富，包括 Query Tree 保存的是数据库内部的对象信息、多了一些 Flag 标记等。语义分析生成的 Query 树如下所示：

Rewriter: 查询重写模块。查询重写模块会根据用户定义的规则对查询进行重写，实际是对 Query Tree 中的成员进行修改或者替换。Rewrite 过程如下所示：

Planner: 优化器模块。优化器的输入是 Query Tree，输出 Plan Tree，用来指导执行器执行，比如如何 join，如何扫描数据，如何排序等。

Executor: 执行器模块。根据优化器输出的 Plan Tree，进行初始化、执行，执行的时候会调用存储引擎的接口，这里不做展开。

2、SQL 执行整体架构

步骤一：业务通过 ELB 下发 SQL 给 CN，SQL 可以是 DDL，DML，DCL。

步骤二：CN 判断 SQL 类型，如果 SQL 类型是 DDL/DCL，不用生成 plan，将 SQL 发送到其他 CN 和所有 DN，在所有 CN/DN 上执行。如果 SQL 类型是 DML，对于不需要使用 stream 算子的（可以分成 3 小类），会将 SQL 直接发给各 DN 执行，对于需要使用 stream 算子的，会生成 plan 下发给 DN 执行。

步骤三：DN 执行 DML 过程中，可能会从其他 DN 获取数据，DWS 提供了三种 stream 算子（Redistribute/Broadcast/Gather），降低数据在 DN 节点间的流动。

步骤四：DN 将结果集返回给 CN 进行汇总。

步骤五：CN 将汇总后的结果返回给业务。

3、DDL 在 CN/DN 如何交互

3.1 单 DDL 的情况

3.2 并发 DDL 的情况

为了避免并发 DDL 造成死锁，默认开启 enable_parallel_ddl，控制从所有 CN 下发的 DDL 都使用同一个 CN 作为起点开始执行。

消息序列图说明

前提：CN 1，CN 2，CN 3 上各收到一条对表 test 进行 DDL 操作的请求。CN 1 为被选定的第一个执行 DDL 的节点。

T1：CN 2 不是第一个执行 DDL 操作的节点，所以 CN 2 将 Command 2 命令发送给第一个执行的节点 CN 1，然后等待 CN 1 回复；

T2：CN 3 也不是第一个执行 DDL 操作的节点，所以 CN 3 将 Command 3 命令发送给第一个执行的节点 CN 1，然后等待 CN1 回复；

T3：CN 1 是第一个执行 DDL 操作的节点，故按基线原有逻辑执行，即先在本地执行；

T4：CN 1 执行 Command 2，对表 test 拿锁。Command 2 执行完成后，CN 1 告知 CN2：Command 2 在我上面已经完成。此时，Command 1 和 Command 3 拿不到锁，处于等待状态；

T5：CN 2 收到 CN 1 的 Command 2 执行完毕的回复之后，给 CN 3 发送 command 2 命令，等待 CN 3 的回复；

T6：CN 3 执行 command 2，回复执行结果给 CN 2；

T7：CN 2 将 command 2 发送给 DN1，DN2，DN3，要求它们在本地执行并等待他们的回复；

T8：DN1，DN2，DN3 分别在本地执行 Command 2，回复 CN 2 执行结果；

T9：CN 2 本地执行 Command 2，成功后提交，至此集群中所有的 CN 和 DN 全部放锁，Command 2 执行完毕；

T10：CN 1 执行 Command 3，对表 test 拿锁。Command 3 执行完成后，CN 1 告知 CN3：Command 3 在我上面已经完成。此时，Command 1 拿不到锁，处于等待状态；

T11：CN 3 收到 CN 1 的 Command 3 执行完毕的回复之后，给 CN 2 发送 command 3 命令，等待 CN 2 的回复；

T12：CN 2 执行 command 3，回复执行结果给 CN 3；

T13：CN 3 将 command 3 发送给 DN1，DN2，DN3，要求它们在本地执行并等待他们的回复；

T14：DN1，DN2，DN3 分别在本地执行 Command 3，回复 CN 3 执行结果；

T15：CN 3 本地执行 Command 3，成功后提交，至此集群中所有的 CN 和 DN 全部放锁，Command 3 执行完毕；

T16：CN 1 将 Command 1 发送给 CN2，CN3，并等待他们的回复；

T17：CN2，CN3 分别在本地执行 Command 1，回复执行结果给 CN 1；

T18：CN 1 将 command 1 发送给 DN1，DN2，DN3，要求它们在本地执行并等待他们的回复；

T19：DN1，DN2，DN3 分别在本地执行 Command 1，回复 CN 1 执行结果；

T20：CN 1 本地执行 Command 1，成功后提交，至此集群中所有的 CN 和 DN 全部放锁，Command 3 执行完毕。

从上面实现可以看到，其中心思想是将多 CN 上并发的 DDL 操作串行化，即指定一个最先执行的 CN，所有的 DDL 都必须先在这个 CN 上执行完成后才可以在别的节点上执行。这样的话，在这个被指定的 CN 上面，DDL 操作就是串行的，拿不到锁的 DDL 会等待，但不再会出现拿不到锁的死锁情况。

4、DML 执行计划生成

4.1 CBO 模型

CBO: Cost-Based Optimization 也即"基于代价的优化器"，相对于 RBO（Rule-Based Optimization），CBO 对数据很敏感，执行计划更灵活，当数据量变化的时候，CBO 往往能生成更优的执行计划。

CBO 的基本优化流程：搜索引擎利用转换规则，对输入的逻辑执行计划进行(逻辑/物理)转换，构造出执行计划的搜索空间。之后，利用代价模型对搜索空间中的每一个执行计划进行代价估算，选出代价最低的物理执行计划。而代价估算的过程离不开基数估计：它利用各个表、列的统计信息，估算出各算子的输入行数、选择率等信息，提供给算子的代价模型，从而估算出查询计划的代价。

DWS 优化器是基于代价的优化器（CBO），它可以为每一条 SQL 构造出搜索空间，并根据数据的统计信息、基数估计、算子代价模型，为搜索空间中的执行机计划估算出执行所需要的代价(CPU/MEM/IO/NET)，最终选出代价最小的执行计划作为 SQL 的具体执行方式。

4.2 搜索空间

采用 Cascade（动态规划）/GEQO（遗传基因）的方式进行计划搜索。通过 Cascade 算法可以实现精确计算，但时间复杂度高，适用于表连接较少的情况。GEQO 是非精确计算的方法，适用于表很多的情况。

4.3 统计信息

包括逻辑表的行数，列的非重复值数（NDV），列 Null 值信息等。

4.4 基数估计

基数估计会估算各个算子中间结果的行数或基数等信息，例如 Join 输出行数，Agg 会产生的 Group 数量等等。

4.5 算子代价

对于同类算子，将所有实现算子的消耗（代价）均计算出来，选择代价最小的。

输入：两个表的大小、Join 列的数据特征、有序性、可用内存大小 work_mem；

输出：算子的代价（消耗时间的维度）

4.6 分布式计划

前 3 个计划都是 CN 下发语句给 DN，第 4 个计划是 CN 生成计划，将计划下发给 DN，第 4 个计划也被称为 stream 计划，是最为常用的计划。

为什么会有下发语句的计划？

CN 生成执行计划，需要耗费较多 CPU 资源，且计划较原始语句大许多，下发语句对于 CN 以及网络传输的开销小很多。

点击关注，第一时间了解华为云新鲜技术~