虽然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的分析过程会用到各种数据源的数据。当然使用多个存储数据源，除了功能上要能够支持导入/导出之外，如何根据各种存储源的能力和执行流获得最优执行计划也是件麻烦事儿。

作者：王玉圆

来源： IT168

原文标题：从数据仓库系统对比看Hive发展前景