SQL Optimizer解析

1.大数据体系 2.sql-接口 大数据处理事实的标准 SQL -> Parser AST>Analyzer__Logincal Plan__>Optimizer__Physical__>excuto 3.1 SQL处理流程-Parser String ->AST 拆分字符串 ->得到各种常量 ->token 将token组成AST node 最终得到一个AST

实现：递归下降,Flex和Bison(PostgreSQL),javaCC(Flink),Antlr

3.2 SQL处理流程-Analyzer和Logcial Plan Analyzer 1.检查并绑定Datebase,Table,Column等信息 2.SQL的合法性检查，比如min/max/avg的输入是数值 3.AST->Logical Plan

Logical Plan 1.逻辑地描述SQL对应的发布计算条件 2.计算操作：算子(operator)

3.3SQL的处理流程 - 查询优化 1.SQL是一种声明式语言，用户只描述做什么，没有告诉数据库在怎么做 2.目标：找到一个正确且执行代价最小的物理执行计划 3.查询优化器是数据库的大脑，最复杂的模块，很多相关问题都是NP的 4.一般SQL越复杂，Join的表越多，数据量越大，查询优化的意义就越大

3.4SQL的处理流程-Physcial Plan 和Executor Plan Fragment:执行计划字树 1.目标：最小化网络数据传输 2.利用数据的物理分布（数据亲和性） 3.增加Shuffle算子

Executor 1.单机并行：cache，pipeline，SIMD 2.多机并行：一个fragment对应多个实例

4.常见的查询优化器 4.1查询优化器分类 Top-down Optimizer 1.从目标输出开始，由上往下遍历计划树，找到完整的最优执行计划 2.例子：Volcabo/Cascade，SqlServer Bottom-up Optimizer 1.从零开始，由下往上便利计划树，找到完整的执行条件 System R,PostgreSQL,IBM DB2 重点： Rule-based Optimizer(RBO) 1.根据关系代数等价语义，重写查询 2.基于启发式规则 3.会访问表的元信息，不会访问到具体的表数据 关系代数

Cost-based Optimizer（CDO) 使用一个模型估算执行计划的代价，选择代价最小的执行计划

优化I/O 网络 CPU&内存

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

4.3CBO概念 使用一个模型估算执行计划的代价，选择代价最小的执行计划 1.执行计划的代价等于所有算子的执行代价之和 2.通过RBO得到所有肯的等价执行计划 算子代价：CPU，内存，磁盘I/O，网络I/O等代价 和算子输入数据的统计信息有关：输入、输出结果的行数，每行的大小 叶子算子Scan：通过统计原始表数据得到 中间算子：根据一定的推搭配规则，从下层算子的统计信息推到得到 和具体的算子的物理实现有关 4.3.1 CBO - 统计信息 原始表统计信息 表或者分区级别：行数、行平均大小、表在磁盘中占用了多少字节等 列级别：min、max、num nulls、num not nulls、num distinct value(NDV)、histogram等 推导统计信息 选择率：对于某一个过滤条件，查询会从表中返回多大比例的数据 基数：在查询计划中常指算子需要的处理的行数 CBO - 统计信息的收集方式 在DDL里指定需要收集的统计信息，数据库会在数据写入时手机或更新统计信息

手动执行explain analyze statement，触发数据库手机或者更新统计信息

动态采样

CBO - 统计信息推导规则 假设列和列之间是独立的，列的值是均匀分布 Filter Selectivity

CBO-统计信息问题

4.3.2CBO - 执行计划美剧 单表扫描：索引扫描（随机I/O） vs 全表扫描(顺序I/O) 如果查询的数据分布非常不均匀，索引扫描可能不如全表扫描 Join的实现：Hash Join vs SortMerge Join 量表 Hash Join ：用小表构建哈希表————如何识别小表 多表Join： 1.哪种连接顺序是最优的？ 2.是否要对每种组合都探索？ 3.N个表连接，仅仅是left-deep tree就有差不多N！种连接顺序 4.e.g. N = 10 ->总共3，628，800个连接顺序

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

4.3CBO小节 CBO使用代价模型和统计信息估算执行计划的代价 CBO使用贪心算法或者动态规划算法寻找最优执行计划 在大数据场景下CBO对查询性能非常重要 04.小节 主流RBO实现一般都有几百条基于经

验归纳得到的优化顺序 RBO实现简单，优化速度快 RBO不保证得到最优的执行计划 CBO使用代价模型和统计信息估算执行计划的代价 CBO使用贪心算法或者动态规划算法寻找最优执行计划 在大数据场景下CBO对查询性能非常重要

5.0社区开源实践 社区开源实践 Apache Calcite概述 One size fits all：统一SQL的查询引擎 模块化 插件化，稳定可靠 支持异构数据模型 1.关系型 2.半结构化 3.流式 4.地理空间数据 内置RBO和CBO

5.2 Calcite RBO HepPlanner 优化规则 1.Pattern:匹配表达式子树 2.等价变换：得到新的表达式 内置100+优化规则 四种匹配规则 ARBITRARY/DEPTH_FIRST:深度优先 TOP_DOWN:拓扑顺序 BOTTON_TOP:与TOP_DOWN相反 遍历所有rule 知道没有rule可以被触发 优化速度快，实现简单，但是不保证最优 5.3 Calcite CBO VolcanoPlanner 基于Volcano/Cascade框架 成本最优假设 Memo：存储候选执行计划 Group：等价计划集合 Top-down 动态规划搜索

VolcanoPlanner 应用Rule搜索候选计划 Memo 本质：AND/OR graph 共享子树减少内存开销

VolcanoPlanner 剪枝（Branch-and-bound pruning):减少搜索空间 可行的Aggregate 总的cost=500 自己的cost = 150 孩子节点的cost上限 = 350

TOP-DOWN 遍历 选择winner构建最优执行计划

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

06.前沿趋势

概览

DATA + AI AI4DB 自配置 1.智能调参(OtterTune，QTune) 2.负载预测/调度 自诊断和自愈合：错误恢复和迁移 自优化： 1.统计信息估计（Learned cardinalities) 2.代价估计 3.学习型优化型（IBM DB2 LEO) 4,索引/引图推荐 DB4AI 1.内嵌人工智能算法(MLSQL,SQLFLOW) 2.内嵌机器学习框架(SparkML,Alink,dl-on-flink)