聊聊GaussDB AP是如何执行SQL的
本文分享自华为云社区《GaussDB AP是如何执行SQL的》，作者：yd_270088468。
前言
介绍GaussDB AP各组件是如何协调工作的，会着重介绍SQL引擎。
1、SQL引擎组件和SQL生命周期
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 分布式计划
|
序号 |
分类 |
作用 |
执行原理 |
适用场景 |
|---|---|---|---|---|
|
1 |
CN下发语句 |
生成完全下推语句的计划（FQS计划） |
各DN分别根据下推语句生成执行计划，进行执行，执行结果在CN上进行汇总（FQS，即Fast Query Shipping） |
各DN执行时无数据交互，像基表扫描的场景 |
|
2 |
CN下发语句 |
生成发送语句的分布式计划（部分下推计划） |
CN下推原语句的部分语句（通常为基表扫描）到DN，各DN分别根据下推语句生成执行计划，执行后将结果发送给CN，CN执行剩余计划 |
不能满足1，3，4的极端场景，性能非常差。目前不支持下推的特征主要有：record数据类型、volatile函数等 |
|
3 |
CN下发语句 |
生成CN轻量化的计划 |
由DN生成执行计划返回结果 |
只有单DN执行语句，且DN结果即为最终返回结果 |
|
4 |
CN生成计划 |
生成下发Plan的分布式计划（Stream计划） |
CN根据原语句生成计划，下发给DN进行执行，各DN执行过程中存在数据交互（Stream操作符） |
各DN执行时有数据交互，AP场景下的复杂语句 |
前3个计划都是CN下发语句给DN，第4个计划是CN生成计划，将计划下发给DN，第4个计划也被称为stream计划，是最为常用的计划。
为什么会有下发语句的计划？
CN生成执行计划，需要耗费较多CPU资源，且计划较原始语句大许多，下发语句对于CN以及网络传输的开销小很多。
号外！
华为将于2023年9月20-22日，在上海世博展览馆和上海世博中心举办第八届华为全联接大会（HUAWEICONNECT 2023）。本次大会以“加速行业智能化”为主题，邀请思想领袖、商业精英、技术专家、合作伙伴、开发者等业界同仁，从商业、产业、生态等方面探讨如何加速行业智能化。
我们诚邀您莅临现场，分享智能化的机遇和挑战，共商智能化的关键举措，体验智能化技术的创新和应用。您可以：
- 在100+场主题演讲、峰会、论坛中，碰撞加速行业智能化的观点
- 参观17000平米展区，近距离感受智能化技术在行业中的创新和应用
- 与技术专家面对面交流，了解最新的解决方案、开发工具并动手实践
- 与客户和伙伴共寻商机
感谢您一如既往的支持和信赖，我们热忱期待与您在上海见面。
大会官网：https://www.huawei.com/cn/events/huaweiconnect
欢迎关注“华为云开发者联盟”公众号，获取大会议程、精彩活动和前沿干货。