分析型数据库：MPP 数据库的概念、技术架构与未来发展方向

随着企业数据量的增多，为了配合企业的业务分析、商业智能等应用场景，从而驱动数据化的商业决策，分析型数据库诞生了。由于数据分析一般涉及的数据量大，计算复杂，分析型数据库一般都是采用大规模并行计算或者分布式计算来提升它的数据处理能力。本篇文章将详细介绍 MPP 数据库的概念，解决的问题、典型的厂商以及它的技术架构和未来的发展方向。

— MPP 数据库简介—

分析型数据库是数据库的一个分支，主要设计目标是存储、管理和分析数据，一般存储的数据类型多，时间维度长，主要配合企业的业务分析、商业智能等应用场景，驱动数据化的商业决策。由于数据分析一般涉及的数据量大，计算复杂，分析型数据库一般都是采用大规模并行计算或者分布式计算来提升它的数据处理能力。行业内从 1984 年开始推出基于多个关系数据库（Postgres 为主）组成的 MPP 数据库方式来提升计算能力，代表性的产品有 Teradata、Netezza、Vertica 等。MPP 全称为 Massive Parallel Processing，是一种并行化的编程模型，其思想是通过管理来协调的，由多个处理单元并行处理一个程序中的不同部分，从而最终完成整个程序的计算模式。每个处理单元有自己独立的运行环境和资源。MPP 数据库中每个处理单元就是一个关系数据库，通过大规模并行的关系数据库的协同来提升数据库能够处理的数据的量级和性能。基本上每个主流的关系数据库厂商都有自己的 MPP 版本，另外也有一些主要开发 MPP 的数据库厂商和开源的 MPP 数据库，国内近几年也涌现了不少的 MPP 数据库。

— 总体架构 —

MPP 数据库一般会包含多个控制节点和多个计算节点，控制节点负责计算任务的编译、执行计划的生成和计算结果的聚合，而计算节点负责计算划分到具体数据库实例的计算任务。为了更好的可扩展性，MPP 数据库一般采用 Shared-nothing 架构，每个数据库节点之间没有数据共享。MPP 数据库一般可以通过增加数据库计算能力，此外因为多个实例，数据库总体的数据加载性能相比较单实例数据库也有很高的提升。

数据分片是能够实现并行化计算的核心，MPP 数据库有多种数据分片方式，主要包括 3 大类：

• Hash 模式

一般适用于事实表或大表，根据一条记录的某个字段或组合字段的 hash 值将数据分散到某个节点上，hash 函数可以有多种方式。通过根据对给定字段的 hash 值来做数据分布，一个大表可以均匀的分散到 MPP 数据库的多个节点上，当对这个表查询时，MPP 数据库编译器可以根据 SQL 中相应的检索字段将查询快速定位到某个或几个相关的数据库节点并将 SQL 下发，对应的数据库节点就可以快速响应查询结果。Hash 模式在真实生产中使用的比较多，不过它也有几个较明显的问题：一是 Hash 取值一般是跟数据库节点数量密切相关，如果数据库添加或者减少节点后，那么已经存在的数据的 Hash 分布就不再正确，因此需要做数据库的数据重分布，带来较大的运维成本；二是在实际操作中需要根据业务特点来设计或选择 Hash 字段，否则容易出现性能热点等影响数据库整体性能的问题。

• 均匀分布模式

一般适用于一些过程中的临时表，在对表的数据的持久化过程中按照均匀分布的方式在每个数据库节点上均匀写入数据。这个模式下数据库的 IO 吞吐可以得到最大化利用，无论是读取还是写入，仅适合表只做一次读写的场景。

• 全复制模式

一般适合记录数比较少的表，一般情况下在各个数据库节点都完整的存储一份数据。这类表一般情况下用于大量的分析类场景，事务类操作比较少，因此虽然存储上有明显的浪费，但是在分析性场景下不再需要将这个表在多个数据库节点上传输或复制，从而提升分析性能。

基于数据分片的方式实现了数据无共享架构，因此可以通过增加数据库实例的方式来提升数据库的性能，因此与早期的 SMP 共享架构数据库（典型代表 Oracle RAC）相比，MPP 数据库的分析性能要远远超出。此外数据库的整体并发响应，以及数据库的读写吞吐量，MPP 数据库都能够通过有效的业务优化达到一个很高的水平。在 MPP 数据库的可扩展性方面，从中国信通院的相关测试来看，开源的 MPP 数据库能够支持一百节点左右的集群规模，而一些商业 MPP 数据库通过更好的软硬件结合已经可以实现单集群达到五百个节点。

— 开源 MPP 数据库 Greenplum —

Greenplum 是以 PostgreSQL 为单实例的 MPP 数据库，于 2003 年诞生，在 2012 年之后演进成为 Pivotal Greenplum Database。Greenplum 用于存储、处理海量的数据，主要用于 OLAP 业务。Greenplum 采用 MPP 架构，底层的逻辑数据库采用 PostgreSQL，客户端支持 psql 和 ODBC。

Greenplum 集群中有三种角色组件，Master、Segment、Interconnect。数据的分片方式以及 SQL 计算的分解/聚合和通用的 MPP 数据库原理基本一致，在此不做赘述。Master 是 Greenplum 数据库系统的入口，接受客户端连接及提交的 SQL 语句，将工作负载分发给其它数据库实例（segment 实例），由它们存储和处理数据。Master 也负责持久化和查询系统级元数据，负责认证用户连接，接收来自客户端的 SQL 处理请求，最终汇总 Segments 的结果并返回客户端。Master Server 本身采用主备方式来保证高可用。Segment 是独立的 PostgreSQL 数据库，负责数据存储和分析的具体执行，集群中的数据分布在各个 Segment 上，用户不直接与 Segment 通信，而是通过 Master 交互。每个 Segment 的数据冗余存放在另一个 Segment 上，数据实时同步，当 Primary Segment 失效时，Mirror Segment 将自动提供服务。Interconnect 负责不同 PostgreSQL 实例之间的通信，它默认使用 UDP 协议以提供更好的网络性能，并通过对数据包的检验来保证可靠性。从 2019 年中国信通院组织的分析数据库基准测试结果来看，一共有 14 个产品通过测试，其中 6 个产品是基于 Greenplum 来二次开发的，这说明了 Greenplum 是开源 MPP 数据库的最受欢迎项目。除了本身开源以外，Greenplum 在以下几方面也比较独特：

• SQL 兼容度：由于 Greenplum 基于 PostgreSQL 内核，因此其本身保持了关系数据库的特性以及 SQL 的兼容性，以及与 PostgreSQL 相似的安全和权限模型。此外，Greenplum 支持完整的分布式事务操作和 MVCC，因此在事务相关操作上也兼容标准 SQL 语义。

• 分析性能：在 SQL 优化方面， GPORCA 优化器是基于代价的优化器的一个出色的开源项目，为各种复杂的分析 SQL 有个极佳的执行计划。

• 并行数据加载：Greenplum 提供了并行加载的技术，其自带的 gpfdist 工具能够直接和每个 Segment 交互做并行导入。

• 开放式的架构：由于 PostgreSQL 能够支持插件化的方式来自定义数据类型、函数、存储过程等能力，Greenplum 也自然继承了这一特点，因此社区的开发者先后贡献了包括地理时空数据处理、机器学习、图分析、文本分析等在内的多个扩展模块，以及支持了 JSON、XML 等半结构化数据类型。

由于 Greenplum 数据库仍然是基于典型的 MPP 架构，因此 MPP 数据库的规模问题（单个集群规模在 200 节点以内）、多租户资源隔离问题、落后者问题等仍然存在，因此在支撑大型企业的多个业务场景时存在较大的技术挑战。由于其比较良好的 SQL 兼容、分布式事务、优秀的优化器等能力，Greenplum 可以比较好的支持一些中小型企业的结构化数据分析任务。Greenplum 自身也在努力和云计算结合来解决多租户资源隔离问题，其已经和多个公有云厂商合作推出云上的数据库服务。另外，Greenplum 也在更加紧密的与 PostgreSQL 社区合作，积极的跟进其最新的功能。

— MPP 数据库的架构问题与未来发展方向 —

MPP 数据库通过并行计算来解决了很多的数据分析的能力问题，不过也有它的架构缺陷，主要包括以下几个问题：数据的分布对业务的性能影响极大：在选择数据分布算法以及对应的分片字段的时候，不仅要考虑数据分布的均匀问题，还需要考虑到业务中对这个表的使用特点。如果多个业务的使用方式有明显差异，往往很难选择一个非常好的表分片字段，因此会导致一些因为数据或业务不均匀分布或跨节点数据 shuffle 可能引起的性能问题。落后者问题（又称 Straggler Node Problem）是 MPP 数据库的一个重要架构问题。工作负载节点（对 GPDB 而言是 Segment 节点）是完全对称的，数据均匀的存储在这些节点，处理过程中每个节点（即该节点上的 Executor）使用本地的 CPU、内存和磁盘等资源完成本地的数据加工。当某个节点出现问题导致速度比其他节点慢时，该节点会成为 Straggler。此时，无论集群规模多大，批处理的整体执行速度都由 Straggler 决定，其他节点上的任务执行完毕后则进入空闲状态等待 Straggler，而无法分担其工作，如下图所示 Executor 7 即为落后者并最终拖慢了整个集群。当集群规模达到一定程度时，故障会频繁出现使 straggler 成为一个常规问题。

集群规模问题：由于 MPP 的“完全对称性”，即当查询开始执行时，每个节点都在并行执行完全相同的任务，这意味着 MPP 支持的并发数和集群的节点数完全无关。在大数据时代，对于联机查询的并发能力要求增加非常迅速，也极大的挑战了 MPP 架构本身。此外，MPP 架构中的 Master 节点承担了一定的工作负载，所有联机查询的数据流都要经过该节点，这样 Master 也存在一定的性能瓶颈。因此很多 MPP 数据库在集群规模上是存在一定限制的。多租户资源隔离问题是 MPP 数据库一个非常难解决的一个架构问题。由于一个企业的 MPP 数据库一般支撑多个业务或多个租户，假如某个业务的部分 SQL 分析在数据库节点 Node 1 上产生了热点并占用了该节点绝大部分的资源，从而拖慢了所有的可能使用 Node 1 的其他租户或业务，导致整体业务服务能力恶化。从我们对行业的一些大型企业客户的调研结果看，这个问题是非常致命的问题，只能通过运维的手段来检测并关闭类似的热点 SQL 来缓解。更好的支撑 AI 程序处理半结构化或非结构化数据是 MPP 数据库的一个重要挑战，尤其是在人工智能相关的需求爆发后，NLP、智能识别等技术都需要有效的半结构化或非结构化数据的存储、检索和计算需求，而这些都不是关系数据库擅长的能力。随着硬件技术的快速发展，尤其是 SSD 和网络性能的大幅度提升，MPP 数据库厂商都开始基于这些新硬件技术来解决当前的软件架构问题，如采用更高速的网络来提升总体的可扩展性，解决集群规模存在上限的问题。另外部分 MPP 数据库重新设计其执行模式，调整其计算架构同时支持 MPP 和 DAG 模式，通过更加的执行计划和 Lazy Evaluation 方式来解决常见的“落后者”问题。此外，近几年 MPP 数据库厂商都在推动存算分离架构，让底层可以直接依赖云存储等方式，从而实现云化服务，并以此来实现多租户隔离等管理能力。

— 小结—

本文介绍了分析型数据库 MPP 数据库，它通过大规模并行的关系数据库的协同来提升数据库能够处理的数据的量级和性能。那么，分析型数据库的另外一个发展方向是以分布式技术来代替 MPP 的并行计算，一方面比 MPP 有更好的可扩展性，另一方面可以解决 MPP 数据库的几个关键架构问题，下篇我们将介绍分布式分析型数据库。