Hive已为Hadoop带来实时查询机制

译文
数据库 Hadoop
Hive是一种“类SQL”查询语言,它对大规模数据集处理速度的显著提升使其成为企业级数据仓库的最佳合作伙伴。

【51CTO外电头条】Apache Hive是一款以Hadoop为基础打造而成的工具,其专长在于利用类SQL语法对大规模非结构化数据集进行分析,从而帮助现有商务智能及企业分析研究人员对Hadoop内容进行访问。作为由Facebook工程师们开发、受到Apache基金会认可并贡献的开源项目,Hive目前已经在商用环境下的大数据分析领域取得了领先地位。

与Hadoop生态系统中的其它组成部分一样,Hive的发展速度同样非常迅猛。在今天的评测文章中,我们将以0.13为目标——该版本解决了其它前续版本中的一些缺陷。0.13版本还显著提升了类SQL查询在多个大规模Hadoop集群之间的处理速度,并针对前续版本中的交互查询机制添加了多项全新功能。 从本质上讲,Hive其实是一套事务型数据存储体系,同时也适用于规模巨大、对查询速度要求不高的相对静态数据集进行分析Hive对现有数据仓库方案作出了很好的补充,但并不属于完整的替代性机制。相反,利用Hive辅助数据仓库能够充分发挥现有投资成果的实际效能,同时又不会对数据容纳能力造成影响。 典型的数据仓库方案包含有众多昂贵的硬件与软件组件,例如RAID或者SAN存储、用于简化及插入数据的优化型ETL(即提取、转换与加载)规程、面向ERP或者其它后端系统的特定连接机制外加面向地理位置、产品或者销售渠道等企业常见销售事务所设计的规划方案。这类仓库体系通过优化为CPU带来丰富的数据内容,从而为规划方案中预设的各类运营问题找到答案。

相比之下,Hive数据存储机制将大量非结构化数据整合到了一起——其中包括日志文件、客户推文、电子邮件信息、地理数据以及CRM交互等——并将它们以非结构化格式保存在成本低廉的商用硬件之上。Hive允许分析师们以这些数据为基础构建类似于数据库的项目结构,引入与传统表、列以及行相仿的机制并针对其编写类SQL查询。这意味着用户完全可以根据查询特性在同一套数据集之上采用不同类型的处理规划,从而透过收集到的数据找出关键性运营问题的确切答案。

过去,Hive查询一直存在比较严重的延迟状况,即使是涉及数据量不大的小型查询也需要耗费相当长的一段时间——这是因为查询需要首先被转化为映射-归约作业,而后才能提交给集群并以批量方式得到执行。这种延迟一般不至于造成什么问题,因为早在查询规划与映射-归约机制起效之前、查询本身就会对整个处理周期的时耗作出预判——至少在运行Hive设计思路所指向的大规模数据集时是如此。

不过用户们很快发现,这类运行周期过长的查询流程在多用户环境下会造成严重的不便甚至麻烦,因为在这种状况下单一作业有可能成为整体集群的首要完成目标。 为了解决这一难题,Hive社区组织起新一轮努力(也被称为‘毒刺’项目)以改善查询处理速度,其目标是让Hive有能力适应实时、交互式查询与探索性操作的需求。这部分改进成效在Hive 0.11、0.12以及0.13三个版本中开始陆续出现。

***,尽管HiveQL查询语言以SQL-92为基础,但它仍然与SQL之间存在一系列重大差别——原因很简单,前者运行在Hadoop基础之上。举例来说,DDL(即数据定义语言)命令需要考虑到表中现有多用户文件系统能够支持多种存储格式这一客观现实。不过总体而言,SQL用户在使用HiveQL语言时能够获得理想的熟悉之感,而且在适应过程中应该不会遇到任何障碍。 Hive平台架构 从上到下,Hive的平台架构看起来与任何其它关系型数据库并没有什么不同。用户编写SQL查询并将其提交至处理流程,且可以使用与数据库引擎直接交互的命令行工具或者通过JDBC或ODBC与数据库进行通信的第三方工具。Hive的具体架构如下图所示:

Hive平台架构示意图。

通过Mac及Windows系统下的JDBC以及ODBC驱动程序,数据工作人员们可以将自己喜爱的SQL客户端与Hive相对接,从而对表进行浏览、查询以及创建。对于资深用户而言,Hive也提供原始的胖客户端CLI、能够与Hive驱动程序直接交互。这套客户端最为强大且要求与Hadoop直接对接,因此特别适合处理本地网络执行事务——防火墙、DNS以及网络拓朴结构都将不是问题。

Hive元存储机制HCatalog原本曾经作为独立的Hadoop项目存在,如今则成为Hive发行版当中的组成部分。在其自有关系型数据库的支持之下,HCatalog能够免去在Hive当中定义规划的步骤、简化新查询同时使此类规划能够为Hadoop工具链中的其它工具——例如Pig——所用。

#p#

Hive上手指南

正如前面所提到,Hive使用的是名为HiveQL的简化版类SQL语言,其支持数据定义与操作语句。任何一位SQL用户都能在使用Hive时拥有熟悉的使用体验。HiveQL在设计思路上尽量简化了由SQL向其过渡的过程,并能够直接让数据分析机制建立并运行在Hadoop之上。

大多数商务智能与SQL开发者工具都能轻松与Hive对接,正如与其它任何数据库相对接一样。在ODBC连接机制的辅助下,用户可以将导入数据并利用PowerPivot for Excel等工具探索并分析数据,进而帮助企业了解到蕴藏在大数据当中的宝贵价值。

HiveQL与标准SQL之间也存在着多项显著区别。Hive 0.13在设计思路上需要利用YARN以及Tez架构对PB级别的数据集进行全表扫描,因此关系型数据库当中的一部分常见功能在Hive当中已经不复存在。缺乏的特性包括事务处理、光标、编报表、行级更新与删除以及对运行中的查询加以撤销等等。

虽然这些功能的缺失不会对数据分析产生影响,但却有可能影响到我们在Hive集群上对现有SQL查询加以使用的能力。查询命令的编写方式可能与其它支持完整SQL语言的引擎有所区别,但经验丰富的传统数据库用户应该不至于在编写Hive查询时遇到阻碍。很多传统SQL编辑环境现在已经可以通过连接机制支持Hive,而Hive表也能够利用多数SQL编辑器实现访问,其中包括甲骨文及微软推出的相关工具。

数据库用户在使用Hive时面临的主要差异在于对存储细节的识别层面。在传统数据库环境当中,数据库引擎控制着指向数据库的全部读取与写入操作。但在Hive方面,数据库表以文件形式被保存在Hadoop分布式文件系统(简称HDFS)当中,而其它应用程序也可以对其加以修改。不过这在某种意义上也算是好事,这意味着Hive会强制要求数据与现有规划的读取机制相匹配,也就是说Hive会针对读取操作对规划加以修改。如果底层数据格式发生变化,Hive将尽力弥合这种差异,但用户也可能因此面对意料之外的调整结果。

Hive用户必须了解数据存储的两大要素:文件格式与压缩机制。经过调整的Hive查询能够对数据库表中的数字、类以及文件作出优化,从而让底层映射-归约作业以更富效率的方式执行。Hive以文本作为默认存储格式,其优势在于能够更轻松地为其它工具所使用。不过作为弊端,我们很难在查询中对于原始文本文件作出优化。

Hive能够读取并写入多种文件格式,并在运行过程中对相关内容进行压缩。不同的文件格式可能给存储要求与查询效率带来巨大影响,大家可以通过以下图表进一步加以了解(由Hortonworks提供)。文件格式属于Hadoop社区的一大研究重点。高效的文件格式既能够降低存储成本,也可以提高查询效率。

HDFS上的文件格式与文件大小。(图表由Hortonworks提供)

大规模数据集的处理流程往往需要分为几步进行,而HiveQL当中包含多种语言结构、用于指定ETL流程。通常情况下,根据具体问题的实际要求,一项作业通常需要保存临时表,而将TB级别的数据移动至HDFS当中显然不切实际。Hive提供三种UDF(即用户定义函数),能够在查询当中被用于完成处理流程定制。由于它们作为Hive查询的组成部分运行而且能够与数据直接对接,因此其执行效率更高且能够消除流程内的中间步骤。UDF必须利用Java语言来编写,因此SQL程序员们可能会面临一些难题——不过Hive工具包的出现在一定程度上消除了此类障碍。如果没有这三种UDF,特定类型的问题将变得更难于解决。

Hive查询性能

Hive 0.13属于毒刺项目(即技术社区为改进Hive性能所构建的项目)的***一部分,而且很明显相关努力收到了不错的成效。我在0.11到0.13版本当中对多项速度参数进行了测试,并实际感受到了版本提升给处理效率带来的改善。其中最引人注目的特性是0.13版本在全新Tez执行框架上运行查询的能力。

在我的测试当中,我发现在引入Tez之后、查询次数与原先相比缩减了一半,而且查询时耗在缓存机制的辅助下也降低了30%。在大规模数据集方面,其速度提升效果变得更为显著。使用在0.11版本中引入的ORC(即优化行列)文件格式时,查询次数降低了约15%。微软专为Hive 0.13打造的Vectorization则进一步将速度提高约10%。0.13版本中的另一项新功能——基于成本的查询优化机制——也能够实现20%效率改进。

需要指出的是,这些测试全部运行在我自己的笔记本设备上、处理对象为小型数据集、使用临时性查询,因此其结果可能无法准确反映Hive 0.13在真实使用环境下的性能水平。很明显,性能调整工具包中的每一项功能特性都具备显著的价值,其在大规模查询作业中将发挥重要的实际作用。

未来几年中,需要收集并加以分析的数据总量当然不可能有所减少。而企业级数据仓库业务中最常用的度量单位——每TB成本——也只会变得更加重要。虽然这种衡量指标易于计算也方便理解,但与大多数简便指标一样、它也会让买家对整体架构的复杂性缺乏足够的理解。无论如何,几乎所有从业人士都认为Hive的数据存储成本要远低于传统数据仓库方案——只相当于后者的1%甚至更低。

传统数据仓库方案的用户们应该认真评估利用Hadoop进行非结构化分析数据存储的可能性,并考虑能否将其引入数据仓库体系。在Hive的帮助下,我们有能力执行PB级别查询,从而定义并简化数据内容并为日后引入数据仓库分析作好准备。Hadoop与Hive也可以在逆向场景中发挥作用:将原本需要保存在数据仓库中的汇总数据分离出来,从而显著降低存储成本。***,Hive能够对非结构化数据进行实验性分析,并在确认其实际价值后再将内容保存在数据仓库当中。

尚未部署数据仓库方案的企业或者技术部门也可以将Hive作为起点,从而在感受数据分析价值的同时将前期投入成本控制在***程度。虽然Hive并不能提供一套完整的数据仓库解决方案,但它确实带来一套具备多种分析工具的优秀、低成本、大规模、可操作型数据存储机制。如果分析师们对于Hive的表现感到满意,那么众多传统数据仓库供应商也将提供相关连接机制与工具、保证用户可以将数据引入数据仓库当中以保护原有资产投入。

在实际运营层面,以数据与分析为基础制定出准确决策的企业将拥有显著的竞争优势。Hive在查询流程方面提供近线性可扩展能力,且拥有比传统企业级数据仓库高出一个量级的卓越性能与性价比,此外其入门门槛也比后者低得多。目前10TB级别的企业数据仓库解决方案大约需要100万美元启动费用,相比之下善于管理大规模非结构化数据集的Hive可谓潜力无限。

原文链接:

http://www.infoworld.com/d/big-data/review-apache-hive-brings-real-time-queries-hadoop-246607

原文标题:Review: Apache Hive brings real-time queries to Hadoop

责任编辑:彭凡 来源: 51CTO
相关推荐

2013-12-19 10:06:18

英特尔Hadoop

2017-03-13 09:50:00

HadoopHive

2012-10-29 09:55:52

HadoopImpalaDremel

2013-12-03 10:20:35

开源SQL查询系统

2017-10-19 15:34:52

Hadoop技术机制学习

2015-03-17 11:09:33

Hadoop大数据数据开源工具

2016-11-09 14:31:36

Hadoop2.6Hive

2012-07-03 10:57:54

Hadoop核心机制

2018-09-18 15:21:47

Hive数据仓库程序

2012-05-31 02:54:07

HadoopJava

2013-11-12 09:04:33

SDN网络平台

2010-10-13 16:44:10

MySQL查询缓存机制

2017-10-23 14:14:26

HadoopHadoop HAQJM

2019-10-31 09:52:02

HadoopJava大数据

2023-05-08 00:08:51

Hive机制场景

2015-06-17 11:27:47

Hadoop集群管理安全机制

2013-10-21 09:31:11

OpenStackIPv6IPv4

2010-11-25 09:37:14

MySQL查询缓存机制

2013-07-24 09:33:46

Hadoop安全加密

2020-04-17 14:23:12

HiveHadoop数据
点赞
收藏

51CTO技术栈公众号