从数据仓库系统对比看Hive发展前景

标签: 云计算 Hive 数据仓库 | 发表时间:2012-05-30 11:07 | 作者:yangshuang
出处:http://www.programmer.com.cn

文 / 杨栋

大数据时代的信息爆炸,使得分布式/并行处理变得如此重要。无论是传统行业,还是新兴行业(特别是互联网行业),日常业务运行所产生的海量用户和服务数据都需要更大的硬件资源来处理。需要并行处理的应用领域主要为网页搜索、广告投放和机器翻译等。从单机应用到集群应用的过渡中,诞生了MapReduce这样的分布式框架,简化了并行程序的开发,提供了水平扩展和容错能力。

虽然MapReduce(Hadoop)的应用非常广泛,但这类框架暴露出来的编程接口仍然比较低级,编写复杂处理程序或Ad-hoc查询仍然十分耗时,并且代码很难复用。目前,Google、Facebook和微软等公司都在底层分布式计算框架之上又提供更高层次的编程模型,将开发者不关心的细节封装起来,提供了更简洁的编程接口。

目前应用最广泛的当属Facebook开源贡献的Hive。Hive是一个基于Hadoop的数据仓库平台,通过Hive,可以方便地进行数据提取转化加载(ETL)的工作。Hive定义了一个类似于SQL的查询语言HQL,能够将用户编写的SQL转化为相应的MapReduce程序。当然,用户也可以自定义Mapper和Reducer来完成复杂的分析工作。从2010年下半年开始,Hive成为Apache顶级项目。

基于MapReduce的Hive具有良好的扩展性和容错性。不过由于MapReduce缺乏结构化数据分析中有价值的特性,以及Hive缺乏对执行计划的充分优化,导致Hive在很多场景下比并行数据仓库慢(在几十台机器的小规模下可能相差更大),Hive的架构如图1所示。

图1 Hive架构图

强大的数据仓库和数据分析平台至少需要具备以下几点特性。

  • 灵活的存储引擎
  • 高效的执行引擎
  • 良好的可扩展性
  • 强大的容错机制
  • 多样化的可视化

本文将简要阐述Hive是否完全具备了以上几点,以及与传统的并行数据仓库对比优劣如何。

存储引擎

Hive没有自己专门的数据存储格式,也没有为数据建立索引,用户可以非常自由地组织Hive中的表,只要在创建表时告诉Hive数据中的列分隔符和行分隔符,Hive就可以解析数据。Hive的元数据存储在RDBMS中,所有数据都基于HDFS存储。Hive包含Table、External Table、Partition和Bucket等数据模型。

并行数据仓库需要先把数据装载到数据库中,按特定的格式存储,然后才能执行查询。每天需要花费几个小时来将数据导入并行数据库中,而且随着数据量的增长和新的数据源加入,导入时间会越来越长。导入时大量的写I/O与用户查询的读I/O产生竞争,会导致查询的性能很差。

Hive执行查询前无需导入数据,执行计划直接执行。Hive支持默认的多种文件格式,同时也可以通过实现MapReduce的InputFormat或OutputFormat类,由用户定制格式。因为公司的数据种类很多,存储于不同的数据源系统,可能是MySQL、HDFS或者Hypertable等,很多时候Hive的分析过程会用到各种数据源的数据。当然使用多个存储数据源,除了功能上要能够支持导入/导出之外,如何根据各种存储源的能力和执行流获得最优执行计划也是件麻烦事儿。

执行引擎

并行数据仓库使用优化器。在生成执行计划时,利用元数据信息估算执行流上各个算子要处理的数据量和处理开销,进而选取最优的执行计划。并行数据仓库实现了各种执行算子(Sort、GroupBy、Union和Filter等),它的执行优化器可以灵活地选择这多个算子的不同实现。此外,并行数据仓库还拥有完备的索引机制,包括磁盘布局、缓存管理和I/O管理等多个层面的优化,这些都对查询性能至关重要。而这恰恰是Hive的不足之处。

Hive的编译器负责编译源代码并生成最终的执行计划,包括语法分析、语义分析、目标代码生成,所做的优化并不多。Hive基于MapReduce,Hive的Sort和GroupBy都依赖MapReduce。而MapReduce相当于固化了执行算子,Map的MergeSort必须执行,GroupBy算子也只有一种模式,Reduce的Merge-Sort也必须可选。另外Hive对Join算子的支持也较少。另外,内存拷贝和数据预处理也会影响Hive的执行效率。当然,数据预处理可能会影响数据的导入效率,这需要根据应用特点进行权衡。

扩展性

并行数据仓库可以很好地扩展到几十或上百个节点的集群,并且达到接近线性的加速比。然而,今天的大数据分析需要的可扩展性远远超过这个数量,经常需要达到数百甚至上千节点。目前,几乎没有哪个并行数据仓库运行在这么大规模的集群上,这涉及多个方面的原因。并行数据仓库假设底层集群节点完全同构;并行数据仓库认为节点故障是很少出现的;并行数据仓库设计和实现基于的数据量并未达到PB级或者EB级。

与并行数据仓库不同的是,Hive更加关注水平扩展性。简单来讲,水平扩展性指系统可以通过简单的增加资源来支持更大的数据量和负载。

Hive处理的数据量是PB级的,而且每小时每天都在增长,这就使得水平扩展性成为一个非常重要的指标。Hadoop系统的水平扩展性是非常好的,而Hive基MapReduce框架,因此能够很自然地利用这点。

容错性

Hive有较好的容错性。Hive的执行计划在MapReduce框架上以作业的方式执行,每个作业的中间结果文件写到本地磁盘,最终输出文件写到HDFS文件系统,利用HDFS的多副本机制来保证数据的可靠性,从而达到作业的容错性。如果在作业执行过程中某节点出现故障,那么Hive执行计划基本不会受到影响。因此,基于Hive实现的数据仓库可以部署在由普通机器构建的分布式集群之上。

如果当某个执行计划在并行数据仓库上运行时,某节点发生故障,那么必须重新执行该计划。所以,当集群中的单点故障(可能是磁盘故障等)发生率较高时,并行数据仓库的性能就会下降。在实际生产环境中,假设每个节点故障发生率是0.01%,那么1000个节点的集群中,单点故障发生率则为10%。这个数字并不是耸人听闻的,处理海量数据的I/O密集型应用集群,平均每月的机器故障率达到1%~10%。当然这些机器可能是2~3万元的普通机型。

可视化

Hive的可视化界面基本属于字符终端,用户的技术水平一般比较高。面向不同的应用和用户,提供个性化的可视化展现,是Hive改进的一个重要方向。个性化的可视化也可以理解为用户群体的分层,例如,图形界面方式提供初级用户,简单语言方式提供中级用户,复杂程序方式提供高级用户。

相关系统

除了Hive,近年来业界系统也诞生了其他各种类型的数据仓库,像Google的Tenzing、Dremel、微软的DryadLINQ、Hadapt的HadoopDB等。Tenzing和DryadLINQ在框架分层上类似于Hive,Dremel除了语言层还实现了计算执行层,而HadoopDB的目标是结合并行数据仓库和Hadoop的优点。

Tenzing的目标是支持Google对数据的Ad-hoc分析,当然之前的分析都是基于传统的关系数据库的。Tenzing在性能方面做了大量优化,包括编译优化以及对MapReduce本身的增强等,这些都使得Tenzing的性能在很多方面接近甚至超过了并行数据仓库。另外,基于LLVM的Tenzing执行引擎可以将单点执行性能提升10倍左右。

DryadLINQ的目标是对并行程序的开发进行抽象,使其和单机开发一样。与Hive不同的是,DryadLINQ并不是一种全新的语言,它将特定语法直接集成到宿主语言(C#等高级语言),充分利用宿主语言的抽象和组合等编程语言机制。与Tenzing类似,DryadLINQ的扩展性和可用性都依赖于底层的执行系统Dryad。

Dremel是Google用于满足交互式查询的系统,主要目标是执行一次性的、结果数据较小的聚合运算,不支持join、update等复杂算子。与Tenzing和DryadLINQ不同,Dremel没有基于MapReduce或Dryad之类的底层计算框架,它实现了一个树状的执行层,这个执行层管理节点的失效或竞争,包括优先级等,与MapReduce的实现机制相似。Dremel的底层存储系统是GFS,基本概念是按列分割数据,把树形结构的数据按列分割。

HadoopDB希望整合并行数据仓库和Hadoop用于大数据分析,这既能保证高性能,又能提供可扩展和高可用能力。HadoopDB的基本思想是在节点上运行并行数据库实例,MapReduce作为这些节点的执行层,尽可能地将执行计划放到并行数据库中完成,利用其已有的优化技术。当然,这会牺牲一部分导入数据的性能,导入数据时会执行一部分表的布局和重组。

总结

作为互联网领域应用最为广泛的开源数据仓库,Hive是份免费的午餐,尤其它在扩展性和容错性方面有强大的优势,其前景被大家一致看好。不过对比传统并行数据仓库,Hive在存储引擎支持、执行引擎高效化以及多样化接口等方面,还有很多工作要做。此外,业界的其他数据仓库,像新兴的Tenzing、DryadLINQ、Dremel或HadoopDB等,都有Hive值得借鉴的地方,Hive原有的实现也还有很大的优化空间。

Hive的诞生带动了Hadoop开源栈系统的进一步发展,也使得很多公司能够从零开始快速搭建数据仓库系统,推动了整个产业链的进步。真心地希望Hive能够继续成长,不断演进,成为全面而强大的通用数据仓库标准。

作者杨栋,百度分布式高级研发工程师,从事Hypertable、Hadoop及流式计算的研究和开发。

本文选自《程序员》杂志2012年05期,未经允许不得转载。如需转载请联系 [email protected]

《程序员》2012年杂志订阅送好礼活动火热进行中

相关 [数据仓库 系统 hive] 推荐:

从数据仓库系统对比看Hive发展前景

- - 技术改变世界 创新驱动中国 - 《程序员》官网
大数据时代的信息爆炸,使得分布式/并行处理变得如此重要. 无论是传统行业,还是新兴行业(特别是互联网行业),日常业务运行所产生的海量用户和服务数据都需要更大的硬件资源来处理. 需要并行处理的应用领域主要为网页搜索、广告投放和机器翻译等. 从单机应用到集群应用的过渡中,诞生了MapReduce这样的分布式框架,简化了并行程序的开发,提供了水平扩展和容错能力.

数据仓库中的SQL性能优化(Hive篇)

- - 奔跑的兔子
一个Hive查询生成多个map reduce job,一个map reduce job又有map,reduce,spill,shuffle,sort等多个阶段,所以针对hive查询的优化可以大致分为针对MR中单个步骤的优化(其中又会有细分),针对MR全局的优化,和针对整个查询(多MR job)的优化,下文会分别阐述.

基于Hadoop的数据仓库Hive 基础知识

- - IT瘾-bigdata
Hive是基于Hadoop的数据仓库工具,可对存储在HDFS上的文件中的数据集进行数据整理、特殊查询和分析处理,提供了类似于SQL语言的查询语言–HiveQL,可通过HQL语句实现简单的MR统计,Hive将HQL语句转换成MR任务进行执行. 数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反应历史变化(Time Variant)的数据集合,用于支持管理决策.

深入浅出数据仓库中SQL性能优化之Hive篇

- - 极客521 | 极客521
一个Hive查询生成多个Map Reduce Job,一个Map Reduce Job又有Map,Reduce,Spill,Shuffle,Sort等多个阶段,所以针对Hive查询的优化可以大致分为针对MR中单个步骤的优化(其中又会有细分),针对MR全局的优化,和针对整个查询(多MRJob)的优化,下文会分别阐述.

漫谈数据仓库之拉链表(原理、设计以及在Hive中的实现)

- - IT瘾-bigdata
本文将会谈一谈在数据仓库中拉链表相关的内容,包括它的原理、设计、以及在我们大数据场景下的实现方式. 先分享一下拉链表的用途、什么是拉链表. 通过一些小的使用场景来对拉链表做近一步的阐释,以及拉链表和常用的切片表的区别. 举一个具体的应用场景,来设计并实现一份拉链表,最后并通过一些例子说明如何使用我们设计的这张表(因为现在Hive的大规模使用, 我们会以Hive场景下的设计为例).

数据仓库

- Ran - Linux@SOHU
翻译:马少兵、曾怀东、朱翊然、林业. 尽管服务器存储、处理能力得到有效的提高,以及服务器价格的降低,让人们能够负担起大量的服务器,但是商业软件应用和监控工具快速的增加,还是使得人们被大量的数据所困扰. 在数据仓库领域中的许多系统管理员、应用开发者,以及初级数据库管理员发现,他们正在处理“海量数据”-不管你准备与否-都会有好多不熟悉的术语,概念或工具.

实时分析系统(HIVE/HBASE/IMPALA)浅析

- - 数据库 - ITeye博客
1. 什么是实时分析(在线查询)系统. 大数据领域里面,实时分析(在线查询)系统是最常见的一种场景,通常用于客户投诉处理,实时数据分析,在线查询等等过. 因为是查询应用,通常有以下特点:. b. 查询条件复杂(多个维度,维度不固定),有简单(带有ID). c. 查询范围大(通常查询表记录在几十亿级别).

Flume+Spark+Hive+Spark SQL离线分析系统

- - CSDN博客推荐文章
前段时间把Scala和Spark一起学习了,所以借此机会在这里做个总结,顺便和大家一起分享一下目前最火的分布式计算技术Spark. 当然Spark不光是可以做离线计算,还提供了许多功能强大的组件,比如说,Spark Streaming 组件做实时计算,和Kafka等消息系统也有很好的兼容性;Spark Sql,可以让用户通过标准SQL语句操作从不同的数据源中过来的结构化数据;还提供了种类丰富的MLlib库方便用户做机器学习等等.

数据仓库概念

- - 互联网 - ITeye博客
数据仓库:是一个数据库环境,它提供用户用于决策支持的当前和历史数据,这些数据在传统的数据库中不方便得到. 特点:面向主题,集成的,相对稳定的,反应历史变化的. 组成:数据仓库的数据库,数据抽取工具,元数据,访问工具,数据集市,数据仓库管理,信息发布系统. 数据挖掘:就是从大量数据中获取有效的,新颖的,潜在有用的,最终可理解的模式的过程.

大数据仓库-kudu

- - 数据库 - ITeye博客
数据仓库里面存储引擎是非常重要的,存储引擎的好坏,基本决定了整个数仓的基础. cloudera公司最近发布了一个kudu存储引擎. 按照cloudera的想法,kudu的出现是为了解决,hbase,parquet不能兼顾分析和更新的需求,所以需要一个新的存储引擎可以同时支持高吞吐的分析应用以及少量更新的应用.