Hive架构介绍


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

架构总览

先来一张官网的架构图:

Hive Architecture

这幅图清楚的展示了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 Architecture2

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

Hive Architecture3

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

配置

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

本文链接:https://time-track.cn/hive-architecture-introduction.html,转载请注明出处。
赞赏


微信赞赏

支付宝赞赏

添加新评论

icon_arrow.gificon_biggrin.gificon_confused.gificon_cool.gificon_cry.gificon_eek.gificon_evil.gificon_exclaim.gificon_idea.gificon_lol.gificon_mad.gificon_mrgreen.gificon_neutral.gificon_question.gificon_razz.gificon_redface.gificon_rolleyes.gificon_sad.gificon_smile.gificon_surprised.gificon_twisted.gificon_wink.gif

友情提醒:填写邮箱是当别人回复你的评论时,会给邮箱发邮件提醒。

|