Spark on Hive 和 Hive on Spark

Spark on Hive 和 Hive on Spark

在数据源与数据格式，以及数据转我们介绍了在 Spark SQL 之上做数据分析应用开发的一般步骤。

我们通过 SparkSession read API 从分布式文件系统创建 DataFrame。然后，通过创建临时表并使用 SQL 语句，或是直接使用 DataFrame API，来进行各式各样的数据转换、过滤、聚合等操作。最后，我们再用 SparkSession 的 write API 把计算结果写回分布式文件系统。

实际上，直接与文件系统交互，仅仅是 Spark SQL 数据应用的常见场景之一。Spark SQL 另一类非常典型的场景是与 Hive 做集成、构建分布式数据仓库。我们知道，数据仓库指的是一类带有主题、聚合层次较高的数据集合，它的承载形式，往往是一系列 Schema 经过精心设计的数据表。在数据分析这类场景中，数据仓库的应用非常普遍。

在 Hive 与 Spark 这对“万金油”组合中，Hive 擅长元数据管理，而 Spark 的专长是高效的分布式计算，二者的结合可谓是“强强联合”。今天这一讲，我们就来聊一聊 Spark 与 Hive 集成的两类方式，一类是从 Spark 的视角出发，我们称之为 Spark on Hive；而另一类，则是从 Hive 的视角出发，业界的通俗说法是：Hive on Spark。

Hive 架构与基本原理

Hive 是 Apache Hadoop 社区用于构建数据仓库的核心组件，它负责提供种类丰富的用户接口，接收用户提交的 SQL 查询语句。这些查询语句经过 Hive 的解析与优化之后，往往会被转化为分布式任务，并交付 Hadoop MapReduce 付诸执行。

Hive 是名副其实的“集大成者”，它的核心部件，其实主要是 User Interface（1）和 Driver（3）。而不论是元数据库（4）、存储系统（5），还是计算引擎（6），Hive 都以“外包”、“可插拔”的方式交给第三方独立组件，所谓“把专业的事交给专业的人去做”，如下图所示。

Hive 的 User Interface 为开发者提供 SQL 接入服务，具体的接入途径有 Hive Server 2（2）、CLI 和 Web Interface（Web 界面入口）。其中，CLI 与 Web Interface 直接在本地接收 SQL 查询语句，而 Hive Server 2 则通过提供 JDBC/ODBC 客户端连接，允许开发者从远程提交 SQL 查询请求。显然，Hive Server 2 的接入方式更为灵活，应用也更为广泛。

我们以响应一个 SQL 查询为例，看一看 Hive 是怎样工作的。接收到 SQL 查询之后，Hive 的 Driver 首先使用其 Parser 组件，将查询语句转化为 AST（Abstract Syntax Tree，查询语法树）。

紧接着，Planner 组件根据 AST 生成执行计划，而 Optimizer 则进一步优化执行计划。要完成这一系列的动作，Hive 必须要能拿到相关数据表的元信息才行，比如表名、列名、字段类型、数据文件存储路径、文件格式，等等。而这些重要的元信息，通通存储在一个叫作“Hive Metastore”（4）的数据库中。

本质上，Hive Metastore 其实就是一个普通的关系型数据库（RDBMS），它可以是免费的 MySQL、Derby，也可以是商业性质的 Oracle、IBM DB2。实际上，除了用于辅助 SQL 语法解析、执行计划的生成与优化，Metastore 的重要作用之一，是帮助底层计算引擎高效地定位并访问分布式文件系统中的数据源。

这里的分布式文件系统，可以是 Hadoop 生态的 HDFS，也可以是云原生的 Amazon S3。而在执行方面，Hive 目前支持 3 类计算引擎，分别是 Hadoop MapReduce、Tez 和 Spark。

当 Hive 采用 Spark 作为底层的计算引擎时，我们就把这种集成方式称作“Hive on Spark”。相反，当 Spark 仅仅是把 Hive 当成是一种元信息的管理工具时，我们把 Spark 与 Hive 的这种集成方式，叫作“Spark on Hive”。

Spark on Hive

在开始正式学习 Spark with Hive 之前，我们先来说说这类集成方式的核心思想