这是我参与[第四届青训营]笔记创作活动的第6天
主要是回顾第一节课的内容:SQL Optimizer,之前的学习主要是关于SQL的增删改查,其中又主要是SQL语句的查询分析。SQL目前是大数据分析常用到的工具,是数据分析是必须掌握的技能。这里主要介绍了SQL的处理流程及常见的优化器。
SQL Optimizer
a.数据库SQL是非常必要的
b.SQL的执行流程
c.查询优化器
大数据体系
通过青训营的第一节课SQL Optimizer了解了大数据体系的组成部分,如图所示:
SQL在分布式下的处理
SQL相对容易,已经称为流行趋势,用SQL处理大数据,是一个入口。大数据体系中SQL的使用主要如下图所示:
SQL的处理流程
SQL的处理流程主要为四个组件的处理,其中方块为组件,箭头为输入输出。
(1)SQL处理流程1
Parser SQL输入,AST输出
输入_String(字符串)—>输出AST(abstract synatax tree)抽象语法树
分析过程:词法分析,语法分析flink(已有组件支持)
(1) SQL处理流程2
Analyzer AST(抽象语法树)输入,Logical Plan(逻辑执行计划)输出
主要实现了将语句转化为逻辑执行计划 ,这里使用的排序方法是快排,堆排,方块排序等。
(2)SQL处理流程3
Optimizer Logical Plan(逻辑执行计划)输入Physical Plan(物理计划)输出,Executor组件
分布式情况下的数据拆分
充分利用机制,采用了单机运行,多机并行等方式,拆分物理计划要有亲和性
把逻辑树筛分,
shffle算子
查询优化器
数据库主要由三部分组成,分别是解析器、优化器和执行引擎。其中优化器是数据库中用于把关系表达式转换成执行计划的核心组件,很大程度上决定了一个系统的性能。
查询优化器的分类
查询优化器有两种分类方法:
一是按照遍历树的顺序进行划分(逻辑计划树),其中system R是最早的数据库优化器,有很多概念,现在仍然在使用。
二是根据优化的方法进行划分,包括
基于规则的优化器(Rule-Based Optimizer,RBO) 和基于代价的优化器(Cost-Based Optimizer,CBO) 。
查询优化器
本文主要了解根据优化的方法分类的优化器
- RBO
根据优化规则对关系表达式进行转换,主要是将一个关系表达式经过优化规则后会变成另外一个关系表达式,同时原有表达式会被裁剪掉,经过一系列转换后生成最终的执行计划。
RBO中包含了一套有着严格顺序的优化规则,同样一条SQL,无论读取的表中数据是怎么样的,最后生成的执行计划都是一样的。同时,在RBO中SQL写法的不同很有可能影响最终的执行计划,从而影响脚本性能。 - CBO
根据优化规则对关系表达式进行转换,主要是将一个关系表达式经过优化规则后会生成另外一个关系表达式,同时原有表达式也会保留,经过一系列转换后会生成多个执行计划。
CBO会根据统计信息和代价模型(Cost Model)计算每个执行计划的Cost,从中挑选Cost最小的执行计划。CBO中有两个依赖:统计信息和代价模型。统计信息的准确与否、代价模型的合理与否都会影响CBO选择最优计划。
查询优化器的执行过程
两种方法的执行过程:
- RBO的执行
1)Transformation
遍历关系表达式,只要模式能够满足特定优化规则就进行转换。
2)Build Physical Plan
经过Step1之后就生成了一个逻辑执行计划,但这只是逻辑上可行,还需要将逻辑执行计划build成物理执行计划,即决定各个Operator的具体实现。如Join算子的具体实现选择BroadcastHashJoin还是SortMergeJoin。 - CBO的执行
1)Exploration
根据优化规则进行等价转换,生成等价关系表达式,此时原有关系表达式会被保留。
2)Build Physical Plan
决定各个Operator的具体实现。
3)Find Best Plan
根据统计信息计算各个执行计划的Cost,选择Cost最小的执行计划。\
总结
目前对于SQL优化器的学习还需要进一步的学习,只是了解了基本的信息,对其中的更深的原理还需要时间去理解。