一、大数据体系和SQL

One SQL rules big data all

SQL的处理流程

1.SQL语句通过Parser（不同的框架/产品有不同的实现方式）经过词法解析和语法解析生成一棵AST（Abstract Syntax Tree，抽象语法树）

2.AST通过Analyzer中的一系列检查生成Logical Plan。Logical Plan是一棵left-deep tree（或者叫执行计划树），这棵树中的每一个节点称为一个算子对应一个操作，如：SCAN（扫描），JOIN（连接）等。并且left-deep tree要求每一个JOIN算子的右子节点必须是一个SCAN算子。

3.Logical Plan经过Optimizer的优化生成Physical Plan

4.最终Physical Plan被执行。执行分为在单机上执行和在分布式系统上执行，也需要考虑各种优化，如：减小在分布式系统上网络传输的开销、增加shuffle算子等。

二、Optimizer优化

RBO

列剪裁：SCAN只扫描需要用到的列，减少上层算子处理的数据量。分析需要用到的列时从计划数的root往下依次分析，将上面节点需要的列传递到下面的节点。

谓词下推：把JOIN上面的Filter条件下推到JOIN下面，减少上层算子处理的数据量。  （思考题：不同的JOIN都有什么样的下推规则？）

传递闭包：通过已有的FILTER推导出新的FILTER并进行谓词下推，减少上层算子处理的数据量。

Runtime Filter：通过JOIN的连接条件以及右子树的数据人为创造一些条件数据传输给左子树作为FILTER，减少上层算子处理的数据量。常用的条件有：min-max条件，in-list条件，bloom filter（布隆过滤器）。其中，min-max在min和max相差过大时过滤效果并不好，in-list在list中数据过多时会带来较大的网络传输开销，bloom filter虽然会有漏筛的情况存在，但是因为在上层的JOIN中仍然要进行连接条件的过滤，所以不会导致最终结果的错误。

CBO

处理流程：人为建立一个代价模型计算执行计划的代价（计算每个算子的执行代价后sum得到整棵计划树的执行代价），遍历所有通过RBO生成的执行计划，通过模型算出代价，选择代价最小的那个计划执行。由于CBO的模型基于一些假设，如：列与列之间相互独立、数据均匀分布，同时依赖数据的统计信息，所以在假设不成立、统计信息不准确时得到的结论也是和实际有差别的。

处理方法：动态规划（基于成本最优假设）/贪心。

三、开源框架--Apache Calcite

HepPlanner(RBO)

简单来说就是通过四种匹配模式（ARBITRARY/DEPTH_FIRST/TOP_DOWN/BOTTOM_UP）遍历所有的Rules寻找可以匹配的Pattern（特定的表达式子树），一旦匹配就根据设定好的方式进行对应的等价变换，直到没有Rule可以被触发则认为RBO优化完毕。

优点：优化速度快，实现简单

缺点：不保证最优。

VolcanoPlanner(CBO)

流程：首先有一颗计划树，我们将计划树上的每一个算子看作一个group，这样就得到了一条由group组成的计划路径，然后根据Rules匹配对这条路径进行横向扩展（实际上是生成很多条可行的计划路径，然后让他们共享相同的节点，就好像对原本的路径进行了横向的扩展），接着基于成本最优假设自底向上计算执行代价得到代价最小的路径，完成优化。在这一步的过程中会根据当前得到的最小代价进行剪枝（分支限界法），这样可以减少搜索空间，提升搜索效率。最后用最优的路径解析出最优的执行计划树。