DMDPC 概述

1 引言

达梦分布计算集群英文全称 DM Distributed Processing Cluster，简称 DMDPC。

DMDPC 是基于达梦数据库管理系统研发的一款同时支持在线分析处理和在线事务处理的新型分布式数据库系统。它既具备传统单机数据库的绝大部分功能，又提供了分布式计算集群才拥有的高可用、高扩展、高性能、高吞吐量和对用户透明等高级特性。

DMDPC 关注和解决的是大数据、计算与存储分离、高可用、支持全部的 SQL 标准、拥有完整的事务处理能力和集群规模能够动态伸缩的业务场景。在这些场景中，用户经常会遇到以下问题：

• 大量的复杂查询操作要求优化器能够生成优良的执行计划，并且执行引擎能够充分利用多机器、多核的硬件资源；
• 某些行业对数据一致性和多副本备份容灾有较高要求，同时希望维护成本足够低和故障恢复时间足够短；
• 用户的业务规模有峰值，要求所需的机器资源能够灵活地添加和删除。

为了解决上述问题，DM 提供了全新的、一站式的分布式数据库解决方案 DMDPC。

本文档主要介绍 DMDPC 的系统架构、系统原理，系统特性，关键技术，并举例说明搭建过程和管理方法。

本手册可以帮助用户：

• 了解 DMDPC 相关概念
• 了解 DMDPC 如何通过 RAFT 协议保证高可用
• 了解 DMDPC 的动态扩展
• 了解 DMDPC 计划生成、子任务划分和通过动态性能视图来监控各子任务、各工作线程的执行情况
• 了解如何对 DMDPC 集群进行部署和使用

2 DMDPC 概述

本章重点介绍 DMDPC 的系统架构、系统原理和系统特性。

2.1 系统架构

DMDPC 架构旨在提供具有分布式特性的可扩展、高性能数据库解决方案，以满足具有高并发、大规模数据存储、业务快速扩张等特征的用户业务对数据库的要求。

2.1.1 DMDPC 架构

一个完整的 DMDPC 架构由计划生成节点 SP、数据存储节点 BP 和元数据服务器节点 MP 三部分组成。SP 对外提供分布式数据库服务，用户可以登录到任意一个 SP 节点，获得完整的数据库服务；BP 负责存储数据，执行 SP 的调度指令并将执行结果返回给 SP；MP 负责存储元数据并向 SP、BP 提供元数据服务。

SP 节点不存储数据，配置成单机即可。MP 和 BP 节点既可以配置成单机，也可以配置成多副本系统。其中每一个多副本系统中只有一个作为主节点，其余节点均作为备份节点。

下图是一个典型的 DMDPC 架构图。左侧为单机 DMDPC，右侧为配有多副本系统的 DMDPC。

图2.1 DMDPC架构和查询执行流程

2.1.1.1 计划生成节点

计划生成节点，英文全称为 SQL Processor，简称为 SP。

SP 为 DMDPC 集群中对外提供数据库服务的节点，负责接收用户请求并生成计划、划分子计划、按照一定规则计算并行度并调度各个子计划，并最终将执行结果返回给用户。对于一次客户端请求任务来说，客户端连接的 SP 负责生成、划分并调度计划，其它的 SP 和 BP 负责执行计划。各个子计划并行度的计算依据数据规模、计划代价以及有无分区智能连接优化（PWJ），且最大并行度值受限于 MAX_PARALLEL_DEGREE 参数。

SP 的实现是在已有的成熟达梦单机数据库处理框架的基础上新增了分布式计算处理。因此 SP 具备以下特征：

• 全部的 SQL 标准支持：包括复杂关联查询、存储过程、视图、序列等某些分布式数据库难以支持的特性。
• SP 节点自身无状态：每个 SP 节点上不存储任何数据字典信息和用户数据，一个集群中可以存在多个 SP 节点。连接上任何一个 SP 节点都可以获得完整的数据库服务。
• SP 具备子计划的执行能力：因为 SP 和 BP 是由同一套代码编译出来的，只是不同的启动参数决定了担任不同的角色，所以 SP 和 BP 一样具有操作符的执行能力。例如：从资源均衡利用和计算存储分离角度来考虑，DMDPC 将部分子计划安排在 SP 上执行。
• 支持动态增删节点。

2.1.1.2 数据存储节点

数据存储节点，英文全称为 Backend Processor，简称为 BP。

BP 为 DMDPC 集群中数据实际存储的节点，负责存储数据和接收 SP 的子任务调度指令，执行子任务，并返回结果给 SP。

一个 DMDPC 集群可配置多个 BP 节点同时提供服务，且可以随着用户业务量变化动态增删 BP 节点。为了保障 BP 节点能够持续提供服务，每一个 BP 节点又可以配置成一个 BP 多副本系统。

2.1.1.3 元数据服务器节点

元数据服务器节点，英文全称为 Metadata Processor，简称为 MP。

MP 为 DMDPC 集群中提供元数据服务（即字典信息服务）的节点。所有 DDL 请求都会经过 SP 转发给 MP 执行，元数据信息全部存储在 MP。

一个 DMDPC 集群只能配置一个 MP 节点提供服务。为了保障 MP 节点能持续提供服务，MP 节点可以配置成一个 MP 多副本系统。

2.1.2 多副本系统

在现实环境中，DMDPC 运行过程中有可能会碰到各种故障情况，比如系统掉电或者出现硬件故障（如磁盘损坏）、自然灾害（地震、火灾）等极端情况，因此需要对 BP 或 MP 采用多副本系统架构进行存储，以保障 DMDPC 的数据安全和高可用性，避免出现数据损坏和丢失，并且可以快速恢复数据库服务，满足用户不间断提供数据库服务的要求。

DM 多副本系统由 N 个节点实例组成，N 必须是大于 1 的奇数。只有配置了 RAFT 归档的实例才能加入多副本系统。

目前一个多副本系统最多支持部署 9 个节点实例。同一个 RAFT 组中的所有节点（三个或三个以上）共同构成一个多副本系统。实例之间通过 XMAL 模块进行 TCP 消息通讯。各个节点实例之间基于 RAFT 协议选举出一个领导者作为主库，其他实例作为备库（也就是副本）角色运行。主库会自动向备库同步日志，备库接收并重新应用日志，从而达到主备库之间数据保持一致的目的。

2.1.2.1 BP 多副本架构

如下图 2.2 展示了三个 BP 域的集群架构，每个 BP 域中都包含多个 BP。同一个 RAFT 组的多个 BP 保存了同样数据的多个副本。例如：BP1、BP1’和 BP1”三者内容完全相同。同一个 RAFT 组中的所有 BP 节点共同构成一个 BP 多副本系统。同一个 RAFT 组中的多个副本中只有一个作为主节点对外提供服务，其余节点均作为备份节点。当主节点发生故障后，系统会从备份节点中（BP1’，BP1”）重新选举出新的主节点对外提供服务。

在 BP 多副本系统中，可通过 V$ARCH_STATUS 和 V$RLOG_RAFT_INFO 来查看整个系统中主备环境的运行状况。

图2.2 BP多副本示意图

2.1.2.2 MP 多副本架构

如下图 2.3 展示了三个 MP 域的集群架构，每个 MP 域中最多只包含 1 个 MP。同一个 RAFT 组的多个 MP 保存了同样数据的多个副本。例如：MP1、MP1’和 MP1”三者内容完全相同。同一个 RAFT 中的三个 MP 节点共同构成一个 MP 多副本系统。同一个 RAFT 组中的多个副本中只有一个作为主节点对外提供服务，其余节点均作为备份节点。当主节点发生故障后，系统会从备份节点中（MP1’，MP1”）重新选举出新的主节点对外提供服务。

在 MP 多副本系统中，可通过 V$ARCH_STATUS 和 V$RLOG_RAFT_INFO 来查看整个系统中主备环境的运行状况。

图2.3 MP多副本示意图

2.2 系统原理

在 DMDPC 中，数据根据用户指定的分布规则分布在不同的 BP 上。DMDPC 的核心在于对用户请求的并行执行。下面对 DML（查询、插入、删除、更新）和 DDL 操作流程分别进行详细说明。

2.2.1 DML 流程

DML 流程分为两种情况：一般流程和优化流程。优化流程是指在实际执行时，优化器会综合多种条件，对符合优化的细节进行优化之后形成的流程。EXPLAIN 查看执行计划时，包含 mpp_opt_flag(1)的即为优化流程下的执行计划，包含 mpp_opt_flag(0)的即为一般流程下的执行计划。

2.2.1.1 查询

DMDPC 架构中各节点相互配合，完成用户的查询请求。下图展示了 DMDPC 架构的查询处理流程。

图2.4 DMDPC架构的查询执行流程

下面以客户端的查询 SELECT 操作为例，介绍并行查询的流程。如上图中箭头序号所示。查询请求的处理流程如下：

1. 客户端发送请求给 SP；
2. SP 生成执行计划，同时 SP 向 MP 申请获取字典信息；
3. MP 返回字典信息给 SP；
4. SP 将生成的执行计划中的一个或多个子计划发送给此次查询相关的 BP；
5. 相关 BP 接收并执行子计划。根据实际需要，不同 BP 间、同一 BP 不同线程间可能存在数据交换；
6. 相关 BP 在子计划执行完成时将成功与否信息和/或请求调度信息返回 SP；
7. SP 向客户端返回最终查询结果。

2.2.1.2 插入

插入分为两种情况：值插入和查询插入。下面分别进行说明：

1. 值插入的流程

SP 端的插入操作符计算出待插入数据所属的 BP 站点，然后以站点为单位逐一发送插入操作符和待插入数据给 BP。BP 端负责插入。

2. 查询插入的流程

查询插入分为查询和插入两部分。

查询部分的执行过程同前文介绍的查询流程一样。

插入分为一般流程和优化流程。一般流程：由 SP 计算记录所属的 BP 站点，然后以站点为单位发送待插入数据。优化流程：查询得到的结果直接发送给待插入表所在 BP，如果待插入表为分区表，那么数据在经过和表分布相同的分发后发送到各个 BP 上。

2.2.1.3 更新

更新分为一般流程和优化流程。

一般流程：SP 上查询得到了待更新的记录，计算每条记录所属的 BP 站点，而后以站点为单位发送更新前后的记录。

优化流程：查询得到的待更新记录按照更新对象的分布方式进行分发，各个 BP 站点直接进行更新，节省一次 SP 中转。可优化的情况下，支持并发更新数据行时冲突自动重试，一般流程不支持，直接报错处理。

2.2.1.4 删除

删除分为一般流程和优化流程。

一般流程：SP 上计算待删除记录的所属 BP 站点，以站点为单位发送待删除记录。

优化流程：待删除记录按照删除表对象的分布方式进行分发，各个 BP 站点直接删除，节省一次 SP 中转开销。可优化的情况下，支持并发删除数据行时冲突自动重试，一般流程不支持，直接报错处理。

2.2.2 DDL 流程

DMDPC 中处理 DDL 请求的流程如下：

1. 客户端发送 DDL 请求给 SP；
2. SP 在经过初步分析后，判断出是 DDL 请求，转发给 MP，等待 MP 响应；
3. MP 接收到 SP 转发的 DDL 请求后，根据具体类型，更改系统表；如果有 B 树创建、删除等用户数据操作，转发给相应 BP 完成；所有步骤完成后回复 SP；
4. SP 根据 MP 的反馈结果向客户端报告成功或失败。

2.3 系统特性

DMDPC 的主要特点包括：高可用、高扩展、高性能、高吞吐量和透明性。

2.3.1 高可用

达梦基于 RAFT 协议实现了一套全新的达梦多副本（DM Multiple Copy）系统架构。与传统的数据守护集群架构相比，此方案不再依赖守护进程和监视器，具有节点自动选主、自动故障处理、自动故障恢复的特点，在发生故障后可以快速恢复数据库服务，满足用户不间断提供数据库服务的要求。并且少数副本出现故障或者网络延迟不会影响整个系统的正常运行，因此也更能够适应分布式集群两地三中心的部署需求。

2.3.2 高扩展

DMDPC 集群提供达梦数据库高扩展性解决方案。根据用户业务量的变化，用户可以对集群规模进行扩展和缩小。详见 5.10 动态增删节点。

2.3.3 高性能

DMDPC 架构对 OLAP 和 OLTP 型场景都很适用。

查询的执行计划被拆分为一系列子任务，这些子计划被分散到多个 BP、SP 上执行以有效利用硬件资源；同时执行框架上采取了基于生产者、消费者的并行执行模型。不同的子任务允许有不同的并行度，同一个子任务在不同 BP 上的并行度也可以不同，并行度设置的灵活性能大大地提升线程资源的利用效率。

另外，通过将业务的不同表、或者同一表的不同分区拆分到多个 BP，甚至于多个主机，在面对高并发的 OLTP 型应用，集群可以极大地提升 IO 能力，分摊并发压力。

在多副本系统中，主备库之间的日志同步采用异步通信方式，主库同步日志时不需要等待备库刷盘或重演完成，备库也以异步消息通知主库自己的日志刷盘进度，消除了主备库之间的消息同步等待时间。

2.3.4 高吞吐量

与单节点数据库管理系统处理用户请求时的性能瓶颈相比，DMDPC 集群中，多个 BP 节点可以充分利用多台物理主机的处理能力，支撑更多的用户连接请求，提供更高的吞吐量。

DMDPC 集群中包含多个 BP 数据库实例，BP 数据库实例访问独立的处理器、内存。数据库实例之间通过 XMAL 模块交换数据，每个 BP 数据库实例都可以接收并处理用户的各种数据库请求。

多个 BP 节点同时提供数据库服务，有效提升集群的整体事务处理能力。

2.3.5 透明性

DMDPC 架构逻辑对用户透明。透明性是指 DMDPC 上任意一个 SP 提供的功能与普通单机数据库基本无异。用户登录 DMDPC 的任意一个 SP 节点，即可获取完整的数据库服务。