解密Apache HAWQ —功能强大的SQL-on-Hadoop引擎

摘要：我们缓存资源的主要原因是减少与全局资源管理器之间的交互代价。资源管理器同时需要保证查询不使用超过分配给该查询的资源，否则查询之间会相互影响，可能导致系统整体不可用。主要向其他组件提供元数据的存储及查询服务。对外的接口为元数据查询语言。

作者简介：

常雷，博士，Pivotal中国研发中心研发总监，HAWQ并行Hadoop SQL引擎创始人，Pivotal HAWQ团队负责人，曾任EMC高级研究员。专注于大数据与云计算领域，在国内外较高级数据管理期刊和会议发表数篇论文，并拥有多项美国专利。

分享主要分为以下五个部分：

HAWQ基本介绍；

HAWQ架构以及各重要组件的基本原理；

HAWQ的中短期规划；

如何贡献到HAWQ和成为Apache Committer；

Q & A。

一、HAWQ基本介绍

HAWQ是一个Hadoop原生大规模并行SQL分析引擎，针对的是分析性应用。和其他关系型数据库类似，接受SQL，返回结果集。但它具有大规模并行处理很多传统数据库以及其他数据库没有的特性及功能。主要如下：

对标准的完善支持：ANSI SQL标准，OLAP扩展，标准JDBC/ODBC支持，比其他Hadoop SQL引擎都要完善。

具有MPP（大规模并行处理系统）的性能，比其他Hadoop里面的SQL引擎快数倍。

具有非常成熟的并行优化器。优化器是并行SQL引擎的重要组成部分，对性能影响很多，尤其是对复杂查询。

支持ACID事务特性：这是很多现有基于Hadoop的SQL引擎做不到的，对保证数据一致性很重要。

动态数据流引擎：基于UDP的高速互联网络。

弹性执行引擎：可以根据查询大小来决定执行查询使用的节点及Segment个数。

支持多种分区方法及多级分区：比如List分区和Range分区。分区表对性能有很大帮助，比如你只想访问最近一个月的数据，查询只需要扫描最近一个月数据所在分区。

支持多种压缩方法：snappy，gzip，quicklz，RLE等。

多种UDF（用户自定义函数）语言支持：Java, python, c/c++, perl, R等。

动态扩容：动态按需扩容，按照存储大小或者计算需求，秒级添加节点。

多级资源或负载管理：和外部资源管理器YARN集成；可以管理CPU，Memory资源等；支持多级资源队列；方便的DDL管理接口。

支持访问任何HDFS及其他系统的数据：各种HDFS格式（文本，SequenceFile，Avro，Parquet等等）以及其他外部系统（HBase等），并且用户自己可以开发插件来访问新的数据源。

原生的机器学习数据挖掘库MADLib支持：易于使用及高性能。

与Hadoop系统无缝集成：存储、资源、安装部署（Ambari）、数据格式、访问等。

完善的安全及权限管理：kerberos；数据库，表等各个级别的授权管理。

支持多种第三方工具：比如Tableau，SAS，较新的Apache Zeppelin等。

支持对HDFS和YARN的快速访问库：libhdfs3和libyarn（其他项目也可以使用）。

支持在本地、虚拟化环境或者在云端部署。

下面我来谈一下HAWQ是原生Hadoop SQL引擎中“原生”的意思，“原生”主要体现在如下几个方面：

数据都存储在HDFS上，不需要使用connector模式。

高可扩展性：和其他Hadoop组件一样，高可扩展。并且具有高性能。

原生的代码存取：和其他Hadoop项目一样。HAWQ是Apache项目。用户可以自由的下载，使用和做贡献。区别与其他的伪开源软件。

透明性：用Apache的方式开发软件。所有功能的开发及讨论都是公开的。用户可以自由参与。

原生的管理：可以通过Ambari部署、资源可以从YARN分配，与其它Hadoop组件可以运行在同一个集群。

HAWQ提供的主要好处：

HAWQ与同类开源和闭源产品比较，如图1：

（图1）

HAWQ与同类开源和闭源产品比较，如图2：

（图2）

HAWQ的历史和现状：

想法和原型系统 (2011)：GOH阶段（Greenplum Database On HDFS）。

HAWQ 1.0 Alpha (2012): 多个国外大型客户试用，当时客户性能测试是Hive的数百倍。促进了HAWQ 1.0作为正式产品发布。

HAWQ 1.0 GA (2013年初): 改变了传统MPP数据库架构，包括事务，容错，元数据管等。

HAWQ 1.X版本 (2014-2015 Q2)：增加了一些企业级需要的功能，比如Parquet存储，新的优化器，Kerberos，Ambari安装部署。客户覆盖全球。

HAWQ 2.0 Alpha发布并成为Apache孵化器项目：针对云环境的系统架构重新设计，数十个高级功能，包括弹性执行引擎，高级资源管理，YARN集成，秒级扩容等等。现在大家在Apache开源的是的2.0 Alpha版本。未来的开发都在Apache进行。

二、Apache HAWQ系统架构

下面我来介绍一下HAWQ的系统架构。图3给出了一个典型的HAWQ集群的主要组件。其中有几个Master节点：包括HAWQ master节点，HDFS master节点NameNode，YARN master节点ResourceManager。现在HAWQ元数据服务在HAWQ master节点里面，将来的版本会成为多带带的服务。其他节点为Slave节点。每个Slave节点上部署有HDFS DataNode，YARN NodeManager以及一个HAWQ Segment。HAWQ Segment在执行查询的时候会启动多个QE (Query Executor, 查询执行器)。查询执行器运行在资源容器里面。

（图3）

图4是HAWQ内部架构图：

（图4）

可以看到在HAWQ master节点内部有如下几个重要组件：查询解析器（Parser/Analyzer），优化器，资源管理器，资源代理，HDFS元数据缓存，容错服务，查询派遣器，元数据服务。在Slave节点上安装有一个物理Segment，在查询执行时，针对一个查询，弹性执行引擎会启动多个虚拟Segment同时执行查询，节点间数据交换通过Interconnect（高速互联网络）进行。如果一个查询启动了1000个虚拟Segment，意思是这个查询被均匀的分成了1000份任务，这些任务会并行执行。所以说虚拟Segment数其实表明了查询的并行度。查询的并行度是由弹性执行引擎根据查询大小以及当前资源使用情况动态确定的。下面我逐个来解释这些组件的作用以及它们之间的关系：

查询解析器：负责解析查询，并检查语法及语义。最终生成查询树传递给优化器。

优化器：负责接受查询树，生成查询计划。针对一个查询，可能有数亿个可能的等价的查询计划，但执行性能差别很大。优化器的作用是找出优化的查询计划。

资源管理器：资源管理器通过资源代理向全局资源管理器（比如YARN）动态申请资源。并缓存资源。在不需要的时候返回资源。我们缓存资源的主要原因是减少HAWQ与全局资源管理器之间的交互代价。HAWQ支持毫秒级查询。如果每一个小的查询都去向资源管理器申请资源，这样的话，性能会受到影响。资源管理器同时需要保证查询不使用超过分配给该查询的资源，否则查询之间会相互影响，可能导致系统整体不可用。

HDFS元数据缓存：用于HAWQ确定哪些Segment扫描表的哪些部分。HAWQ是把计算派遣到数据所在的地方。所以我们需要匹配计算和数据的局部性。这些需要HDFS块的位置信息。位置信息存储在HDFS NameNode上。每个查询都访问HDFS NameNode会造成NameNode的瓶颈。所以我们在HAWQ Master节点上建立了HDFS元数据缓存。

容错服务：负责检测哪些节点可用，哪些节点不可用。不可用的机器会被排除出资源池。

查询派遣器：优化器优化完查询以后，查询派遣器派遣计划到各个节点上执行，并协调查询执行的整个过程。查询派遣器是整个并行系统的粘合剂。

元数据服务：负责存储HAWQ的各种元数据，包括数据库和表信息，以及访问权限信息等。另外，元数据服务也是实现分布式事务的关键。

高速互联网络：负责在节点之间传输数据。软件实现，基于UDP。

查询执行

了解清楚各个组件之后，我们来看一下一个查询的主要流程（请参见图5）。

（图5）

用户通过JDBC/ODBC提交查询之后，查询解析器得到查询树，然后优化器根据查询树生成查询计划，派遣器和资源管理器打交道得到资源，分解查询计划，然后派遣计划到Segment的执行器上面执行。最终结果会传回给用户。

下面我来简单看一下并行查询计划长什么样。图6给出了一个具体的例子。

（图6）

这个查询包含一个连接，一个表达式和一个聚集。图中有两个查询计划。简单来看，并行查询计划和串行查询计划最不同的是多了一些Motion操作符。Motion负责在节点之间交换数据。底层是通过高速互联网络实现的。我们可以看到这里有三种Motion：

Redistribution Motion: 负责按照hash键值重新分布数据

Broadcast Motion: 负责广播数据

Gather Motion: 负责搜集数据到一起。

左边的查询计划表示了如果表lineitem和orders都使用了连接键进行分布的情况。在这个例子中，lineitem按照l_orderkey进行hash分布，orders表按照o_orderkey进行分布。这样的话两个表做连接的时候是不需要进行重新分布的。右边的查询计划表示了一个需要重新分布数据的例子。该查询计划和左边的查询计划相比多了一个Motion节点。

弹性执行引擎

弹性执行引擎有几个关键设计点：存储和计算的完全分离，无状态Segment以及如何使用资源。存储和计算的分离使得我们可以动态的启动任意多个虚拟Segment来执行查询。无状态Segment使得集群更容易扩展。要想保证大规模集群的状态一致性是比较困难的问题，所以我们采用了无状态的Segment。如何使用资源包括如何根据查询的代价申请多少资源，并且如何有效的使用这些资源，比如如何使得数据局部性最优。HAWQ内部针对每一个部分都进行了非常优化的设计。

元数据服务

元数据服务位于HAWQ Master节点。主要向其他组件提供元数据的存储及查询服务。对外的接口为CaQL(元数据查询语言, Catalog Query Language)。CaQL支持的语言是SQL的一个子集，包括单表选择，计数，多行删除，单行插入更新等。把CaQL设计为SQL语言的一个子集的原因是，在未来我们希望把元数据从主节点分离出去，作为一个多带带的服务，支持一个简单的子集作为元数据服务来说已经够用了，并且容易扩展。

高速互联网络

高速互联网络的作用是在多个节点之间交换大量数据。HAWQ高速互联网络基于UDP协议。大家可能会问为什么我们不使用TCP。其实我们同时支持TCP和UDP两种协议。TCP协议早于UDP协议。就是因为我们遇到了TCP不能很好解决的问题，我们才开发了基于UDP的协议。图7展示了一个高速互联网络的例子。

（图7）

例子中各个节点上的执行器进程形成了一个数据交换的流水线。假设每个节点上有1000个进程。有1000个节点，这些进程需要相互交互，每个节点上就会有上百万个连接。TCP是没办法高效地支持这么多的连接数的。所以我们开发了基于UDP的互联协议。针对UDP传输，操作系统是不能保证可靠性的，并且不能保证是有序传递的。我们的设计目标需要保持以下特性：

可靠性：能够保证在丢包的情况下，重传丢失的包

有序性：保证包传递给接受者的最终有序性

流量控制：如果不控制发送者的速度，接收者可能会被淹没，甚至会导致整个网络性能急剧下降

性能和可扩展性：性能和可扩展性是我们需要解决TCP问题的初衷

可支持多种平台

（图8）

图8展现了我们实现UDP高速互联网络的状态机。并且设计时还需要考虑死锁的消除。详细信息可以参考参考文献。

事务管理

事务是数据管理系统一个非常重要的属性。大部分Hadoop里面的SQL引擎不支持事务。让程序员自己保证事务和数据的一致性，基本上是非常困难的事。

HAWQ支持事务的所有ACID属性，支持Snapshot Isolation。事务发生由Master节点协调和控制。采用的是一种泳道模型。比如并发的插入各个查询使用各自的泳道，互不冲突。在事务提交的时候通过记录文件逻辑长度的方式来保证一致性。如果事务失败的时候，需要回滚，删除文件末尾的垃圾数据。起初HDFS是不支持truncate的，现在HDFS刚支持的truncate功能是根据HAWQ的需求做出的。

资源管理器

HAWQ支持三级资源管理：

全局资源管理：可以集成YARN，和其他系统共享集群资源。未来会支持Mesos等

HAWQ内部资源管理：可以支持查询，用户等级别的资源管理

操作符级别资源管理：可以针对操作符分配和强制资源使用

现在HAWQ支持多极资源队列。可以通过DDL方便的定义和修改资源队列定义。下面是HAWQ资源管理器的主要架构图：

（图9）

资源管理器中的各个组件作用如下：

请求处理器：接收查询派遣器进程的资源请求

资源分配器：负责资源的分配

资源池：保存所有资源的现有状态

策略存储：保存所有的分配策略，将来会做到策略可定制。

资源代理：负责与全局资源管理器交互

存储模块 

HAWQ支持多种内部优化的存储格式，比如AO和Parquet。提供MapReduce InputFormat，可以供外部系统直接访问。其他各种存储格式通过扩展框架访问。针对用户专有格式，用户可以自己开发插件。同时支持各种压缩，多极分区等各种功能。

MADLib

（图10）

如上图所示。MADLib是一个非常完善的并行机器学习和数据挖掘库。支持多种各种机器学习和统计分析方法。HAWQ原生支持MADLib。现在MADLib是一个独立的Apache项目，基本包含了所有常用的机器学习方法。

三、HAWQ中短期规划

HAWQ团队短期内专注于2.0GA。长期来看我们会做以下几个方面的工作：

跨数据中心的灾难恢复

分布式索引支持

快照支持

与更多其他生态系统进行集成

对新硬件的支持进一步提高性能：GPU等

Q1：HAWQ的查询优化是采用了原来的MPP数据库的优化器，还是针对HDFS的读写特性进行改进？

A: 基于MPP并行优化器，但是针对弹性执行引擎，资源管理以及HDFS的特性进行了很多改进。

Q2：HAWQ的事务支持全部的隔离级别还是只支持其中的一部分？具体有哪些？

A: 因为是Snapshot Isolation，除了可串行话，其他都支持。

Q3：HAWQ的数据权限如何控制，影响效率如何？

A: 通过标准SQL Grant语句控制。基本没有效率影响。因为查询通常是时间的大头。

Q4：HAWQ与Hive，以及Impala等同类产品相比，性能表现如何，各自更适合哪种场景？

A: HAWQ和Hive及Impala性能相比，标准化TPCDS性能测试要快数倍。而且Hive和Impala支持SQL标准有限，很多TPCDS查询执行不了。

Q5：hawq是支持分布式事务吗？

A: 是的。因为HAWQ是分布式的，支持分布式事务。

Q6：跟Impala谁强？

A： 我先来找一下TPCDS性能比较图，比Impala快多倍。

（图11）

Q7：HAWQ可以用作OLAP吗？性能有保障吗？分布式事务用什么方法保证一致性？

A: 虽然HAWQ支持分布式事务，可以保证一致性，但不推荐用作oltp。因为我们是针对OLAP进行优化的。事务实现可以参见我们的SIGMOD论文[1] Lei Chang et al: HAWQ: a massively parallel processing SQL engine in hadoop. SIGMOD Conference 2014: 1223-1234

Q8：具体的数据可以说下吗？比如什么规模，具体性能数据。

A: 数据规模应该在30T。大约20个节点。