目录
Hive 架构图
Hive 架构
图1显示了Hive的主要组件及其与Hadoop的交互。如图所示，Hive的主要组件为:
用户界面——用户向系统提交查询和其他操作的用户界面。截至2011年，该系统有一个命令行界面和一个基于web的GUI正在开发中。
驱动程序——接收查询的组件。该组件实现了会话句柄的概念，并提供了基于JDBC/ODBC接口建模的执行和获取api。
编译器——解析查询的组件，对不同的查询块和查询表达式进行语义分析，最终在从metastore查找的表和分区元数据的帮助下生成执行计划。
Metastore——存储仓库中各种表和分区的所有结构信息的组件，包括列和列类型信息、读写数据所需的序列化器和反序列化器，以及存储数据的相应HDFS文件。
Hive数据模型
Hive中的数据组织为:
表——这些表类似于关系数据库中的表。表可以过滤、投影、连接和统一。此外，表的所有数据都存储在HDFS中的目录中。Hive还支持外部表的概念，通过为表创建DDL提供适当的位置，可以在HDFS中的prexisting文件或目录上创建表。表中的行组织成类型化列，类似于关系数据库。
分区——每个表可以有一个或多个分区键，这些键决定数据的存储方式，例如，具有日期分区列ds的表T具有存储在HDFS中的< Table location>/ds=<date>目录中的特定日期的数据文件。分区允许系统根据查询谓词(例如，对满足谓词T的行感兴趣的查询)删除要检查的数据。只需要查看HDFS中<table location>/ds=2008-09-01/目录中的文件。
桶——每个分区中的数据可以根据表中列的哈希值被分成桶。每个bucket都作为一个文件存储在分区目录中。分段允许系统有效地评估依赖于数据样本的查询(这些查询使用表上的sample子句)。
除了基本列类型(整数、浮点数、泛型字符串、日期和布尔值)之外，Hive还支持数组和映射。此外，用户可以通过编程从任何基本类型、集合或其他用户定义的类型组合自己的类型。类型系统与SerDe (Serailization/Deserialization)和对象检查器接口紧密相关。用户可以通过实现自己的对象检查器来创建自己的类型，使用这些对象检查器，他们可以创建自己的SerDes来将数据序列化和反序列化到HDFS文件中)。当涉及到理解其他数据格式和更丰富的类型时，这两个接口提供了必要的挂钩来扩展Hive的功能。像ListObjectInspector、StructObjectInspector和MapObjectInspector这样的内置对象检查器提供了必要的原语，以可扩展的方式组合更丰富的类型。对于映射(关联数组)和数组，提供了有用的内置函数，如大小和索引操作符。点符号用于导航嵌套类型，例如a.b.c = 1查看类型a的字段b的字段c，并将其与1进行比较。
Metastore
动机-设计目标
Metastore 提供了数据仓库的两个重要但常常被忽略的特性:数据抽象和数据发现。如果没有Hive中提供的数据抽象，用户必须提供关于数据格式、提取器和加载器以及查询的信息。在Hive中，这些信息在表创建期间给出，并且在每次引用表时重用。这与传统的仓储系统非常相似。第二个功能，数据发现，使用户能够发现和探索仓库中相关和特定的数据。可以使用此元数据构建其他工具，以公开和增强关于数据及其可用性的信息。Hive通过提供与Hive查询处理系统紧密集成的元数据存储库来实现这两个特性，以便数据和元数据保持同步。
元数据对象
数据库——是表的名称空间。它在未来可以作为一个行政单位使用。数据库'default'用于没有用户提供数据库名称的表。
表的元数据包含列、所有者、存储和SerDe信息的列表。它还可以包含任何用户提供的键和值数据。存储信息包括底层数据的位置、文件inout和输出格式以及存储信息。SerDe元数据包括序列化器和反序列化器的实现类以及实现所需的任何支持信息。所有这些信息都可以在表的创建过程中提供。
分区——每个分区可以有自己的列、SerDe和存储信息。这可以在不影响旧分区的情况下促进模式更改。
Metastore架构
Metastore是一个具有数据库或文件备份存储的对象存储。数据库支持的存储是使用名为DataNucleus的对象关系映射(ORM)解决方案实现的。将其存储在关系数据库中的主要动机是元数据的可查询性。为元数据使用单独的数据存储而不是使用HDFS的一些缺点是同步和可伸缩性问题。此外，由于缺少对文件的随机更新，没有明确的方法在HDFS上实现对象存储。这一点，加上关系存储的可查询性的优点，使我们的方法成为一种明智的方法。
可以将metastore配置为以两种方式使用:远程和嵌入式。在远程模式下，metastore是一个Thrift接口服务。这种模式对于非java客户机非常有用。在嵌入式模式下，Hive客户机使用JDBC直接连接到底层的metastore。这种模式很有用，因为它避免了需要维护和监视的其他系统。这两种模式都可以共存。(更新:局部转移是第三种可能性。详情请参见Hive Metastore Administration。)
Metastore Interface
Metastore提供了一个Thrift接口来操作和查询Hive元数据。Thrift在许多流行的语言中提供绑定。第三方工具可以使用此接口将Hive元数据集成到其他业务元数据存储库中。
Hive Query Language
HiveQL是Hive的一种类似sql的查询语言。它主要模仿SQL语法来创建表，将数据加载到表中并查询表。HiveQL还允许用户嵌入定制的map-reduce脚本。这些脚本可以用任何语言编写，使用简单的基于行的流接口——从标准输入读取行，然后将行写到标准输出。这种灵活性的代价是由于将行与字符串转换而导致性能下降。但是，我们看到用户并不介意这一点，因为他们可以用自己选择的语言实现脚本。HiveQL的另一个独特特性是多表插入。在这个结构中，用户可以使用一个HiveQL查询对相同的输入数据执行多个查询。Hive优化这些查询以共享输入数据的扫描，从而将这些查询的吞吐量提高几个数量级。由于篇幅不够，我们省略了更多的细节。有关HiveQL语言的更完整描述，请参阅语言手册。
Compiler
解析器——将查询字符串转换为解析树表示。
语义分析器——将解析树转换为内部查询表示，它仍然是基于块的，而不是操作符树。作为该步骤的一部分，验证列名并执行*之类的展开。在此阶段还将执行类型检查和任何隐式类型转换。如果考虑的表是分区表(这是常见的场景)，则收集该表的所有表达式，以便稍后使用它们来修剪不需要的分区。如果查询指定了抽样，那么也会收集抽样，以便以后使用。
逻辑计划生成器——将内部查询表示转换为逻辑计划，其中包含一个操作符树。其中一些运算符是关系代数运算符，如“filter”、“join”等。但有些操作符是特定于Hive的，稍后将使用它们将该计划转换为一系列map-reduce作业。其中一个操作符是发生在map-reduce边界上的reduceSink操作符。这一步还包括优化器将计划来提高性能,其中的一些转换包括:一系列的连接转换成一个多路连接,执行一个group by map-side部分聚合,执行一个group by 2阶段避免场景中当一个减速器可以成为瓶颈的存在扭曲数据分组的关键。每个操作符包含一个描述符，描述符是一个可序列化的对象。
查询计划生成器——将逻辑计划转换为一系列map-reduce任务。操作符树被递归遍历，分解为一系列map-reduce序列化任务，这些任务稍后可以提交给Hadoop分布式文件系统的map-reduce框架。reduceSink操作符是map-reduce边界，其描述符包含约简键。reduceSink描述符中的约简键用作map-reduce边界中的约简键。如果查询指定了计划，则计划由所需的示例/分区组成。计划被序列化并写入文件。
Optimizer
优化器将执行更多的计划转换。优化器是一个不断发展的组件。截至2011年，它是基于规则的，执行了以下操作:列修剪和谓词下推。但是，基础设施已经就绪，并且正在进行包括其他优化的工作，比如map-side join。(Hive 0.11增加了几个连接优化。)
优化器可以增强为基于成本的(参见Hive和Hive -5775中的基于成本的优化)。还可以保留输出表的排序性质，并在以后用于生成更好的计划。该查询可以对小样本数据执行，猜测数据分布情况，从而生成更好的计划。
在Hive 0.12中添加了一个相关优化器。
该计划是一个通用的操作符树，可以很容易地操作。
Hive APIs
Hive api概述描述了Hive提供的各种面向公众的api。
原文：