GaussDB AP是如何执行SQL的

漫天 发表于 2023/09/07 08:56:46 2023/09/07
【摘要】 前言介绍GaussDB AP各组件是如何协调工作的,会着重介绍SQL引擎。 1、SQL引擎组件和SQL生命周期Parser: 词法/语法分析模块。词法分析会从SQL字符串中解析出一个个单词,作为语法分析的输入。语法分析可以想象成是一个"正则表达式",但远比正则表达式复杂,它定义了所有SQL类型的语法规则以及操作符的优先级和结合律。语法分析结束后,会生成一个Parse Tree,作为语义分析...

前言

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

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

GaussdbAP是如何执行SQL的_1.png

  • Parser: 词法/语法分析模块。词法分析会从SQL字符串中解析出一个个单词,作为语法分析的输入。语法分析可以想象成是一个"正则表达式",但远比正则表达式复杂,它定义了所有SQL类型的语法规则以及操作符的优先级和结合律。语法分析结束后,会生成一个Parse Tree,作为语义分析模块的输入。比如一个SQL是SELECT id,data FROM tbl_a WHERE id < 300 ORDER by data;,语法解析生成的Parse Tree如下所示:
    GaussdbAP是如何执行SQL的_2.png
  • Analyzer: 语义分析模块。语义分析会访问数据库中的对象,检查表是否存在、列是否合法,并将表、排序列、投影列等转化为内部对象ID。另外,它还会检查SQL语义是否正确合法,比如Aggregate函数在where子句中是不合法的。经过语义分析后,Parse Tree会转化成Query Tree,作为查询重写模块的输入。Query Tree的结构与Parse Tree有点类似,但在内容上更加丰富,包括Query Tree保存的是数据库内部的对象信息、多了一些Flag标记等。语义分析生成的Query树如下所示:
    GaussdbAP是如何执行SQL的_3.png
  • Rewriter: 查询重写模块。查询重写模块会根据用户定义的规则对查询进行重写,实际是对Query Tree中的成员进行修改或者替换。Rewrite过程如下所示:
    GaussdbAP是如何执行SQL的_4.png
  • Planner: 优化器模块。优化器的输入是Query Tree,输出Plan Tree,用来指导执行器执行,比如如何join,如何扫描数据,如何排序等。
    GaussdbAP是如何执行SQL的_5.png
  • Executor: 执行器模块。根据优化器输出的Plan Tree,进行初始化、执行,执行的时候会调用存储引擎的接口,这里不做展开。

2、SQL执行整体架构

GaussdbAP是如何执行SQL的_6.png
步骤一:业务通过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的情况

GaussdbAP是如何执行SQL的_7.png

3.2 并发DDL的情况

为了避免并发DDL造成死锁,默认开启enable_parallel_ddl,控制从所有CN下发的DDL都使用同一个CN作为起点开始执行。
GaussdbAP是如何执行SQL的_8.png
消息序列图说明
前提: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以及网络传输的开销小很多。

5、参考

《GaussDB(DWS)SQL引擎优化器综述一:数据库计划生成主要技术介绍》-- 李茂增
《MPPDB分布式执行框架》-- 焦航
《数据库基础架构》-- 齐天
《GaussDB(DWS)分布式架构培训》-- 路贵朝
MPPDB 分布式DDL简介》-- 朱云龙

【版权声明】本文为华为云社区用户原创内容,未经允许不得转载,如需转载请自行联系原作者进行授权。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。