PostgreSQL GreenPlum HAWQ三者的关系及演变过程

这个日程安排同时也是我们公司核心团队的技术进阶史。公司创始团队成员有幸以核心开发者的角色参与，从单机版的关系型数据库（PostgreSQL），大规模并行处理（MPP）数据库（Greenplum Database）到SQL on Hadoop解决方案（Apache HAWQ），以及最新的SQL on Cloud数据仓库（HashData）。通过回顾这个技术演进的历程，我们将阐述如何一步一步地解决联机分析（OLAP）系统低延迟、高并发以及扩展性问题。

PostgreSQL

由于后面讨论的所有的分布式数据库，包括Greenplum Database，Apache HAWQ以及HashData云端数据仓库，都是基于单机版关系型数据库PostgreSQL的，所以我们首先简单介绍一下PostgreSQL，作为后续讨论的基础。

每个PostgreSQL数据库的实例包含一个PostMaster的damon进程和多个子进程,包括负责写出脏数据的BG Writer进程，收集统计信息的Stats Collector进程，写事务日志的WAL Writer进程，等等。

客户端应用通过libpq协议连接到PostMaster进程；PostMaster收到连接请求后，fork出一个子进程Postgres Server来处理来自这个连接的查询语句。Postgres Server进程的功能组件可以分成两大类：查询执行和存储管理。查询执行组件包括解析器、分析器、优化器以及执行器。在查询执行过程中，需要访问和更新系统状态和数据，包括缓存，锁，文件和页面等等。

Greenplum

 

 

作为一个单机版的关系型数据库，PostgreSQL更多地是作为联机事务处理（OLTP）系统使用的。当然，由于其丰富的分析功能，很多企业也会基于PostgreSQL来构建数据仓库，特别是在数据量不大的情况下。但是，随着数据量的增大，基于单机PostgreSQL构建的数据仓库就无法满足企业用户对查询响应时间的要求：低延迟。

为了解决这个问题，MPP架构就被引入了。这是MPP架构分布式数据库的简单示意图。MPP数据库通过将数据切片分布到各个计算节点后并行处理来解决海量数据分析的难题。每个MPP数据库集群由一个主节点（为了提供高可用性，通常还会有一个从主节点）和多个计算节点组成。主节点和每个计算节点都有自己独立的CPU，内存和外部存储。主节点负责接收客户端的请求，生成查询计划，并将计划下发到每个计算节点，协调查询计划的完成，最后汇总查询结果返回给客户端。计算节点负责数据的存储以及查询计划的执行。计算节点之间是没有任何共享依赖的（shared nothing）。查询在每个计算节点上面并行执行，大大提升了查询的效率。

我们接下来要讲的开源Greenplum Database就是基于PostgreSQL的MPP数据库。对应到这个架构图，每个节点上面的数据库实例可以简单的认为是一个PostgreSQL实例。

我们首先通过一条简单的查询，感性地认识一下Greenplum Database是如何执行一条查询的。

这是一条简单的两表等值连接语句。其中，customer表是维度表，表数据以cust_id作为hash分布的key；sales表是事实表，在这个例子中，我们可以认为它的表数据是round-robin的方式随机分布的，不影响查询的执行。

每个查询执行是一个由操作符组成的树。只看其中一个节点的话（如前面所说，每个计算节点就是一个PostgreSQL的实例），为了执行两表的等值连接，我们首先会将两表的数据分别扫描出来，然后基于维度表customer建立hash桶。对于每一条从sales表扫描出来的纪录，我们都会到hash桶去查。如果满足匹配条件，数据连接结果；否则，直接pass。

如前面提到的，在Greenplum Database中，每张表的数据按照hash分布或者随机分布打散到每个计算节点上面。在这个例子中，由于sales表是随机分布的，为了正确执行基于cust_id的等值连接，生成的执行计划会在table scan上面添加一个Redistribution motion节点。这个motion节点根据cust_id的hash值对数据作重分布，类似MapReduce中的shuffling。由于hash join操作是在每个节点上面分布式执行的，在将结果返回给客户端的时候，需要在主节点上面执行汇总操作。Gather motion的作用就在于将每个节点上面的中间结果集中到主节点上面。

对于这样一个并行的查询计划，我们会根据数据重分布的操作将整棵查询执行树切割成不同的子树。每个子树对应查询计划的一个阶段，我们称为slice。查询计划和slice是逻辑上的概念。