这是我参与「第四届青训营 」笔记创作活动的第 2 天!
01 大数据体系和SQL
大数据体系中的SQL
- 0ne SQL rules big data all
- SQL较流行(因为语法简单方便高效,已经成为大数据处理事实的接口。)
- 1、因为有 MySQL、Oracle 之类使用 SQL 作为交互语言的数据库
- 2、因为有 JDBC、ODBC 之类和各种数据库交互的标准接口
- 3、因为有大量数据科学家和数据分析师等不太会编程语言但又要使用数据的人
- 4、因为多个大数据计算引擎都支持 SQL 作为更高抽象层次的计算入口:
-
- MapReduce -> Hive SQL
-
- Spark -> Spark SQL
-
- Flink -> Flink SQL
-
- SQL较流行(因为语法简单方便高效,已经成为大数据处理事实的接口。)
SQL 的处理流程
graph LR
A([DataScan]) -- SQL --> B([Parser]) -- AST --> C([Analyzer]) -- Logical Plan --> D([Optimizer]) -- Physical Plan --> E([Executor])
- SQL —— Structured Query Language 结构化查询语言
- Parser —— 语法分析器
- 把文本变成抽象语法树结构(AST)
- 涉及词法分析阶段(拆分字符串,提取关键字,字符串,数值等)和语法分析阶段(把词条按照定义的语法规则组装成抽象语法树结构)
- 和编译原理课程里的“前端”知识相关
- AST —— Abstract Syntax Tree 抽象语法树
- 词法分析:拆分字符串,得到关键字、数值常量、字符串常量、运算符号等token(记号)。
- 语法分析:将 token 组成 AST node,最终得到了一个AST。
- Analyzer —— 分析器
- 访问库/表元信息并绑定
- 判断 SQL 是否合理,比如数据库,表和列名是否存在,列的数据类型是否正确
- 将 AST 转换成逻辑计划树(在某些系统中这个工作由一个 Converter 完成)
- Logical Plan —— 逻辑计划
- 所谓逻辑计划树,可以理解为逻辑地描述一个 SQL 如何一步步地执行查询和计算,最终得到执行结果的一个分步骤地计划。树中每个节点是是一个算子,定义了对数据集合的计算操作(过滤,排序,聚合,连接),边代表了数据的流向,从孩子节点流向父节点。之所以称它为逻辑的,是因为算子定义的是逻辑的计算操作,没有指定实际的算法,比如对于逻辑的排序算子,逻辑计划树里没有指定使用快排还是堆排。
- 所谓逻辑计划树,可以理解为逻辑地描述一个 SQL 如何一步步地执行查询和计算,最终得到执行结果的一个分步骤地计划。树中每个节点是是一个算子,定义了对数据集合的计算操作(过滤,排序,聚合,连接),边代表了数据的流向,从孩子节点流向父节点。之所以称它为逻辑的,是因为算子定义的是逻辑的计算操作,没有指定实际的算法,比如对于逻辑的排序算子,逻辑计划树里没有指定使用快排还是堆排。
- Optimizer —— 优化器
- Physical Plan —— 物理计划
- Executer —— 编译器
- 查询优化:
02 常见的查询优化器
分类
- Top-down Optimizer
- Bottom-up Optimizer
- RBO(Rule-based Optimizer)
- CBO(Cost-based Optimizer)
RBO(Rule-based Optimizer)
- 关系代数
- 结合率 结合先后顺序不影响结果
- 优化原则
- 列裁剪
- 谓词下推
- (filter和join位置调换结果不受影响)filter作为join的子节点,这样就完成了join的提前过滤
- Q:哪些能推哪些不能推?
- 谓词下推,就是在将过滤条件下推到离数据源更近的地方,最好就是在table_scan时就能过滤掉不需要的数据,在关系代数中谓词是可以左右上下移动的,由于join查询的特殊性,在优化join condition中的谓词时,对应不同的join 内型,有不同的策略
- 谓词下推,就是在将过滤条件下推到离数据源更近的地方,最好就是在table_scan时就能过滤掉不需要的数据,在关系代数中谓词是可以左右上下移动的,由于join查询的特殊性,在优化join condition中的谓词时,对应不同的join 内型,有不同的策略
- 传递闭包
- 根据表达式的等价关系,加上过滤条件,创造谓词下推——>join连接加快
- 根据表达式的等价关系,加上过滤条件,创造谓词下推——>join连接加快
- Runtime Filter
- 提早过滤不必要的数据,操作开销减少,提高join效率
- 产生新的filter,推到查询端
- 由已知scan数据 传递给其他scan 完成过滤
- 列裁剪
CBO(Cost-based Optimizer)
- 统计信息
- 准确的cardinality,远比到家模型本身更重要:www.vldb.org/pvldb/vol9/…
- 统计信息的收集方式
- 统计信息的推导规则
(NDV:一个列里独立互不相同值的个数)
- min-max(缺点:范围传递过大,传递效率不是很好)
- in-list
- 优:有效解决min-max面对 数据集中在一块,同时其他数据分散 的情况;数据集中块和分散的数据皆可包括其中。
- 缺:若集合过多则查询时间边长。
- bloom filter:(固定大小)(给我一个数,判断需要的数据是否存在此表)(存储引擎还会详细展开)
- 统计信息的问题
- 执行计划枚举
- 动态规划
- 原理:(RST表中两表)表作(HashJOIN、SortMergeJOIN)连接得到子问题 —> (分别)分析子问题代价 —> 得出子问题最优解 —> (三表连接、HashJOIN、SortMergeJOIN)问题扩大,(根据各种情况Cost)得出最优解(即执行计划)(R-S、R-T、S-T)
- CBO效果(TPC-DS Q25)
- 原理:(RST表中两表)表作(HashJOIN、SortMergeJOIN)连接得到子问题 —> (分别)分析子问题代价 —> 得出子问题最优解 —> (三表连接、HashJOIN、SortMergeJOIN)问题扩大,(根据各种情况Cost)得出最优解(即执行计划)(R-S、R-T、S-T)
- 动态规划
03 社区开源实践
概览
Apache Calcite
04 前沿趋势
概览
DATA + AI
- 智能调参
- OtterTune:www.cs.cmu.edu/~ggordon/va…
- QTune:www.vldb.org/pvldb/vol12…
- 统计信息估计
- Learned Cardinalities:arxiv.org/abs/1809.00…
- 学习型优化器
- LEO – DB2’s LEarning Optimizer:diaswww.epfl.ch/courses/adm…
总结
- 经过一天的青训营学习,我自我感觉还是收获蛮多,比如CBO、RBO的实现原理等。只不过要重新再学习SQL基础语句等知识了,加油!
参考文献:
- 谓词下推的条件:zhuanlan.zhihu.com/p/129026235