本文目录
一、Apache Spark
二、Spark SQL发展历程
三、Spark SQL底层执行原理
四、Catalyst 的两大优化
一、Apache Spark
Apache Spark是用于大规模数据处理的统一分析引擎，基于内存计算，提高了在大数据环境下数据处理的实时性，同时保证了高容错性和高可伸缩性，允许用户将Spark部署在大量硬件之上，形成集群。
Spark源码从1.x的40w行发展到现在的超过100w行，有1400多位大牛贡献了代码。整个Spark框架源码是一个巨大的工程。
二、Spark SQL发展历程
我们知道Hive实现了SQL on Hadoop，简化了MapReduce任务，只需写SQL就能进行大规模数据处理，但是Hive也有致命缺点，因为底层使用MapReduce做计算，查询延迟较高。
1. Shark的诞生
所以Spark在早期版本（1.0之前）推出了Shark，这是什么东西呢，Shark与Hive实际上还是紧密关联的，Shark底层很多东西还是依赖于Hive，但是修改了内存管理、物理计划、执行三个模块，底层使用Spark的基于内存的计算模型，从而让性能比Hive提升了数倍到上百倍。
产生了问题：
- 因为 Shark 执行计划的生成严重依赖 Hive，想要增加新的优化非常困难；
- Hive 是进程级别的并行，Spark 是线程级别的并行，所以 Hive 中很多线程不安全的代码不适用于 Spark；
- 由于以上问题，Shark 维护了 Hive 的一个分支，并且无法合并进主线，难以为继；
- 在 2014 年 7 月 1 日的 Spark Summit 上，Databricks 宣布终止对 Shark 的开发，将重点放到 Spark SQL 上。
2. SparkSQL-DataFrame诞生
解决问题：
- Spark SQL 执行计划和优化交给优化器 Catalyst；
- 内建了一套简单的 SQL 解析器，可以不使用 HQL；
- 还引入和 DataFrame 这样的 DSL API，完全可以不依赖任何 Hive 的组件。
新的问题：
对于初期版本的 SparkSQL，依然有挺多问题，例如只能支持 SQL 的使用，不能很好的兼容命令式，入口不够统一等。
3. SparkSQL-Dataset诞生
SparkSQL 在 1.6 时代，增加了一个新的 API，叫做 Dataset，Dataset 统一和结合了 SQL 的访问和命令式 API 的使用，这是一个划时代的进步。
在 Dataset 中可以轻易的做到使用 SQL 查询并且筛选数据，然后使用命令式 API 进行探索式分析。
三、Spark SQL底层执行原理
Spark SQL 底层架构大致如下：
可以看到，我们写的SQL语句，经过一个优化器（Catalyst），转化为RDD，交给集群执行。
SQL到RDD中间经过了一个Catalyst，它就是Spark SQL的核心，是针对Spark SQL语句执行过程中的查询优化框架，基于Scala函数式编程结构。
我们要了解Spark SQL的执行流程，那么理解Catalyst的工作流程是非常有必要的。
一条SQL语句生成执行引擎可识别的程序，就离不开解析（Parser）、优化（Optimizer）、执行（Execution） 这三大过程。而Catalyst优化器在执行计划生成和优化的工作时候，它离不开自己内部的五大组件，如下所示：
- Parser模块：将SparkSql字符串解析为一个抽象语法树/AST。
- Analyzer模块：该模块会遍历整个AST，并对AST上的每个节点进行数据类型的绑定以及函数绑定，然后根据元数据信息Catalog对数据表中的字段进行解析。
- Optimizer模块：该模块是Catalyst的核心，主要分为RBO和CBO两种优化策略，其中RBO是基于规则优化，CBO是基于代价优化。
- SparkPlanner模块：优化后的逻辑执行计划OptimizedLogicalPlan依然是逻辑的，并不能被Spark系统理解，此时需要将OptimizedLogicalPlan转换成physical plan（物理计划） 。
- CostModel模块：主要根据过去的性能统计数据，选择最佳的物理执行计划。这个过程的优化就是CBO（基于代价优化）。
为了更好的对整个过程进行理解，下面通过简单的实例进行解释。
步骤1. Parser阶段：未解析的逻辑计划
Parser简单说就是将SQL字符串切分成一个一个的Token，再根据一定语义规则解析成一颗语法树。Parser模块目前都是使用第三方类库ANTLR进行实现的，包括我们熟悉的Hive、Presto、SparkSQL等都是由ANTLR实现的。
在这个过程中，会判断SQL语句是否符合规范，比如select from where 等这些关键字是否写对。当然此阶段不会对表名，表字段进行检查。
步骤2. Analyzer阶段：解析后的逻辑计划
通过解析后的逻辑计划基本有了骨架，此时需要基本的元数据信息来表达这些词素，最重要的元数据信息主要包括两部分：表的Scheme和基本函数信息，表的Scheme主要包括表的基本定义（列名、数据类型）、表的数据格式（Json、Text）、表的物理位置等，基本函数主要指类信息。
Analyzer会再次遍历整个语法树，对树上的每个节点进行数据类型绑定及函数绑定，比如people词素会根据元数据表信息解析为包含age、id以及name三列的表，people.age会被解析为数据类型的int的变量，sum被解析为特定的聚合函数。
此过程就会判断SQL语句的表名，字段名是否真的在元数据库里存在。
步骤3. Optimizer模块：优化过的逻辑计划
Optimizer优化模块是整个Catalyst的核心，上面提到优化器分为基于规则的优化（RBO）和基于代价优化（CBO）两种。基于规则的优化策略实际上就是对语法树进行一次遍历，模式匹配能够满足特定规则的节点，在进行相应的等价转换。下面介绍三种常见的规则：谓词下推(Predicate Pushdown) 、常量累加(Constant Folding) 、列值裁剪(Column Pruning) 。
- 谓词下推(Predicate Pushdown)
上图左边是经过解析后的语法树，语法树中两个表先做join，之后在使用age>10进行filter。join算子是一个非常耗时的算子，耗时多少一般取决于参与join的两个表的大小，如果能够减少参与join两表的大小，就可以大大降低join算子所需的时间。
谓词下推就是将过滤操作下推到join之前进行，之后再进行join的时候，数据量将会得到显著的减少，join耗时必然降低。
