为何选MPP架构？

介绍

像Greenplum（GPDB），ClickHouse，Impala，Presto，Tidb，Greenplum衍生物AnalyticDB PostgreSQL（adbpg）等都是采用MPP架构的，采用MPP架构的很多OLAP引擎号称：亿级秒开，正因为MPP引擎逐渐表现出强大的高吞吐、低时延计算能力；

MPP即大规模并行处理结构，是由多台SMP服务器通过一定的节点互联网络进行连接，协同工作，完成相同的任务，从用户的角度来看是一个服务器系统。每个节点只访问自己的资源，所以是一种完全无共享（Shared Nothing）结构。

MPP结构扩展能力最强，它最早出现是为了解决关系型数据库扩展性差的问题，消除共享存储。由于MPP是多台SPM服务器连接的，每个节点都有独立的磁盘存储系统和内存系统每个节点的CPU不能访问另一个节点内存，所以也不存在异地访问的问题。

MPP架构图：

虽然MPP虽然具有扩展性，但是节点我理解实际上不会无限扩展，市面上MPP架构的集群规模也并不会太大；对于MPP架构来说，因为task和Executor是绑定的，如果某个Executor执行过慢或故障，将会导致整个集群的性能就会受限于这个故障节点的执行速度(所谓木桶的短板效应)，所以MPP架构的最大缺陷就是——短板效应。另一点，集群中的节点越多，则某个节点出现问题的概率越大，而一旦有节点出现问题，对于MPP架构来说，将导致整个集群性能受限，所以一般实际生产中MPP架构的集群节点不易过多，这也是我们看到很多存储都有节点上限。再考虑硬件的损耗，维护成本居高不下。

架构特征&机制

MPP是多机可水平扩展的架构，符合“分布式”的基本要求；上面也说了每个节点只访问自己的资源，所以是一种完全无共享（Shared Nothing）架构。

一般来说，MPP架构特征：

• 分布式计算;
• 数据分布式存储(本地化);
• 任务并行执行，
• 一定的并发访问能力；
• 横向扩展，支持集群节点的扩容;
• Shared Nothing（完全无共享）架构。

GPDB具有较高的开源程度，通过分析他来分析MPP架构工作机制；GPDB属于主从架构，Slave称为Segment是主要的数据加工节点，是在PostgreSQL基础上的封装和修改，天然具备事务处理的能力，可进行水平扩展；集群内有唯一Active状态的Master节点，除了元数据存储和调度功能外，同时承担一定的工作负载，即所有外部对集群的数据联机访问都要经过Master节点；

在高可靠设计方面，首先设置了Standby Master节点，可以通过外部的HA监控模块发现并激活，在Master节点宕机时接管其任务，其次将Segment节点则细分为两类不同角色Primary和Mirror，后者是前者的备节点，数据提交时在两者间进行强同步，以此保证Primary宕机时，Mirror可以被调度起来接替前者的任务。

并发

由于MPP的“完全对称性”，即当查询开始执行时，每个节点都在并行的执行完全相同的任务，这意味着MPP支持的并发数和集群的节点数完全无关；看下面计算公式：rds_segment_expansion_coeff 并行最大倍数上限，是个默认固定值

通过外面的测试数据，几个节点的集群和上百个节点的集群支持的并发查询数是相同的，随着并发数增加，这二者几乎在相同的时点出现性能骤降。笔者在使用adbpg时候也发现了，随着节点的扩充，单个节点的并发数增加，在一定的时候，水位飙升，都会出现性能骤降情况；

传统MPP的联机查询主要面向企业管理层的少数用户，对并发能力的要求较低。而在大数据时代，数据的使用者从战略管理层转向战术执行层乃至一线人员，从孤立的分析场景转向与业务交易场景的融合。对于联机查询的并发能力已经远超传统MPP时代，这也是分布式数据库要考虑的一个重要问题。

除上述两点以外，通过adbpg来看，架构中的Master节点承担了一定的工作负载，所有联机查询的数据流都要经过该节点，这样Master也存在一定的性能瓶颈。同时，在实践中adbpg对数据库连接数量的管理也是非常谨慎的，虽然adbpg本身也支持了多master。Pivotal专家给出了一个建议的最大值且不会随着集群规模扩大而增大。

横向扩展

上面也提到了短板效应，相比MapReduce，MapReduce如果某个Executor执行过慢，那么这个Executor会慢慢分配到更少的task执行，批处理架构有个推测执行策略，推测出某个Executor执行过慢或者有故障，则在接下来分配task时就会较少的分配给它或者直接不分配；MPP后续结合这种能力融合进来，我理解会更加强大。

当然相比MapReduce，MPP架构性能上也是有很大优势的，它不需要将中间数据写入磁盘，因为一个单一的Executor只处理一个单一的task，因此可以简单直接将数据stream到下一个执行阶段。这个过程称为pipelining，它提供了很大的性能提升。

举个例子：要实现两个大表的join操作，对于批处理而言，如Spark将会写磁盘3次(第一次写入：表1根据join key进行shuffle；第二次写入：表2根据join key进行shuffle；第三次写入：Hash表写入磁盘)， 而MPP只需要一次写入(Hash表写入)。这是因为MPP将mapper和reducer同时运行，而MapReduce将它们分成有依赖关系的tasks(DAG),这些task是异步执行的，因此必须通过写入中间数据共享内存来解决数据的依赖。

Share Nothing

数据库架构设计的三种模式：share nothing , share everythong , share disk

数据库构架设计中主要有Shared Everthting、Shared Nothing、和Shared Disk：

• Shared Everthting:一般是针对单个主机，完全透明共享CPU/MEMORY/IO，并行处理能力是最差的，典型的代表SQLServer
• Shared Disk：各个处理单元使用自己的私有 CPU和Memory，共享磁盘系统。典型的代表Oracle Rac， 它是数据共享，可通过增加节点来提高并行处理的能力，扩展能力较好。其类似于SMP（对称多处理）模式，但是当存储器接口达到饱和的时候，增加节点并不能获得更高的性能 。
• Shared Nothing：各个处理单元都有自己私有的CPU/内存/硬盘等，不存在共享资源，类似于MPP（大规模并行处理）模式，各处理单元之间通过协议通信，并行处理和扩展能力更好。典型代表DB2 DPF和Hadoop ，各节点相互独立，各自处理自己的数据，处理后的结果可能向上层汇总或在节点间流转。我们常说的 Sharding 其实就是Share Nothing架构，它是把某个表从物理存储上被水平分割，并分配给多台服务器（或多个实例），每台服务器可以独立工作，具备共同的schema，比如MySQL Proxy和Google的各种架构，只需增加服务器数就可以增加处理能力和容量。最后总的来说，MPP架构或许也有短板效应，现在也有方案解决，比如HAQW， 但凭借着在一定大数据下强大的高吞吐、低时延计算能力等，相比而言MPP架构还是很多存储的选择。