Spark Catalyst-SparkSQL执行流程

工作流程

SQL语句首先通过Parser模块被解析为语法树，即未解析的逻辑计划(Unresolved Logical Plan); 然后通过Analyzer模块借助于数据元数据解析为逻辑计划(Logical Plan); 此时再通过各种基于规则的优化策略进行深入优化，得到优化过的逻辑计划(Optimized Logical Plan); 优化后的逻辑计划依然是逻辑的，并不能被Spark系统理解，此时需要将此逻辑执行计划转换为物理计划(Physical Plan)。

为了更好的对整个过程进行理解，下文通过简单的实例进行解释。

• 未解析的逻辑计划–Parser
  Parser简单来说是将SQL字符串切分成一个一个Token，再根据一定语义规则解析为一颗语法树。Parser模块目前基本都使用第三方类库ANTLR进行实现，比如Hive、Presto、SparkSQL等。
  
• 解析过的逻辑计划–Analyzer
  通过解析后的逻辑执行计划基本有了骨架，此时需要基本的元数据信息来表达这些词素，最重要的元数据信息主要包括两部分：表的Scheme和基本函数信息，表的schema主要包括表的基本定义(列名、数据类型)、表的数据格式(Json、Text)、表的物理位置等，基本函数信息主要指类信息。

Analyzer会再次遍历整个语法树，对树上的每个节点进行数据类型绑定以及函数绑定，比如people词素会根据元数据表信息解析为包含age、id以及name三列的表，people.age会被解析为数据类型为int的变量，sum被解析为特定的聚合函数。

• 优化过的逻辑计划–Optimizer
  优化器是整个Catalyst的核心，上文提到优化器分为基于规则优化和基于代价优化两种。基于规则的优化策略实际上就是对语法树进行一次遍历，模式匹配能够满足特定规则的节点，在进行相应的等价转换。下文介绍三种常见的规则：谓词下推(Predicate Pushdown)、常量累加(Constant Folding)和列值裁剪(Column Pruning)。

谓词下推(Predicate Pushdown)

上图左边是经过解析后的语法树，语法树中两个表先做join，之后再使用age>10进行filter。join算子是一个非常耗时的算子，耗时多少一般取决于参与join的两个表的大小，如果能够减少参与join两表的大小，就可以大大降低join算子所需时间。

谓词下推会将过滤操作下推到join之前进行，之后再进行join的时候，数据量将会得到显著的减少，join耗时必然降低。

常量累加(Constant Folding)

常量累加就是比如计算x+(1+2)-> x+3 ,虽然是一个很小的改动，但是意义巨大。如果没有进行优化的话，每一条结果都需要执行一次100+80的操作，然后再与结果相加。优化后就不需要再次执行100+80操作

列值裁剪(Column Pruning)
列值裁剪是当用到一个表时，不需要扫描它的所有列值，而是扫描只需要的id，不需要的裁剪掉。这一优化一方面大幅度减少了网络、内存数据量消耗，另一方面对于列存储数据库来说大大提高的扫描效率。

• 物理计划–Physical Plan
  至此，逻辑执行计划已经得到了比较完善的优化，然而，逻辑执行计划依然没办法真正执行，他们只是逻辑上可行，实际上Spark并不知道如何去执行这个东西。比如Join只是一个抽象概念，代表两个表根据相同的id进行合并，然而具体怎么实现这个合并，逻辑执行计划并没有说明。

此时就需要将逻辑执行计划转换为物理执行计划，将逻辑上可行的执行计划变为Spark可以真正执行的计划。比如Join算子，Spark根据不同场景为该算子制定了不同的算法策略，有BroadcastHashJoin、ShuffleHashJoin以及SortMergeJoin等（可以将Join理解为一个接口，BroadcastHashJoin是其中一个具体实现），物理执行计划实际上就是在这些具体实现中挑选一个耗时最小的算法实现，这个过程涉及到基于代价优化策略。这里不再细说。

总结

我们将Catalyst的通用树转换框架分为四个阶段。

• 未解析的逻辑计划–Parser
• 解析过的逻辑计划–Analyzer
• 优化过的逻辑计划–Optimizer
• 物理计划–Physical Plan