SparkSQL

一、从Shark说起

　　Shark即Hive on Spark，为了实现与Hive兼容，Shark在HiveQL方面重用了Hive中HiveQL的解析、逻辑执行计划翻译、执行计划优化等逻辑。

　　Shark和Hive区别仅将物理执行计划从MapReduce作业替换成了Spark作业，通过Hive的HiveQL解析，把HiveQL翻译成Spark上的RDD操作。

Shark的设计导致了两个问题(由于这两个问题存在，Shark被停止开发了)：
一是执行计划优化完全依赖于Hive，不方便添加新的优化策略；
二是因为Spark是线程级并行，而MapReduce是进程级并行，因此，Spark在兼容Hive的实现上存在线程安全问题，导致Shark不得不使用另外一套独立维护的打了补丁的Hive源码分支

　　Hive过程如下：

二、Spark SQL设计

　　Spark SQL在Hive兼容层面仅依赖HiveQL解析、Hive元数据，也就是说，从HQL被解析成抽象语法树（AST）起，就全部由Spark SQL接管了。Spark SQL执行计划生成和优化都由Catalyst（函数式关系查询优化框架）负责。

 

　　Spark SQL增加了SchemaRDD（即带有Schema信息的RDD），使用户可以在Spark SQL中执行SQL语句，数据既可以来自RDD，也可以是Hive、HDFS、Cassandra等外部数据源，还可以是JSON格式的数据
　　Spark SQL目前支持Scala、Java、Python三种语言，支持SQL-92规范

 

SparkSQL的表数据在内存中存储不是采用原生态的JVM对象存储方式，而是采用内存列存储，如下图所示。

 

该存储方式无论在空间占用量和读取吞吐率上都占有很大优势。

2、 SparkSQL运行架构

　　类似于关系型数据库，SparkSQL也是语句也是由Projection（a1，a2，a3）、Data Source（tableA）、Filter（condition）组成，分别对应sql查询过程中的Result、Data Source、Operation，也就是说SQL语句按Result-->Data Source-->Operation的次序来描述的。

 

执行SparkSQL语句的顺序为（解析、绑定、优化、执行）：

1.对读入的SQL语句进行解析（Parse），分辨出SQL语句中哪些词是关键词（如SELECT、FROM、WHERE），哪些是表达式、哪些是Projection、哪些是Data Source等，从而判断SQL语句是否规范；

2.将SQL语句和数据库的数据字典（列、表、视图等等）进行绑定（Bind），如果相关的Projection、Data Source等都是存在的话，就表示这个SQL语句是可以执行的；

3.一般的数据库会提供几个执行计划，这些计划一般都有运行统计数据，数据库会在这些计划中选择一个最优计划（Optimize）；

4.计划执行（Execute），按Operation-->Data Source-->Result的次序来进行的，在执行过程有时候甚至不需要读取物理表就可以返回结果，比如重新运行刚运行过的SQL语句，可能直接从数据库的缓冲池中获取返回结果。

2.1 Tree和Rule

　　SparkSQL对SQL语句的处理和关系型数据库对SQL语句的处理采用了类似的方法，首先会将SQL语句进行解析（Parse），然后形成一个Tree(抽象语法树)，在后续的如绑定、优化等处理过程都是对Tree的操作，而操作的方法是采用Rule，通过模式匹配，对不同类型的节点采用不同的操作。在整个sql语句的处理过程中，Tree和Rule相互配合，完成了解析、绑定（在SparkSQL中称为Analysis）、优化、物理计划等过程，最终生成可以执行的物理计划。

2.1.1 Tree(抽象语法树)

l  Tree的相关代码定义在sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/trees

l  Logical Plans(逻辑计划)、Expressions、Physical Operators(物理计划执行)都可以使用Tree表示

l  Tree的具体操作是通过TreeNode来实现的

Ø  SparkSQL定义了catalyst.trees的日志，通过这个日志可以形象的表示出树的结构

Ø  TreeNode可以使用scala的集合操作方法（如foreach, map, flatMap, collect等）进行操作

Ø  有了TreeNode，通过Tree中各个TreeNode之间的关系，可以对Tree进行遍历操作，如使用transformDown、transformUp将Rule应用到给定的树段，然后用结果替代旧的树段；也可以使用transformChildrenDown、transformChildrenUp对一个给定的节点进行操作，通过迭代将Rule应用到该节点以及子节点。

l  TreeNode可以细分成三种类型的Node：

Ø  UnaryNode 一元节点，即只有一个子节点。如Limit、Filter操作

Ø  BinaryNode 二元节点，即有左右子节点的二叉节点。如Jion、Union操作

Ø  LeafNode 叶子节点，没有子节点的节点。主要用户命令类操作，如SetCommand

2.1.2 Rule(操作方法)

  Rule的相关代码定义在sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/rules

  Rule在SparkSQL的Analyzer、Optimizer、SparkPlan等各个组件中都有应用到

  Rule是一个抽象类，具体的Rule实现是通过RuleExecutor完成

  Rule通过定义batch和batchs，可以简便的、模块化地对Tree进行transform操作

  Rule通过定义Once和FixedPoint，可以对Tree进行一次操作或多次操作（如对某些Tree进行多次迭代操作的时候，达到FixedPoint次数迭代或达到前后两次的树结构没变化才停止操作，具体参看RuleExecutor.apply）

2.2 sqlContext和hiveContext的运行过程

　　SparkSQL有两个分支，sqlContext和hiveContext，sqlContext现在只支持SQL语法解析器（SQL-92语法）；hiveContext现在支持SQL语法解析器和hivesql语法解析器，默认为hiveSQL语法解析器，用户可以通过配置切换成SQL语法解析器，来运行hiveSQL不支持的语法，

2.2.1 sqlContext的运行过程

sqlContext总的一个过程如下图所示：

1.SQL语句经过SqlParse解析成UnresolvedLogicalPlan(未处理逻辑计划)；

2.使用analyzer(分析器)结合数据数据字典（catalog）进行绑定，生成resolvedLogicalPlan(已处理逻辑计划)；

3.使用optimizer(优化器)对resolvedLogicalPlan(已处理逻辑计划)进行优化，生成optimizedLogicalPlan(优化后逻辑计划)；

4.使用SparkPlan将LogicalPlan(逻辑计划)转换成PhysicalPlan(物理计划)；

5.使用prepareForExecution()将PhysicalPlan(物理计划)转换成可执行物理计划；

6.使用execute()执行可执行物理计划；

7.生成SchemaRDD。

在整个运行过程中涉及到多个SparkSQL的组件，如SqlParse、analyzer、optimizer、SparkPlan等等

2.2.2hiveContext的运行过程

hiveContext总的一个过程如下图所示：

1.SQL语句经过HiveQl.parseSql解析成Unresolved LogicalPlan，在这个解析过程中对hiveql语句使用getAst()获取AST树，然后再进行解析；

2.使用analyzer结合数据hive源数据Metastore（新的catalog）进行绑定，生成resolved LogicalPlan；

3.使用optimizer对resolved LogicalPlan进行优化，生成optimized LogicalPlan，优化前使用了ExtractPythonUdfs(catalog.PreInsertionCasts(catalog.CreateTables(analyzed)))进行预处理；

4.使用hivePlanner将LogicalPlan转换成PhysicalPlan；

5.使用prepareForExecution()将PhysicalPlan转换成可执行物理计划；

6.使用execute()执行可执行物理计划；

7.执行后，使用map(_.copy)将结果导入SchemaRDD。

 

2.3 catalyst优化器

SparkSQL1.1总体上由四个模块组成：core、catalyst、hive、hive-Thriftserver：

 core处理数据的输入输出，从不同的数据源获取数据（RDD、Parquet、json等），将查询结果输出成schemaRDD；

 catalyst处理查询语句的整个处理过程，包括解析、绑定、优化、物理计划等，说其是优化器，还不如说是查询引擎；

 hive对hive数据的处理

 hive-ThriftServer提供CLI和JDBC/ODBC接口

　　在这四个模块中，catalyst处于最核心的部分，其性能优劣将影响整体的性能。由于发展时间尚短，还有很多不足的地方，但其插件式的设计，为未来的发展留下了很大的空间。下面是catalyst的一个设计图：

 

其中虚线部分是以后版本要实现的功能，实线部分是已经实现的功能。从上图看，catalyst主要的实现组件有：

lsqlParse，完成sql语句的语法解析功能，目前只提供了一个简单的sql解析器；

Analyzer，主要完成绑定工作，将不同来源的Unresolved LogicalPlan和数据元数据（如hive metastore、Schema catalog）进行绑定，生成resolved LogicalPlan；

optimizer对resolved LogicalPlan进行优化，生成optimized LogicalPlan；

Planner将LogicalPlan转换成PhysicalPlan；

CostModel，主要根据过去的性能统计数据，选择最佳的物理执行计划

　　这些组件的基本实现方法：

l 先将sql语句通过解析生成Tree，然后在不同阶段使用不同的Rule应用到Tree上，通过转换完成各个组件的功能。

l Analyzer使用Analysis Rules，配合数据元数据（如hive metastore、Schema catalog），完善Unresolved LogicalPlan的属性而转换成resolved LogicalPlan；

l optimizer使用Optimization Rules，对resolved LogicalPlan进行合并、列裁剪、过滤器下推等优化作业而转换成optimized LogicalPlan；

l Planner使用Planning Strategies，对optimized LogicalPlan转换为physicalPlan

CostModel依据过去性能统计数据，选择最优physicalPlan来执行。