这是我参与「第四届青训营 」笔记创作活动的的第1天
大数据体系和SQL
为什么先讲SQL优化器
- 非常流行、简单
- 很多系统都支持的接口
- 大数据处理的一个实时的接口
One SQL rules big data all
SQL 的处理流程
Parser --> Analyzer --> Optimizer --> Executor
Parser
- 输入：String 或者文本
- 输出：AST（abstract syntax tree）抽象语法树
- 步骤：词法分析、语法分析
- 实现：递归下降（ClickHouse）, Flex（词法分析）和Bison（语法分析）（PostgreSQL），JavaCC（Flink），Antlr（Presto,Spark）
Analyzer
- 输入：AST
- 输出：Logical Plan
- 检查并绑定Database，Table，Column等元信息
- SQL合法性检查，比如min/max/avg的输入是数值
Logical Plan
- 顾名思义：逻辑地描述SQL对应的分步骤计算操作
- 计算操作：算子（operator）
Optimizer
- 为什么叫查询优化：SQL是一种声明示语言，用户只描述做什么，没有告诉数据怎么做
- 目标：找到一个正确且执行代价最小的物理执行计划
- 查询优化器是数据库的大脑，最复杂的模块（哈人）很多相关问题都是NP的
- 一般SQL越复杂，Join的表越多，数据量越大，查询优化的意义就越大，因为不同执行方式的性能差别可能有成千上百倍
Physical Plan
- 目标：最小化网络数据传输
- 利用上数据的物理分布（数据亲和性）
- 连接：增加Shuffle算子
Executor
- 单机并行：cache,pipeline,SIMD
- 多机并行：一个fragment对应多个实例
常见的查询优化器
查询优化器分类
- 按照遍历树的顺序来划分
-
- Top-down Optimizer
-
- Bottom-up Optimizer
- 按照优化方法划分
-
- Rule-based Optimizer（RBO）（基于规则）
-
- Cost-based Optimizer（CBO）（基于代价）
RBO
- 优化原则：I/O、Network、CPU & Memory
- 列裁剪
- 谓词下推
- 传递闭包
- Runtime Filter
越来越好、越来越难
- 优点：实现简单，优化速度快
- 缺点：不保证得到最优的执行计划（靠经验）
CBO
- 概念：使用一个模型估算执行计划的代价，选择代价最小的执行计划
- 执行流程：统计信息 + 推导规则 --> 计算算子代价 --> 计算执行计划代价 --> 执行计划效率
- 统计信息：推导统计信息 选择率、基数（准确的基数cardinality很重要）
- 统计信息收集方式
-
- 在DDL里指定
-
- 手动执行explain analyze statement
-
- 动态采样
- 执行计划枚举：贪心算法、动态规划（寻找最优执行计划）
CBO对查询性能非常重要
以上总体按照上课顺序整理，个人对RBO的几个优化方法的例子没太看懂……通过本次课大概对SQL的流程有了一个总体的认识，了解了一些查询优化器，期待在未来自己去运用。
