本文主要是介绍【hive-design】hive架构详解：描述了hive架构，hive主要组件的作用、hsql在hive执行过程中的底层细节、hive各组件作用，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
文章目录
- 一. Hive Architecture
- 二. Metastore
- 1. Metastore Architecture
- 2. Metastore Interface
- 三. Compiler
- 四. hive架构小结
本文主要讨论了
- 描述了hive架构，hive主要组件的作用
- 详细描述了hsql在hive执行过程中的底层细节
- 描述了hive各组件作用
一. Hive Architecture
架构图：
如上图表达了hive的主要组件和以及与hadoop的交互：
主要的hive组件：
- UI：用户提交接口，用于用户提交查询和其他操作等。
- Driver：接收查询的组件。该组件实现了会话句柄（ing），并提供基于 JDBC/ODBC 接口的execute、 fetch APIs。
- Compiler：该组件解析查询，在不同查询块和查询表达式中做语义分析，最终借助从metastore查找的表和分区元数据生成执行计划。
- MetaStore：存储所有表、分区的结构化信息包括：列和列类型信息、读写数据所需的序列化器和反序列化器以及相关存储的hdfs文件（？）。
- Execution Engine：执行由Compiler生成的执行计划。执行计划是一个由stages组成的有向无环图，执行引擎管理stage之间的依赖关系，并让合适的组件执行对应的stage。
看下一个查询触发的hive行为
UI调用执行接口将查询发送到Driver，Driver创建了查询的session handle（会话句柄），并发送查询到Compiler来产生执行计划。Compiler从metastore中获取必要的元数据，这些元数据用于对查询树中的表达式进行类型检查，并根据查询谓词修剪分区。
compiler生成的执行计划是一系列组成DAG的stages，每一个stage可能是map/reduce任务、元数据操作或在HDFS的操作。
对于map/reduce stage，执行计划包含了map操作符树（执行在mapper上），reduce操作符树（执行在reduce上）。执行引擎提交这些stage到合适的组件上(steps 6, 6.1, 6.2 and 6.3)。
和表或中间结果相关的反序列化器用于读取HDFS文件的行，并通过相关的算子树传递这些行。当产生输出结果时，（为了防止不需要reduce，）mapper会通过序列化器将结果写出到一个HDFS临时文件，用于给下游stage提供数据。
dml和查询操作：
对于DML操作，最终的临时文件会被移到表的位置。且因为文件重命名是HDFS的原子操作，所以保证了任务不会读取脏数据。
对于查询操作，执行引擎直接从HDFS读取临时文件的内容，作为Driver fetch call的一部分。
二. Metastore
Metastore提供了数据仓库的两个重要但经常被忽视的特性:数据概述和数据发现。
- 如果没有Hive提供的数据概述，用户必须在查询的同时提供有关数据格式、提取器和加载器的信息。在Hive中，这个信息在表创建时给出，并且在每次表被引用时重用。这与传统的仓储系统非常相似。
- 数据发现，它使用户能够发现和探索仓库中的相关和特定数据。可以使用此元数据构建其他工具，以公开并可能增强有关数据及其可用性的信息。
1. Metastore Architecture
元数据是存储在数据库或文件后端的对象存储。数据库支持的存储是使用称为DataNucleus的对象关系映射(ORM)解决方案实现的。
将其存储在关系数据库中的主要动机是元数据的可查询性。但会存在同步和伸缩性的问题。
对于存储在HDFS上，因为无法对文件的随机更新，现在还没有明确的方法在HDFS上实现对象存储。这一点，再加上关系存储的可查询性优势，使我们的方法变得合理。
可以通过远程和嵌入式两种方式来配置Metastore。详情见：
https://cwiki.apache.org/confluence/display/Hive/AdminManual+Metastore+Administration
2. Metastore Interface
Metastore提供了一个Thrift接口来操作和查询Hive元数据。Thrift可以绑定到许多流行语言中。第三方工具可以通过该接口将Hive元数据集到其他业务元数据存储库中。
三. Compiler
Parser ：
将查询转换为解释树表达式
Semantic Analyser：语义分析器
将解析树表达式转换为内部查询表达式，内部查询表达式是基于块的而不是算子树（ing）。
此过程中还会执行：验证列名并展开（select）* 、类型检查和任何隐式类型转换。
如果表是分区表，则收集该表的所有表达式，以便稍后使用它们来删除不需要的分区。如果查询指定了采样，那么也将收集采样以供以后使用。
Logical Plan Generator：逻辑计划产生器：
- 转换内部查询表达式为逻辑计划，逻辑计划由算子树组成。
其中一些算子是关系代数运算符，如“过滤”、“连接”等。一些算子是Hive特有的，稍后将该计划转换为一系列map-reduce作业。比如发生在map-reduce边界的reduceSink算子。- 此过程还包括优化器转换逻辑计划以提高性能，如下:
– 将一系列join转换为单个multi-way join
– map端执行group-by部分聚合
– 分两个阶段执行group-by，以避免单个reducer因group key导致数据倾斜而成为瓶颈的情况。- 每个操作符包含一个描述符，它是一个可序列化的对象。
Query Plan Generator：查询计划产生器。
- 将逻辑计划转变为一系列的map-reduce任务。操作符树被递归地遍历，被分解成一系列map-reduce可序列化的任务，这些任务稍后提交给Hadoop分布式文件系统的map-reduce框架。
- reduceSink算子是map-reduce边界，算子描述符中包含reduction key，作为map-reduce边界。
- 如果查询中明确了samples/partitions，计划还会包含samples/partitions。
- 执行计划会被序列化写到一个文件中。
上述参考官网：hive-Design
四. hive架构小结
Hive主要由以下四个模块组成：
1.用户接口模块
用来实现对hive的访问，有CLI、HWI、JDBC、Thrift Server等
-
Cli（Command Line Interface）：即命令行操作，类似sql
-
web ui（界面基本不用）
-
通过jdbc/odbc进行连接：一般地hive连接：jdbc:hive2://(hive所在节点的)主机名:10000；
从上面的架构图可以看到，通过JDBC、ODBC连接，先会经过Thrift Server，然后再到Driver；其他通过command line和hive web interface则直接和Driver进行交互。
2.thrift server
即跨语言服务层：它将其他语言（java，c，python）转化为hive可识别的语言可以让不同的编程语言调用Hive的接口。
其中hive提供的Thrift 接口可以让用户通过JDBC连接发送HiveQL请求到thrift接口，然后交由 Driver，最后Thrift将执行结果返回客户端。
3.Driver
Hive执行的核心流程：
解释器：将Hql语句转化为抽象的语法树（提取关键字）；
编译器：将抽象语法树编译成mapreduce任务；
优化器：对编译结果进行优化（任务的合并）；
执行器：最后由 Executor 执行器进行执行。
- Meta Store
1）hive元数据可以存储在mysql中。默认元数据存储在一个自带的关系型数据库derby，但因为是单用户企业不适用。
2）hive元数据的储存内容：表数据的字段信息（字段名，字段类型，字段顺序）、表名信息表、以及和hdfs目录对应的关系。
这篇关于【hive-design】hive架构详解：描述了hive架构，hive主要组件的作用、hsql在hive执行过程中的底层细节、hive各组件作用的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
