首页 > 代码库 > HAWQ实践（一）——为什么选择HAWQ
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，也许它正是我所需要的。
但是Hive的缺点也很明显——速度太慢。随着技术的不断进步，Hive的执行引擎也从最初的MapReduce一种，发展出Hive on Spark、Hive on Tez等。尤其是运行在Tez框架上的Hive，其性能有了长足改进。即便如此，Hive的速度还是比较适合后台批处理应用场景，而不适合交互式即席查询和联机分析。
为了解决MapReduce的性能问题，Spark使用RDD作为分布式程序的工作集合，它提供一种分布式共享内存的受限形式。在分布式共享内存系统中，应用可以向全局地址空间的任意位置进行读写操作，而RDD是只读的，对其只能进行创建、转化和求值等操作。这种内存操作大大提高了计算速度。
开发Spark的初衷是用于机器学习系统的培训算法，而不是SQL查询。Spark宣称其应用的延迟可以比MapReduce降低几个数量级，但是我们的实际使用中，在20TB的数据集合上做SQL查询也要10分钟左右出结果，这个速度纵然是比Hive快了3倍，但显然不能支撑交互查询和OLAP应用。Spark还有一个问题是需要占用大量内存，当内存不足时，容易出现OOM错误。
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从代码级别上可以说是数据存储在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）的处理需求。
（4）分区表
与传统DBMS系统类似，HAWQ也支持多种分区方法及多级分区，如List分区和Range分区。分区表对查询性能和数据可维护性都有很大帮助。
（5）过程化编程
HAWQ支持内建的SQL、C、Java、Perl、pgSQL、Python、R等多种语言的过程化编程。参见Using Languages and Extensions in HAWQ。
（6）原生Hadoop文件格式支持
HAWQ支持HDFS上的AVRO、Parquet、平面文本等多种文件格式，支持snappy、gzip、quicklz、RLE等多种数据压缩方法。与Hive不同，HAWQ实现了schema-on-read（读时模式）数据验证处理，不符合表定义或存储格式的数据是不允许进入到表中的，这点与DBMS系统保持一致。
（7）外部数据整合
HAWQ通过名为Pivotal eXtension Framework（PXF）的模块提供访问HDFS上的Json文件、Hive、HBase等外部数据的能力。而且PXF还允许用户自定义：PXF提供框架API以便用户为其自有数据堆栈开发新的连接器，增强了数据引擎的松耦合程度。
除了用于访问HDFS文件的PXF协议，HAWQ还提供了gpfdist文件服务器，它利用HAWQ系统并行读写本地文件系统中的文件。
HAWQ采用基于成本的SQL查询优化器，该查询优化器以针对大数据模块化查询优化器架构的研究成果为基础而设计。
HAWQ能够制定执行计划，可优化利用Hadoop 集群的资源，还可以针对特定环境，如软件版本、硬件类型、CPU、IOPS指标等信息配置优化器。
HAWQ已经验证，能够快速为涉及超过50个关联表的高性能查询找到理想的查询计划。因此可以将HAWQ用于大量数据分析的传统企业数据仓库工作负载要求。
（2）Dynamic pipelining
SQL-on-Hadoop的主要设计目标是在Hadoop上执行SQL连接时最大程度地降低数据传输的开销。HAWQ采用Dynamic pipelining来解决这一关键要求，使基于HDFS的数据适用于交互式查询。Dynamic pipelining是一种并行数据流框架，结合了以下独特的技术：
（3）与Impala的性能比较
图2是HAWQ提供的TPC-DS性能比较图，可以看到HAWQ平均比Impala快4.55倍。
（4）与Hive的性能比较
图3是我在自己的实验环境中所做的，HAWQ与Hive查询性能对比图。对于不同查询，HAWQ比Hive快4-50倍。测试具体的软硬件环境、数据模型、数据量、查询语句等参见HAWQ与Hive查询性能对比测试。
HAWQ是我所使用过的SQL-on-Hadoop解决方案中唯一支持过程化编程的，Hive、SparkSQL、Impala都没有此功能。对于习惯了编写存储过程的DBA来说，这无疑大大提高了HAWQ的易用性。HAWQ的UDF提供以下特性：
然而，在去年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）的处理需求。
图1
（4）分区表
与传统DBMS系统类似，HAWQ也支持多种分区方法及多级分区，如List分区和Range分区。分区表对查询性能和数据可维护性都有很大帮助。
（5）过程化编程
HAWQ支持内建的SQL、C、Java、Perl、pgSQL、Python、R等多种语言的过程化编程。参见Using Languages and Extensions in HAWQ。
（6）原生Hadoop文件格式支持
HAWQ支持HDFS上的AVRO、Parquet、平面文本等多种文件格式，支持snappy、gzip、quicklz、RLE等多种数据压缩方法。与Hive不同，HAWQ实现了schema-on-read（读时模式）数据验证处理，不符合表定义或存储格式的数据是不允许进入到表中的，这点与DBMS系统保持一致。
（7）外部数据整合
HAWQ通过名为Pivotal eXtension Framework（PXF）的模块提供访问HDFS上的Json文件、Hive、HBase等外部数据的能力。而且PXF还允许用户自定义：PXF提供框架API以便用户为其自有数据堆栈开发新的连接器，增强了数据引擎的松耦合程度。
除了用于访问HDFS文件的PXF协议，HAWQ还提供了gpfdist文件服务器，它利用HAWQ系统并行读写本地文件系统中的文件。
2. 性能
（1）基于成本的SQL查询优化器HAWQ采用基于成本的SQL查询优化器，该查询优化器以针对大数据模块化查询优化器架构的研究成果为基础而设计。
HAWQ能够制定执行计划，可优化利用Hadoop 集群的资源，还可以针对特定环境，如软件版本、硬件类型、CPU、IOPS指标等信息配置优化器。
HAWQ已经验证，能够快速为涉及超过50个关联表的高性能查询找到理想的查询计划。因此可以将HAWQ用于大量数据分析的传统企业数据仓库工作负载要求。
（2）Dynamic pipelining
SQL-on-Hadoop的主要设计目标是在Hadoop上执行SQL连接时最大程度地降低数据传输的开销。HAWQ采用Dynamic pipelining来解决这一关键要求，使基于HDFS的数据适用于交互式查询。Dynamic pipelining是一种并行数据流框架，结合了以下独特的技术：
- 适应性高速UDP互联技术。
- 操作运行时执行环境。这是所有SQL查询的基础，并针对大数据工作负载进行了调优。
- 运行时资源管理确保查询的完整性。
- 无缝数据分配机制，将经常用于特定查询的部分数据集集中起来。
（3）与Impala的性能比较
图2是HAWQ提供的TPC-DS性能比较图，可以看到HAWQ平均比Impala快4.55倍。
图2
（4）与Hive的性能比较
图3是我在自己的实验环境中所做的，HAWQ与Hive查询性能对比图。对于不同查询，HAWQ比Hive快4-50倍。测试具体的软硬件环境、数据模型、数据量、查询语句等参见HAWQ与Hive查询性能对比测试。
图3
三、适合DBA的解决方案
当初HAWQ最吸引我的地方是它支持SQL过程化编程。这是通过用户自定义函数（user-defined functions，UDF）实现的。编写UDF的语言可以是SQL、C、Java、Perl、Python、R和pgSQL。数据库开发人员常用的自然是SQL和pgSQL，PL/pgSQL函数可以为SQL语言增加控制结构，执行复杂计算任务，并继承所有PostgreSQL的数据类型（包括用户自定义类型）、函数和操作符。HAWQ是我所使用过的SQL-on-Hadoop解决方案中唯一支持过程化编程的，Hive、SparkSQL、Impala都没有此功能。对于习惯了编写存储过程的DBA来说，这无疑大大提高了HAWQ的易用性。HAWQ的UDF提供以下特性：
- 给HAWQ内部函数起别名。
- 返回结果集的表函数。
- 参数个数可变的函数。
- 多态数据类型。
四、HAWQ系统架构
图4是给出了一个典型的HAWQ集群的主要组件。图5是HAWQ内部架构图。关于HAWQ的系统架构说明，参见解密Apache HAWQ ——功能强大的SQL-on-Hadoop引擎。图4
图5
HAWQ实践（一）——为什么选择HAWQ
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。