这是我参与「第四届青训营」笔记创作活动的的第1天

SQL的处理流程

查询优化

• 执行计划子树

  • 最小化网络数据传输
  • 利用数据的物理分布
  • 增加shuffle算子【有更多的map和reduce同时进行】

• Executor

  • 单机并行：cpu cache，指定的流水线（pipeline）乱序执行，SIMD（单指令流多数据流）
  • 多机并行：同一个fragment对应多个实例，一个fragment在多个节点上并行执行

常见的查询优化器

查询优化器分类

• Top-down Optimizer

  从目标输出，由上向下遍历计划树，找到完整的最优执行计划【SQLServer】

• Bottom-up Optimizer

  由下往上

RBO

运算符和等价变换和学校里的数据库基础一样，这里不多做解释

优化原则

• 优化IO
• 优化网络
• 优化CPU和内存

优点：实现简单

缺点：不保证最优

• 无法保证单表扫描的时候是索引还是全表
• 无法选择最优Join【Hash or SortMerge】
• 两表Hash Join的时候，优先选用小表构建哈希，但是RBO无法识别小表
• 多表Join时，无法选择最优连接顺序

CBO

使用模型估算执行计划的代价，选择最优执行

• 执行计划的代价是所有算子执行代价的总和
• 利用RBO获得可能的等价执行计划

算子代价：CPU，内存，磁盘IO，网络IO

• 与算子的输入数据有关
  • 叶子算子Scan：读数据
  • 中间算子：根据一定的推导规则，从下层算子的统计信息推导得到
• 与算子类型有关

统计信息 + 推导规则 -> 计算算子代价 -> 计算执行计划代价 -> 执行计划枚举

社区开源

自己用过的框架的查询优化器

Apache Calcite：

Hive，Flink，Alibaba MaxCompute

自研, RBO + CBO:

Spark, ClickHouse

Apache Calcite

解析SQL，进行优化。目的是做一个通用的SQL查询优化层，可以对接不同的存储系统

优点

• 统一的SQL查询引擎

• 支持异构数据模型

  • 关系型
  • 半结构化
  • 流式
  • 地理空间数据

• 内置RBO和CBO