这是我参与「第四届青训营 」笔记创作活动的第1天。
虽然距离该课程已经过去一周，我才迟迟写下这篇笔记。青训营的培训对于是充满考验的，几乎完全陌生的知识，要在一个月内吸收总结运用，在布置完大项目时，我有点知难而退了。但是好在有自己的打气，朋友的支持，并且青训营给了我一次机会充分认识到自己的不知，结识了比我优秀的同学，让我有勇气继续去面对这场考验。
以下为我总结的上课笔记：
SQL Optimizer 浅析（一）
一、大数据体系和SQL
大数据体系包括基础设施（ECS、存储、VPC）、存储系统（HDFS、HBase、NAS/Object Store/数据湖）、资源调度（YARN/K8S）、分析引擎（批式分析、实时分析、交互分析）、权限管控（Apache Ranger、GDPR)、数据开发(Airflow、DAG)、业务应用(BI报表、数据挖掘、营销分析、精准推荐）。
graph TD
SQL --> AST --> LogicalPlan --> PhyscicalPlan
- Parser
由SQL到AST（abstract syntax tree）抽象语法树的转换
词法分析：拆分字符串，得到关键词，数值常量，字符串常量，运算符号等token 语法分析：将token组成AST node，最终形成一个AST 实现：递归下降（click house）Flex和Bison（postgreSQL),Javacc(Flink),Anth(Presto,Spark)
- Analyzer
检查并绑定DataBase,Table,Column等元信息 SQL的合法性检查，比如min/max/avg的输入是数值 Logical Plan逻辑的描述SQL对应的分布计算步骤
- Optimizer
Physical Plan Plan Frafment:执行计划子树 目标：最小化网络数据传输，利用上数据的物理分布（数据亲和性），增加shuffle算子
- Executor
单击执行：cache，pipeline，SIMD 多机执行：一个fragment对应多个实例
小结： One SQL rules big data all. SQL需要依次经过Parser,Analyzer,Optimizer和Executor的处理。 查询优化器是数据库的大脑，在大数据场景下对查询性能至关重要。 查询优化器需要感知数据分布，充分利用数据的亲和性。 查询优化器按照最小化网络数据传输的目标把逻辑计划拆分成多个物理计划片段。
二、常见的查询优化器
查询优化器分类有两种：
Top-down Optimizer(从目标输出开始，从上往下遍历计划树，找到完整的最优执行计划，例子：Volcano/Cascade,SQL Server),Bottom-up Optimizer( 从零开始，由下往上遍历计划树，找到完整的执行计划，例子：System R,PostgreSQL,IBM DB2)
Rule-based Optimizer(RBO)(根据关系代数等价语义，重写查询，基于启发式规则，会访问表的元信息（catalog),不会涉及具体的表数据（data））。 Cost-based Optimizer(CBO)(使用一个模型估算执行计划的代价，选择代价最小的执行计划）
- RBO 优化原则：Read data less and faster(I/O),Transfer data less and faster(Network),Process data less and faster(CPU&meomory) 列裁剪（从上往下看需要哪些列，放在最底层选出来），谓词下推（将选择过滤等谓词放到下面一层，减少计算量），传递闭包（将满足条件的filter放在其他的查询中去），Runtime Filter
主流RBO实现一般都有几百条基于经验归纳得到的优化规则，优点：实现简单，优化速度快。缺点：不保证得到最优的执行计划。
