走进Spark SQL

从Shark说起：

Shark即Hive on Spark，为了实现与Hive兼容，Shark在HiveQL方面重用了Hive中HiveQL的解析、逻辑执行计划翻译、执行计划优化等逻辑，可以近似认为仅将物理执行计划从MapReduce作业替换成了Spark作业，通过Hive的HiveQL解析，把HiveQL翻译成Spark上的RDD操作。Shark的出现，使得SQL-on-Hadoop的性能比Hive有了10-100倍的提高。

但是，shark的设计导致了两个问题：

①.执行计划优化完全依赖于hive，不方便添加新的悠哈策略。

②.因为Spark是线程级并行，而MapReduce是进程级并行，因此，Spark在兼容hive的实现上存在线程安全问题，导致Shark不得不使用另外一套独立维护的打了补丁的hive源码分支。

也因此发展出两个直线：Spark SQL和hive on Spark。

 

Spark SQL是Spark的计算模块之一，它和Spark的基础模块RDD不一样，是专门用于处理结构化数据的。Spark SQL兼容Hive，拥有比hive更好的性能，目前已支持TPC-DS基准，是大数据背景下优良的数据仓库解决方案之一。Spark SQL提供了对关系型数据库的增、删、查、改等的交互式操作， 也可以对Hive 和Json 等数据格式的数据进行符合要求的处理。

Spark SQL既可以使用标准的SQL语法，也可以使用HiveSQL来执行SQL的查询和读写，Spark SQL还可以从已经存在的hive数据仓库中读取数据。

 

Spark SQL设计：

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

 

Spark SQL目前支持Scala、Java、Python三种语言，支持SQL-92规范

为什么推出Spark SQL？（翻译来自Google）

（虽然关系型数据库的流行表明用户通常情况下更喜欢编写声明性查询，但是关系型数据库对于大多数应用程序来说是不够的。首先，用户希望对可能是非结构化的各种数据源执行ETL，这需要自定义代码。其次，用户希望执行在关系系统中难以表达的高级分析，例如机器学习和图形处理。在实践中，我们观察到大多数数据流水线理想地用关系查询和复杂过程算法的组合来表达。不幸的是，这两类系统 - 关系和程序 - 到目前为止仍然基本上是不相交的，迫使用户选择一种范式或另一种范式。）

（Spark SQL通过两个贡献弥补了两个模型之间的差距。首先，Spark SQL提供了一个DataFrame API，可以对外部数据源和Spark的内置分布式集合执行关系操作。此API类似于R [32]中广泛使用的数据框架概念，但是懒惰地评估操作以便它可以执行关系优化。其次，为了支持大数据中的各种数据源和算法，Spark SQL引入了一种名为Catalyst的新型可扩展优化器。 Catalyst可以轻松地为机器学习等域添加数据源，优化规则和数据类型。）

 

概括为：1.关系数据库已经很流行，但是关系数据库在大数据时代却已经不能满足要求，主要 原因有：

             ①.首先，用户需要从不同数据源执行各种操作，包括结构化和非结构化数据；

             ②其次，用户需要执行高级分析，比如机器学习和图像处理；

             ③.在实际大数据应用中，经常需要融合关系查询和复杂分析算法（比如机器学习或图像处理）

              但是，缺少这样的系统。

             Spark SQL很好地填补了这个鸿沟：

             ①.首先，Spark SQL可以提供DataFrame API，可以对内部和外部各种数据源执行各种关系操作；

             ②.其次，可以支持大量的数据源和数据分析算法，Spark SQL可以融合：传统关系数据库的结构化数据管理能力和机器学习算法的数据处理能力。

 

参考厦门大学林子雨老师的《Spark编程基础》书中的第六章Spark SQL。