Hive架构介绍

栏目: 服务器 · 发布时间: 5年前

内容简介:《Hive安装使用》介绍了一下Hive的安装和数据模型,本文主要介绍Hive的架构及查询流程。先来一张官网的架构图:

《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架构介绍

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

Hive架构介绍

这幅图中那个"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图见 这里

最后来一张图帮助理解:

Hive架构介绍

配置

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安装使用》介绍了一下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架构介绍

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

Hive架构介绍

这幅图中那个"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图见 这里

最后来一张图帮助理解:

Hive架构介绍

配置

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架构介绍》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

程序正义论

程序正义论

徐亚文 / 山东人民出版社 / 2004-3-1 / 22.00元

程序正义论,ISBN:9787209033916,作者:徐亚文著一起来看看 《程序正义论》 这本书的介绍吧!

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

URL 编码/解码
URL 编码/解码

URL 编码/解码

RGB HSV 转换
RGB HSV 转换

RGB HSV 互转工具