HAWQ论文笔记

原创文章，转载请注明: 转载自 镜中影的技术博客
本文链接地址: HAWQ论文笔记
URL:http://blog.csdn.net/linkpark1904/article/details/49884017

1、背景

HAWQ是一个构建在HDFS之上的MPP（massively parallel processing）SQL引擎，不像其他构建在hadoop之上的SQL引擎，HAWQ支持标准SQL，并且完整的支持数据库事务。性能上，HAWQ比Stinger快40倍，比原生的HIVE快35倍-40倍。
对于分析型业务，系统需要满足这样一些特性，去满足用户的需求:

1. 交互性查询（Interactive queries）
2. 线性可扩展性（Scalability）
3. 一致性（Consistency）
4. 通用性（Extensibility）
5. 支持通用标准(Standard compliance)
6. 生产率：(Productivity)

Hadoop生态圈在这方面很难满足所有的需求，MapReduce是hadoop的基础计算框架用来计算结构化数据以及非结构化数据。然而，MapReduce在许多应用上存在诸多的限制，例如，很难满足交互性分析，低层次的编程模型对业务分析事务不友好。当然，Hive和Pig的出现弥补了一些不足，但是计算性能依然满足不了实时计算的需求。

在数据库领域，一个主要的趋势是构建MPP数据库系统(独立节点构成的分布式集群)。
HAWQ主要有以下几个方面的特性:

1. 无状态分片（stateless segment）架构，支持元数据分离以及独立的执行引擎。
2. 基于UDP的网络交互协议，解决计算过程中TCP端口不足问题。
3. 基于Simming lane的事务模型，用来支持并发更新操作。
4. 比原生HIVE快40倍。

2、架构

HAWQ集群构建在通用的硬件体系之上（x86集群），没有用到一些特殊的硬件。

HAWQ分层架构如下图2-1所示，一个MPP shared-nothing计算层构建在存储层（hdfs）之上。一个HAWQ集群至少包括三种节点——HAWQ master，HDFS NameNodes以及segment host，其中Segment host包含HAWQ segments和HDFS DataNode。

Master node：提供一切用户交互接口，包括授权认证，SQL解析，生成SQL执行计划，启动SQL执行引擎，以及拆分SQL执行计划。与此同时，Master节点还跟踪执行任务的状态以及合并最终结果。一个Master节点包含一个热备Master节点(双活master)。

Segment：包含HDFS DataNodes，主要用来存储表的分片。

2.1 数据类型

HAWQ包含两种类型的数据：catalog和user data。Catalog是整个系统的核心，用来描述系统和所有用户对象。Catalog是几乎所有的算子的关键所在，包括创建数据库和表，以及查询优化和算子执行。在HAWQ中，calalog分为4种类型：

1. Database object：描述文件空间，表空间，schemas，databases，tables，partitions，columns，index，constraints，types，statistics，resourcequeues，operators，functions以及object dependencies。
2. System information: segments和segment 状态的描述信息。
3. Security: 用户，角色以及权限
4. Language and encoding：语言和编码的支持。
5. Catalog存储在catalog service（UCS）中，一些应用可以通过SQL语句来操作catalog数据。

这里的Catalog类似于整个数据库的元数据集合，所有的用户数据，数据库相关的元数据信息都是存储在Catalog中。

2.2 数据分布

除了catalog表存储在UCS中之外，所有的数据分布在整个集群中，一个数据表通过横切和纵切来进行分片。每个segment都有一个分离的字典存储在hdfs中。最常用的数据分布策略是hash分布，将数据表中的行进行hash操作，将数据列切开。用户可以指定某两个列的hash分布策略，用来提高系统的执行性能。举例说明如下：

如果两张表经常进行join操作，用户将这两张表按照统一的hash规则进行数据分布，这样就可以提高查询的性能，并且减少网络传输代价。

另外，HAWQ还提供另外一种数据分布策略——RANDOMLY。数据表中的行通过Round-robin策略分布在segments中。

数据表的分片可以交由用户来完成，用户通过SQL语句可以对数据表进行分片操作，具体如下所示:

CREATE TABLE sales( id INT, date DATE, amt DECIMAL(10,2)) DISTRIBUTED BY (id) PARTITION BY RANGE (date)( START (date ’2008-01-01’) INCLUSIVE END (date ’2009-01-01’) EXCLUSIVE EVERY (INTERVAL ’1 month’));

2.3 查询任务执行流程

整个查询任务执行流程如下图2-2所示:

当用户连接master节点时，master节点会fork一个query dispatcher（QD）进程，QD用来保持用户session，和用户进行交互以及控制整个查询执行过程。当接收一个查询请求之后，QD首先解析query，将其转换成一棵原始的语法树，然后对其进行语义分析，判断语法树是否合法，语义分析阶段会用到catalog中的数据，检查数据库，表，类型等的正确性。语义分析阶段后，语法树通过一些查询重写规则进行重写。

在解析流程完成之后，就进入查询计划生成的流程，这个流程由planner模块承载，planner接收语法树，生成并行执行计划，然后将执行计划进行分解成一个个slice，slice是最小执行单元。

拆分完成之后，QD将各个slice下发到QE（Query engine）中，QE执行每个单独的slice，最后，由QD负责统一收集结果数据，返回给用户。（QD是否会成为瓶颈，论文里面并没有给出具体说法，但是最终的数据收集工作确实都是由单台节点负责完成）

2.4 存储模型

传统的关系型数据库针对OLTP业务，将数据库表按行来存储，一个元组的所有列都存储在一起。然而，分析型业务和传统的OLTP业务不一样。OLTP业务特点在于短事务读写，而分析性数据库常常涉及到复杂的SQL语句，涉及到大量的数据。

针对OLTP和OLAP型事务，HAWQ在存储模型上构建比较灵活，用户可以根据每张表支撑的具体业务来自定义存储模型，在HAWQ系统中，存储模型有如下几种：

• Row-oriented/Read Optimized AO:
  对整表扫描以及大块数据append操作有优化。针对这一块儿的数据压缩算法可以是轻量级压缩也可以是重量级压缩(gzip，quicklz)，具体算法可以由用户ddl来决定。（横切）
• Column-oriented/Read optimized CO:这里采用列数据库思想，将数据按列进行存储。将列切分分别存储在不同的segments文件中。（纵切）
• Column-oriented/Parquet: 和CO一致，只不过，数据进一步被横切。将列进行横切，组织成行组（row group），分散在各个segments中。（纵横切）

2.5 容错

对于Master节点的容错，采用双击热备，standby master用来同步主master上的日志信息。对于Segment上的容错，由于Segment是无状态的，所以Segement容错相对简单，Master节点拥有一个错误探测器（fault detector）用来周期性的检测Segment的状态。

3、执行流程

在HAWQ中，SQL的执行大致被分为两个阶段，制定执行计划（query planner），执行（excute）。Planner负责解析和优化查询树，executor负责并行执行执行计划。解析优化器采用代价模型，从不同的执行路劲中选择一条代价最小的路径执。

对于一个查询计划，抽象出了很多和关系数据库相关的算子，例如scans，joins，sorts，aggregations等等，但是这里提出了一个新的算子motion，motion算子用描述数据如何在节点之间传递的。

在制定执行计划阶段，QD会根据catalog考虑数据的分布情况来制定比较合理的计划。例如，join算子，在进行计算时，数据可能会进行重新分布，来满足join算子的输入条件。数据的重新分布往往涉及到CPU开销以及网络带宽开销，那么在制定计划阶段就需要去权衡，选择CPU开销小同时网络开销也相对小的方案。

对于Motion算子的类型大概有三种类型:

• Broadcast Motion(N:N)，每个segment将数据广播给其他的segments。
• Redistibute Motion(N:N)，每个Segement将数据进行hash，分布到各个Segements中。
• Gather Motion(N:1)，每个Segement将数据发送给其中的一个segment。

一个具体的执行实例如下：
SELECT l_orderkey, count(l_quantity)
FROM lineitem, orders
WHERE l_orderkey=o_orderkey AND l_tax>0.01
GROUP BY l_orderkey;
其具体执行计划如下图3-1所示：

其中一个slice表示可以在同一个segments里执行的执行计划。左边由于数据分布基于hash进行分布，所以所有分片的join操作均可以并行执行，只有在最后的Gather motion需要节点之间的数据交互，右边的执行计划由于表的分布并没有按照统一的hash规则进行，所以，在做join之前需要对数据进行重新分布，于是就有了Redistributie Motion算子，之后的流程就和左边的图（a）类似。每个QE具体的执行交互流程图如下图3-2所示:

每一次数据交换就涉及到motion算子的执行，在每个节点内部，对于数据的发送和接收的状态转换图如下图3-3所示：

在集群比较大的情况下，如果采用TCP连接会发现发送的端口资源不够用(TCP interconnect is limited by the number of slices it can support due tothe port number limitation of TCP (about 60k per IP address) and time consuming connection setup step for a large number of concurrent connections. For example, with 1,000 segments, a typical5-slice query needs to set up about 3 million connections, and on each node, there are thousands of connections.)

所以HAWQ系统基于UDP开发了一套应用层可靠协议，协议具体满足如下特性：Reliability，Ordering，Flow control，Performance and scalability，Portability。

论文原文：HAWQ: A Massively Parallel Processing SQL Engine in
Hadoop