这是我参与「第四届青训营 」笔记创作活动的的第1天
一.大数据体系和SQL
1.大数据体系中的SQL
SQL仍是目前最广泛的结构化数据计算技术。
批式分析：Spark、Hive、MR
实时分析：Flink
交互分析：Presto、ClickHouse、Doris
以上三种分析引擎都在广泛使用SQL技术
2.SQL的处理流程
一条SQL语句生成执行引擎可识别的程序，就离不开解析（Parser）、优化（Optimizer）、执行（Execution） 这三大过程。
- Parser模块：将SQL字符串解析为一个抽象语法树/AST。
- Analyzer模块：该模块会遍历整个AST，并对AST上的每个节点进行数据类型的绑定以及函数绑定，然后根据元数据信息对数据表中的字段进行解析。
- Optimizer模块：该模块是核心部分，主要分为RBO和CBO两种优化策略，其中RBO是基于规则优化，CBO是基于代价优化
- Executor模块：优化后的逻辑执行计划OptimizedLogicalPlan依然是逻辑的，并不能被Spark系统理解，此时需要将OptimizedLogicalPlan转换成physical plan（物理计划）
- 根据过去的性能统计数据，选择最佳的物理执行计划。这个过程的优化就是CBO（基于代价优化）。
二、常见的查询优化器
1.RBO - Rule-based Optimizer
- RBO的执行过程比较简单，主要包含两个步骤：
1）Transformation
遍历关系表达式，只要模式能够满足特定优化规则就进行转换。
2）Build Physical Plan
经过Step1之后就生成了一个逻辑执行计划，但这只是逻辑上可行，还需要将逻辑执行计划build成物理执行计划，即决定各个Operator的具体实现。如Join算子的具体实现选择BroadcastHashJoin还是SortMergeJoin。
- RBO小结：
主流RBO实现一般都有几百条基于经验归纳得到的优化规则
优点：实现简单、优化速度快
缺点：不保证得到最优的执行计划
2.CBO - Cost-based Optimizer
-使用一个模型估算执行计划的代价，选择代价最小的执行计划
- CBO查询优化主要包含三个步骤：
1）Exploration
根据优化规则进行等价转换，生成等价关系表达式，此时原有关系表达式会被保留。
2）Build Physical Plan
决定各个Operator的具体实现。
3）Find Best Plan
根据统计信息计算各个执行计划的Cost，选择Cost最小的执行计划。
- CBO小结
1.CBO使用贪心或者动态规划算法寻找最优执行计划
2.在大数据场景下CBO对查询性能非常重要
三、前沿趋势
大数据创业如火如荼，SQL查询优化器仍然是必不可少的一个重要组件
引擎架构的进化、云原生、湖仓一体等对SQL查询优化器有新的要求和挑战
AI加持，学习型查询优化器在不断进化
