一、OLTP与OLAP区别

OLTP(OnLine Transaction Processing ，联机事务处理)系统

例如mysql。擅长事务处理，在数据操作中保持着很强的一致性和原子性 ，能够很好的支持频繁的数据插入和修改 ，但是，一旦数据量过大，OLTP便力不从心了。

OLAP(On-Line Analytical Processing，联机分析处理)系统

例如Greenplum。不特别关心对数据进行输入、修改等事务性处理，而是关心对已有的大量数据进行多维度的、复杂的分析的一类数据系统 。

二、MPP（Massively Parallel Processing）数据库是什么

MPP架构是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果。采用MPP架构的数据库称为MPP数据库。

大规模并行分析（MPP）数据库（Analytical Massively Parallel Processing (MPP) Databases）是针对分析工作负载进行了优化的数据库：聚合和处理大型数据集。MPP数据库往往是列式的，因此MPP数据库通常将每一列存储为一个对象，而不是将表中的每一行存储为一个对象（事务数据库的功能）。这种体系结构使复杂的分析查询可以更快，更有效地处理。

这些分析数据库将其数据集分布在许多机器或节点上，以处理大量数据（因此得名）。这些节点都包含自己的存储和计算功能，从而使每个节点都可以执行查询的一部分。

在过去的十年中，分析MPP数据库的激增和成本下降为数据驱动型组织提供了巨大的机会来运营和分析比以往更大的数据集。这些数据库是不断壮大的分析师工具包的绝妙补充，但同时也为体系结构带来了额外的复杂性。

三、为什么需要MPP数据库

3.1 海量数据的分析需求

传统数据库无法支持大规模集群与PB级别数据量，单台机器性能受限、成本高昂，扩展性受限。
MPP数据库非常擅长最常见的分析工作负载，这些工作负载通常以对子集的查询为特征，并在广泛的行范围内进行汇总。这是由于它们的列式体系结构允许他们仅访问完成查询所需的字段（与事务性数据库相反，事务性数据库必须连续访问所有字段）。

列式体系结构还为MPP数据库提供了对分析工作负载有用的其他功能。这些功能因数据库而异，但通常包括压缩类似数据值，有效索引非常大的表以及处理宽的非规范化表的功能。

3.2 支持复杂的结构化查询（这里是重点）

复杂查询经常使用多表联结、全表扫描等，牵涉的数据量往往十分庞大；支持复杂sql查询和支持大数据规模；

3.3 Hadoop技术的先天不足

Hive等sql-on-hadoop性能太慢，分析场景不一样，SQL兼容性与支持不足

四、MPP数据库应用领域

4.1 大数据分析

MPP数据库做大数据计算或分析平台非常适合，例如:数据仓库系统、历史数据管理系统、数据集市等。

有很强的并行数据计算能力和海量数据存储能力，但是他不擅长高频的小规模数据插入、修改、删除，每次事务处理的数据量不大。这类数据衡量指标是TPS，适用的系统是OLTP数据库。

所以，报表统计分析、运维统计数据，快速生成报表展示都可以使用mpp数据库。

符合几个条件：不需要更新数据，不需要频繁重复离线计算，不需要并发大。

有上百亿以上离线数据，不更新，结构化，需要各种复杂分析的sql语句，那就可以选择他。几秒、几十秒立即返回你想要的分析结果。例如sum，count，group by，order，好几层查询嵌套，在几百亿数据里分分钟出结果

4.2 数据集中化

组织通常使用分析型MPP数据库作为数据仓库或集中式存储库，其中包含组织内部生成的所有数据，例如交易销售数据，Web跟踪数据，营销数据，客户服务数据，库存/后勤数据，人力资源/招聘数据以及系统日志数据。由于分析MPP数据库可以处理大量数据，因此组织可以轻松地依靠这些数据库来存储数据，还可以支持来自这些各种业务功能的分析工作负载。

4.3 线性可伸缩性

通过向系统添加更多服务器，分析MPP数据库可以轻松地线性扩展其计算和存储功能。这与垂直扩展计算和存储功能相反，后者涉及升级到更大，功能更强大的单个服务器，并且通常会在规模上遇到障碍。分析型MPP数据库能够如此快速，轻松和高效地进行横向扩展，以使按需数据库供应商能够根据查询的大小自动执行该过程来按比例放大或缩小系统。

五、MPP数据仓库解决方案

5.1 自我管理的MPP数据库

HPE Vertica

MemSQL

Teradata

5.2 按需MPP数据库

Amazon Redshift

Azure SQL数据仓库

Google BigQuery

雪花

Greenplum

六、Greenplum

6.1 Greenplum 介绍

Greenplum是基于数据库分布式架构的开源大数据平台，采用无共享(no shareing)的MPP架构，具有良好的线性扩展能力，具有高效的并行运算、并行存储等特性。拥有独特的高效的ORCA优化器。兼容SQL语法。适合用于高效PB数据量级的存储、处理和实时分析能力。由于内核是基于PostgreSQL数据库，也支持涵盖OLTP型业务混合负载。同时数据节点和主节点都有自己备份节点。提供数据库的高可用性。

6.2 Greenplum特性

1. 支持海量数据存储和处理
2. 高性价比
3. 支持Just In Time BI：通过准实时、实时的数据加载方式，实现数据仓库的实时更新，进而实现动态数据仓库（ADW），基于动态数据仓库，业务用户能对当前业务数据进行BI实时分析（Just In Time BI）
4. 系统易用性
   • 支持主流的sql语法，使用起来十分方便，学习成本低
   • 扩展性好，支持多语言的自定义函数和自定义类型等
   • 提供了大量的维护工具，使用维护起来很方便
   • 在internet上有这丰富的postgreSQL资源供用户参考
5. 支持线性扩展：采用MPP并行处理架构。在MPP结构中增加节点就可以线性提供系统的存储容量和处理能力
6. 较好的并发支持及高可用性支持除了提供硬件级的Raid技术外，还提供数据库层Mirror机制保护，也将每个节点的数据在另外的节点中同步镜像，单个节点的错误不影响整个系统的使用。对于主节点，还提供Master/Stand by机制进行主节点容错，当主节点发生错误时，可以切换到Stand by节点继续服务
7. 支持MapReduce计算引擎
8. 支持数据库数据内部压缩

6.3 Greenplum 架构

GPDB是典型的Master/Slave架构，在Greenplum集群中，存在一个Master节点和多个Segment节点，每个节点上可以运行多个数据库。Greenplum采用shared nothing架构（MPP），典型的Shared Nothing系统汇集了数据库、内存Cache等存储状态的信息，不在节点上保存状态的信息。节点之间的信息交互都是通过节点互联网络实现的。通过将数据分布到多个节点上来实现规模数据的存储，再通过并行查询处理来提高查询性能。每个节点仅查询自己的数据，所得到的结果再经过主节点处理得到最终结果。通过增加节点数目达到系统线性扩展。

Greenplum 架构示意图

Greenplum 架构示意图

上图为GPDB的基本架构，客户端通过网络连接到gpdb，其中Master 是GP的主节点（客户端的接入点），Segment Host是子节点（连接并提交SQL语句的接口），主节点不存储用户数据，子节点存储数据并负责SQL查询。
主节点负责相应客户端请求并将请求的SQL语句进行转换，转换之后调度后台的子节点进行查询，并将查询结果返回客户端。

6.3.1 Greenplum Master

• Master 是整个Greenplum数据库系统的入口，它接受连接和SQL查询并且把工作分布到Segment实例上。
• Master 是全局系统目录的所在地。全局系统目录是一组包含了有关Greenplum数据库系统本身的元数据的系统表。Master上不包含任何用户数据，数据只存在于Segment之上。Master会认证客户端连接、处理到来的SQL命令、在Segment之间分布工作负载、协调每一个Segment返回的结果以及把最终结果呈现给客户端程序。
• Master负责处理连接，通过元数据及统计信息生成执行计划，拆分执行计划，然后分发到segment，segment把自己执行的结果返回给master，master再返回给client。
• Greenplum的最小并行单元不是节点层级，而是在实例层级，在一个节点上有多个Postgresql数据库同时并行工作，可以充分利用到每个节点的所有CPU和IO能力。

Greenplum 功能：

• 访问系统的入口
• 数据库侦听进程（postgres）处理所有用户连接
• 建立查询计划，分发计划
• 协调工作处理过程
• 管理工具
• 系统目录表及元数据（数据字典）
• 不存放任何用户数据

Master高可用

Master高可用

Master高可用

Standby Master 实时与Primary Master节点的catalog和事务日志保持同步，Primary Master损坏时，Standby Master提供 Master服务，当原Primary Master节点恢复后状态将会是Standby。

6.3.2 Greenplum Segment

• Segment实例是独立的PostgreSQL数据库，每一个都存储了数据的一部分并且执行查询处理的主要部分。
• client 通过Master连接到数据库并且发出一个查询时，在每一个Segment数据库上都会创建一些进程来处理该查询的工作。
• 用户定义的表及其索引会分布在可用的Segment上，每一个Segment都包含数据的不同部分。服务于Segment数据的数据库服务器进程运行在相应的Segment实例之下。
• 一台Segment主机通常运行2至8个Greenplum的Segment，这取决于CPU核数、RAM、存储、网络接口和工作负载。
• Segment主机最好采用相同的配置，这样所有的Segment可以同时开始为一个任务工作并且同时完成它们的工作。木桶原理，整体性能取决于最差的那个segment。
• Segment存贮用户数据的部分，执行query，至少1CPU core、4G内存、单独网络接口。

Segment功能：

• 分段存放数据
• 一个segment host部署多个segment实例
• 实例级别的并行
• 一个系统多个段
• 用户不能直接访问段数据
• 所有对段的访问都要经过master
• 数据库监听进程(postgres)监听来自master 的连接
• 木桶效应

6.3.2.1 Segment 高可用

Segment 高可用

Segment 高可用

• 通过基于pg流复制来实现primary与mirror的一致，目前gp仅支持一个primary对应一个mirror。

• 如果是内存表则通过事务日志去应用。

• Append-optimized tables实时同步

• Primary Segment 失败后Mirror Segment 接管成为新的Primary Segment，原来的 Primary Segment 恢复后将成为新的Mirror Segment。

6.3.3 Greenplum Interconnect

• Interconect是Greenplum数据库架构中的网络层。
• Interconnect指的是Segment之间的进程间通信以及这种通信所依赖的网络基础设施。Greenplum的Interconnect采用了一种标准的以太交换网络。出于性能原因，推荐使用万兆网或者更快的系统。
• 默认情况下，Interconnect使用使用UDPIFC协议在网络上发送消息。Greenplum软件在UDP之上执行包验证。这意味着其可靠性等效于传输控制协议（TCP）且性能和可扩展性要超过TCP。如果Interconnect被改为TCP，Greenplum数据库会有1000个Segment实例的可扩展性限制。对于Interconnect的默认协议UDPIFC则不存在这种限制。
• UDPIFC协议=UDP+流控制（额外的数据验证），可靠性与TCP一致。
• 支持TCP、UDP、UDPIFC
• TCP限制segment数量是1000个
• 节点之间的数据传输
• 基于千兆以太网架构
• 属于系统内部私网配置
• 交换机冗余
• 网卡冗余

6.4 Greenplum核心组件

Greenplum 数据库包括以下核心组件：

组件	说明
解析器	主节点收到客户端请求后，执行认证操作。认证成功建立连接后，客户端可以发送查询给数据库。解析器负责对收到的查询SQL字符串进行词法解析、语法解析，并生成语法树。
优化器	优化器对解析器的结果进行处理，从所有可能的查询计划中选择一个最优或者接近最优的计划，生成查询计划。查询计划描述了如何执行一个查询，通常以树形结构描述。Greenplum最新的优化器叫 ORCA，关于 ORCA，可以从 ACM 论文中获得详细信息。http://dl.acm.org/citation.cfm?id=2595637&dl=ACM&coll=DL&CFID=569750122&CFTOKEN=89888184）
调度器（QD）	调度器发送优化后的查询计划给所有数据节点（Segments）上的执行器（QE）。调度器负责任务的执行，包括执行器的创建、销毁、错误处理、任务取消、状态更新等。
执行器（QE）	执行器收到调度器发送的查询计划后，开始执行自己负责的那部分计划。典型的操作包括数据扫描、哈希关联、排序、聚集等。
Interconnect	负责集群中各个节点间的数据传输。
系统表	系统表存储和管理数据库、表、字段的元数据。每个节点上都有相应的拷贝。
分布式事务	主节点上的分布式事务管理器协调数据节点上事务的提交和回滚操作，由两阶段提交（2PC）实现。每个数据节点都有自己的事务日志，负责自己节点上的事务处理。

6.5 Greenplum 和 PostgreSQL 的区别

1. Greenplum 在基于 Postgressql 查询规划器的常规查询规划器之外，可以利用GPORCA进行查询规划。
2. Greenplum 可以使用追加优化的存储。
3. Greenplum 可以选用列式存储，数据在逻辑上还是组织成一个表，但其中的行和列在物理上是存储在一种面向列的格式中，而不是存储成行。列式存储只能和追加优化表一起使用。列式存储是可压缩的。当用户只需要返回感兴趣的列时，列式存储可以提供更好的性能。 所有的压缩算法都可以用在行式或者列式存储的表上，但是行程编码（RLE）压缩只能用于列式存储的表。
4. Greenplum 在所有使用列式存储的追加优化表上都提供了压缩。