阿里云原生数据库系统：机遇与挑战（附下载）

目录

1、简介

(资料图片仅供参考)

2、阿里巴巴数据库系统架构

3、阿里巴巴数据库系统的其他关键功能

4、阿里云本机数据库

5、应用和操作

6、结论

Cloud-Native Database Systems at Alibaba: Opportunities and Challenges

阿里云原生数据库系统：机遇与挑战

摘要

由于各种应用程序对 弹性和按需（elasticity and on-demand）使用 的需求，云原生数据库在云计算时代变得越来越重要。这些来自云应用程序的挑战为云原生数据库带来了新的机遇，传统的企业内部数据库系统无法完全解决这些问题。云原生数据库利用软硬件协同设计来探索新硬件（如 RDMA、NVM）和 DPDK 等内核绕过协议提供的加速（A cloud-native database leverages software-hardware co-design to explore accelerations offered by new hardware such as RDMA, NVM, kernel bypassing protocols such as DPDK）。同时，新的设计架构，如共享存储，使云原生数据库能够将计算与存储分离，并提供出色的弹性特性。对于需要水平伸缩性的高度并发的工作负载，云原生数据库可以利用一个无共享层来提供分布式查询和事务处理。应用程序还需要云原生数据库通过分布式共识协议提供高可用性。

在阿里巴巴，我们探索了一套设计云原生数据库系统的技术。我们的存储引擎 X-Engine 和 PolarFS 通过使用 LSM 树设计和自适应的冷热数据记录分离来提高写入和读取吞吐量。在此基础上，我们设计并实现了 POLARDB 及其分布式版本 POLARDB-X，成功支持了 2018 年 11 月 11 日全球购物节期间极端的交易负载，并在阿里云上取得了商业成功。我们还设计了一个名为 AnalyticDB（简称 ADB ）的 OLAP 系统，用于实现大数据的实时交互式数据分析。我们开发了一个自动驱动（self-driving）的数据库平台，实现了数据库的弹性伸缩和智能化管理。我们将分享关键技术和经验教训，强调阿里巴巴云计算数据库系统面临的技术挑战和机遇。

1、简介

随着越来越多的应用程序和系统向云端迁移，云原生数据库系统开始获得广泛的支持和普及。云服务供应商提供的云数据库服务，如 AWS、Microsoft Azure、阿里云、Google 云等，为云原生数据库的开发做出了贡献。因此，近年来，云数据库的市场份额迅速增长。越来越多的企业和组织已经将其业务从内部数据中心迁移到云端。云平台提供了高弹性、严格的服务级别协议（SLA，Service-level Agreement），以确保可靠性和易管理性，同时降低运营成本。云数据库在支持基于云的业务方面起着关键作用。它成为连接底层资源（IaaS）和各种应用程序（SaaS）的中心枢纽，使其成为云计算的关键系统。

在阿里巴巴集团，数据库系统需要支持一个丰富而复杂的商业生态系统，涵盖娱乐和数字媒体、电子商务和电子支付，以及各种新的零售和 o2o（offline to online）业务运营。在 2018 年 "光棍节" 全球购物节（2018年11月11日）期间，阿里巴巴的数据库每秒处理多达 49.1 万笔销售交易，相当于每秒处理超过 7000 万事务。由于对灵活性、可伸缩性和可管理性的需求，传统的数据库内部部署已经不能满足这种复杂的业务操作。

例如，如 图1所示（2018 年阿里巴巴光棍节期间，TPS 增长超过 100 倍，响应时间稳定。），在光棍节购物节的第一秒，TPS 突然增加，大约是前一秒的 122 倍。当我们简单地将 MySQL 或 PostgreSQL 部署在本地SSD和高I/O虚拟机的云实例（cloud instance）上时，得到的数据库实例容量有限，不适合提供可伸缩的数据库服务。它无法在潜在的磁盘驱动器故障中生存；数据库实例必须管理数据复制以提高可靠性。此外，该实例使用通用文件系统，如 ext4 或 XFS。当使用低 I/O 延迟硬件（如 RDM A或 PCIe SSD）时，内核空间和用户空间之间的消息传递成本可能会迅速地使吞吐量达到饱和状态。相比之下，采用云本地设计的数据库（如计算和存储的解耦、自动缩放）更具吸引力，能够提供更多的计算和存储容量，并提供更快的恢复能力和更低的成本[30,7]。

对于云原生数据库来说，还有其他至关重要的能力：支持异构数据源和多样化查询接口的多模型；自动管理和调整数据库实例的自治性和智能性，以降低手动操作的成本；软硬件协同设计，利用高性能硬件的优势；高可用性，满足严格的 SLA 需求（例如，RPO = 0，RTO 非常小）。考虑到这些设计，云原生数据库在基于云的部署方面获得了快速增长。

在本文中，我们发表了在阿里云上建立的企业级云原生数据库的最新进展[1]，该数据库还支持阿里巴巴集团内的各个业务部门（从娱乐、电子商务到物流）的整个业务运营。为了满足各种各样的应用程序需求，我们提供了广泛的数据库系统和工具，如图3所示。我们为每个节点开发了 100TB 的数据库处理容量。为了进一步扩展容量，我们已经开发了 POLARDB-X，一个集成了共享内容和共享存储设计的分布式 OLTP 数据库。我们还开发了 AnalyticDB，这是一个 OLAP 数据库，作为下一代数据仓库，用于 PB 级的高并发、低延迟和实时分析查询。为了管理云端承载的大量数据库实例，我们构建了 SDDP，这是一个自治的数据库操作平台，它可以自动管理实例并调整性能，只需很少的 DBA 参与。在阿里云上运行的数据库实例有近 50 万个（来自客户和阿里集团内的各个业务部门）。 POLARDB 和 AnalyticDB 在电子商务、金融、媒体和娱乐、教育、新零售等广泛的商业领域都获得了快速增长。这些云数据库系统和技术成功地服务于阿里巴巴集团内部复杂的商业生态系统和许多外部企业客户。

2、阿里巴巴数据库系统架构

根据共享的内容，我们在阿里巴巴探索了三种流行的构建数据库系统的架构，如 图2所示。第一类是单实例，这是主流数据库最常用的架构。在这个模型中，数据库中的所有进程共享处理器内核、主内存空间和本地磁盘（即在一台机器上）。这样的体系结构促进并简化了系统内部的通信和协调。

随着 Google、Amazon、Microsoft、Alibaba 等大型互联网企业在数据量和工作负荷上的快速增长，人们发现单实例架构有其局限性。单台机器的无法满足日益增长的业务需求。因此，提出了共享存储架构，以 AWSAurora和 Alibaba POLARDB为代表。在该模型中，底层存储层（通常由多个节点组成）被解耦，存储的每个数据记录都可以被运行在任意节点上的任何上层数据库的内核访问。通过利用 RDMA 等快速网络，数据库可以与共享分布式存储层进行交互，就像与单个（共享）本地磁盘进行交互一样。在这个共享存储之上，我们可以轻松地启动多个计算节点来创建单个数据库的副本，在同一数据上具有相同的视图。因此，可以将请求分发到不同的（只读）节点进行并行处理。但是，为了避免写冲突，避免处理分布式事务和分布式提交的复杂性，通常只有一个节点处理数据库的所有写请求（例如，插入、更新、删除）。这种体系结构通过改变只读节点的数量，可以根据需要动态调整查询容量。允许对多个节点（即多主节点）的写入以扩展写容量也是可行的，但通常需要复杂的并发控制机制和一致性协议[6,12,16,17,23,34]。

共享存储体系结构也有其自身的局限性。首先，计算节点和存储节点之间的低延迟数据传输不能总是得到保证。对于跨交换机、数据中心甚至区域传输的消息，传输时间将大大增加，特别是当使用本地 RDMA 网络时。其次，单个数据库支持的只读节点数量是有限的。当节点数量达到一定的规模时，大量的请求将被阻塞，使得访问远程存储的成本高得令人望而却步。因此，一个实际的限制是大约有十几个只读节点。为了解决这个问题，我们需要一个无共享的架构（shared nothing architecture）。在共享存储体系结构中，逻辑数据库被分成多个分片，每个分片分配给一个节点。这些节点可以放置和复制到不同的数据中心和区域。这种架构的一个典型实现是 Google Spanner[7]，它使用 GPS 和原子钟来实现跨区域的副本一致性和事务一致性。在阿里云上，我们构建了 POLARDB-X，它扩展了 POLARDB。我们探讨了在多个数据库之上构建一个无共享系统的好处，而每个数据库都有一个共享的分布式存储。（we build POLARDB-X that extends POLARDB and explores the benefits of building a shared-nothing system on top of multiple databases each with a shared distributed storage）

请注意，这种无共享和共享存储体系结构（shared-nothing and share-storage architectures）的混合体带来了一些特殊的好处。我们可以在顶层应用分表，但是将多个节点分配给一个分片（而不是每个分片一个节点）。在这个分片下面，这些节点可以访问共享存储。这种混合架构的好处是它减轻了小碎片过多的缺点。特别是，它有助于简化分片重新平衡的过程，降低跨分片事务的概率（并减少昂贵的分布式提交量）。同时，它还支持出色的水平扩展性。这种混合架构同时利用了无共享和共享存储的优点，是我们在POLARDB-X数据库设计中探索的一个很有前途的方向。

3、阿里巴巴数据库系统的其他关键功能

除了探索不同的系统架构外，在阿里巴巴复杂的业务应用程序的驱动下，阿里巴巴数据库系统的设计还考虑了一些其他关键特性。

3.1 多模型分析

阿里巴巴的一个重要应用场景是支持多模型分析，它包括两个方面：southbound 和northbound 的多模型访问。Southbound 多模型访问表明底层存储支持不同的数据格式和数据源。存储的数据可以是结构化的，也可以是非结构化的，例如图形、矢量和文档存储。然后，数据库提供一个统一的查询接口，如 SQL 或类似 SQL 的接口，用于查询和访问各种类型的数据源和格式，形成数据湖服务。Northbound 多模型访问表明，单个数据模型和格式（例如，在大多数情况下，键值模型）用于将所有结构化、半结构化和非结构化数据存储在单个数据库中。在这个单一存储模型的基础上，数据库支持多个查询接口，如 SQL、SPARQL 和 GQL，这取决于应用程序的需要。微软 CosmosDB[9]就是这类系统的代表。

除了满足我们内部的业务运营需求外，能够支持多模型分析也是云数据库服务的基本要求。许多云应用程序需要从异构数据源收集大量数据，并进行联合分析，以链接不同的数据源并揭示业务洞察力（即 southbound 多模型访问）。另一方面，云数据库（例如，大型 KV 存储，如HBase）通常是一个中央数据存储库，由具有不同应用需求的多个应用程序访问。由于可用性和效率的原因，他们可能更喜欢使用不同的查询接口，在这种情况下需要进行 northbound 多模型分析。

3.2 自治性和智能性

鉴于阿里巴巴数据库系统需要管理的数据库实例数量庞大，工作负载复杂，因此，提高数据库操作平台的自治性（autonomous）和智能性是必不可少的要求。在我们的平台上运行着数十万个实时数据库实例，以每个实例的方式来响应传统的基于 DBA 的手动操作、调优和维护是不可行的。从数据库内核和底层操作平台的角度来看，支持自主操作的机会很多[8、18、19、21、24、26、29]。基于此，我们致力于建设一个具有自我检测、自我决策、自我恢复和自我优化能力的自我驱动数据库平台（SDDP）。以自优化为例，数据库内核中的各个模块（如索引、查询优化器和缓冲池管理）将通过采用机器学习技术进行增强，以便这些模块能够针对动态工作负载进行自适应优化。然而，由于机器学习模型的训练和推理成本很高，使得它们在数据库内核中既有效又高效是一项具有挑战性的任务。另一方面，自我检测、自我决策和自我恢复的目标是提高数据库操作平台的效率和有效性。如何自动检测实例状态和检测异常行为，以及一旦检测到错误，如何在较短的反应时间内做出正确的修复决策，是一个关键的挑战。

3.3 软硬件协同设计

阿里巴巴数据库系统创新的另一个关键课题是在硬件领域探索和利用快速发展和创新的硬件。与任何其他系统一样，我们的目标是设计和实现我们的数据库系统，这些系统能够以安全和高效的方式使用有限的系统硬件资源。这一目标意味着系统必须关注硬件性能的不断变化和改进，以便能够利用创新的新硬件特性的优势。作为一个性能为主的系统，数据库系统需要充分利用可用的资源，稳健高效地执行查询和事务。随着新的硬件性能不断提高，简单地遵循现有的数据库设计并期望它们在新硬件上的性能最大化是不明智的。例如，直接运行在支持 RDMA 的分布式存储上的复杂数据库（如 MySQL）的性能明显低于具有相同 CPU 和内存配置的本地 PCIe SSD 上的性能，这需要仔细重新设计[5]。因此，新硬件带来的机遇是设计阿里巴巴数据库系统的重要考虑因素。例如，我们广泛探索和集成了新的硬件技术，如 RDMA、NVM、GPU/FPGA 和 NVMe SSD。

3.4 高可用性

高可用性是阿里巴巴数据库系统的基本要求之一，以确保我们的业务运营和云客户零停机，因为大多数企业客户无法容忍业务中断。高可用性的一个标准解决方案是复制，它可以在数据库实例、表或表碎片的粒度上完成。广泛使用的主备份和三向复制（primary-backup and three-way replications）在大多数情况下都能胜任。对于需要更高可用性的银行和金融部门，可以强制执行四个或更多副本，这些副本通常放置在不同的数据中心（可用区域）和区域，以便在大区域故障（如网络故障和数据中心停机）中生存。

在采用复制时，必须仔细处理副本之间的数据一致性。CAP 定理的结论是，在一致性、可用性和分区容差之间，只有三个属性中的两个可以满足。在阿里巴巴，我们在设计和实现我们的数据库系统时考虑到了"C"（一致性）和"P"（分区容差），并通过定制的 Parallel Paxos 协议（称为 X-Paxos）来确保高可用性，从而确保我们仍然可以提供高达99.999%的极高可用性。X-Paxos 实现并优化了复杂的复制技术和一致性协议，并通过日志确保数据的一致性和可用性。

4、阿里云本机数据库

在本节中，将分享我们在阿里巴巴构建云原生数据库系统方面的最新进展。图3总结了阿里巴巴和阿里云上的数据库系统和产品的完整概述。重点讨论了 POLARDB（共享存储 OLTP 数据库）及其分布式版本 POLARDB-X（一个基于 POLARDB 之上的共享 OLTP 数据库）、AnalyticDB（一个实时交互式OLAP数据库）和 SDDP（一个自主的数据库操作平台）。

4.1 POLARDB：云原生 OLTP 数据库

POLARDB 是基于 AliSQL（MySQL/InnoDB 的一个分支）[2]构建的关系型数据库系统，在阿里云上作为数据库服务提供。POLARDB 遵循云本地架构，提供高弹性、高容量和高并发性。另外，POLARDB 与 MySQL 和 PostgreSQL 完全兼容，帮助客户进行透明、流畅的业务应用迁移。

4.1.1 系统设计

POLARDB遵循共享存储架构，如 图4所示。它由三层组成：PolarProxy 作为统一的访问门户、多节点数据库集群和分布式共享文件系统 PolarFS。PolarProxy 是一个具有自适应能力的分布式无状态代理集群。

它集成了多个计算节点的资源，为应用程序提供了一个统一的访问门户。它的动态扩展能力支持灵活地增加/减少节点。POLARDB 中的数据库节点分为 主节点和 多个只读节点两种类型。主节点可以同时处理读和写查询，而 RO 节点只处理读查询。主节点和 RO 节点共享 Redo 日志文件和数据文件，这些文件由 PolarFS（第4.1.2节）管理，PolarFS 是一种具有超低延迟、高吞吐量和高可用性的分布式文件系统。

这种体系结构有几个独特的优点。首先，计算和存储资源被解耦。计算和存储节点可以使用不同类型的服务器硬件，并且可以单独定制。例如，计算节点不再需要考虑内存大小与磁盘容量的比率，这高度依赖于应用场景，并且很难预测。其次，它突破了单节点数据库（如 MySQL、PostgreSQL）的局限性。存储节点上的磁盘形成一个存储池，这降低了碎片化、使用不平衡和空间浪费的风险。存储群集的容量和吞吐量可以透明地横向扩展。POLARDB 能够提供 100TB 的存储容量，每个节点实现 100万 QPS。第三，由于数据都存储在存储集群上，计算节点上没有本地持久状态，这使得执行数据库迁移更容易、更快。由于 PolarFS 提供的数据复制和其他高可用特性，数据可靠性也可以得到提高。

除了 POLARDB，其他云数据库服务也可以从这个架构中获益。首先，数据库可以基于虚拟化技术（如 Xen[3]、KVM[13] 或 Docker[20]构建一个更安全、更易于扩展的环境。其次，由于后端存储集群提供了快速 I/O、数据共享和快照功能，因此可以轻松实现数据库的一些关键功能，如多个只读实例和检查点。

4.1.2 PolarFS 和 PolarStore

数据存储技术持续地快速变化，当前的云平台很难充分利用 RDMA 和 NVMe SSD 等新兴硬件标准。例如，一些广泛使用的开源分布式文件系统，如 HDFS[4] 和 Ceph[31]，被发现比本地磁盘有更高的延迟。当使用最新的 PCIe SSD 时，性能差距甚至可能达到数量级。与具有相同 CPU 和内存配置的本地 PCIe SSD 相比，直接在这些分布式存储上运行的 MySQL 之类的关系数据库的性能要差得多。

为此，我们构建 PolarFS[5] 作为 POLARDB 的共享存储层。它是建立在 PolarStore（基于RDMA 网络的共享的分布式存储）之上的分布式文件系统，通过以下机制提供超低延迟、高吞吐量和高可用性。首先，PolarFS 充分利用了 RDMA 和 NVMe-SSD 等新兴硬件，在用户空间实现了一个轻量级的网络栈和 I/O 栈，以避免陷入内核和处理内核锁。第二，PolarFS 提供了一个类似 POSIX 的文件系统 API，目的是编译到数据库进程中，替换操作系统提供的文件系统接口，使整个 I/O 路径都能保存在用户空间中。第三，PolarFS 数据平面的 I/O 模型也被设计用来消除锁和避免关键数据路径上的上下文切换。所有不必要的内存拷贝都被消除了，而 RDMA 被大量用于在主内存和 RDMA NIC/NVMe 磁盘之间传输数据。所有的本地到文件端的系统延迟都大大降低了。

由于大型 POLARDB 集群中的节点故障很常见，因此需要一个共识协议来确保所有提交的修改不会丢失。按位复制应该总是一致的。在 PolarFS 中，我们首先使用 Raft[23]，这是 Paxos 家族[17，16]的一种变体，它更易于实现，并且广泛应用于许多分布式系统。然而，当 Raft 被应用时，我们发现它严重地阻碍了 PolarFS 的 I/O 可扩展性，在 PolarFS 中使用低延迟 NVMe SSD 和 RDMA（其延迟约为几十微秒）。因此，我们开发了基于 Raft 的一致性协议 ParallelRaft，它允许无序的日志确认、提交和应用，同时允许 PolarFS 遵循传统的 I/O 语义。使用该协议，并行 I/O 并发性得到了显著的提高。

综上所述，PolarFS 支持 POLARDB，其特点是：（1）PolarFS 可以将文件元数据的修改（如文件的截断或扩展、文件的创建或删除）从主节点同步到 RO 节点，这样 RO 节点的所有更改都是可见的。（2）PolarFS 确保对文件元数据的并发修改是序列化的，这样文件系统本身在所有数据库节点上都是一致的。（3）在网络分区的情况下，两个或多个节点可以作为主节点并发地写入共享文件。PolarFS 可以确保只有真正的主节点成功服务，防止数据损坏。更多技术细节见[5]。

4.2 POLARDB-X：分布式 OLTP 数据库

POLARDB 可以很好地扩展到多达数十个节点（由于底层 RDMA 网络的限制），但这不足以支持大量数据和事务的高度并发的工作负载，例如在单日购物节上发现的数据和事务。因此，我们扩展了 POLARDB 并构建了 POLARDB-X，这是一个分布式的无共享 OLTP 数据库，以支持水平扩展。POLARDB-X结合了共享存储和无共享架构。与在每个分片上使用单个节点实例的标准无共享体系结构相比，这种设计的好处是，由于共享存储体系结构引入的扩展能力，每个分片现在可以存储和处理更多的数据和事务。因此，对于相同数量的数据和/或事务处理需求，与标准的无共享系统相比，混合体系结构需要的碎片数量要少得多；这反过来又减少了处理复杂且昂贵的分布式事务处理和分布式提交的机会。因此，它支持海量数据上的高并发事务，并通过 Parallel Paxos 协议 X-Paxos 确保 cross-AZ 和跨区域事务的一致性。

4.2.1 系统设计

图5显示了 POLARDB-X 的体系结构，其中关系数据被划分为多个 POLARDB 实例，并由分布式关系数据库服务（DRDS）管理。DRDS 接受 SQL 查询或事务，解析并优化它们的计划，最后将它们路由到相应的 POLARDB 实例以供执行。如前所述，每个 POLARDB 实例由一个主节点和多个只读节点组成。每个读节点都作为主节点的一个副本，共享 PolarFS 上的相同存储，PolarFS 又位于 PolarStore（阿里巴巴的块存储系统）上。在 POLARDB 节点中，有一个用于从 DRDS 推送的查询计划的计划执行器（用于事务处理的事务服务）和一个 X-Engine（阿里巴巴基于 LSM 树的 OLTP 存储引擎）。

4.2.2 X-Engine

我们发现，在阿里巴巴和我们的大企业客户处理此类交易时，必须解决三个关键挑战：（1）海啸问题——随着大型销售和促销活动的启动，交易量急剧增加（例如，阿里巴巴光棍节全球购物节出现了 122 次高峰），这给底层数据库带来了巨大的压力。（2）泄洪问题——大量的热记录很容易淹没系统缓冲区，如果缓冲区无法快速刷新，则会阻碍后续事务处理。（3）活动时快速移动问题——由于持续时间短的大量促销事件，记录的"热度"（即热、暖、冷）频繁发生快速变化，这大大降低了缓存命中率。

我们构建 X-Engine[10]是为了应对阿里巴巴电子商务平台所面临的上述挑战，因为事务处理性能的一个重要部分归结于数据的持久性和从存储中检索的效率。X-Engine 利用多核处理器中的线程级并行性（TLP）来处理主存中的大多数请求，将写入与事务分离以使其异步，并将长的写入路径分解为管道中的多个阶段，以提高总体吞吐量（decomposes a long write path into multiple stages in a pipeline in order to increase the overall throughput）。为了解决泄洪问题，X-Engine 利用一种分层存储方法在不同层之间移动记录，利用了改进的 LSM 树结构[22，25]和优化的压缩算法。我们还将 FPGA 卸载应用于压缩。最后，为了解决当前快速移动的问题，我们引入了一个多版本的元数据索引，该索引以写时拷贝的方式更新，以加速分层存储中的点查找，而不考虑数据热度。

图6显示了 X-Engine 的体系结构。X-Engine将每个表划分为多个子表，并维护LSM树、关联的元快照和每个子表的索引。X-Engine 为每个数据库实例包含一个重做日志。每个 LSM 树由驻留在主内存中的热数据层和驻留在NVM、SSD、HDD中的暖/冷数据层（进一步划分为不同的级别）组成，其中术语 Hot、Warm 和 Cold 指的是数据热度，表示应该放在相应层中的数据的理想访问频率。热数据层包含 一个活跃的Memtable和 多个不可变的Memtable，它们是存储最近插入的记录的跳板，以及缓冲热记录的缓存。暖/冷数据层以树状结构组织数据，树的每一级都存储一个经过排序的区段序列。数据块打包记录块及其关联的筛选器和索引。

X-Engine 利用Redo日志、元快照和索引支持事务处理的多版本并发控制（MVCC）。每个元快照都有一个元数据索引，用于跟踪快照中树的所有级别的所有内存表和扩展数据块。在相邻的一层或多个层次上存储一个或多个层次的硬盘驱动器。X-Engine 中的每个子表都有自己的热、暖和冷数据层（即 LSM 树），以面向行的格式存储记录。我们设计了一个多版本 Memtables 来存储不同版本的记录，以支持 MVCC。在磁盘上，元数据索引跟踪存储在扩展数据块中的所有记录版本。更多技术细节见[10]。

4.3 AnalyticDB：实时 OLAP 数据仓库

AnalyticDB 是一个实时的 OLAP 数据库系统，设计用于 PB 级的高并发、低延迟和实时分析查询。它从 3 个节点运行到 2000 多台物理机，并作为一个数据库服务在阿里云上提供相应的服务。它服务于电子商务、金融科技、物流、公共交通、气象分析、娱乐等多个业务领域的企业客户，以及阿里巴巴集团内部的业务运营。

最近的著作[28,14,15,32,11]总结了设计 OLAP 系统的主要挑战：实现低查询延迟、数据新鲜度、灵活性、低成本、高可扩展性和可用性。与这些工作相比，来自我们应用场景的大规模分析工作负载将 AnalyticDB 提升到更大的规模：10PB+ 数据、数十万个表和数万亿行，这对 AnalyticDB 的设计和实现提出了重大挑战：（1）今天的用户面临比以往任何时候都更复杂的分析场景，但仍然对低查询延迟抱有很高的期望。尽管来自不同应用程序的查询是多样和复杂的，但它们通常不能容忍花费很长时间的查询。（2）新兴的复杂分析倾向于结合不同类型的查询和数据。超过一半的用户数据具有复杂的数据类型，例如文本、JSON 字符串或 vector。一个实用的数据库应该能够有效地支持对具有复杂类型的异构数据的查询。（3）在以低延迟处理实时查询的同时，系统还需要每秒处理数千万个在线写入请求。在同一进程路径中读写数据的传统设计不再适合这种情况。应该考虑在查询延迟、写入吞吐量和数据可见性之间进行仔细的设计。

为了解决这些挑战，我们用几种新颖的设计构建了 AnalyticDB。首先，AnalyticDB 嵌入了一个高效的索引引擎。在这个引擎中，索引建立在每个表中的所有列上，以显著提高复杂查询的性能。我们进一步提出了一种基于运行时过滤器比率的索引路径选择机制，以避免索引滥用导致的性能下降。由于在关键路径中更新大型索引的成本过高，因此索引是在非高峰时段异步构建的。我们还维护了一个轻量级的排序索引，以最小化异步索引构建对涉及增量数据（即，在当前一轮索引构建开始之后写入的数据）的影响。

其次，我们设计了底层存储布局，以支持结构化数据和其他复杂类型数据的行列混合存储。特别是，我们使用快速顺序磁盘 I/O，因此无论是 OLAP 样式还是点查找工作负载（OLAP-style or point-lookup workloads），其开销都是可以接受的。我们进一步在存储中加入了复杂的数据类型（包括索引），以提供与结构化数据一起搜索资源（即JSON、vector、text）的能力。

第三，为了支持高吞吐量写和低延迟查询，我们的系统遵循一种将读写解耦的体系结构，即分别由写入节点和读取节点提供服务。这两种类型的节点彼此隔离，因此可以独立伸缩扩展。特别是，写节点会持久地向盘古（阿里云上的一个可靠分布式存储）发送写入请求。为了确保服务查询时数据的新鲜度，在读取节点上应用版本验证机制，这样就可以看到以前在写节点上处理的写操作。

第四，为了进一步提高查询延迟和并发性，我们在 AnalyticDB 中增强了优化器和执行引擎，以充分利用我们存储和索引的优势。具体来说，我们提出了一种基于存储的 SQL 优化机制，根据存储特性，生成最优的执行计划，并在基于成本的优化器（estimation in cost based optimizer）中提出了一种有效的基数估计实时采样技术。此外，我们还设计了一个高性能的用于混合存储的矢量化执行引擎，可提高计算密集型分析查询的效率。

系统架构如 图7所示。AnalyticDB 中主要有三种类型的节点，即协调器、写入节点和读取节点（Coordinator, WriteNode and Read Node）。协调器从客户机连接收集请求（包括写入和查询），并将它们分派到相应的写入和读取节点。写入节点负责处理写入（如INSERT、DELETE、UPDATE）以及将 SQL 语句刷新到盘古中以实现持久性。读取节点负责处理查询（例如SELECT）。通过这种方式，写和读节点彼此解耦。伏羲（阿里云上的资源管理器和作业调度器）利用所有这些节点上的可用资源为异步任务的执行提供计算工作。此外，AnalyticDB 还提供了一个在计算工作上运行的通用管道模式执行引擎。以列块为单位的数据通过系统从存储器流向客户机。所有的数据处理都在内存中，并且在网络的不同阶段之间通过管道传输。这种流水线工作流使 AnalyticDB 能够以高吞吐量和低延迟服务于用户的复杂查询。更多技术细节见[33]。

4.4 SDDP：自驱动数据库平台

为了管理阿里云上众多的数据库实例，我们搭建了一个自治的数据库管理平台 SDDP（Self-Driving database platform）。该平台收集所有运行数据库实例的实时统计信息，并使用机器学习和统计方法来优化实例和提供资源。

4.4.1 系统设计

图8显示了 SDDP 的体系结构。混合云数据库管理（HDM）层从数据库实例收集 SQL 和度量，并将它们存储在时间序列数据库（TSDB）中。同时，HDM 检测数据库状态并将这些信息与控制器同步。数据库状态通常由 DDL 操作更改。例如，我们可以使用 ALTER TABLE t1 HOTCOLD="SMART" 将表设置为智能模式，并自动分离热/冷数据（第4.4.3节）。HDM 还分配控制器来驱动机器学习任务，例如参数调整（第4.4.2节）、资源调度和异常检测。控制器将这些任务调度到模型训练平台（MTP，Model Training Platform）。MTP 从 TSDB 检索数据，包括 SQL 和衡量指标，并使用不同的模块来完成相应的作业。结果将由控制器传回 HDM 并应用于数据库实例。

4.4.2 缓冲区大小调整

缓冲池是 OLTP 数据库的一个关键资源，它作为一个数据缓存空间来保证理想的系统性能。对阿里巴巴超过 10000 个实例的 OLTP 数据库集群的实证研究表明，缓冲池平均消耗每个实例 98% 的内存空间。数据库管理员（通常基于固定的数据库配置和经验）一致推荐。这种手动过程既不高效也不有效，甚至不适用于大型云集群，尤其是当工作负载可能在单个数据库实例上动态变化时。

为此，我们构建了 iBTune[27]，个性化的缓冲区优化，以自动减少任何单个数据库实例的缓冲区大小，同时仍保持其响应时间的服务质量，而不依赖 DBA 来设置预定义的级别。我们利用未命中率和缓冲池大小之间的关系来优化内存分配。我们的模型利用类似实例中的信息。同时，我们设计了一个新的双深度神经网络，利用实例对的测量值来预测响应时间的上界。到目前为止，iBTune 已经部署在 SDDP 上，并应用于 10000 多个数据库实例。我们成功地将内存消耗减少了 17%（≥ 27TB），同时仍然满足我们多样化业务应用所需的服务质量。

图9显示了 iBTune 的体系结构和工作流的概述。有四个关键组件：数据收集、数据处理、决策和执行。iBTune 工作流形成了一个封闭的循环，因为数据首先从 DBMS 内核收集、处理并用于训练，然后生成的模型再次应用于 DBMS。在数据收集中，我们使用定制的代理从 DBMS 收集各种数据库衡量指标和日志。收集了 1000 多个指标。代理位于 DBMS 外部，以避免 DBMS 内核不必要的性能开销。所有的衡量指标和日志都以一秒的粒度收集并输入到消息队列中。在数据处理中，流处理系统从消息队列中读取数据，并执行某些数据操作/标准化操作，如规范化、聚合和日志转换。然后，处理后的衡量指标和日志存储在分布式数据存储系统中，用于分析和模型训练。在决策中，我们提出了一种新的预测 RT 和计算新的 BP（缓冲池）大小的方法。如果预测的 RT 满足要求，计算出的新 BP 大小将被发送到执行组件（execution component），该组件包含一个计划器和一个调度程序（planner and a scheduler）。为了处理大量的数据库实例，Action Planner 的目标是为成千上万个操作制定一个全局高效、无冲突的执行计划。它包括不同操作类别之间的优先级设置、同一实例的操作合并、操作冲突的检测与解决、canary 执行策略等。它最终将多个操作序列输出到 Action Scheduler。更多技术细节见[27]。

4.4.3 其他场景

除了缓冲区大小调整外，我们还探索了其他自治设计，如慢 SQL 优化、空间缩减、冷热分离、ML 优化器、故障检测和恢复。以热/冷分离为例，通过数据的热度（范围）来区分 X-Engine（第4.2.2节）中的水平。一个区段的热度是通过它在最近的窗口中的访问频率来计算的。当执行压缩时，X-Engine 使用阈值指定的数量选择最冷的数据块，例如 500 个数据块，并将这些数据块推到更深的级别进行压缩。通过这样做，X-Engine 保持了上层的热数据块（warm extents）和深层的冷数据块（cold extents）。但是这种方法不能很好地处理动态工作负载。例如，当前块的存取频率较低时，此算法会把将来可能会变热的块视为冷数据。为此，我们研究了基于机器学习的算法来识别合适的热度范围。直觉是，除了范围之外，我们还使用行级别（record）作为粒度来推断热度（warm/cold）。如果在最近的窗口中从未访问过某个记录，则该记录被标识为处于 cold。否则，它被认为是 warm。因此，热度辨识转化为二元分类问题，并可使用分类模型（例如使用随机森林或基于神经网络的方法）来解决。

5、应用和操作

在阿里云上运行的数据库实例已近 50 万个，既支持阿里集团内部业务运营，也支持外部客户业务应用。通过利用我们的云原生数据库系统，我们成功地为大量复杂的应用程序场景提供服务。

POLARDB。POLARDB 在阿里云上的人数增长迅速。它为金融科技、游戏和娱乐、教育和多媒体等不同行业的领先公司提供服务。许多应用程序选择迁移到 POLARDB，因为它们的自部署数据库支持的事务处理速率有限。例如，一个应用程序在 MySQL 实例中，在高峰时间会增加 5 倍的延迟和频繁的事务失败。POLARDB 有助于将所有事务延迟保持在 1 秒之内，并将峰值吞吐量提高 3 倍。另外，一个 POLARDB 实例能够在 5 节点复制的 MySQL 集群上保持相同的查询性能，并减少经验丰富的 DBA 所需的工作。在大多数情况下，它可以将数据库的总体拥有成本（TCO）降低50-80%。

POLARDB-X。POLARDB-X 已应用于阿里巴巴的许多性能为主和成本敏感的商业领域中。例如，2018年光棍节全球购物节开始时，我们处理的交易量增加了 122 倍，每秒处理多达 49.1 万笔销售交易，相当于每秒超过 7000 万数据库事务。为此，已经在线部署了 2000 多个 POLARDB-X 节点。随着 GMV（总商品量）的快速增长，管理 OLTP 数据库和维护底层服务器的成本迅速上升，这是阿里巴巴面临的一大挑战。为了降低成本，我们在阿里巴巴的许多业务中用 POLARDB-X 替换了 MySQL，这些业务利用了降级的硬件（例如，CPU 核数和存储量更少），同时保持了相同的 QPS/TPS 级别。在许多情况下，我们设法将数据库的总体拥有成本降低了50%。

AnalyticDB。AnalyticDB 已经在阿里云 2000 多个节点上运行。它服务于广泛的商业领域，如电子商务、金融科技、物流、公共交通和娱乐。基于 AnalyticDB，我们扩展了一个端到端的解决方案，涵盖了从数据采集到数据可视化的整个分析途径。与其他解决方案相比，我们的客户能够无缝构建在线分析服务，同时降低总成本。AnalyticDB 帮助应用程序更好地利用其数据：对万亿级数据的即时多维分析和业务探索可以在毫秒内完成；用户可以通过调用内置函数和模块来定义和启动其分析任务；在许多情况下，可视化新获取的数据的端到端延迟减少到小于一分钟；并且不需要客户手动操作来维护服务。

SDDP。SDDP 已经被用于管理阿里巴巴的数万个数据库实例。我们通过使用多个自主智能模块，成功地节省了大量集群资源：SQL 优化模块检测并优化了 2740万 条低效 SQL 请求；空间优化模块释放了 2.26PB 的存储空间（如通过去碎片化和删除无用的索引/表）；iBTune 模块在保证服务质量的同时，节省了 27TB 的内存空间；全局工作负载调度模块将磁盘利用率从 46% 提高到 63%。

6、结论

云原生数据库系统是一个日益重要的研究和开发课题。它为数据库社区和行业带来了许多新的技术挑战和新的机遇。在阿里云内部，我们分享了阿里云在本地和本地数据库建设方面的丰富经验和教训。考虑到云技术的快速发展，云原生数据库系统在未来的道路上将变得更加关键，并为支持下一代云应用开辟新的令人兴奋的研究方向和工程挑战。