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

大数据体系

1. SQL

1.1 SQL的处理流程

 SQL             AST            Logical Plan             Physical Plan
----->  Paresr  -----> Analyzer    ----->    Optinizer       ----->     Executor

Parser：

·String -> AST
词法分析：拆分字符串，得到关键词、数值常量、字符串常量、运算符号等token
语法分析：将token组成AST node，最终得到一个AST
·实现：递归下降（ClickHouse）：Flex和bison(PostgreSQL)，JavaCC(Flink)，Antlr(Presto，Spark)

Analyzer和Logical Plan：

·Analyzer：
检查并绑定Database，Table，Column等元信息
SQL的合法性检查，比如min/max/avg的输入是数值
AST -> Logical Plan
·Logical Plan:
逻辑的描述SQL对应的分步骤计算操作
计算操作：算子（operator）

Physical Plan 和 Executor：

·Plan Fragment：执行计划子树
目标：最小优化网络数据传输
利用上数据的物理分布（数据亲和性）
增加Shuffle算子
·Executor：
单机并行：cache，pipeline，SIMD
多机并行：一个fragment对应多个实例

2. 常见的查询优化

2.1 查询优化器分类

Top-down Optimizer

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

Bottom-up Optimizer

从目标输出开始，由下往上遍历计划树，找到完整的执行计划
例子：System R，PostgreSQL，IBM DB2

Rule-based Optiimizer（RBO）

根据关系代数等价语义，重写查询
基于启发式规则
会访问表的元素信息（catalog），不会涉及具体的表数据

Cost-based Optimizer（CBO）

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

RBO：

主流RBO实现一般都有几百条基于经验归纳得到的优化规则
优点：实现简单，优化速度快
缺点：不保证得到最优的执行计划
    单表扫描：索引扫描（随机I/O)vs全表扫描（顺序I/O）
        如果查询的数据分布非常不均衡，索引扫描可能不如全表扫描
    join的实现：Hash join vs SortMerge Join
    两表的Hash Join：用小表构建哈希表——如何识别小表？
    多表Join：
        哪种连接顺序是最优的？
        是否要对每种组合都探索？
            N个表连接，仅仅是left-deep tree就有差不多N！种连接顺序
            e.g.N=10->总共3,628,800个连接顺序

CBO：

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

关于优化器CBO 和 RBO 还有很多运用实例和具体细节，接下来还需要加深学习！