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（Resilient Distributed DataSet），一个分布于集群节点的只读数据集合。传统的 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 之上的大规模并行处理（Massively Parallel Processing，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-write（写时模式）数据验证处理，不符合表定义或存储格式的数据是不允许进入到表中的，这点与 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 查询的基础，并针对大数据工作负载进行了调优。
运行时资源管理确保查询的完整性。
无缝数据分配机制，将经常用于特定查询的部分数据集集中起来。

大数据模块化查询优化器架构中突出的性能分析显示，对于基于 Hadoop 的分析与数据仓库工作负载，HAWQ 要比现有 Hadoop 查询引擎快一或两个数量级。这些性能改进主要归功于 Dynamic pipelining 和 HAWQ 内基于成本的查询优化器的强大功能。

（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 解决方案中唯一支持 SQL 过程化编程的，Hive、SparkSQL、Impala 都没有此功能。对于习惯了编写存储过程的 DBA 来说，这无疑大大提高了 HAWQ 的易用性。HAWQ 的 UDF 提供以下特性：