SQL 查询优化器浅析笔记(一) | 青训营笔记
这是我参与「第四届青训营 -大数据场」笔记创作活动的的第1天
一、大数据体系和 SQL
1.大数据体系全景图
提问:为什么第一节课要讲SQL
回答:SQL已经成为了一个趋势以及很多框架的一个接口。
例如:有 MySQL、Oracle 之类使用 SQL 作为交互语言的数据库;有 JDBC、ODBC 之类和各种数据库交互的标准接口……
2.为什么在大数据领域中 SQL 如此流行?
- 有 MySQL、Oracle 之类使用 SQL 作为交互语言的数据库
- 有 JDBC、ODBC 之类和各种数据库交互的标准接口
- 有大量数据科学家和数据分析师等不太会编程语言但又要使用数据的人
- 多个大数据计算引擎都支持 SQL 作为更高抽象层次的计算入口
- MapReduce -> Hive SQL
- Spark -> Spark SQL
- Flink -> Flink SQL
3. SQL 的一生
3.1 SQL的处理流程
下图为SQL从编译→执行→查询→结果流程:
首先会经过分析器,进行语法分析和语义检查,得到一棵语法分析树,然后经过查询优化器得到查询计划,最后交给执行器进行执行。
3.2 Parser
- 把文本变成抽象语法树结构(AST)
- 涉及词法分析阶段(拆分字符串,提取关键字,字符串,数值等)和语法分析阶段(把词条按照定义的语法规则组装成抽象语法树结构)
- 和编译原理课程里的“前端”知识相关 实现:递归下降(ClickHouse),Flex和Bison (PostgreSQL),JavaCC(Flink),Antlr (Presto, Spark)
3.3 Analyzer
- 访问库/表元信息并绑定;
- 去判断SQL是否合理,比如数据库,表和列名是否存在,列的数据类型是否正确;
- 将AST转换成逻辑计划树
3.4 Logical Plan
- 逻辑地描述SQL对应的分步骤计算操作
- 计算操作:算子(operator)
3.5 查询优化
- SQL是一种声明式语言,用户只描述做什么,没有告诉数据库怎么做
- 目标:找到一个正确且执行代价最小的物理执行计划
- 查询优化器是数据库的大脑,最复杂的模块,很多相关问题都是NP的
- 一般SQL越复杂,Join的表越多,数据量越大,查询优化的意义就越大,因为不同执行方式的性能差别可能有成百上千倍。
3.6 Physical Plan
- Plan Fragment:执行计划子树
- 目标:最小化网络数据传输
- 利用上数据的物理分布(数据亲和性)
- 增加Shuffle算子
3.7 Executor
- 单机并行:cache,pipeline,SIMD
- 多机并行:一个fragment对应多个实例
小结:
- One SQL rules big data all
- SQL需要一次经过Parser,Analyzer,Optimizer和Executor的处理
- 查询优化器是数据库的大脑,在大数据场景下对查询性能至关重要
- 查询优化器需要感知数据分布,充分利用数据的亲和性
- 查询优化器按照最小化网络数据传输的目标把逻辑计划拆分成多个物理计划片段