赞
踩
Figure 1
图1显示了Hive的主要组件及其与Hadoop的交互。如该图所示,Hive的主要组件是:
上图中显示了典型的查询如何在系统中流动(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中的数据分为:
<table location>/ds=\<date>
目录中的特定日期的数据的文件。分区允许根据查询谓词修剪要检查的数据,例如,对于 T 中满足判断的行感兴趣的查询T.ds = '2008-09-01'
只需要在HDFS上查看<table location>/ds=2008-09-01/
目录。除了原始列类型(整数、浮点数、通用字符串、日期 和 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提供了数据仓库的两个重要但经常被忽视的功能:数据抽象(data abstraction)和数据发现(data discovery)。如果没有Hive中提供的数据抽象,用户必须提供有关数据格式、提取器(extractors)和加载器(loaders)的信息以及查询。在Hive中,此信息在表创建期间给出,并在每次引用表时重用。这与传统的仓储系统非常相似。第二个功能是数据发现,使用户能够发现和探查仓库中的相关和特定的数据。可以使用此元数据构建其他工具,以公开并可能增强有关数据及其可用性的信息。Hive通过提供与Hive查询处理系统紧密集成的元数据存储库来实现这两个功能,以便数据和元数据保持同步。
Metastore是一个带有数据库或文件备份存储的对象存储。数据库支持的存储是使用称为DataNucleus的对象关系映射(ORM)解决方案实现的。将其存储在关系数据库中的主要目的是元数据的可查询性。使用单独的数据存储而不是使用HDFS的一些缺点是同步和可伸缩性问题。此外,由于缺少对文件的随机更新,因此没有明确的方法在HDFS之上实现对象存储。这一点,再加上关系存储的可查询性的优势,使这种方法变得合情合理。
Metastore可以配置为以两种方式使用:远程和嵌入式。在远程模式下,Metastore是Thrift服务。此模式对非Java客户端非常有用。在嵌入模式下,Hive客户端使用JDBC直接连接到底层的Metastore。此模式很有用,因为它避免了需要维护和监视的另一个系统。这两种模式都可以共存。(更新:本地Metastore是第三种可能性。有关详细信息,请参阅Hive Metastore Administration)
Metastore提供Thrift接口来操作和查询Hive元数据。Thrift提供许多流行语言的绑定。第三方工具可以使用此界面将Hive元数据集成到其他业务元数据存储库中。
HiveQL是Hive的类似SQL的查询语言。它主要模仿用于创建表的SQL语法,将数据加载到表中以及查询表的SQL语法。 HiveQL还允许用户嵌入他们的自定义map-reduce脚本。这些脚本可以使用简单的基于行的流接口以任何语言编写 - 从标准输入读取行并将行写出到标准输出。这种灵活性的代价是由于将行转换为字符串而导致性能损失。但是,我们已经看到用户不介意这一点,因为他们可以用他们选择的语言实现他们的脚本。 HiveQL的另一个独特功能是多表插入。在此构造中,用户可以使用单个HiveQL查询对相同的输入数据执行多个查询。 Hive优化这些查询以共享输入数据的扫描,从而将这些查询的吞吐量提高几个数量级。由于空间不足,我们省略了更多细节。有关HiveQL语言的更完整描述,请参阅语言手册。
*
的扩展,此阶段还会执行类型检查和任何隐式类型转换,如果正在考虑的表是分区表(这种是常见的情况),则会收集该表的所有表达式,以便稍后可以使用它们来修剪不需要的分区。如果查询已指定采样,则也会收集该采样以便稍后使用。'filter'
, 'join'
等。但是有一些运算符是特定于Hive的,后来用于将此计划转换为一系列map-reduce作业。一个这样的运算符是reduceSink运算符,它出现在map-reduce边界处。此步骤还包括优化器(Optimizer),用于转换计划以提高性能 - 其中一些转换包括:将一系列 join 转换为单个multi-way join,为分组执行映射端部分聚合,对于group-by,通过分两个阶段来避免单个reducer在存在group key的数据倾斜时成为瓶颈的情况。(具体理解可以参考下面我整理的一张图)
优化程序执行更多计划转换。 优化器是一个不断发展的组件。 截至2011年,它基于规则并执行以下操作:列修剪和谓词下推(predicate pushdown)。 但是,基础设施已经到位,正在进行的工作包括其他优化,例如map-side join。 (Hive 0.11添加了几个join optimizations)
优化器可以增强为基于成本的(参见Cost-based optimization in Hive 和HIVE-5775)。 输出表的排序特性也可以保留并在以后用于生成更好的计划。 可以对少量数据样本执行查询以猜测数据分布,这可以用于生成更好的计划。
在Hive 0.12中添加了correlation optimizer(关联优化器)。
该计划是通用运算树,并且可以轻松操作。
Hive API概述描述了Hive提供的各种面向公共的API。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。