这是我参与「第四届青训营 」笔记创作活动的第1天
一、 大数据体系和SQL
SQL的处理流程
Parser
String -> AST (Abstruct Syntax Tree)：
- 词法分析:拆分字符串，得到关键词、数值常量、字符串常量、运算符号等token
- 语法分析:将token组成ASTnode，最终得到一个AST
Analyzer
- 检查并绑定Database, Table, Column等元信息
- SQL的合法性检查，比如min/max/avg的输入是数值
- AST -> Logical Plan
Logical Plan：
- 逻辑地描述SQL对应的分步骤计算操作
- 计算操作:算子( operator )
Physical Plan:
- 目标:最小化网络数据传输
- 利用上数据的物理分布(数据亲和性)
- 增加Shuffle算子
Executor
- 单机并行: cache，pipeline, SIMD
- 多机并行: 一个fragment对应多个实例
小结
- One SQL rules big data all
- SQL 需要依次经过Parser，Analyzer，Optimizer和Executor的处理
- 查询优化器是数据库的大脑，在大数据场景下对查询性能至关重要
- 查询优化器需要感知数据分布，充分利用数据的亲和性
- 查询优化器按照最小化网络数据传输的目标把逻辑计划拆分成多个物理计划片段
二、 常见的查询优化器
查询优化器分类
- 第一种：根据遍历树的顺序不同，分为Top-down Optimizer和Bottom-up Optimizer
- 第二种：根据优化原理不同，分为Rule-based Optimizer(RBO)和Cost-based Optimizer(CBO)
- RBO:实现简单，优化速度快，但不保证是最优
- 优化I/O
- 优化网络
- 优化CPU内存
- CBO:执行流程大致如下： 统计信息+推导规则 -> 计算算子代价 -> 计算执行计划代价 -> 枚举
小结
- 主流RBO实现-般都有几百条基于经验归纳得到的优化规则
- RBO实现简单，优化速度快
- RBO不保证得到最优的执行计划
- CBO使用代价模型和统计信息估算执行计划的代价
- CBO使用贪心或者动态规划算法寻找最优执行计划
- 大数据场景下CBO对查询性能非常重要
三、 社区开源实践
Apache Calcite:(大数据领域流行的查询优化器)
- 统一的SQL查询引擎
- 使用Pattern匹配子树，执行等价变换
- 支持异构数据模型
- 内置RBO和CBO
Calcite RBO:
- 内置100+优化规则
- 四种匹配规则
Calcite CBO:
- 基于Volcano/Cascade框架
- 成本最优假设
- Top-down动态规划搜索
