Hive架构介绍

《Hive安装使用》介绍了一下Hive的安装和数据模型，本文主要介绍Hive的架构及查询流程。

架构总览

先来一张官网的架构图：

这幅图清楚的展示了Hive和Hadoop的关系，并且展示了Hive一些重要的组件：

• UI ：主要是Hive的各种客户端。这是用户使用Hive的窗口，包括我们之前使用的HiveCli、Beeline等CLI，以及一些Web GUI接口。用户通过UI来提交自己的操作请求。
• Driver ：接收用户查询，并且实现了会话处理，基于JDBC/ODBC实现了执行、拉取数据等API。
• Compiler ：解析查询语句，做语义分析，最终借助在Metastore中查询到的表和分区的元数据生成执行计划(execution plan)，这个和传统的RDBMS比较像。当然其实Hive也有优化器（Optimizer），图中没有画出来。
• Metastore ：存储表和分区的元数据信息，包括字段、字段类型、读写数据需要的序列化和反序列化信息。
• Execution Engine ：执行引擎，用来执行Compiler生成的执行计划，是Hive和Hadoop之间的桥梁。现在Hive支持的计算引擎包括MR（逐渐废弃）、Tez、Spark。

Tips：Hive中Compiler生成的执行计划是一个多阶段的DAG，像MR、Tez、Spark这些计算引擎都可以执行。

这便是Hive里面几个核心的组件。下面我们看看一下一次查询的完整流程（下面的step n对应图中的数组序号）：

1. 用户通过UI提交自己的查询请求到Driver（step 1）；
2. Driver创建一个会话来处理用户的这次请求，并将请求发到Compiler以生成执行计划（step 2）；
3. Compiler从Metastore获取一些必要的元数据信息（step 3、4），做类型检查以及一些优化操作，然后最终生成执行计划发送给Driver（step 5），Driver再将执行计划发送给Execution Engine（以下简称EE）。
4. EE拿到执行计划之后，会发送给合适的组件（step 6.1、6.2、6.3）。Hive的数据存储在HDFS上，所以执行的时候必然要和HDFS打交道。比如要先去NameNode上面查询数据的位置，然后去DataNode上面获取数据。如果是DDL操作的话（比如CREATE、DROP、ALTER等），还要和Hive的MetaStore通信。图中画的是使用MR的情况，MR可能有多个阶段，中间也会生成一些临时文件，这些文件都存储在HDFS上面。如果是DML操作，最后会将临时文件直接重命名（HDFS的重命名是一个原子操作）为最终的表名。如果是查询语句，Driver会调用fetch语句，通过Execution Engine直接从HDFS上面读取临时文件。

这便是Hive内部的处理流程。

HiverServer2

HiverServer2（以下简称HS2）是Hive里面非常重要的一个模块，基于Thrift开发，所以有时也被称为Thrift Server，主要功能是提供客户端操作Hive的接口，默认端口是10000。最早提供该功能的是HiveServer(为了和HS2区分，有时也叫HS1，也是基于Thrift开发)，因为缺乏并发支持和认证机制，在Hive 1.0.0版本中被移除，引入了HS2。HS2解决了HS1缺乏的并发和认证功能，并增加了一些新的特性，有兴趣的可以看一下这篇文章： How HiveServer2 Brings Security and Concurrency to Apache Hive 。

需要注意的是：HS2也是Hive的一个模块，和Hive的Driver、Compiler、Execution Engine模块一样。比如看下面的另外两种种Hive的架构图：

这幅图中蓝色的"Hive Server"就是HS2。

这幅图中那个"Thrift Server"就是HS2。

但实际中，会将Hive的HS2、Driver、Compiler、Execution Engine以及一个基于Jetty的Web UI(默认端口是10002)全部实现在一个进程里面，而这个进程对应的程序文件就是 $HIVE_HOME/bin/hiveserver2 。所以要注意HS2是一个单独的模块，而hiveserver2是包含HS2模块以及其它一些模块的一个整体的服务，有些地方对于HS2的描述没有对此作区分，但我们心里要清楚。

所以，正常情况我们可以看到Hive最多就三个进程：MetaStore、HiveServer2、WebHCat(可选，做Hive元数据管理的)。

更多关于HS2的信息，可参加： HiveServer2 Overview .

MetaStore

MetaStore是Hive必不可少的一个模块。

设计动机

MetaStore提供了两个非常重要的功能： 数据抽象（data abstraction） 和 数据发现（data discovery） 。

• 数据抽象：使用Hive处理数据之前，我们必须先定义库、表、分区、序列化、反序列化等信息，这些信息都会作为元数据存储在MetaStore里面，后面操作表里面的数据的时候直接去MetaStore里面就可以获取到数据的这些元信息，而不用每次操作数据的时候再去看数据格式是什么样子，如何读取，如何加载等。
• 数据发现：一方面用户可以通过元数据去了解数据，另一方面其它一些系统也可以基于Hive的元数据做一些功能，比如Impala。

存储部署

MetaStore里面的存储使用的是JPOX ORM( Data Nucleus ) 方案,所以任何支持该方案的存储都可以作为MetaStore后端的存储，比如Apache Derby以及大多数RDBMS都支持。目前MetaStore支持的RDBMS见 这里 .

MetaStore有两种部署方式：

• Local/Embedded Metastore Database (Derby) ：该方式一次只能有一个进程连接到MetaStore，所以仅用于测试。这种模式下，Hive客户端直接通过JDBC访问MetaStore。Local模式可以使用一些RDBMS，而Embedded就是使用内置的Derby。
• Remote Metastore Database ：这种模式下使用远程的RDBMS来作为存储（典型的就是MySQL），用于生产环境。此时，MetaStore通过Thrift方式提供服务，Hive客户端通过该服务访问MetaStore。

MetaStore的E/R图见 这里 。

最后来一张图帮助理解：

配置

MetaStore的核心配置有4个：

• javax.jdo.option.ConnectionURL ：JDBC连接信息。比如使用Derby时的值可以为`jdbc:derby:;databaseName=
  ../build/test/junit_metastore_db;create=true ;使用 MySQL 时的值可以为： jdbc:mysql://<host name>/<database name>?createDatabaseIfNotExist=true`.
• javax.jdo.option.ConnectionDriverName ：JDBC驱动类名,Derby模式下值为 org.apache.derby.jdbc.EmbeddedDriver , MySQL为 com.mysql.jdbc.Driver .
• hive.metastore.uris ：uri，如果为空则表示为local模式，否则为remote模式。
• hive.metastore.warehouse.dir ：默认表的位置。

配置在 hive-site.xml 或者 hivemetastore-site.xml 里面均可，后者优先级高于前者。

HCatalog && WebHCat

HCatalog是Apache下面的一个元数据管理工具，后来被集成到Hive里面，是的一些第三方 工具 比如Pig、MR、Spark等可以通过HCatalog直接访问HDFS上的数据。而WebHCat（以前称为Templeton）提供访问HCatalog的REST API。对于Hive而言，HCatalog和WebHCat是非必须的。

Hive的架构就介绍到这里。

References：

• Hive wiki

《Hive安装使用》介绍了一下Hive的安装和数据模型，本文主要介绍Hive的架构及查询流程。

架构总览

先来一张官网的架构图：

这幅图清楚的展示了Hive和Hadoop的关系，并且展示了Hive一些重要的组件：

• UI ：主要是Hive的各种客户端。这是用户使用Hive的窗口，包括我们之前使用的HiveCli、Beeline等CLI，以及一些Web GUI接口。用户通过UI来提交自己的操作请求。
• Driver ：接收用户查询，并且实现了会话处理，基于JDBC/ODBC实现了执行、拉取数据等API。
• Compiler ：解析查询语句，做语义分析，最终借助在Metastore中查询到的表和分区的元数据生成执行计划(execution plan)，这个和传统的RDBMS比较像。当然其实Hive也有优化器（Optimizer），图中没有画出来。
• Metastore ：存储表和分区的元数据信息，包括字段、字段类型、读写数据需要的序列化和反序列化信息。
• Execution Engine ：执行引擎，用来执行Compiler生成的执行计划，是Hive和Hadoop之间的桥梁。现在Hive支持的计算引擎包括MR（逐渐废弃）、Tez、Spark。

Tips：Hive中Compiler生成的执行计划是一个多阶段的DAG，像MR、Tez、Spark这些计算引擎都可以执行。

这便是Hive里面几个核心的组件。下面我们看看一下一次查询的完整流程（下面的step n对应图中的数组序号）：

1. 用户通过UI提交自己的查询请求到Driver（step 1）；
2. Driver创建一个会话来处理用户的这次请求，并将请求发到Compiler以生成执行计划（step 2）；
3. Compiler从Metastore获取一些必要的元数据信息（step 3、4），做类型检查以及一些优化操作，然后最终生成执行计划发送给Driver（step 5），Driver再将执行计划发送给Execution Engine（以下简称EE）。
4. EE拿到执行计划之后，会发送给合适的组件（step 6.1、6.2、6.3）。Hive的数据存储在HDFS上，所以执行的时候必然要和HDFS打交道。比如要先去NameNode上面查询数据的位置，然后去DataNode上面获取数据。如果是DDL操作的话（比如CREATE、DROP、ALTER等），还要和Hive的MetaStore通信。图中画的是使用MR的情况，MR可能有多个阶段，中间也会生成一些临时文件，这些文件都存储在HDFS上面。如果是DML操作，最后会将临时文件直接重命名（HDFS的重命名是一个原子操作）为最终的表名。如果是查询语句，Driver会调用fetch语句，通过Execution Engine直接从HDFS上面读取临时文件。

这便是Hive内部的处理流程。

HiverServer2

HiverServer2（以下简称HS2）是Hive里面非常重要的一个模块，基于Thrift开发，所以有时也被称为Thrift Server，主要功能是提供客户端操作Hive的接口，默认端口是10000。最早提供该功能的是HiveServer(为了和HS2区分，有时也叫HS1，也是基于Thrift开发)，因为缺乏并发支持和认证机制，在Hive 1.0.0版本中被移除，引入了HS2。HS2解决了HS1缺乏的并发和认证功能，并增加了一些新的特性，有兴趣的可以看一下这篇文章： How HiveServer2 Brings Security and Concurrency to Apache Hive 。

需要注意的是：HS2也是Hive的一个模块，和Hive的Driver、Compiler、Execution Engine模块一样。比如看下面的另外两种种Hive的架构图：

这幅图中蓝色的"Hive Server"就是HS2。

这幅图中那个"Thrift Server"就是HS2。

但实际中，会将Hive的HS2、Driver、Compiler、Execution Engine以及一个基于Jetty的Web UI(默认端口是10002)全部实现在一个进程里面，而这个进程对应的程序文件就是 $HIVE_HOME/bin/hiveserver2 。所以要注意HS2是一个单独的模块，而hiveserver2是包含HS2模块以及其它一些模块的一个整体的服务，有些地方对于HS2的描述没有对此作区分，但我们心里要清楚。

所以，正常情况我们可以看到Hive最多就三个进程：MetaStore、HiveServer2、WebHCat(可选，做Hive元数据管理的)。

更多关于HS2的信息，可参加： HiveServer2 Overview .

MetaStore

MetaStore是Hive必不可少的一个模块。

设计动机

MetaStore提供了两个非常重要的功能： 数据抽象（data abstraction） 和 数据发现（data discovery） 。

• 数据抽象：使用Hive处理数据之前，我们必须先定义库、表、分区、序列化、反序列化等信息，这些信息都会作为元数据存储在MetaStore里面，后面操作表里面的数据的时候直接去MetaStore里面就可以获取到数据的这些元信息，而不用每次操作数据的时候再去看数据格式是什么样子，如何读取，如何加载等。
• 数据发现：一方面用户可以通过元数据去了解数据，另一方面其它一些系统也可以基于Hive的元数据做一些功能，比如Impala。

存储部署

MetaStore里面的存储使用的是JPOX ORM( Data Nucleus ) 方案,所以任何支持该方案的存储都可以作为MetaStore后端的存储，比如Apache Derby以及大多数RDBMS都支持。目前MetaStore支持的RDBMS见 这里 .

MetaStore有两种部署方式：

• Local/Embedded Metastore Database (Derby) ：该方式一次只能有一个进程连接到MetaStore，所以仅用于测试。这种模式下，Hive客户端直接通过JDBC访问MetaStore。Local模式可以使用一些RDBMS，而Embedded就是使用内置的Derby。
• Remote Metastore Database ：这种模式下使用远程的RDBMS来作为存储（典型的就是MySQL），用于生产环境。此时，MetaStore通过Thrift方式提供服务，Hive客户端通过该服务访问MetaStore。

MetaStore的E/R图见 这里 。

最后来一张图帮助理解：

配置

MetaStore的核心配置有4个：

• javax.jdo.option.ConnectionURL ：JDBC连接信息。比如使用Derby时的值可以为`jdbc:derby:;databaseName=
  ../build/test/junit_metastore_db;create=true ;使用MySQL时的值可以为： jdbc:mysql://<host name>/<database name>?createDatabaseIfNotExist=true`.
• javax.jdo.option.ConnectionDriverName ：JDBC驱动类名,Derby模式下值为 org.apache.derby.jdbc.EmbeddedDriver , MySQL为 com.mysql.jdbc.Driver .
• hive.metastore.uris ：uri，如果为空则表示为local模式，否则为remote模式。
• hive.metastore.warehouse.dir ：默认表的位置。

配置在 hive-site.xml 或者 hivemetastore-site.xml 里面均可，后者优先级高于前者。

HCatalog && WebHCat

HCatalog是Apache下面的一个元数据管理工具，后来被集成到Hive里面，是的一些第三方工具比如Pig、MR、Spark等可以通过HCatalog直接访问HDFS上的数据。而WebHCat（以前称为Templeton）提供访问HCatalog的REST API。对于Hive而言，HCatalog和WebHCat是非必须的。

Hive的架构就介绍到这里。

References：

• Hive wiki