从架构特点到功能缺陷，重新认识分析型分布式数据库 (juejin.cn)
###################################
MPP on HDFS
这是MPP架构分布式数据库的简单示意图。MPP数据库通过将数据切片分布到各个计算节点后并行处理来解决海量数据分析的难题。每个MPP数据库集群由一个主节点（为了提供高可用性，通常还会有一个从主节点）和多个计算节点组成。主节点和每个计算节点都有自己独立的CPU，内存和外部存储。主节点负责接收客户端的请求，生成查询计划，并将计划下发到每个计算节点，协调查询计划的完成，最后汇总查询结果返回给客户端。计算节点负责数据的存储以及查询计划的执行。计算节点之间是没有任何共享依赖的（shared nothing）。查询在每个计算节点上面并行执行，大大提升了查询的效率。
我们接下来要讲的开源分布式数据库Greenplum Database就是基于PostgreSQL的MPP数据库。对应到这个架构图，每个节点上面的数据库实例可以简单的认为是一个PostgreSQL实例。
我们首先通过一条简单的查询，感性地认识一下Greenplum Database是如何执行一条查询的。
下略
。。。
。。。
介绍完Greenplum Database的查询组件和系统状态组件后，我们再看看它是如何提供高可用性的。首先是管理节点的高可用。我们采取的方式是，启动一个称为Standby的从主节点作为主节点的备份，通过同步进程同步主节点和Standby节点两者的事务日志，在Standby节点上重做系统表的更新操作，从而实现两者在全局系统表上面的信息同步。当主节点出故障的时候，我们能够切换到Standby节点，系统继续正常工作，从而实现管理节点的高可用。
计算节点高可用性的实现类似于管理节点，但是细节上有些小不同。每个Segment实例都会有另外一个Segment实例作为备份。处于正常工作状态的Segment实例我们称为Primary，它的备份称为Mirror。不同于管理节点日志重放方式，计算节点的高可用是通过文件复制来实现的。对于每一个Segment实例，它的状态以文件的形式保存在本地存储介质中。这些本地状态可以分成三大类：本地系统表、本地事务日志和本地表分区数据。通过以文件复制的方式保证Primary和Mirror之间的状态一致，我们能够实现计算节点的高可用。
Hadoop出现之前，MPP数据库是为数不多的大数据处理技术之一。随着Hadoop的兴起，特别是HDFS的成熟，越来越多的数据被保存在HDFS上面。一个自然的问题出现了：我们怎样才能高效地分析保存在HDFS上面的数据，挖掘其中的价值。4，5年前，SQL-on-Hadoop远没有现在这么火，市场上的解决方案也只有耶鲁大学团队做的Hadapt和Facebook做的Hive，像Impala，Drill，Presto，SparkSQL等都是后来才出现的。而Hadapt和Hive两个产品，在当时无论是易用性还是查询性能方面都差强人意。
我们当时的想法是将Greenplum Database跟HDFS结合起来。与其它基于connector连接器的方式不同，我们希望让HDFS，而不是本地存储，成为MPP数据库的数据持久层。这就是后来的Apache HAWQ项目。但在当时，我们把它叫做Greenplum on Hadoop，其实更准确的说法应该是，Greenplum on HDFS。当时的想法非常简单，就是将Greenplum Database和HDFS部署在同一个物理机器集群中，同时将Greenplum Database中的Append-only表的数据放到HDFS上面。Append-only表指的是只能追加，不能更新和删除的表。这是由于HDFS本身只能Append的属性决定的。