Hive 架构

Design

目录

• Hive Architecture （Hive架构）
• Hive Data Model（Hives数据模型）
• Metastore（元数据）
  • Motivation（动因）
  • Metadata Objects （元数据对象）
  • Metastore Architecture （元数据架构）
  • Metastore Interface（元数据接口）
• Hive Query Language（Hive查询语言）
• Compiler（编译器）
• Optimizer（优化器）
• Hive APIs

Figure 1

Hive Architecture（Hive 架构）

图1显示了Hive的主要组件及其与Hadoop的交互。如该图所示，Hive的主要组件是：

• UI：用户向系统提交查询和其他操作的用户界面。
• Driver：接收查询的组件（Component）。这个组件实现了session句柄的概念，并提供了在JDBC/ODBC接口上执行和获取模型化的API。
• Compiler：解析查询的组件，对不同的查询块（query blocks）和查询表达式(query expressions)进行语义分析，最终在表(元数据表)的帮助下生成执行计划，并从Metastore中查找分区元数据。
• MetaStore：存储仓库中各种表和分区的所有结构化信息的组件，包括列和列类型信息，读取和写入数据所需的序列化程序和反序列化程序，以及存储数据的相应HDFS文件。
• Execution Engine：执行编译器创建的执行计划（execution plan）的组件。该计划是一个stage的DAG。执行引擎管理计划的这些不同stage之间的依赖关系，并在适当的系统组件上执行这些stage。

上图中显示了典型的查询如何在系统中流动（flows），UI调用Driver的执行接口（step 1）。Driver为查询创建会话句柄(session handle)，并将查询发送到Compiler以生成执行计划（step 2）。Compiler从Metastore获取必要的元数据（step 3 and 4），此元数据用于查询树中的表达式进行类型检查以及基于查询谓词修剪分区（prune partitions）。由Compiler生成的计划（step 5）是一个stage的DAG，每个stage 是一个 map/reduce job、元数据操作或一个 HDFS上的操作，对于map/reduce阶段，计划包含map运算树（在mappers上执行的运算树）和reduce运算树（用于需要reducers的操作），执行引擎(Execution engine)将这些stage提交给适当的组件（step 6，6.1，6.2和6.3），在每个Task（mapper/reducer）中与表或中间输出相关联的反序列化用于从HDFS文件中读取行，这些行通过关联的运算树传递。生成输出后，它将通过序列化程序写入临时HDFS文件（如果操作不需要reduce，则会在mapper中发生），临时文件用于向计划的后续map/reduce阶段提供数据。对于DML(Data Manipulation Language)操作，最终临时文件将移动到表的位置，此方案用于确保不读取脏数据（文件重命名是HDFS中的原子操作）。对于查询，执行引擎直接作为来自Driver的提取调用的一部分从HDFS读取临时文件内容（step 7,8和9）。

Hive Data Model（Hive 数据模型）

Hive中的数据分为：

• Table（表）：类似于关系型数据库中的表，可以进行过滤(Filtered)、投影（Projected）、关联（Joined）和联合（Unioned）。此外表的所有数据都存储在HDFS的目录中，Hive还支持外表（external table）的概念，通过为表创建DDL提供的合适位置上，可以在HDFS中现有的文件或目录上创建表。表中的 rows 被组织为类似于关系型数据库中的 columns。
• Partitions（分区）：每个表可以由一个或多个分区Key，用于确定数据的存储方式，例如具有日期分区列 ds 的表 T 具有存储在HDFS中的 <table location>/ds=\<date> 目录中的特定日期的数据的文件。分区允许根据查询谓词修剪要检查的数据，例如，对于 T 中满足判断的行感兴趣的查询T.ds = '2008-09-01'只需要在HDFS上查看<table location>/ds=2008-09-01/目录。
• Buckets（桶）：每个分区中的数据可以依次根据表中列的散列划分为桶。每个存储桶都作为文件存储在分区目录中。Bucketing允许系统有效地评估依赖于数据样本的查询（这些是在表上使用SAMPLE子句的查询）。

除了原始列类型（整数、浮点数、通用字符串、日期 和 booleans）之外，Hive还支持 array 和 map。此外用户可以从任何原语（primitives）、集合（collections）或其他用户定义的类型以编程方式组成自己的类型。typing系统与SerDe（Serailization/Deserialization）和对象检查器接口（object inspectors interfaces）密切相关。用户可以通过实现自己的对象检查器来创建自己的类型，并使用这些对象检查器，可以创建自己的SerDes来将其数据序列化和反序列化为HDFS文件。在理解其他数据格式和更丰富的类型时，这两个接口提供了必要的钩子(hooks)来扩展Hive的功能。像ListObjectInspector这样的内置对象检查器，StructObjectInspector和MapObjectInspector提供必要的原语，以可扩展的方式组成更丰富的类型。对于map和array，提供了有用的内置函数，如大小和索引运算符。点分表示法(dotted notation)用于导航嵌套类型，例如a.b.c = 1查看类型a字段的b字段的c并将其与1进行比较。

MetaStore（元数据）

Motivation（动因）

Metastore提供了数据仓库的两个重要但经常被忽视的功能：数据抽象（data abstraction）和数据发现（data discovery）。如果没有Hive中提供的数据抽象，用户必须提供有关数据格式、提取器（extractors）和加载器(loaders)的信息以及查询。在Hive中，此信息在表创建期间给出，并在每次引用表时重用。这与传统的仓储系统非常相似。第二个功能是数据发现，使用户能够发现和探查仓库中的相关和特定的数据。可以使用此元数据构建其他工具，以公开并可能增强有关数据及其可用性的信息。Hive通过提供与Hive查询处理系统紧密集成的元数据存储库来实现这两个功能，以便数据和元数据保持同步。

Metadata Objects（元数据对象）

• Databases- 是表的 namespace。它可以在将来用作管理单元（administrative unit）。数据库 ‘default’ 用于用户未提供数据库的默认名称的表。
• Table - 表的元数据包含列、所有者、存储和SerDe信息的列表。它还可以包含任何用户提供的键和值数据。存储信息包括底层数据的位置、文件输入和输出格式以及存储信息。SerDe元数据包括序列化器和反序列化器（serializer和deserializer）的实现类以及实现所需的任何支持信息。在创建表期间可以提供所有这些信息。
• Partition - 每个分区都有自己的列和SerDe和存储信息。这有助于架构更改，而不会影响旧分区。

Metastore Architecture（元数据架构）

Metastore是一个带有数据库或文件备份存储的对象存储。数据库支持的存储是使用称为DataNucleus的对象关系映射（ORM）解决方案实现的。将其存储在关系数据库中的主要目的是元数据的可查询性。使用单独的数据存储而不是使用HDFS的一些缺点是同步和可伸缩性问题。此外，由于缺少对文件的随机更新，因此没有明确的方法在HDFS之上实现对象存储。这一点，再加上关系存储的可查询性的优势，使这种方法变得合情合理。

Metastore可以配置为以两种方式使用：远程和嵌入式。在远程模式下，Metastore是Thrift服务。此模式对非Java客户端非常有用。在嵌入模式下，Hive客户端使用JDBC直接连接到底层的Metastore。此模式很有用，因为它避免了需要维护和监视的另一个系统。这两种模式都可以共存。（更新：本地Metastore是第三种可能性。有关详细信息，请参阅Hive Metastore Administration）

Metastore Interface

Metastore提供Thrift接口来操作和查询Hive元数据。Thrift提供许多流行语言的绑定。第三方工具可以使用此界面将Hive元数据集成到其他业务元数据存储库中。

Hive Query Language (Hive 查询语言)

HiveQL是Hive的类似SQL的查询语言。它主要模仿用于创建表的SQL语法，将数据加载到表中以及查询表的SQL语法。 HiveQL还允许用户嵌入他们的自定义map-reduce脚本。这些脚本可以使用简单的基于行的流接口以任何语言编写 - 从标准输入读取行并将行写出到标准输出。这种灵活性的代价是由于将行转换为字符串而导致性能损失。但是，我们已经看到用户不介意这一点，因为他们可以用他们选择的语言实现他们的脚本。 HiveQL的另一个独特功能是多表插入。在此构造中，用户可以使用单个HiveQL查询对相同的输入数据执行多个查询。 Hive优化这些查询以共享输入数据的扫描，从而将这些查询的吞吐量提高几个数量级。由于空间不足，我们省略了更多细节。有关HiveQL语言的更完整描述，请参阅语言手册。

Compiler （编译器）

• Parser （解析器）– 将查询字符串转换成解析树表示。
• Semantic Analyser（语义分析器）-将解析树转换为内部查询表示，它仍然是基于 block 而不是运算树。作为这个步骤的一部分，将验证列名并执行类似 * 的扩展，此阶段还会执行类型检查和任何隐式类型转换，如果正在考虑的表是分区表（这种是常见的情况），则会收集该表的所有表达式，以便稍后可以使用它们来修剪不需要的分区。如果查询已指定采样，则也会收集该采样以便稍后使用。
• Logical Plan Generator（逻辑计划生成器） - 将内部查询表示转换为逻辑计划，逻辑计划由运算树组成。一些运算符是关系代数运算符，如'filter', 'join'等。但是有一些运算符是特定于Hive的，后来用于将此计划转换为一系列map-reduce作业。一个这样的运算符是reduceSink运算符，它出现在map-reduce边界处。此步骤还包括优化器（Optimizer），用于转换计划以提高性能 - 其中一些转换包括：将一系列 join 转换为单个multi-way join，为分组执行映射端部分聚合，对于group-by,通过分两个阶段来避免单个reducer在存在group key的数据倾斜时成为瓶颈的情况。
• Query Plan Generator（查询计划生成器）- 将逻辑计划转换为一系列map-reduce任务。递归遍历运算树，将其分解为一系列map-reduce可序列化Task，这些Task稍后可以提交到Hadoop分布式文件系统的map-reduce框架。reduceSink运算符是map-reduce边界，其描述符包含reduction key。如果查询指定了，则计划包含所需的samples/partitions。该计划已序列化并写入文件。

(具体理解可以参考下面我整理的一张图)

Optimizer （优化器）

优化程序执行更多计划转换。 优化器是一个不断发展的组件。 截至2011年，它基于规则并执行以下操作：列修剪和谓词下推(predicate pushdown)。 但是，基础设施已经到位，正在进行的工作包括其他优化，例如map-side join。 （Hive 0.11添加了几个join optimizations）

优化器可以增强为基于成本的（参见Cost-based optimization in Hive 和HIVE-5775）。 输出表的排序特性也可以保留并在以后用于生成更好的计划。 可以对少量数据样本执行查询以猜测数据分布，这可以用于生成更好的计划。

在Hive 0.12中添加了correlation optimizer（关联优化器）。

该计划是通用运算树，并且可以轻松操作。

Hive APIs

Hive API概述描述了Hive提供的各种面向公共的API。