Spark SQL架构的工作原理和工作流程是什么？

Spark SQL兼容Hive，这是因为Spark SQL架构与Hive底层结构相似，Spark SQL复用了Hive提供的元数据仓库（Metastore）、HiveQL、用户自定义函数（UDF）以及序列化和反序列工具（SerDes），下面通过图1深入了解Spark SQL底层架构。

图1 Spark SQL架构

从图1中可以看出，Spark SQL架构与Hive架构相比，除了把底层的MapReduce执行引擎更改为Spark，还修改了Catalyst优化器，Spark SQL快速的计算效率得益于Catalyst优化器。从HiveQL被解析成语法抽象树起，执行计划生成和优化的工作全部交给Spark SQL的Catalyst优化器进行负责和管理。

Catalyst优化器是一个新的可扩展的查询优化器，它是基于Scala函数式编程结构，Spark SQL开发工程师设计可扩展架构主要是为了在今后的版本迭代时，能够轻松地添加新的优化技术和功能，尤其是为了解决大数据生产环境中遇到的问题（例如，针对半结构化数据和高级数据分析），另外，Spark作为开源项目，外部开发人员可以针对项目需求自行扩展Catalyst优化器的功能。下面通过图2描述Spark SQL的工作原理。

图2 Spark SQL工作原理

Spark要想很好地支持SQL，就需要完成解析（Parser）、优化（Optimizer）、执行（Execution）三大过程。Catalyst优化器在执行计划生成和优化的工作时候，它离不开自己内部的五大组件，具体介绍如下所示。

Parse组件：该组件根据一定的语义规则（即第三方类库ANTLR）将SparkSql字符串解析为一个抽象语法树/AST。
Analyze组件：该组件会遍历整个AST，并对AST上的每个节点进行数据类型的绑定以及函数绑定，然后根据元数据信息Catalog对数据表中的字段进行解析。
Optimizer组件：该组件是Catalyst的核心，主要分为RBO和CBO两种优化策略，其中RBO是基于规则优化，CBO是基于代价优化。
SparkPlanner组件：优化后的逻辑执行计划OptimizedLogicalPlan依然是逻辑的，并不能被Spark系统理解，此时需要将OptimizedLogicalPlan转换成physical plan（物理计划）。
CostModel组件：主要根据过去的性能统计数据，选择最佳的物理执行计划。

在了解了上述组件的作用后，下面分步骤讲解Spark SQL工作流程。

1． 在解析SQL语句之前，会创建SparkSession，涉及到表名、字段名称和字段类型的元数据都将保存在Catalog中；

2． 当调用SparkSession的sql()方法时就会使用SparkSqlParser进行解析SQL语句，解析过程中使用的ANTLR进行词法解析和语法解析；

3． 接着使用Analyzer分析器绑定逻辑计划，在该阶段，Analyzer会使用Analyzer Rules，并结合Catalog，对未绑定的逻辑计划进行解析，生成已绑定的逻辑计划；

4． 然后Optimizer根据预先定义好的规则（RBO）对 Resolved Logical Plan 进行优化并生成 Optimized Logical Plan（最优逻辑计划）；

5． 接着使用SparkPlanner对优化后的逻辑计划进行转换，生成多个可以执行的物理计划Physical Plan；

6． 接着CBO优化策略会根据Cost Model算出每个Physical Plan的代价，并选取代价最小的 Physical Plan作为最终的Physical Plan；

7． 最终使用QueryExecution执行物理计划，此时则调用SparkPlan的execute()方法，返回RDD。

猜你喜欢：

Spark与Hadoop有哪些区别？【大数据培训】

SparkMllib如何解决回归问题？[大数据培训]

怎样操作Spark SQL性能调优？

Spark SQL通过JDBC连接MySQL读写数据

传智教育大数据项目开发培训