【hive-design】hive架构详解：描述了hive架构，hive主要组件的作用、hsql在hive执行过程中的底层细节、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：接收查询的组件。该组件实现了会话句柄（in g），并提供基于 JDBC/ODBC 接口的execute、 fetch APIs。

Com piler：该组件解析查询，在不同查询块和查询表达式中做语义分析，最终借助从meta store 查找的表和分区元数据生成执行计划。

MetaStore：存储所有表、分区的结构化信息包括：列和列类型信息、读写数据所需的序列化器和反序列化器以及相关存储的hdfs 文件（？）。

Execut ion Engine：执行由Com piler生成的执行计划。执行计划是一个由sta g es组成的有向无环图，执行引擎管理stage之间的依赖关系，并让合适的组件执行对应的stage。

看下一个查询触发的hive行为

UI调用执行接口将查询发送到Driver，Driver创建了查询的session handle（会话句柄），并发送查询到Com piler来产生执行计划。Com piler从meta store中获取必要的元数据，这些元数据用于对查询树中的表达式进行类型检查，并根据查询谓词修剪分区。

com piler生成的执行计划是一系列组成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+Admini stration

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。

执行计划会被序列化写到一个文件中。