这是我参与「第四届青训营 」笔记创作活动的第1天，在第一节课中主要了解到了大数据体系和SQL、常见的SQL查询优化器、社区开源实践、以及前沿趋势等内容。

一、大数据体系和SQL

• 大数据体系中的SQL

大数据体系：

• SQL的处理流程

Parser

• String->AST(abstract syntax tree)
• 实现：递归下降(ClickHouse),Flex和Bison(PostgreSQL),JavaCC(Flink),Antlr(Presto,Spark)

Analyzer

• 检查并绑定Database,Table,Column等元信息
• SQL的合法性检查，比如min/max/avg的输入是数值
• AST->Logical Plan

Logical Plan

• 逻辑地描述SQL对应的分步骤计算操作
• 计算操作：算子(operater)

查询优化

• SQL是一种声明式语言，用户只描述做什么，没有告诉数据库怎么做
• 目标：找到一个正确且执行代价最小的物理执行计划
• 查询优化器是数据库的大脑，最复杂的模块
• 一般SQL越复杂，Join的表越多，数据量越大，查询优化的意义越大

Physical Plan

• 目标：最小化网络数据传输
• 利用上数据的物理分布（数据亲和性）
• 增加Shuffle算子

Executor

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

小结

• One SQL reles big data all
• SQL需要依次经过Parser,Analyzer,Optimizer和Executor的处理
• 查询优化是数据库的大脑，在大数据场景下对查询性能至关重要
• 查询优化需要感知数据分布，充分利用数据的亲和性

二、常见的查询优化器

查询优化器的分类

Top-down Optimizer

• 从目标输出开始，由上往下遍历计划树，找到完整的最优执行计划
• 例：Volcano/Cascade,SQLSever

Bottom-up Optimizer

• 从零开始，由下往上遍历计划树，找到完整的执行计划
• 例：System R,PostgreSQL,IBM DB2

RBO(Rule-based Optimizer)

• 主流RBO实现一般都有几百条基于经验归纳得到的优化规则
• 优点：实现简单，优化速度快
• 缺点：不保证得到最优的执行计划

CBO(Cost-based Optimizer)

• CBO使用代价模型和统计信息估算执行计划的代价
• CBO使用贪心或者动态规划算法寻找最优执行计划
• 在大数据场景下CBO对查询性能非常重要

小结

• 主流RBO实现一般都有几百条基于经验归纳得到的优化规则
• RBO实现简单，优化速度快
• RBO不保证得到最优的执行计划
• CBO使用代价模型和统计信息估算执行计划的代价
• CBO使用贪心或者动态规划算法寻找最优执行计划
• 大数据场景下CBO对查询性能非常重要

三、社区开源实践

社区开源实践概览

• One size fits all
• 模块化、插件化、稳定可靠
• 支持异构数据模型
• 内置RBO和CBO

Apache Calcite

Calcite RBO

- HepPlanner

• 优化规则
• 内置有100+优化规则
• 四种匹配规则
• 遍历所有的rule,直到没有rule可以被触发
• 优化速度快，实现简单，但是不保证最优

-VolcanoPlanner

• 基于Volcano/Cascade框架
• 成本最优假设
• Memo:存储候选执行计划
• Top-down动态规划搜索
• 应用Rule搜索候选计划
• Group winner:目前的最优计划

小结

• 主流的查询优化都包含RBO和CBO
• Apache Calcite 是大数据领域很流行的查询优化器
• Apache Calcite RBO定义了许多优化规则，使用pattern匹配子树，执行等价变换
• Apache Calcite CBO基于Volcano/Cascade框架
• volcano/Cascade 的精髓：Memo、动态规划、剪枝

四、前沿趋势

• 大数据创业如火如荼，SQL查询优化仍是必不可少的一个重要组件
• 引擎架构的进化、云原生、湖仓一体等对SQL查询优化器有新的要求和挑战
• AI加持，学习型查询优化器在不断进化