阿里云已将 Serverless 数据库大规模落地，这是否代表着数据库的新风向？

数据库是 Serverless 化难度极高的应用。阿里云数据库已全面向 Serverless 演进，进一步实现了完全自动化的扩容，为用户带来更经济的计费模式和更无感的扩容体验，让业务根据请求的繁忙程度实现平滑的全自动响应，无需人工介入......近日，InfoQ 采访到了阿里云数据库团队，深入了解阿里云数据库 Serverless 化的具体思路及核心技术。

全面 Serverless 化

2012 年，Iron.io 的副总裁 Ken Form 所写的一篇名为《Why the Future of Software and Apps is Serverless》的文章提出了一个新的观点：即使云计算已经逐渐的兴起，但是大家仍然在围绕着服务器转。

正是这篇文章将“Serverless”带进了大众视野。

此后，国内外的 Serverless 生态迅速发展了起来，诞生了比如 Serverless Framework、函数计算、云函数等很多优秀的产品，越来越多的技术人开始对外分享公司内部在 Serverless 层面的相关实践。

然而，我们很少见到数据库这一重要基础设施服务 Serverless 化的实战分享。

究其原因，无非一个“难”字。

Serverless 的三大主要特征是资源解耦和服务化、自动弹性伸缩以及按使用量计费。

数据库的大量状态存储很难做到类似 FaaS 这种即开即用的能力，FaaS 本身不具备共享内存的能力也会让计算和数据库之间的资源动态扩展能力不一致，FaaS 也无法承受服务器通过 driver 和连接池访问数据库时繁重的初始化......

诸如此，数据库 Serverless 化一直未取得突破性的进展，这也成为了阿里云数据库研发团队势必要实现的一个小目标。

在阿里巴巴内部，数据库的形态一直在不断演变。

第一阶段，大量业务依赖 Oracle 数据库，集团内部诞生了大量优秀的 DBA 和 Oracle ACE。

第二阶段，传统的单机数据库难以匹配淘宝等业务的快速发展，团队开始探索开源的数据库方案，尝试用 MySQL 替换 Oracle。在这个过程中，团队逐步做了异地多活等架构层面的创新。

第三阶段，阿里巴巴开始对外提供公有云服务，团队将在 MySQL 层面积累的经验通过云的形式提供给用户，这也是如今的主流方式之一，只是这个阶段的用户普遍头痛于突发的数据库扩容需求。

第四阶段，自研云原生数据库 PolarDB 来了，可以很好地解决上一个阶段出现的扩缩容问题。使用传统云数据库，用户需要提前购买足够支撑业务运行的数据库资源。PolarDB 与底层的 RDMA 高性能网络、CIPU、飞天操作系统等基础设施充分融合，实现了存储计算分离、分钟级别弹性等核心云原生能力，结合 ADB、DMS 等产品逐渐形成了一站式全链路数据管理与服务这样一个被称为云原生数据库 2.0 的阶段。

第五阶段，全面 Serverless 化，更进一步实现了秒级自动化的缩扩容，能够随用户业务请求数的增加和减少智能化“膨胀”和“缩小”，实现资源的自动“吞吐”。这种特性，能够为用户带来更经济的计费模式和更无感的扩容体验，让业务根据请求的繁忙程度实现平滑的全自动响应，无需人工介入。

“过去多年，我们深入和底层基础设施结合，哪怕这个过程很痛苦。数据库 on ECS 还是物理机？on ECS 的一开始肯定会带来成本和性能的挑战，这就倒逼着我们必须通过技术创新解决这些问题，迈过这些坎就会发现 on ECS 带来的池化规模效应是巨大的，迈过去就是核心壁垒，Serverless亦然。”阿里云智能数据库事业部负责人李飞飞表示。

那么，在 Serverless 化的过程中，阿里云数据库团队迈过了哪些坎呢？ 

数据库 Serverless 化的关键技术解析

计算、内存、存储三层解耦才能实现真正的 Serverless

在此之前，阿里云自研的云原生数据库 PolarDB 对数据库架构进行了改造，实现了存储和计算分离，并基于此实现了一写多读，适配云架构，实现了存储池化和按量计费。

但此架构下，CPU 和内存依然是强绑定的，无法摆脱传统的 vCPU+内存的数据库售卖模式，随着 PolarDB Serverless 新架构的提出，这种情况可能会出现极大改变。

2021 年 SIGMOD 大会上，阿里云发表《PolarDB Serverless: A Cloud Native Database for Disaggregated Data Centers》论文，创造性地提出了 DDC（Disaggregated Data Centers）架构，实现数据库内计算、内存和存储三层资源解耦，三层资源均可以按需分层弹性，内存层支持 PB 级弹性扩展。

在理想情况下，整个 IDC 形成一个多租户的大数据库，其全部的 CPU，内存，存储构成三个独立的资源池。在资源池未耗尽的情况下，任何一个用户（租户）都可能任意弹性扩展任何一种资源到任何一个规格，用户为其 SQL 动态消耗的 CPU、内存和存储买单，不需要预置任何的规格。

这种情况下，CPU 和内存资源因其池化其使用率会大幅度提升，云原生数据库的成本会进一步大幅降低。

解决跨设备迁移潜在的高可用问题

在 Serverless 的场景下，同一台物理机上运行的数据库实例可能都需要资源扩容，此时有可能遇到物理机资源无法满足所有扩容请求的场景。当本地资源不足时，需要将计算节点实例迁移到资源充足的物理机上部署。当实例发生跨设备迁移时将可能导致迁移时间长和用户业务中断受损，因此 Serverless 数据库需要具备高效的高可用能力。

通过自动切换、热备节点的全局预热系统、利用中间件 Proxy 的链接技术保证用户链接不中断、无损事务续传的方案让用户得以进行更高效的资源管理， 并且因为内存和存储中的状态与数据库节点解耦，使用 Serverless 架构的 PolarDB 节点的崩溃恢复时间比使用单机架构的 PolarDB 内核快 5.3 倍。 

真正高性能的多节点横向扩展

Serverless 架构本身对数据库的性能会产生负面影响，毕竟数据库要从远程访问数据，因此想要高性能地多节点横向扩展不是一件容易的事情。

通过 Proxy 技术以及数据库引擎 PolarTrans 事务系统利用提交时间戳技术 CTS 和 RDMA 网络在内核层面提供集群全局一致性读 SCC 服务，保证发往集群任意副本的读请求都可以获得全局一致性的结果；通过 Scan 操作会将算子尽量推送到缓存端或者远程的存储之上，降低实际计算的数据量；并依靠新的硬件解决性能瓶颈，比如阿里云的倚天 710 等。

接下来，阿里云数据库团队还会在计算资源标准化、计费方式精确化、无感扩所容、资源快速调度、数据共享以及智能自治等层面继续优化 Serverless 能力。随着硬件的不断发展和计算任务的合理匹配，这种模式最终将会用户从中获得成本优势及体验优势。 

下一步技术规划

在日前召开的云栖大会上，阿里云数据库提出了整体向“四化”方向发展：云原生化(资源解耦、Serverless)、平台化(基于云构建数据平台能力、OpenAPI 标准化)、一体化(处理分析一体化、离在线一体化、集中分布一体化、多模处理一体化)、智能化(AI for DB 简化运维、In-DB ML 挖掘数据价值)。

数据库 Serverless 化是阿里云数据库团队在云原生方向的重要进展，然而这并不足以实现团队“让数据业务永远在线，数据价值不断放大”的最终愿景。达成这一点，还需要在平台化、一体化和智能化三个方向上努力，这也是团队接下来在数据库层面的技术规划。

平台化：数据库正在逐步走向融合

今年 10 月份，Oracle 发布了 Oracle Database 23c Beta，这是最新版本的融合数据库，支持所有数据类型、工作负载和开发风格。

这与阿里云数据库团队的理念不谋而合，但又不完全一致。

如前文言，阿里云数据库诞生之初就是要与底层云平台做融合，这也是阿里云成为国内最大的数据库厂商之一的重要原因。当然，这种趋势在整个行业内越来越明显，不仅仅是数据库，即便是自动驾驶厂商也在努力向软硬件一体的平台化方向努力，这也是 RDS 基于倚天 710 芯片，PolarDB 基于高性能的 RDMA 做存储，云原生数仓利用硬件能力做算子加速的核心逻辑。

在李飞飞看来，一个独立的数据库厂商如果只是在纯软件层面进行优化，所能构建的竞争力壁垒是非常薄的，如果不去做软硬协同的创新，就很难把竞争对手甩开。也正是基于这个逻辑，李飞飞强调，“我们是阿里云数据库。这是非常重要的区别。”

一体化：放弃分布式、集中式等执念，共生共存

在一体化层面，我们可以从三个方面来理解：处理分析一体化、离在线一体化、集中分布一体化，多模处理一体化。

处理分析一体化层面，阿里云数据库团队提出了两种模式：一是云原生 HTAP，PolarDB 基于 IMCI（In-Memory Column Index，内存列式索引) 处理轻量的分析业务；二是打通 PolarDB 和 AnalyticDB 提供一体化 HTAP 解决方案，让数据不需要通过部署额外的同步链路而是直接在内核层面传输，用户对此基本是无感的。

离在线一体化层面，AnalyticDB 已经做到一份数据同时支持在线分析和离线计算，通过智能的冷热分层和两大互相隔离的计算模型（传统的在线数据库交互式引擎和大数据引擎），并统一了计费单位、数据管道、数据管理及数据访问来实现离在线一体化。

集中分布一体化层面，团队认为这两种模式均有很好的应用场景，并不存在取代关系，阿里云数据库也确实是这么做的，PolarDB- X 通过将云原生数据库架构的 Shared Everything+Shared Storage 模式与分布式的 Shared Nothing 模式做融合，可以平滑地从集中式过渡到分布式，即便是应对双 11 大促这类超大规模数据量的并发也没有问题。

李飞飞认为，集中式和分布式的边界在快速抹平，而且从用户视角看，用户也不需要关心数据库是集中式还是分布式。“我觉得未来的趋势从客户视角其实就是一体化的数据化，什么集中分布式那是你内核需要解决的问题，客户不需要关心。”

多模处理一体化层面，随着数据的多样性不断增长，需要多模系统对多元异构的数据进行处理，Lindorm 将时序、宽表、KV、文档等多个数据模型融合在一个平台上，提供一体化的多模数据处理能力，化繁为简，让海量数据看得见，存得起。 

智能化：向自动驾驶的数据库平台努力

数据库智能化或者说自治是一系列原子技术的组合，广义上包含两大类：数据库外部运维和内核技术的智能化。外部运维就是最近流行的 AIOps，内核技术则是用 AI 技术提升数据库内核的某些性能。目前学术上对后者有很多前沿研究，比如 MIT 提出过使用深度学习网络代替 B-Tree 做索引，在一些实例上取得了不错的效果；IBM 使用深度模型做 SQL 执行计划优化等。但是，目前离成熟的、大规模产品落地还有一段距离。

“当前，业界的实现路径呈现‘百家争鸣，百花齐放’的状态。我们采取的策略是‘外围包围内核’， 先从 AIOps 做起，逐步进入内核智能化的领域。阿里云数据库自治服务 DAS 基于全量 SQL 和性能指标的大数据能力，深度融合人工智能和专家经验，可以分成上游的可观测技术，和下游的可控制技术两个系统。上游包括例如异常 SQL 定位，信号异常检测，针对稀疏数据或倾斜分布的高效统计采样， 还有把观测技术的结果按场景进行归类，用来驱动下游的控制。下游技术包括例如 SQL 外置优化，限流，压测，调参，弹性扩缩容，资源调度，SQL 审计等。这是一个复杂的，包含众多原子技术的体系。通过单点技术的原子能力，加上体系上的构建的丰富的产品功能，和阿里云上独有的规模化的服务，三者的结合构成飞轮效应，呈现给用户智能化的数据库自治能力，让用户聚焦在自己的业务创新和发展上。

虽然距离完全的数据库自动驾驶还有很长一段距离，但目标是可期的。

数据库的场景化爆发时代，来了

数据库是非常典型的场景化催生的产品，最早的场景便是处理银行交易。正是因为银行交易场景对数据一致性、隔离性、持久性、原子性等的强需求才催生了数据库将 Transaction 模型内置其中，但该场景如今已经被标准化。

如今，物理世界数字化以及生物世界数字化让数据库再度站在场景化爆发的路口，数据使用的多样性在需求侧大迸发，这也是空天数据库引擎 Ganos 得以被广泛关注的原因，但无论是智慧城市还是元宇宙这样的诉求都不是数据库本身就可以满足的，必然需要与底层的硬件能力、云计算能力深入融合，而这种融合所带来的成本优势、性能优势已经可以从阿里云数据库产品中窥见一二。

可以预见未来很长一段时间内，计算、内存、存储三层解耦的 Serverless 数据库以及云原生化、平台化、一体化和智能化的趋势将会成为数据库的主要形态。

注：本文部分内容参考自《Serverless数据库技术》研究报告，感兴趣的读者欢迎下载报告全文。