SQL Optimizer 解析 | 青训营笔记

71 阅读6分钟

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

今天是大数据专场基础班的第一次课,主要内容是介绍SQL优化器的相关知识,主要分为四个板块。

一、大数据体系和SQL

1. 大数据体系

大数据体系主要内容如下图所示:

image.png

2.SQL的处理流程

image.png

  • 将输入的Strings通过Parser处理成抽象语法树(AST)

  • AST通过Analyzer分析处理成逻辑计划

  • 通过查询优化找到一个正确且执行代价最小物理执行计划,从而提高执行的效率

  • 将优化后的逻辑计划拆分成小的执行计划子树

  • 将拆分后的子树发送给结点执行,可分为单机并行和多机并行

小结:

  • One SQL rules big data all

  • SQL需要一次经过Parser,Analyzer,Optimizer和Executor的处理

  • 查询优化器是数据库的大脑,在大数据场景下对查询性能至关重要

  • 查询优化器需要感知数据分布,充分利用数据的亲和性

  • 查询优化器按照最小化网络数据传输的目标把逻辑计划拆分成多个物理计划片段

二、常见的查询优化器

1.查询优化器的分类

  • 按照遍历方向分类:
  1. Top-down Optimizer: 从目标输出开始,从上往下遍历计划树,找到完整的最优执行计划
  2. Bottom-up Optimizer: 从零开始,由下往上遍历计划树,找到完整的执行计划
  • 按照优化方法分类
  1. RBO(Rule-based Optimizer): 根据关系代数等价语义,重写查询;基于启发式规则;会访问表的元信息,不会涉及具体的表数据
  2. CBO(Cost-based Optimizer): 使用一个模型估算执行计划的代价,选择代价最小的执行计划

2.常见的查询优化器

2.1 RBO(Rule-based Optimizer)

2.1.1 关系代数

image.png

2.1.2 优化原则

  • 优化I/O: 读取更少的数据/更快的读取数据
  • 优化网络: 传输的数据更少/传输的数据更快
  • 优化CPU&内存: 处理的数据更少/处理的数据更快

2.1.3 四种优化规则

  • 列裁剪: 对于一个查询的算子,用不到的列不需要读取或保留,尽早的把这些列去掉,从而减少对于I/O或者内存的占用,实现时从上往下扫描
  • 谓词下推: 过滤掉一些不必要的数据或者不必要的行数,显著的减少传输或者计算的开销
  • 传递闭包: 根据表达式的等价关系以及过滤条件,可以推导出新的过滤条件
  • Runtime Fliter: 通过在join的probe端提前过滤掉那些不会命中join的输入数据来大幅减少join中的数据传输和计算,从而减少整体的执行时间

RBO小结:

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

2.2 CBO(Cost-based Optimizer)

2.2.1 概念

  • 使用一个模型估算执行计划的代价,选择代价最小的执行计划
  • 算子代价:CPU,内存,磁盘 I/O ,网络 I/O等代价

2.2.2 流程

image.png

2.2.3 统计信息

  • 原始表统计信息
  • 推导统计信息:
    1. 选择率(selectivity): 对于某一个过滤条件,查询会从表中返回多大比例的数据
    2. 基数(cardinality): 在查询计划中常指算子需要处理的行数

2.2.4 统计信息的收集方式

  • 在DDL里指定需要收集的统计信息,数据库会在数据写入时收集或者更新统计信息
  • 手动执行explain analyze staement,触发数据库收集或者更新统计信息
  • 动态采样

2.2.5 统计信息推导规则

  • Filter Selectivity:
AND条件:fs(a AND b)=fs(a)*fs(b) 
OR条件:fs(a OR b)=fs(a)+fs(b)-(fs(a)*fs(b)) 
NOT条件:fs(NOT a)=1.0-fs(a) 
等于条件:(x = literal)
   literal<min && literal>max : 0 
   1/NDV 
小于条件(X<literal) 
   literal<min : 0 
   literal>max : 1 
   (literal-min)/(max-min)

2.2.6 执行计划枚举

  • CBO通常使用 贪心算法 或者 动态规则 选出最优的执行计划

CBO小结

  • CBO使用代价模型和统计信息估算执行计划的代价
  • CBO使用代价模型和统计信息估算执行计划的代价
  • 在大数据场景下CBO对查询性能非常重要

小结

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

三、社区开源实践

1.社区开源实践概览

image.png

2.Apache Calcite

  • 统一的SQL查询引擎
  • 模块化、插件化、稳定可靠
  • 支持异构数据模型:关系型、半结构化、流式、地理空间数据
  • 内置RBO和CBO

2.1 Calcite RBO

  • HepPlanner
    • 优化规则:
      • Pattern:匹配表达式子树
      • 等价变换:得到新的表达式
    • 内置有100+优化规则
    • 四种匹配规则:
      • arbitrary/depth_fitst:深度优先
      • top_down:拓扑顺序
      • bottom_up:与top_down相反
    • 遍历所有的rule,直到没有rule可以被触发
    • 优化速度快,实现简单,但不保证最优

2.2 Calcite CBO

  • VolcanoPlanner
    • 基于Volcano/Cascade框架
    • 成本最优假设
    • Group:等价计划集合
    • 应用Rule搜索候选计划
    • Group winner:目前的最优计划
    • Top-down遍历:选择winner构建最优执行计划
    • 精髓:
      • Memo:
        • 存储候选执行计划
        • 本质是AND/OR graph
        • 共享子树减少内存开销
      • 剪枝:减少搜索空间
      • Top-down动态规划搜索

小结

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

四、前沿趋势

1. 前沿趋势

image.png

2. DATA + AI

image.png

小结

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

五、课程总结

SQL是大数据处理中的核心部分,而查询优化器是数据库的大脑,在大数据场景下对查询性能至关重要。之后,我们学习了常见的几种查询优化器,例如RBO和CBO,然后对于这些查询优化器进行更详细的介绍。最后,了解了一些社区开源实践的相关内容以及大数据方向的前沿趋势。

作为一个非科班专业,同时也没有什么基础的同学,对于老师讲的大部分内容都不是很理解,所以需要在课后下功夫,自己去消化。

最后也希望能在接下来的一个月里,和大家一起学习,一起进步,成为更好的自己!!!

引用参考

内容主要参考了周东炎老师在「SQL Optimizer 解析」课程里所教授的内容,图片来自于老师的PPT,链接如下: SQL 查询优化器浅析 周东炎 ppt.pptx - 飞书文档 (feishu.cn)