这里我们讲解一下SparkSQL的优化器系统Catalyst，Catalyst本质就是一个SQL查询的优化器，而且和 大多数当前的大数据SQL处理引擎设计基本相同（Impala、Presto、Hive（Calcite）等）。了解Catalyst的SQL优化流程，也就基本了解了所有其他SQL处理引擎的工作原理。
*SQL优化器核心执行策略主要分为两个大的方向：基于规则优化（RBO）以及基于代价优化(CBO)，基于规则
优化是一种经验式、启发式地优化思路，更多地依靠前辈总结出来的优化规则，简单易行且能够覆盖到大部分优
化逻辑，但是对于核心优化算子Join却显得有点力不从心。举个简单的例子，两个表执行Join到底应该使用
BroadcastHashJoin 还是SortMergeJoin？当前SparkSQL的方式是通过手工设定参数来确定，如果一个
表的数据量小于这个值就使用BroadcastHashJoin，但是这种方案显得很不优雅，很不灵活。基于代价优化
就是为了解决这类问题，它会针对每个Join评估当前两张表使用每种Join策略的代价，根据代价估算确定一种
代价最小的方案
*我们这里主要说明基于规则的优化，略提一下CBO
如上图是一个SQL经过优化器的最终生成物理查询计划的留存，红色部分是我们要重点说明的内容。大 家思考我们写的一个SQL最终如何在Spark引擎中转换成具体的代码执行的。任何一个优化器工作原理都大同小异：SQL语句首先通过Parser模块被解析为语法树，此棵树称为Unresolved Logical Plan； Unresolved Logical Plan通过Analyzer模块借助于数据元数据解析为Logical Plan；此时再通过各种基于规则的优化策略进行深入优化，得到Optimized Logical Plan；优化后的逻辑执行计划依然是逻辑的，并不能被Spark系统理解，此时需要将此逻辑执行计划转换为Physical Plan；为了更好的对整个过程进行理解，下文通过一个简单示例进行解释。
Parser
Parser简单来说是将SQL字符串切分成一个一个Token，再根据一定语义规则解析为一棵语法树。Parser模块目前基本都使用第三方类库 ANTLR 进行实现，比如Hive、 Presto、SparkSQL等。下图是一个示例性的SQL语句（有两张表，其中people表主要存储用户基本信息，score表存储用户 的各种成绩），通过Parser解析后的AST语法树如下图所示：
Analyzer
通过解析后的逻辑执行计划基本有了⻣架，但是系统并不知道score、sum这些都是些什么⻤，此 时需要基本的元数据信息来表达这些词素，最重要的元数据信息主要包括两部分：表的Scheme和 基本函数信息，表的scheme主要包括表的基本定义（列名、数据类型）、表的数据格式（Json、Text）、表的物理位置等，基本函数信息主要指类信息。
Analyzer会再次遍历整个语法树，对树上的每个节点进行数据类型绑定以及函数绑定，比如people 词素会根据元数据表信息解析为包含age、id以及name三列的表，people.age会被解析为数据类型 为int的变量，sum会被解析为特定的聚合函数，如下图所示：
Optimizer
优化器是整个Catalyst的核心，上文提到优化器分为基于规则优化和基于代价优化两种，此处只介 绍基于规则的优化策略，基于规则的优化策略实际上就是对语法树进行一次遍历，模式匹配能够满 足特定规则的节点，再进行相应的等价转换。因此，基于规则优化说到底就是一棵树等价地转换为 另一棵树。SQL中经典的优化规则有很多，下文结合示例介绍三种比较常⻅的规则：谓词下推（Predicate Pushdown）、常量累加（Constant Folding）和列值裁剪（Column Pruning）
1.谓词下推， 下图左边是经过Analyzer解析后的语法树，语法树中两个表先做join，之后再使用age>10对结果进行过滤。大家知道join算子通常是一个非常耗时的算子，耗时多少一般取决于参与join的两个表的大小，如果能够减少参与join两表的大小，就可以大大降低join算子所需 时间。谓词下推就是这样一种功能，它会将过滤操作下推到join之前进行，下图中过滤条件age>0以及id!=null两个条件就分别下推到了join之前。这样，系统在扫描数据的时候就对数据 进行了过滤，参与join的数据量将会得到显著的减少，join耗时必然也会降低。
2.常量累加，如下图。 常量累加其实很简单，就是 x+(1+2) -> x+3 这样的规则，虽然是一个很小的改动，但是意义巨大。示例如果没有进行优化的话，每一条结果都需要执行一次100+80的操作，然后再与变量math_score以及english_score相加，而优化后就不需要再执行100+80操作。
3.列值裁剪，如下图。这是一个经典的规则，示例中对于people表来说，并不需要扫描它的所有列值，而只需要列值id，所以在扫描people之后需要将其他列进行裁剪，只留下列id。这个 优化一方面大幅度减少了网络、内存数据量消耗，另一方面对于列存数据库（Parquet）来说 大大提高了扫描效率
物理计划
经过上述步骤，逻辑执行计划已经得到了比较完善的优化，然而，逻辑执行计划依然没办法真正执行，他们只是逻辑上可行，实际上Spark并不知道如何去执行这个东⻄。比如Join只是一个抽象概 念，代表两个表根据相同的id进行合并，然而具体怎么实现这个合并，逻辑执行计划并没有说明。
此时就需要将逻辑执行计划转换为物理执行计划，将逻辑上可行的执行计划变为Spark可以真正执 行的计划。比如Join算子，Spark根据不同场景为该算子制定了不同的算法策略，有BroadcastHashJoin、ShuffleHashJoin以及SortMergeJoin等（可以将Join理解为一个接口， BroadcastHashJoin是其中一个具体实现），物理执行计划实际上就是在这些具体实现中挑选一个耗时最小的算法实现，这个过程涉及到基于代价优化(CBO)策略，所谓基于代价 ， 是因为物理执行计划的每一个节点都是有执行代价的，这个代价主要分为两部分
第一部分:该执行节点对数据集的影响，或者说该节点输出数据集的大小与分布（需要去采集）
第二部分:该执行节点操作算子的代价（相对固定，可用规则来描述）
在SQL 执行之前会根据代价估算确定一种代价最小的方案来执行。我们这里以Join为例子做个简单说明
*在SparkSQL中，Join可分为ShufflebasedJoin和BroadcastJoin。ShufflebasedJoin需要引入Shuffle，代价相对较高。BroadcastJoin无须Join，但要求至少有一张表足够小，能通过Spark的Broadcast机制广播到每个Executor中。*在不开启CBO中，SparkSQL通过spark.sql.autoBroadcastJoinThreshold判断是否启用BroadcastJoin。其默认值为10485760即10MB。并且该判断基于参与Join的表的原始大小。*在下图示例中，Table1大小为1TB，Table2大小为20GB，因此在对二者进行join时，由于二者都远大于自动BroatcastJoin的阈值，因此SparkSQL在未开启CBO时选用SortMergeJoin对二者进行Join。*而开启CBO后，由于Table1经过Filter1后结果集大小为500GB，Table2经过Filter2后结果集大小为10MB低于自动BroatcastJoin阈值，因此SparkSQL选用BroadcastJoin。
