HAWQ实践——为什么选择HAWQ

Posted wzy0623

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了HAWQ实践——为什么选择HAWQ相关的知识，希望对你有一定的参考价值。

        为了跟上所谓“大数据”技术的脚步，从两年前开始着手实践各种SQL-on-Hadoop技术，从最初的Hive，到SparkSQL，再到Impala，进行了一系列ETL、CDC、多维数据仓库、OLAP的实验。作为一名从业20年以上的DBA，从数据库的角度看，我的总体感觉是这些技术与传统的DBMS相比，功能不完善，性能差距很大，甚至很难找到一个可行的、相对完备的Hadoop数据仓库解决方案。这使我在实际应用中使用这些产品的时候总是感到顾此失彼、捉襟见肘。也可能是我做数据库的时间太长了，只会用锤子，所以拿什么都跟钉子比。
        然而，在去年12月举办的BDTC大会上听到常雷博士介绍HAWQ项目时，立即引起了我的兴趣。从常博士的演讲中得知，HAWQ支持事务、性能相对于其它SQL-on-Hadoop产品高很多。更为关键的是HAWQ与SQL的兼容性非常好，甚至支持存储过程，这是我以往所接触过的产品中从未有过的。对于传统数据库的开发人员或DBA，使用HAWQ转向大数据平台的成本应该是很低的。于是当时就决定今年要系统研究一下HAWQ，也许它正是我所需要的。

一、常用SQL-on-Hadoop产品的不足


1. Hive

        Hive是最老牌的一款Hadoop数据仓库产品，更够部署在所有Hadoop发行版本之上。它在MapReduce计算框架上封装一个SQL语义层，极大简化了MR程序的开发。直到现在，Hive以其稳定性依然赢得大量用户。
        但是Hive的缺点也很明显——速度太慢。随着技术的不断进步，Hive的执行引擎也从最初的MapReduce一种，发展出Hive on Spark、Hive on Tez等。尤其是运行在Tez框架上的Hive，其性能有了长足改进。即便如此，Hive的速度还是比较适合后台批处理应用场景，而不适合交互式即席查询和联机分析。


2. SparkSQL

        SparkSQL是Hadoop中另一个著名的SQL引擎，正如名字所表示的，它以Spark作为底层计算框架，实际上是一个Scala程序语言的子集。Spark基本的数据结构是RDD，一个分布于集群节点的只读数据集合。传统的MapReduce框架强制在分布式编程中使用一种特定的线性数据流处理方式。MapReduce程序从磁盘读取输入数据，把数据分解成键/值对，经过混洗、排序、归并等数据处理后产生输出，并将最终结果保存在磁盘。Map阶段和Reduce阶段的结果均要写磁盘，这大大降低了系统性能。也是由于这个原因，MapReduce大都被用于执行批处理任务。
        为了解决MapReduce的性能问题，Spark使用RDD作为分布式程序的工作集合，它提供一种分布式共享内存的受限形式。在分布式共享内存系统中，应用可以向全局地址空间的任意位置进行读写操作，而RDD是只读的，对其只能进行创建、转化和求值等操作。这种内存操作大大提高了计算速度。
        开发Spark的初衷是用于机器学习系统的培训算法，而不是SQL查询。Spark宣称其应用的延迟可以比MapReduce降低几个数量级，但是我们的实际使用中，在20TB的数据集合上做SQL查询也要10分钟左右出结果，这个速度纵然是比Hive快了3倍，但显然不能支撑交互查询和OLAP应用。Spark还有一个问题是需要占用大量内存，当内存不足时，容易出现OOM错误。


3. Impala

        Impala是一个运行在Hadoop之上的大规模并行处理（MPP）查询引擎，提供对Hadoop集群数据的高性能、低延迟的SQL查询，使用HDFS作为底层存储。对查询的快速响应使交互式查询和对分析查询的调优成为可能，而这些在针对处理长时间批处理作业的SQL-on-Hadoop传统技术上是难以完成的。
        Impala的最大亮点在于它的执行速度。官方宣称大多数情况下它能在几秒或几分钟内返回查询结果，而相同的Hive查询通常需要几十分钟甚至几小时完成，因此Impala适合对Hadoop文件系统上的数据进行分析式查询。Impala缺省使用Parquet文件格式，这种列式存储对于典型数据仓库场景下的大查询是较为高效的。
        Impala的问题主要体现在功能上的欠缺。如不支持update、delete操作，不支持Date数据类型，不支持XML和JSON相关函数，不支持covar_pop、covar_samp、corr、percentile、 percentile_approx、histogram_numeric、collect_set等聚合函数，不支持rollup、cube、grouping set等操作，不支持数据抽样（Sampling），不支持ORC文件格式等等。其中分组聚合、取中位数等是数据分析中的常用操作，当前的Impala存在如此多的局限，使它在易用性上大打折扣，在实际使用时要格外注意。


二、HAWQ的可行性

        刚才介绍了几种SQL-on-Hadoop产品的主要问题，那么重点来了，HAWQ是否有能力取而代之呢？下面从功能与性能两方面，简单分析一下使用HAWQ的主要特点。具有了这些特性，使用HAWQ在Hadoop上开发分析型数据仓库应用是完全可行的。


1. 功能

（1）完全兼容SQL标准
        HAWQ从代码级别上可以说是数据存储在HDFS上的PostgreSQL数据库，100%符合ANSI SQL规范并且支持SQL 92、99、2003。它支持内连接、外连接、全连接、笛卡尔连接、相关子查询等所有表连接方式，支持并集、交集、差集等集合操作，并支持递归查询。作为一个数据库系统，提供这些功能很好理解。

（2）丰富的函数
        除了包含诸多字符串、数字、日期时间、类型转换等常规标量函数以外，HAWQ还包含丰富的窗口函数和高级聚合函数，这些函数经常被用于分析型数据查询。窗口函数包括cume_dist()、dense_rank()、first_value(expr)、lag(expr [,offset] [,default])、last_valueexpr、lead(expr [,offset] [,default])、ntile(expr)、percent_rank()、rank()、row_number()等。高级聚合函数包括MEDIAN (expr)、PERCENTILE_CONT (expr) WITHIN GROUP (ORDER BY expr [DESC/ASC])、PERCENTILE_DISC (expr) WITHIN GROUP (ORDER BY expr [DESC/ASC])、sum(array[])、pivot_sum (label[], label, expr)等。具体的函数说明参见 Using Functions and Operators。

（3）TPC-DS合规性
        TPC-DS针对具有各种操作要求和复杂性的查询定义了99个模板，例如点对点、报告、迭代、OLAP、数据挖掘等。成熟的基于Hadoop的SQL系统需要支持和正确执行多数此类查询，以解决各种不同分析工作场景和使用案例中的问题。图1所示的基准测试是通过TPC-DS中的99个模板生成的111个查询来执行的。图中显示了4种基于SQL-on-Hadoop常见系统的合规等级，绿色和蓝色分别表示：每个系统可以优化的查询个数；可以完成执行并返回查询结果的查询个数。从图中可以看到，HAWQ完成了所有查询，表现远优于其它系统。HAWQ虽然没有提供update、delete等DML语句，但通过其强大的数据查询功能，可以轻松实现多维数据仓库中渐变维（SCD）的处理需求。