这是我参与[第四届青训营]笔记创作活动的第一天

一、本课堂重点内容

总体框架

步骤： 1）词法分析：拆分字符串，得到关键词，数值常量，字符串常量，运算符号等token 2）语法分析：将token组成AST node，最终的到一个AST(抽象语法树）实现：递归下降，Flex和Bison(PostgreSQL),JavaCC(Flink),Antir(Presto Spark)

把抽象语法树转变成逻辑计划

检查并绑定Database，Table，Column等元素信息 SQL的合法性检查，比如：min/max/avg的输入是数值

logic PLAN 逻辑地描述SQL对应的分步骤计算操作

逻辑计划树

所谓逻辑计划树，可以理解为逻辑地描述一个 SQL 如何一步步地执行查询和计算，最终得到执行结果的一个分步骤地计划。树中每个节点是是一个算子，定义了对数据集合的计算操作（过滤，排序，聚合，连接），边代表了数据的流向，从孩子节点流向父节点。之所以称它为逻辑的，是因为算子定义的是逻辑的计算操作，没有指定实际的算法，比如对于逻辑的排序算子，逻辑计划树里没有指定使用快排还是堆排。

SQL是一种声明式的语言，用户只描述做什么，没有告诉数据库怎么做，在这之中就存在许多操作空间，给数据库很高的自由度，从而进行查询优化。

目标：找到一个正确且执行代价最小的物理执行计划

一般SQL越复杂，join的表越多，数据量越大，查询优化的意义就越大，因为不同的执行方式的性能差别可能有成百上千倍。

目标：最小化网络数据传输

优化器的输出是一个分布式的物理执行计划。
分布式物理执行计划的目标是在单机 Plan 的基础上最小化数据移动和最大化本地 Scan，生成 PlanFragment 树。
一个 PlanFragment 封装了在一台机器上对数据集的操作逻辑。每个 PlanFragment 可以在每个 executor 节点生成 1 个或多个执行实例，不同执行实例处理不同的数据集，通过并发来提升查询性能。
Plan 分布式化的方法是增加 shuffle 算子，执行计划树会以 shuffle 算子为边界拆分为PlanFragment。

单机并行：cache，pipeline，SIMD 多机并行：一个fragment对应多个实例

1.Top-down Optimizer
2.Bottom-up Optimizer
3.Rule-based Optimizer(RBO)
4.Cost-based Optimizer(CBO)\

优化原则 RBO

基于关系代数等价规则对逻辑计划进行变换
实现上：
- Pattern：定义了特定结构的 Operator 子树（结构）
- Rule：定义了如何将其匹配的节点替换（Substitute）为新形态，从而生成新的、等价的Operator 树（原地替换）
- 优化器搜索过程被抽象为不断匹配 Pattern 然后应用 Rule 转换，直到没有可以匹配的 rule
局限性：
- 无法解决多表连接问题
- 无法确定和选择最优的分布式 Join/Aggregate 执行方式

列裁剪：列去掉，减少I/O内存的占用谓词（where）下推：过滤掉数据传递闭包（表达式的等价条件，推导出新的关系条件 Runtime Filter:提早过滤不要的数据