目录
SparkSql的架构设及实现
从sparkSql到生成RDD的执行.spark内部实现的基础框架称为Catalyst.
Catalyst.主要用来负责查询语句的解析，绑定，优化和生成物理计划等过程。
整个Catalyst的执行过程分为两个大阶段。逻辑计划阶段和物理计划阶段。
架构图
逻辑计划 （Logical Plan）
1.parser阶段。
分为2步。
1.生成语法树。
parser模块目前底层使用的是Antlr语法生成工具实现解析工作。（当然如果需要重构SparkSql的语法，也可以重新自定义好相关语法后，通过Antlr对SqlBase.g4（语法解析文件）进行语法解析）编译SqlBase.g4后会得到SqlBaseLexer.java(解析)和SqlBaseParser .java（构建）。
最终通过Lexcer来解析关键词以及各种标识符。然后通过parser来进行构建语法树。
2.转换为未绑定的逻辑计划。
这里，通过SparkSqlParser当中的AstBuilder将语法树转换为未绑定的逻辑计划。也就是Unresolved LogicalPlan.
这里会得到有未绑定和的属性的逻辑计划结构。
2.Analyzer阶段
SparkSql中的Catalog体系是以SessionCatalog为主体，通过SparkSession提供给外部调用。一般一个SparkSession对应一个SessionCatalog。其实也就是对底层的元数据信息，临时表信息，视图信息和函数信息进行了封装。
这里借助SessionCatalog进行rule规则的匹配，来完善和绑定未绑定的逻辑计划的属性从而转换成已绑定的逻辑计划（包括表的数据来源，聚合函数，字段，过滤条件，返回的数据类型等都会进行绑定）。
3.Optimizer阶段
因为Analyzed LogicalPlan是根据 Unresolved LogicalPlan 一对一转换而来的，所以得到的Plan很可能不是最优的， 那么就需要根据RBO（基于规则的）对逻辑计划进行优化。比如：列裁剪（过滤掉不需要使用的列），谓词下推（将过滤尽可能下沉到数据源端），常量累加（可以提前计算好的），常量替换（比如 SELECT * FROM table WHERE i = 5 AND j = i + 3 可以转换成 SELECT * FROM table WHERE i = 5 AND j = 8 ）等。
物理计划 (Physical plan)
在生成SparkPlan之前，一个逻辑计划经过一系列的策略（strategy ）处理之后，会用来分辨LogicalPlan 子类并替换为合适的SparkLan子类得到多个物理计划，，之后多个物理计划会基于每个物理计划的代价（CBO）得到最优的物理计划。