Hive架构回顾

1）用户接口：Client

CLI（command-line interface）、JDBC/ODBC(jdbc 访问 hive)、WEBUI（浏览器访问 hive）

2）元数据：Metastore

元数据包括：表名、表所属的数据库（默认是 default）、表的拥有者、列/分区字段、表的类型（是否是外部表）、表的数据所在目录等；

默认存储在自带的 derby 数据库中，推荐使用 MySQL 存储 Metastore

3）Hadoop

使用 HDFS 进行存储，使用 MapReduce 进行计算。

4）驱动器：Driver

5）解析器（SQL Parser）

将 SQL 字符串转换成抽象语法树 AST，这一步一般都用第三方工具库完成，比如 antlr；

对 AST 进行语法分析，比如表是否存在、字段是否存在、SQL 语义是否有误。

6）编译器（Physical Plan）

将 AST 编译生成逻辑执行计划。

7）优化器（Query Optimizer）

对逻辑执行计划进行优化。

8）执行器（Execution）

把逻辑执行计划转换成可以运行的物理计划。对于 Hive 来说，就是 MR/Spark。 

HQL 转换为 MR 任务流程说明

1.进入程序，利用Antlr框架定义HQL的语法规则，对HQL完成词法语法解析，将HQL转换为为AST（抽象语法树）；

2.遍历AST，抽象出查询的基本组成单元QueryBlock（查询块），可以理解为最小的查询执行单元；

3.遍历QueryBlock，将其转换为OperatorTree（操作树，也就是逻辑执行计划），可以理解为不可拆分的一个逻辑执行单元；

4.使用逻辑优化器对OperatorTree（操作树）进行逻辑优化。例如合并不必要的ReduceSinkOperator，减少Shuffle数据量；

5.遍历OperatorTree，转换为TaskTree。也就是翻译为MR任务的流程，将逻辑执行计划转换为物理执行计划；

6.使用物理优化器对TaskTree进行物理优化；

7.生成最终的执行计划，提交任务到Hadoop集群运行。

可以发现Hive框架底层就是MapReduce，所以在Hive中执行SQL时，往往很慢很慢

Spark出现以后，将HiveQL语句翻译成基于RDD操作，此时Shark框架诞生了。

前身Shark框架

Shark即Hive on Spark，本质上是通过Hive的HQL进行解析，把HQL翻译成Spark上对应的RDD操作，然后通过Hive的Metadata获取数据库里表的信息，实际为HDFS上的数据和文件，最后有Shark获取并放到Spark上计算。

但是Shark框架更多是对Hive的改造，替换了Hive的物理执行引擎，使之有一个较快的处理速度。然而不容忽视的是Shark继承了大量的Hive代码，因此给优化和维护带来大量的麻烦。为了更好的发展，Databricks在2014年7月1日Spark Summit上宣布终止对Shark的开发，将重点放到SparkSQL模块上。

在许多年前(2012\2013左右)Hive逐步火热起来, 大片抢占分布式SQL计算市场。

Spark作为通用计算框架, 也不可能放弃这一细分领域。于是, Spark官方模仿Hive推出了Shark框架(Spark 0.9版本)。

Shark框架是几乎100%模仿Hive, 内部的配置项\优化项等都是直接模仿而来.不同的在于将执行引擎由MapReduce更换为了Spark。

因为Shark框架太模仿Hive, Hive是针对MR优化, 很多地方和SparkCore(RDD)水土不服, 最终被放弃。

Spark官方下决心开发一个自己的分布式SQL引擎 也就是诞生了现在的SparkSQL

SparkSQL模块主要将以前依赖Hive框架代码实现的功能自己实现，称为Catalyst引擎。

● 2014年 1.0正式发布

● 2015年 1.3  发布DataFrame数据结构, 沿用至今

● 2016年 1.6 发布Dataset数据结构(带泛型的DataFrame), 适用于支持泛型的语言(Java\Scala)

● 2016年 2.0 统一了Dataset 和 DataFrame, 以后只有Dataset了, Python用的DataFrame就是 没有泛型的Dataset

● 2019年 3.0 发布， 性能大幅度提升，SparkSQL变化不大