1.4 MPP架构的兴起
大数据解决方案中，在Hadoop分布式架构之外，还有一种流行的并行处理架构MPP。
1.4.1 什么是MPP架构
MPP（Massively Parallel Processing，大规模并行处理）是在数据库非共享集群中（传统的单节点不属于集群，双机热备或Oracle RAC等，均是基于共享存储的），每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，提供数据库服务。非共享数据库集群具备可伸缩性、高可用、高性能、高性价比、资源共享等优势。
简单来说，MPP架构是将任务并行地分散到多个服务器和节点上，在每个节点的计算完成后，将结果汇总在一起得到最终的结果。
从数据库技术架构的角度来说，分布式数据库架构分为Shared Everything、Shared Nothing和Shared Disk。Shared Everything一般是针对单个主机，完全透明共享CPU、内存、I/O，并行处理能力是最差的，典型代表是SQL Server。Shared Disk的代表是Oracle RAC，用户访问RAC就像访问一个数据库，而这背后是一个集群，RAC保证这个集群的数据一致性。Shared Nothing的典型代表就是Hadoop和Greenplum，二者在实现上有很大的不同。三者的架构差异如图1-6所示。
图1-6 完全共享、共享磁盘和MPP架构的对比
谈到MPP架构，就不得不和Hadoop架构进行对比。MPPDB与Hadoop都是将运算分布到节点中独立运算后进行结果合并（分布式计算），因依据的理论和采用的技术路线不同而有各自的优缺点和适用范围。二者主要是在资源管理上存在差异。与MPP架构相比，由于Hadoop资源管理器（YARN）可以提供更细粒度的资源管理，MapReduce作业也不需要并行运行所有计算任务，因此可以同时处理大量任务。实际上，Hadoop比MPP资源管理器慢，有时在管理并发性方面的效果并不好。表1-3所示是传统数据库、Hadoop和MPP数据库多个维度的对比。
表1-3 传统数据库、Hadoop和MPP数据库的对比
表1-3从侧面解释了为什么Hadoop不能完全替代传统企业数据仓库，而基于MPP架构的数据库可以在一定程度上替代Hadoop平台。Facebook虽然安装了300PB Hadoop，但仍然使用小型50TB Vertica群集，LinkedIn虽然拥有庞大的Hadoop群集，但仍然使用Aster Data群集（Teradata购买的MPP架构）。
1.4.2 MPP架构的蓬勃发展
近年来，MPP架构数据库蓬勃发展，MPP（Shared Nothing）架构已经变为分布式数据库的事实标准。基于MPP架构的Shared Nothing特性，数据库的扩展能力大大加强，将数据分而治之，从而提高数据库的插入、删除、查询性能。
MPP架构通常采用成熟的MySQL或者PostgreSQL作为底层数据存储和查询引擎，在中间层封装了管理、数据分发和数据共享功能，以实现多节点对用户透明的效果。一个服务节点上可以有多个MySQL或者PostgreSQL实例，以提高CPU的利用率。目前，最大的MySQL集群有上万台节点。表1-4所示是笔者整理的主流MPP架构数据库介绍。
表1-4 主流MPP架构数据库介绍
列举了这么多MPP数据库，其中大部分是国产开源或者国产商业化的，一方面是想告诉读者，MPP架构真的很火，在MySQL/PostgreSQL集群上面加一个MPP的壳（包括管理功能、数据分发功能、查询优化功能等），就可以衍生出一款新的高并发、易扩展、PB级容量的数据库；另一方面，也是想让大家了解这个趋势，这些数据库大多和云厂商绑定了，并且在特定的场景下接受过严酷的考验，可以满足大多数应用需求。
大家也不要被各厂商的“自主研发”“100%自助知识产权”所吓倒，大部分数据库还是基于MySQL或者PostgreSQL研发的，“虽然是基于开源数据库，但已经对开源代码进行了大量修改，在很大程度上接近于自研”（引用华为的介绍）。不过在笔者看来，这也不是坏事，遍地开花的数据库，结合云生态，可以大幅降低企业的IT成本，帮助企业实现去IOE，并且满足未来的业务发展需求。
1.4.3 MPP数据库代表—TBase
本节以腾讯TBase为例，详细介绍MPP数据库的架构原理。以下内容整理自TBase官网文档。
TBase是腾讯数据平台团队在开源的PostgreSQL基础上研发的企业级分布式HTAP数据库管理系统。TBase在提供NewSQL便利性的同时，完整支持分布式事务并保持SQL兼容性，支持RR、RC、SSI三种隔离级别，同时兼容Oracle语法。对于日益多元化的企业客户，TBase满足了他们对业务融合、场景融合、管理融合的更高诉求。强大的安全和容灾能力，让TBase成功应用于腾讯内部的微信支付，以及外部众多金融、政府、电信、医疗等行业的核心业务系统。2020年7月13日，TBase发布了开源版本2.1.0，该版本在多活分布式能力、性能、安全性、可维护性等多个关键领域得到全面的增强和升级，复杂查询性能提升了10倍以上。
集群有3种节点类型，各自承担不同的功能，通过网络连接成为一个系统。系统架构如图1-7所示。
图1-7 腾讯TBase物理架构
这3种节点类型如下。
1）Coordinator：协调节点对外提供接口，负责数据的分发和查询规划，多个节点位置对等，每个节点都提供相同的数据库视图，协调节点存储系统的全局元数据。
2）Datanode：数据节点处理存储本节点相关的元数据，每个节点还存储数据的一个分片。在功能上，Datanode负责完成执行协调节点分发的请求。
3）GTM：全局事务管理器（Global Transaction Manager）负责管理集群事务信息，同时管理集群的全局对象，比如序列。除此之外，GTM不提供其他的功能。
TBase主要实现功能如下。
1）分布式事务全局一致性能力：通过拥有自主知识产权的分布式事务一致性技术，包括两阶段提交以及全局时钟的策略来保证在全分布式环境下的事务一致性。
2）SQL兼容能力：支持SQL2003标准、PostgreSQL语法、常用Oracle函数及数据类型、UDF/UDAF、常见窗口函数、JSON/JSONB/XML/数组等多种NoSQL类型、递归WITH、无锁DDL操作、扩展插件等。
3）HTAP能力：提供OLTP及OLAP两个平面视角，OLTP业务运行在Datanode主节点上，OLAP业务运行在Datanode节点的备份节点上，二者的数据同步采用流复制的方式进行。
4）读写分离能力：提供了读写和只读两个平面视角，读写流量请求由主节点处理，只读流量请求由备份节点处理，主备节点的数据同步采用流复制的方式进行。
5）卓越的数据安全保障能力：通过三权分立体系，将传统数据库系统DBA的角色分解为3个相互独立的角色，即安全管理员、审计管理员和数据管理员。基于此提出的安全策略，主要细分为3个部分，即数据加密、数据脱敏访问、强制访问控制，三者组合后提供多个层级的数据安全保障能力，如图1-8所示。
图1-8 TBase数据安全体系
6）高效的数据治理能力：数据倾斜治理可以解决数据分布不均带来的存储以及性能压力；冷热数据分级存储可以降低业务的存储成本、提升热数据的性能。
7）多核并行计算能力：节点内部采用并行计算，根据表的大小同时启动多个进程来协同完成一个查询任务。
8）多租户能力：基于节点组的集群内多租户解决方案，实现数据库集群内部的业务和资源隔离，多个业务在TBase内部相互隔离运行。
9）多级容灾能力：采用强同步复制机制保证主从数据完全一致，保障主节点故障时数据不会丢失；提供基于任意时间点的恢复特性以防止误操作带来的数据丢失。
10）在线扩容能力：通过引入shard map层（用于存储shardid和Datanode的映射关系），在新加节点时，只需要把一些shard map中的shardid映射到新加的节点上，并把对应的数据迁移过去，大大缩短了扩容时间。
11）丰富的周边生态能力：PostGIS、异构数据复制、LVS负载均衡、FDW联邦能力等。
1.4.4 浅谈HTAP
在数据库中，数据处理可分为两类—联机事务处理（OLTP）和联机分析处理（OLAP）。联机事务处理是传统关系型数据库的主要应用，用来执行一些基本的、日常的事务，比如数据库增、删、改、查等，而联机分析处理则是分布式数据库的主要应用，虽然它对实时性要求不高，但处理的数据量大，通常应用于复杂的动态报表系统上。二者的主要区别如表1-5所示。
表1-5 OLTP和OLAP对比
同时维护OLTP和OLAP两套系统，不仅会造成数据冗余存储，而且成倍增加了系统的运维成本。同时，由于OLAP系统的数据依赖于ETL通过数据复制功能从OLTP系统同步数据，因此时效性受到了很大的影响。于是业界提出了在线事务处理/在线分析处理（Hybrid Transactional/Analytical Processing，HTAP）的概念。
从单个数据库的能力上看，HTAP确实是未来的趋势，即OLTP和OLAP需要在一定程度上进行融合。早期的Oracle、DB2数据库都是同时具有OLTP和OLAP功能的。从Hadoop时代开始，为了提高OLAP的性能，衍生出了MapReduce和Hive。为了提高OLTP的性能，衍生出了HBase，从此OLTP和OLAP分道扬镳。从实际应用的角度看，Hive广泛用于数据仓库的批处理平台，但是完全不支持OLTP功能，在某些场景下也是很不方便的，而HBase则无法满足批量查询要求。
从OLTP和OLAP的能力维度评价各主流数据库如图1-9所示。
图1-9 从OLAP和OLTP的角度看主流数据库
近年来，虽然实时数仓非常火热，但是实现起来只是差强人意。如果有一款用于批处理的OLAP数据平台，同时又具备较好的OLTP性能，可以满足当日数据通过Kafka源源不断地写入，并且高效地被前端应用查询到，那么我们是不是就能很好地实现流批一体、流批结合了呢。
从实际情况来看，还没有这样一款成熟并且广泛应用的数据库出现。这种应用场景要求数据平台以OLAP为主，兼顾OLTP的需求，目前做得比较好的有Doris、Greenplum、Impala+Kudu组合。
大型交易数据也会有一些批量查询需求，从目前的情况看，这类需求并没有被很好地满足，也是一个需要技术突破的地方。目前大多数号称已经是HTAP数据库的厂商都是在满足OLTP性能的基础上，增强OLAP查询能力。例如腾讯的TBase、PingCAP的TiDB、SAP的HANA、阿里的OceanBase等。
OceanBase是由蚂蚁金服、阿里巴巴完全自主研发的金融级分布式关系型数据库，始创于2010年。OceanBase具有数据强一致、高可用、高性能、在线扩展、高度兼容SQL标准和主流关系数据库、低成本等特点。OceanBase至今已成功应用于支付宝全部核心业务：交易、支付、会员、账务等系统以及阿里巴巴淘宝收藏夹、P4P广告报表等。除在蚂蚁金服和阿里巴巴业务系统中广泛应用外，从2017年开始，OceanBase开始服务外部客户。
值得称赞的是，2020年5月，OceanBase以7.07亿的TPM-C评测成绩再次夺冠，将自己之前创造的纪录提升了近11倍。2021年5月，OceanBase再次以1526万QphH的性能总分夺冠数据分析型基准测试（TPC-H）30000GB级。这意味着，OceanBase成为唯一在OLTP和OLAP两个领域性能测试中都获得第一的中国自研数据库。