阿里云&中国信通院：Serverless数据库技术研究报告（2022）（30页）.pdf

《阿里云&中国信通院：Serverless数据库技术研究报告（2022）（30页）.pdf》由会员分享，可在线阅读，更多相关《阿里云&中国信通院：Serverless数据库技术研究报告（2022）（30页）.pdf（30页珍藏版）》请在三个皮匠报告上搜索。

1、 阿里云计算有限公司中国信息通信研究院云计算与大数据研究所 2022年11月Serverless数据库技术研究报告本报告版权属于阿里云计算有限公司和中国信息通信研究院云计算与大数据研究所，并受法律保护。转载、摘编或利用其它方式使用本报告文字或者观点的，应注明“来源：阿里云计算有限公司和中国信息通信研究院云计算与大数据研究所”。违反上述声明者，编者将追究其相关法律责任。参编单位阿里云计算有限公司 中国信息通信研究院云计算与大数据研究所编写组成员阿里云计算有限公司：于巍、章颖强、韦仁忠、曹龙、徐东来、滕万欣、李飞飞、王远中国信息通信研究院云计算与大数据研究所：刘思源、马嘉慧、马鹏玮、魏凯、姜春宇、

2、闫树版权声明编委会一、Serverless数据库概述 5（一）Serverless理念的起源 5（二）Serverless概念及特点 6（三）Serverless数据库的历史演进 7（四）Serverless数据库的市场前景 8二、Serverless数据库关键技术及应用场景 9（一）Serverless数据库关键技术 9（二）Serverless数据库应用场景 19三、Serverless数据库技术趋势 21（一）专注数据库易用性，打造面向业务的Serverless数据库 21（二）计算资源标准化，统一底层资源 21（三）计费方式更加精确，按需计费 22（四）扩缩容无感，纵享极致弹性，更快的

3、业务反应 23（五）资源快速调度，提升资源利用率 24（六）数据共享，打破Serverless数据库数据孤岛 24（七）数据库智能自治，提升Serverless易用性 25（八）新硬件加持，提升Serverless性能 25四、总结和展望 26附录：典型客户案例 27（一）PolarDB、AnalyticDB支撑双十一阿里集团电商业务 27（二）中国联通核心系统 31（三）云原生数据仓库AnalyticDB助力菜鸟运配平稳过高峰 32（四）PolarDB助力易仓快速扩容，应对业务洪峰 34目录图 1 数据库应用发展阶段 9图 2 存储资源池化 12图 3资源管理与调度 13图 4 计算+内存+

4、存储三层解耦 14图 5云原生数据库自动选主机制 16图 6 热备RO节点 16图 7 Proxy链接保持功能 17图 8 无损事务续传功能 18图 9 全局一致性RO节点 20图 10 PolarDB支撑双十一阿里集团电商业务 30图 11支撑双十一阿里集团电商业务 33图目录 2020年以来，数据库迁移上云态势显著提速，相较传统部署的数据库而言，云原生数据库通过存储计算分离，实现资源池化和弹性，具备高扩展性、高可用性、低成本等优势。在存算分离架构基础上，引入Serverless技术，可为用户提供真正具备秒级智能弹性扩容能力，随需而动的云原生数据库。据相关机构预测，2020年全球Server

5、less服务市场规模达到446.1亿元。中国Serverless服务的市场规模达到63.7亿元，约占全球市场的14.3%。2022年阿里云数据库制定ALL in Serverless战略。核心产品PolarDB、RDS、AnalyticD-BA、Lindorm全面实现Serverless能力。PolarDB结合存储计算分离架构和软硬一体化等创新设计，成本只有传统商用数据库的1/10，计算能力最高可扩展至1000核以上，存储容量最高可达100TB。RDS Serverless支持秒级变配，最高实现70%成本优化。AnalyticDB Server-less可支持海量数据毫秒/秒级实时分析查询，最

6、高节省90%的TCO。2021年在ACM SIGMOD大会上，阿里云发表PolarDB Serverless:A Cloud Native Database for Disaggregated Data Centers论文，创造性地提出了DDC（Disaggregat-ed Data Centers）架构，实现数据库内计算、内存和存储三层资源解耦，三层资源均可以按需分层弹性，内存层支持PB级弹性扩展。随着弹性RDMA高速网络、新型内存、新一代云计算架构CIPU等技术在云平台的普及等技术在云平台的普及，Serverless技术使计算、内存和存储资源的三层解耦从理论走向实际，未来将成为云原生数据库

7、发展的新趋势。开篇词李飞飞（飞刀）阿里云智能数据库产品事业部负责人达摩院数据库与存储实验室负责人ACM杰出科学家,IEEE杰出科学家,阿里巴巴集团副总裁随业务负载5秒自动弹性伸缩按业务用量秒级计费，成本最高降70%内核BP Online Resize优化，弹的更稳RESTful访问支持业界弹性范围最广，01000核扩展随业务负载5s探测，1s切换全球首创无感切换，连接保持无中断全球首创三层解耦，成本再降60%单作业010000个ACU秒级弹性扩展按规则和按负载，3秒自动弹升，秒级弹降分钟级计费，批处理SQL作业级别计费按量计费，成本最高降80%阿里云数据库核心能力摘要70%成本最高降60%成本

8、最高降80%成本最高降RDSPolarDB AnalyticDB 2009年，UC Berkeley发表了Above the Clouds:A Berkeley View of Cloud Comput-ing，并在该文章中首次对云计算做出定义：云计算包含互联网上的应用服务及在数据中心提供这些服务的软硬件设施。近年来，随着云计算飞速发展，云计算的形态也在不断的演进，从IaaS到PaaS，再到SaaS，云计算也逐渐地“找到了正确的发展方向”。2012年，Iron.io的副总裁Ken Form所写的一篇名为Why the Future of Software and Apps is Serverl

9、ess 的文章中，提出了一个新的观点：即使云计算已经逐渐的兴起，但是大家仍然在围绕着服务器转。不过，这不会持续太久，云应用正在朝着服务器无感知（Server-less）方向发展，这将对应用程序的创建和分发产生重大影响。这首次将“Serverless”这个词带进了大众的视野。此后国外Serverless生态迅速发展，诞生了如Serverless Framework、Vercel等很多优秀的产品。然而国内起步较晚，直到2017年阿里云和腾讯云才相继发布了国内的Serverless产品：函数计算和云函数，这时Serverless才开始进入大多数国内开发者的视野，各大厂商开始极力宣传和实践Server

10、less，短短三年后，国内Serverless开发进入蓬勃发展期，国内诸多企业开始用Serverless解决业务中的效率和成本问题。Serverless 翻译为中文是“服务器无感知”，这代表开发者不需要关心服务器。根据CNCF的定义，“Serverless是指构建和运行应用程序不需要管理服务器的概念。它描述了一种更细粒度的部署模型，即将应用程序打包为一个或多个功能，上传到平台，然后执行、扩展和计费，以响应当时确切的需求。”其核心思想是将应用程序解耦至“Function”并自动扩展缩减，让用户无需再关注服务器，包括托管或发生在服务器上的所有内容，从而进一步提高云的效率，降低运营的工作量和成本，有

11、效解决资源浪费与成本高的问题。广义的Serverless是一、Serverless数据库概述（一）Serverless理念的起源（二）Serverless概念及特点指构建和运行软件时不需要关心服务器的一种架构思想。基于 Serverless 思想实现的软件架构就是 Serverless 架构。与 Serverless 对应的概念就是 Serverful。在Serverful架构下，如果要保证应用持续稳定运行，需要用户自行解决很多问题，例如备份容灾、弹性伸缩、日志监控等。解决这些复杂的问题需要投入大量的人力物力，小公司几乎无法完成。Serverless 就是为了解决这些问题诞生的，它可以将底层硬

12、件、存储等基础资源隐藏起来，由平台统一调度、运维，并将常用的基础技术抽象、封装，比如数据库、消息队列等，将其以服务的方式提供给开发者。开发者只专注于开发业务逻辑，所有业务无关的基础设施，都交给 Serverless 平台。概括而言，Serverless 和 Serverful 的架构有如下区别，一是资源分配，在 Serverless 架构中，无需关心应用运行的资源（比如服务配置、磁盘大小），只提供一份代码就行；二是计费方式，在 Serverless 架构中，计费方式按实际使用量计费（比如函数调用次数、运行时长），不按传统的执行代码所需的资源计费（比如固定CPU），计费粒度也精确到了毫秒级，而不

13、是传统的小时级别；三是弹性伸缩，Serverless架构的弹性伸缩更自动化、更精确，可以快速根据业务并发扩容更多的实例，甚至允许缩容到零实例状态来实现零费用，对用户来说是完全无感知的，而传统架构这一过程需要较长时间。Serverless被业界认为是继虚拟化、容器技术之后的云计算的第三代通用计算平台。数据库对外服务形态也在不断演化，从传统的自建数据库一路演化到现在Serverless DB。第一阶段是用户自建数据库，这是数据库部署最传统的方式，用户自建机房时，就要考虑数据库选型，而数据库本身更要关注机房本身的物理部署，灵活性和可扩展性并不高。第二阶段是在云上以PaaS（平台即服务）服务形态，以租

14、用服务的方式提供给用户，这也是目前数据库应用的主流。在这一阶段，用户经常会碰到数据库扩容的突发需求，能否满足这些突发的扩容需求，成为用户关注的重点。第三阶段是云原生的数据库服务，其可以提供快速的扩缩容的能力，在这一阶段，用户不需要考虑扩缩容时机，但要考虑它的费用、成本等。云原生数据库还（三）Serverless数据库的历史演进不能实现按更小的粒度，即实现按使用量付费。第四阶段是Serverless数据库应用阶段，其具备完全自动化的扩容能力，它能够随着用户业务的请求数的增加和减少，智能化“膨胀”和“缩小”，实现资源的自动“吞吐”。这种全自动化特性，能够为用户带来更经济的计费模式和更无感的扩容体验

15、，它可以让业务根据请求的繁忙程度实现平滑的全自动响应，无需人工介入。在云数据库领域，云原生数据库市场空间广阔。据IDC预测，2022年全球关系型数据库规模有望超过300亿美金。根据2021年上半年中国关系型数据库软件市场跟踪报告 数据，2021上半年中国公有云关系型数据库规模6.7亿美金，同比增长50.1%。未来随着微服务理念和无服务器架构的Serverless技术的逐步成熟，容器和Serverless架构的融合发展有巨大前景，有望成为容器技术未来发展的趋势。2020年全球Serverless服务市场营收达446.1亿元，中国Server-less服务的市场规模达到63.7亿元，约占全球市场的

16、14.3%。传统云数据库的容器架构与Serverless架构结合，使云原生数据库在弹性、自动化等方面带来创新性价值。Serverless 架构提供了极强的弹性伸缩能力，按照负载动态分配资源，从而达到让资源适配业务需求。提供一种真正按需付费，并且在资源空闲时不收费的计费模型。这些特性使得Serverless服务在全球的热度持续增长。当前Serverless相关的应用已经在全球被广泛使用。FaaS(functions-as-a-service)作为Serverless技术领域中最具代表性的技术形态，是各大云厂商当前在Serverless生态上的主要服务之一。可以预见的是，Serverless的优势

17、将会促进更多PaaS技术产品与之融合。在与数据库技术结合后，Serverless数据库可以更好地满足市场需求。根据2021年上半年中国关系型数PaaS图 1 数据库应用发展阶段 （四）Serverless数据库的市场前景据库软件市场跟踪报告 数据，2021上半年中国公有云关系型数据库规模6.7亿美金，同比增长50.1%。未来，我国公有云数据库将主要以Serverless数据库形态呈现，所以Serverless关系型数据库市场将持续升温，是各大云数据库厂商未来发展机遇的重要战略地，是打开数据库市场规模与价值的必经之路。当前，用户对关系型Serverless数据库的应用主要集中在开发、测试等数据库

18、场景，未来或将有更多的客户将Serverless数据库应用于生产环境以及核心业务系统。云计算的核心理念在于池化资源的弹性使用。阿里云数据库基于线上数百万实例的运维经验，分析大量客户的核心痛点需求，总结出以底层池化资源为基础，利用RDMA高性能网络高效管理、使用物理资源的云原生数据库Serverless关键技术，实现资源池化及弹性扩展、高可用、高性能、低成本的Serverless能力。1、资源池化及弹性扩展（1）存储资源池化，存储计算解耦 云数据库作为贴近数据存储的中间件服务，其与底层存储有着紧密联系。传统数据库将数据存储在物理机本地的持久化存储设备中，如磁盘、NVMe SSD等，并在同一台物理

19、机上部署数据库实例以访问持久化数据。因此，当用户数据超出本机存储上限时，需要手动添加新的存储设备，或者迁移数据到存储空间更大的机器上。无论哪一种方案都是缓慢且长时间影响数据库服务能力。云原生数据库第一步是要将底层的庞大数据量池化，使得数据存储空间的弹性伸缩成为可能。池化的存储资源池，为上层的数据库计算服务提供弹性的存储能力。常见的池化存储方法可以是分布式文件存储服务，如Ceph、HDFS等，也可以是数据库系统定制的共享存储服务，如Ceph、HDFS等，也可以是数据库系统定制的共享存储服务，如Aurora的quorum机制存储服务、（一）Serverless数据库关键技术二、Serverless

20、数据库关键技术及应用场景PolarDB高性能共享存储PolarStore等。存储池化条件下，当用户需要进行存储空间扩容时，只需要向底层服务发起请求，数据库计算实例不需要做任何数据迁移，用户业务亦是无损影响。（2）资源调度 在存储资源池化以后，云原生数据库Serverless的计算资源弹性也需要实现优异的资源隔离能力，进而为基础的计算资源提供池化管理。管理平台需实时监控实例负载，根据丰富的弹性参考维度（CPU、内存、IOPS、链接数等），提供高效率的计算资源调度服务，最终提供秒级的计算资源弹性能力。实现该功能的常见技术路线可以是使用以Kubernetes等容器形式管理和调度计算资源，也可以是以虚

21、拟机的形式管理计算资源，例如开源服务OpenStack。Storage PoolRW（server-a）RO（server-b）RO（server-c）RW（server-b）RO（server-a）.图 2 存储资源池化示意图中心控制页面汇聚计算业务执行控制资源再分配秒级采集MySQL本地控制页面业务 资源决策决策数据链路控制链路图 3资源管理与调度（3）计算+内存+存储三层解耦 云数据库通常需要较大的内存对缓存磁盘上海量数据进行加速查询，以保证数据库的服务质量，尤其是对于OLTP类型对延时及其敏感的业务。然而，云上用户的业务类型丰富，其各种业务对计算资源与内存资源的需求比例是不同的，这就导

22、致固定的vCPU+内存的数据库规格售卖模式，通常导致用户购买的实例存在部分资源浪费的现状。例如用户对200G常用数据进行简单的插入操作，由于不需要复杂的计算，因此4vCPU可能足以满足用户需求，但是用户为了保证服务质量，想选用32GB内存从而缓存更多的数据实现加速查询，但当用户购买8vCPU+32GB规格的数据库实例，将导致购买的实例闲置了4vCPU资源。在其它场景下，用户业务可能需要更多的CPU资源，但对数据量要求并不多，导致用户购买的内存资源闲置。为了更多地降低用户成本，提升云上资源的利用率，云原生数据库需要将内存与计算节点进行深度解耦，实现CPU+内存+持久化存储的三层解耦模型。如图4所

23、示，在共享存储服务和计算节点之间存在一个GBP（Global Buffer Pool Service）服务。计算节点在物理服务器上只需要较小的内存作为用户查询在GBP中实际需求数据页的缓存，而将其余clean data page暂存在GBP中。使用池化内存有两个好处，一是计算节点服务器不再需要巨大内存，当用户需要扩展内存时只需要在GBP中动态扩展即可；二是当实例崩溃、重启或者迁移时，由于其数据页仍然在GBP中，其可以快速恢复服务而不需要再此从共享存储中加载持久化数据。Storage ServiceStorage NodeStorage NodeStorage NodeMemory NodeMe

24、mory NodeMemory NodeRW（server-a）RO（server-b）RW（server-d）RO（server-c）RO（server-e）LBP-aLBP-dLBP-eLBP-bLBP-cGlobal Buffer Pool Service图 4 计算+内存+存储三层解耦示意图LBP:local bu er poolGBP:global bu er pool2、高可用 云上环境中，多个用户的数据库实例部署在一台物理机上，并通过资源隔离保证其相互间不受影响。在Serverless场景下，统一物理机上运行的数据库实例可能都需要资源扩容，此时有可能遇到物理机资源无法满足所有扩容

25、请求的场景。如果选择预留足够多的资源以应对每一个数据库实例可能的扩容请求，这与Serverless的成本初衷背道而驰。因此，当本地资源不足时，我们需要将计算节点实例迁移到资源充足的物理机上部署。当实例发生跨设备迁移时，将产生两个连带问题，即迁移时间长和用户业务中断受损。为解决上述问题，云原生Serverless数据库需要具备高效的高可用能力。高可用能力可以总结为以下四部分：云原生数据库系统自动切换能力、RO节点预热状态的快速切换能力、用户链接保持与事务保持能力。（1）自动切换能力 当前业界的云原生数据库一写多读架构中，主节点的切换、旧RO（Read Only，只读）节点链接到新主节点一般都需要

26、外部模块进行决策与下发任务。该模块可能需要下发主节点停止任务、更新该模块必要拓扑信息、升级选定RO节点。这是一个耗时的任务流，并且有外部模块元信息和数据库集群不一致的风险。因此云原生数据库内核需要在数据库集群发生切主或者RW（读写）节点崩溃时，某个RO节点自动竞争成为新主，其余RO快速自动链接到新主节点。当前业界主要有两种解决方案，一是集群各个节点通过一致性协议，如Paxos、Raft选出一个新主的去中心化解决方案；二是利用云原生数据库中心化共享存储的分布式锁解决方案，如PolarDB Voting Disk Service解决方案。两种方案的核心都是集群节点通过某种协商机制，实现集群主节点的

27、自我维护。协商机制：一致性协议分布式锁RW协商模块RO 3协商模块RO 2RO 1图 5云原生数据库自动选主机制（2）热备节点：全局预热系统 在拥有集群主节点自我维护能力以后，进一步地，用户希望备RO节点选主成为新主以后，能快速完成RO至RW角色切换。云原生数据库引入了热备节点的角色。热备节点是一个资源弱化版的RO节点，同时也是一个更接近主节点、随时准备接班的灾备节点。相比普通的只读节点，它保留有限的读服务，预留更多的CPU、内存资源去优化切换速度。有了热备节点的全局预热系统加持，云原生数据库Serverless可以更快地完成切换，进一步降低用户业务的受损时间。（3）链接保持 在缩短了切主时间

28、以后，数据库系统快速恢复了服务能力，可以开始执行新的事务。但在切换过程中需要保持用户会话不中断，否则用户将明显感知到实例迁移而发生应用连接闪断、新建连接短暂失败、存量事务回滚等问题。因此，Serverless还需要解决在跨机迁移过程中的链接中断问题。对于迁移时的空闲链接，可以引入中间件Proxy，利用Proxy的链接技术保证用户链接不中断。Proxy作为流量入口，是当前云原生数据库的基础组件，负责云原生数据库一写多读的负载均衡，Storage ServiceHot Buffer PoolHot UndoHot RedoHot BinlogHot ReplicaBuffer PoolTransa

29、ction SysRedoBinlogMasterspace_id,page_idtrx infolsnfile,offsetruntimeapplywriteread图 6 热备RO节点接管理、高可用、安全防护。对于预期内的跨机迁移场景，首先管控组件会通知云原生数据库Proxy节点。Proxy节点收到通知后,开始进入高可用模式,在此模式下，新的建立链接请求被接受后,会开始被阻塞并等待后续释放通知；已经建立的链接,代理会阻塞新请求的发送。当代理探测到新的节点已经恢复并且加入到代理之中后，代理会和新节点建立链接,并同步环境变量(如字符集、用户变量、模式等信息)。随后,所有被阻塞的前端链接会被放行

30、,请求会继而发送到后端数据库。（4）无损事务续传 Proxy的链接保持技术只能处理切换时没有事务执行的空闲链接。对于切换瞬间正在执行的事务，一方面Proxy无法从数据库内核中找回原有事务的上下文，另一方面新主会将未提交的悬挂事务回滚，释放这些事务持有的锁。因此在这种场景下，链接保持就会失效。数据库内核还需要提供无损事务续传能力以解决这一缺陷，例如阿里云PolarProxy+PolarDB内核事务续传解决方案。在Proxy连接保持的基础上，对于切换时正在执行的事务，内核在切换以后会维护事务一段时间。在此段时间内，Proxy利用保存的用户连接信息与内核沟通，将事务恢复到切换时SQL语句的执行状态。

31、如下图所示，用户如果在执行事务1的更新语句时，发生了RW节点切换，Proxy会在内核切换完成后，在内核找到事务1的信息并重新执行更新语句。在用户视角，整个begin;insert;update;commit;事务信息缓存会话信息缓存语句缓存Proxytrx infosession tracker:会话信息、事务信息insertMasterSessionTransaction Sys热备SessionTransaction Sysinsert应用程序图 7 Proxy链接保持功能事务1begin;insert;update;commit;事务信息缓存会话信息缓存语句缓存ProxyAttach T

32、rxupdate故障MasterSessionTransaction Sys热备MasterSessionTransaction Sys应用程序update主备切换过程中，应用程序只感知到一条更新语句变成了慢SQL，但不会接收到连接报错或事务报错，后续应用层就不需要显式执行连接重连和事务重试，事务续传技术彻底解决了用户的感知问题。3、高性能（1）高性能全局一致性 因为云原生数据库横向扩展的RO节点上的数据和RW节点上的数据会存在复制延迟，用户通常无法在RO节点获取准确的最新数据。如下图所示，用户先后发起了事务1和事务2。事务1先发起，然后在RW上完成了数据A的更新。此时只读事务2发起在RO节点

33、上，假设事务2与事务1的间隙时间是t1。因为事务1的事务日志在传输到RO时存在复制延迟和回放延迟t2，如果t2t1,则事务2在RO上读到的数据结果是A=0。然而，根据数据库事务的定义，在Read Committed、Repeatable Read和Serialization隔离级别下，事务2都应该读到事务1的数据，也就是A=1。因此若不能实现在RO节点读强一致性的事务数据，数据库系统事务的一致性就遭到了破坏。在此情形下，为了保持数据正确性，数据库Serverless实例只能在单节点弹升。但是部署在物理机上的数据库实例能力会被物理机的集群自动切换+热备+无损事务续传的跨机迁移解决方案为用户管控侧

34、提供了更高的自由度，使更高效的资源管理方案成为可能。图 8 无损事务续传功能示意图单机规格上限所限制。因此，云原生数据库Serverless需要有跨节点全局一致性读的能力才能真正实现多节点横向扩展的弹性能力。因此，云原生数据库必须提供全局强一致的事务读能力，才能使事务一致性的RO节点替RW节点透明地分担用户负载。全局强一致性当前有两种技术方案，一是引入Proxy的辅助，让数据库RO节点上的事务等待日志回放到指定位点才能返回。但是所有读事务都等待，将使得数据库的性能极大回缩；二是PolarDB高性能全局一致性集群SCC（Strict Consistency Cluster）解决方案，PolarD

35、B数据库引擎的PolarTrans事务系统利用提交时间戳技术CTS和RDMA网络，在内核层面提供集群全局一致性读SCC服务，保证发往集群任意副本的读请求都可以获得全局一致性的结果。（2）计算算子（Shuffle、Scan）进一步分离，写跟读会分离 在OLAP应用场景，由于计算与存储分离后，计算相对没有状态。但是Shuffle在本地会导致BSP恢复成本较高，Scan操作需要将远程的数据拉取到本地。针对Shuffle会有类似ShuffleSer-vice的服务出现，Scan操作会将算子尽量推送到缓存端或者远程的存储之上，降低实际计算的数据量；存储层面，写操作由于需要较大吞吐量，读操作在计算后，将少

36、量数据返回；一般会将写操作做成单独的服务，进而承接大吞吐量的写操作。Storage Service事务系统事务系统A=0A=1Redo LogRedo LogA=0RW NodeRO NodeRedo Log复刷事务2：Select A事务1：update A=1非全局一致全局一致A=1A=0？A=1图 9 全局一致性RO节点示意图（3）引入新的硬件解决瓶颈问题 引入如GPU、FPGA、P-Memory来解决 Shuffle、Scan等池化后，进一步提升性能；新的芯片带来的新的指令集，如阿里云的倚天，计算需要在新的芯片下提供更高的性能；在向量化或者串通执行跟指令集做更加深层次的结合，在单机ru

37、ntime层面进一步提升性能；核心在于单位硬件的投入可以带来数单位的性能提升；如果不选择对象存储，则需要厂商自己提供机型，采取通用机型性价比较低，需要定制新的存储机型满足需求。4、低成本（1）将Meta&负载均衡&接入层等相关非计算存储资源池化 在OLAP应用场景，Meta、接入层、优化器、基于LSM的Build数据写入服务等全部池化，单客户初始化成本不到一分钱；一般Serverless后，会拓展大量的小客户，数据仓库需要提供非常低成本的规划，这就需要在计算与存储池化的基础之上，将负载均衡层、接入层、监控等全部池化；计算资源混合部署与超卖提升资源的售卖率，毫秒级的调度降低调度开销。大量的MPP

38、或者BSP计算模型的节点，需要快速的启动时间，降低资源的调度开销；不同用户在实际运行时，CPU或者内存占用率通常未达到100%，如果能实现一定程度的超卖也是未来竞争力的关键。数据库领域，用户在以下五个场景中可能应用到Serverless技术：1、可变工作负载 正在运行不常用的应用程序，每天或每年会出现数次峰期，每次持续30分钟到几个小时，例如人力资源、预算或业务汇报应用程序。使用Serverless技术后就不再需要按峰值容量预置，从而避免为不经常使用的资源付费，也无需按平均容量预置，从而避免可能导致的性能问题和糟糕的用户体验。2、不可预测的工作负载 正在运行的工作负载需要全天候使用数据库并且具

39、有难以预测活动高峰的特点，例如电商大促时可能出现活动量激增的流量站点。应用Serverless技术后数据库将自动扩展容量以满足应（二）Serverless数据库应用场景程序的峰期负载需求，并在活动量激增结束后缩减容量。3、企业数据库队列管理 如果企业拥有数以百计甚至千计的应用程序，每个应用程序都由一个或多个数据库支持，则必须妥善管理整个数据库队列的资源。由于应用程序的需求不断变化，要持续监控并调节各个数据库的容量以确保高性能、高可用性，同时将成本控制在预算范围内，将是一件难度极高的工作。应用Serverless技术后会根据应用程序的需求自动调整数据库容量，管理员无需再手动管理队列中数以千计的数

40、据库。4、软件即服务应用程序 软件即服务(SaaS)供应商通常会在单个集群中运行数以百计甚至千计的数据库，每个数据库支持不同客户，从而提高利用率和成本效率。但供应商仍需要逐一管理每个数据库。借助Serverless技术，SaaS供应商可以为每个单独的客户预置数据库集群，无需担心所预置容量的成本。系统会在数据库未使用时自动关闭数据库以节省成本，并且会即时调整数据库的容量以满足不断变化的应用需求。5、跨多个服务器横向扩展数据库 写入或读取需求高的客户经常会跨多个实例拆分数据库，从而实现更高的吞吐量。但用户预置的实例数量往往太多或太少，导致成本增加或扩展能力受到限制。借助 Serverless技术，

41、用户能够跨多个实例拆分数据库，让服务根据需求即时自动调整容量。系统可以无缝调整每个节点的容量，不会造成停机或中断，仅使用支持应用程序所需的资源量进行服务。Serverless数据库核心特点是高易用性，借助Serverless架构，底层的数据库操作可以被屏蔽，数据库能够根据需求动态进行资源部署、扩缩容等操作，而使用者只需要关注自身业务的相关数据使用问题。随着Serverless技术的不断发展，数据库的易用性将进一步提升，如支持更三、Serverless数据库技术趋势（一）屏蔽底层数据库操作，提升易用性多的扩容手段、支持自动的横向扩展能力，将用户从复杂的业务资源评估和运维工作中进一步解放出来。亚马

42、逊Serverless数据库Amazon Aurora Serverless能够完成无差别的繁复工作和自动化扩展，用户只需要关注面向业务的数据库模式设计、查询构建和查询优化。智能运维等能力也开始成为了主流云厂商持续投入的方向，如阿里云的DAS产品和以此为基础的阿里云PolarDB Serverless，腾讯云PostgreSQL for Serverless也在近期发布了面向业务的Serverless数据库。传统数据库的底层资源多种多样，存在多样化的异构硬件，用户数据库常常受到底层资源干扰，无法专注于业务。Serverless数据库能够屏蔽底层资源属性，通过计算资源的方式统一底层资源，不向用户

43、暴露底层具体数据，而是通过标准的计算资源方式为用户提供服务，避免用户受到底层资源干扰。标准化、归一化的算力服务能让更多类型的硬件无缝无感地接入到Serverless服务中，实现硬件无感化。2018年，亚马逊发布Aurora Serverless V1，支持ACU（Aurora Capacity Unit）衡量，最小1ACU最大128ACU；2022年，Aurora Serverless V2发布，最小支持0.5 ACU，实现了更加精细的资源归一化。2022年，阿里云发布RDS Server-less，以计算能力（RCU：RDS Capacity Unit）定价，真正实现按量付费，对底层资源进行

44、标准化和归一化。未来，更高标准化水平将成为Serverless数据库发展的一个重要方向。企业降本增效的需求对数据库的成本提出了更高要求，传统数据库按照使用资源，例如云服务器实例、虚拟机的规格等进行计费，同时计算资源和存储资源绑定，如计算资源增加会导致存储资源关联增加，造成资源浪费。Serverless数据库相比传统数据库成本更低，依赖于计算和存储资源解耦，用户能够按照服务的使用量，比如调用次数、时长等计费，而不必担心资源的浪费，从而获得更具性价比的数据库服务。随着存算资源的深度解耦，未来Serverless数据库的计费方式将更加精确，比如精确到具体SQL等，同时在成本管理方面，Serverle

45、ss数据库将会有更加完善的成本管理机制，比如预算预警、成本预测等功能，帮助用户节省成本。目前，行业以Amazon Aurora Serverless、MongoDB、阿里云RDS Serverless等为代表，实现按需计费。（二）计算资源标准化，统一底层资源（三）计费方式更加精确，按需计费 大量企业上云会产生规模效应，但目前线上资源全局利用率低，没有彻底获取规模效应的红利。因此，Serverless数据库具有超卖基础，而超卖面临的问题是如何进行资源调度。调度器是支持资源调度的核心组件，依赖于调度器，能够对CPU、内存、缓存等资源的利用率进行更加灵活地调度，从而获得数据库的极致性能和资源的更高利

46、用率，同时将红利释放给平台和用户。随着Serverless技术持续发展，更高资源利用率的调度会为Serverless产品在成本和客户体验上赢得更多主动权。随着精细化运营的深入发展，企业内多业务间的数据关联分析越来越复杂，为保证业务隔离（五）资源快速调度，提升资源利用率（六）数据共享，打破Serverless数据库数据孤岛 随着用户业务不断上云，企业面临工作负载不均衡等场景，比如双十一等，波峰和波谷往往差异极大，为数据库的选型带来较多挑战。传统数据库难以应对这类不均衡场景，在波峰时无法打破工作瓶颈，在波谷时无法避免资源浪费，这为企业用户带来巨大不便。Serverless数据库将资源进行细粒度地拆

47、解，即对存储计算能力进行解耦并拆分为可售卖的资源，以满足业务的资源编排。基于此架构，代码的执行不再需要手动分配资源，无需为服务的运行指定所需资源（例如使用机器数量、带宽大小、磁盘空间等），Serverless数据库能够根据用户的负载需求进行扩缩容，从而避免资源浪费或遭遇瓶颈，为用户极致的弹性体验。目前，Serverless数据库在分配资源时还需要用户提供预置策略，例如单个实例的规格、最大并发数、单实例最大CPU使用率等。同时，扩缩容由于不够平滑，无法实现快速反应以应对业务变化。未来，随着机器学习算法不断发展，Serverless数据库有望实现预测未来资源增长，快速供给资源，实现自适应分配，从而

48、达到扩缩容无感，有效满足业务需求变化。产业界目前在弹性能力上不断深入研究，阿里云PolarDB在业内首次实现计算、内存与存储的三层解耦，实现内存池化，使得弹性能力呈数量级提升。未来，随着资源不断解耦，Serverless数据库将提供更加极致的弹性体验、更加快速的扩缩容功能。（四）扩缩容无感，实现更快的业务反应 在数据库领域，人工智能扮演越来越重要的角色，推动数据库管理从被动支撑变为主动赋能。Serverless资源细颗粒解耦为数据库智能化提供新思路，增强数据库的可用性和自治能力。机器学习算法是实现Serverless数据库智能化的关键算法，算法可以对大量数据进行分析学习，构建应用领域模型，使数

49、据库更加自动化、智能化。数据库智能化分为三个方向，分别是智能诊断、智能优化和智能预测。智能优化如针对数据库表结构进行优化，为用户提供降低集群使用成本、提高集群使用效率的调优建议。智能诊断从不同的层次进行诊断分析，帮助用户快速定位问题，直观地提供问题根因，如数据倾斜、索引低效等。智能预测能够根据历史工作负载预测未来工作负载趋势，如预测访问峰值、资源使用情况等。阿里云DAS专门为数据库提供智能优化和智能诊断，此服务将会大幅减少用户强依赖于经验进行的数据库运维操作。未来，智能化将帮助数据库实现自治，数据库可以实现自监控、自决策、自执行，几乎不需要人工处理。Serverless数据库底层依赖于硬件的支

50、持，新硬件能力的提升带来了Serverless数据库能力的提升。目前融合Serverless数据库、云计算与新硬件的优势，结合新硬件，例如RDMA、GPU、（七）数据库智能自治，提升Serverless易用性（八）新硬件加持，提升Serverless性能 和资源独享，企业一般会创建多个业务实例。如需对同一份数据进行流转，需要数据在实例间多次复制，极大地降低企业分析效率并增加了数据库运维的复杂程度，这对Serverless数据库提出了数据共享的需求。Serverless数据库使用存储计算分离架构，通过共享的元数据和数据存储实现无冗余数据共享，可以解决数据共享的难题，支持一存多读，实现数据在多个实

51、例间的流转，并避免出现数据冗余、数据不一致、数据缺乏实效性等问题。数据共享可以极大地优化两个核心业务场景，一是负载隔离场景，支持将访问共享数据的工作负载彼此隔离；二是业务协作场景，支持进行跨业务协作，数据可以在业务线、客户组、业务组之间进行共享。2022年3月，云原生数据仓库AnalyticDB PostgreSQL版率先在国内推出数据共享功能，无需移动数据即可实现账号下多实例的联合分析。利用数据共享解决数据流转问题，打破数据孤岛，这是未来Serverless数据库发展的重要方向之一。四、总结和展望 2022年以来，数据库迁移上云态势显著提速，相较传统部署的数据库而言，云原生数据库通过存储计算

52、分离，实现资源池化和弹性，具备高扩展性、高可用性、低成本等优势。近年来，云原生数据库在存算分离架构基础上，引入Serverless技术，具备智能弹性扩容能力，能够随着用户业务的请求数的增加和减少，自动“膨胀”和“缩小”，实现资源的智能“吞吐”。2021年SIGMOD大会上，阿里云发表PolarDB Serverless:A Cloud Native Database for Disag-gregated Data Centers论文，创造性地提出了DDC（Disaggregated Data Centers）架构，实现数据库内计算、内存和存储三层资源解耦，三层资源均可以按需分层弹性，内存层支持

53、PB级弹性扩展。智能弹性技术的引入，为用户带来更经济的计费模式和更无感的扩容体验，成为云原生数据库技术新趋势。资源池化方面，随着RDMA高速网络和新型内存技术普及，在同一数据中心内，计算、内存和存储资源的三层解耦逐渐从理论走向实际，成为云原生数据库资源管理的新趋势。（一）PolarDB、AnalyticDB支撑双十一阿里集团电商业务附录：典型客户案例FPGA，有助于实现计算下推存储、关键算子加速，不断优化向量化执行引擎，发挥硬件的极致性能，提高数据库的性能表现。同时，由于顶层架构不断精细化和计算存储解耦，顶层任务可以被分配到最合适的硬件进行执行，从而发挥每个硬件的优势，提升整体性能。未来，随着

54、硬件不断发展和计算任务的合理匹配，用户将获得更加极致、快速的Serverless数据库体验。PolarDB 11金融云物流云零售云阿里巴巴电商核心业务ALL INPolarDB1.4亿次/秒 2021 11 TPS图 10 PolarDB支撑双十一阿里集团电商业务 双十一是阿里巴巴旗下淘宝商城（天猫）的年度促销活动，双十一购物狂欢节从2009年11月11日举办至今经过了十多年的发展，已经成为每年例行的全民购物大狂欢，参与人数也从早期的百万人发展到现在上亿人，成交额从5000万跃进到5000亿。双十一与智能手机、移动互联网的兴起同步，见证了中国经济的蓬勃发展。2020年双十一，PolarDB、A

55、nalyticDB支持了阿里数字经济体内几乎所有BU的业务，承载了集团的菜鸟、新零售供应链、DT数据系列产品、数据银行、生意参谋、人群宝、达摩院店小蜜、AE数据、盒马、天猫营销平台等130多个主要业务。双十一大促当天，部分商家的优惠活动存在时限性或名额限制，在零点开始的一小时内，大量客户涌入，业务流量会突增数百倍，且在双十一当天，业务流量都远远超出日常访问值。数据库作为大促交易链路的核心环节，为了应对业务流量的突增，对数据库的弹性提出了很高的挑战。针对OLTP场景，传统方式下需要采购大量的服务器资源以支撑双十一流量高峰，数据库整体弹性能力不足，服务器采购周期长，双十一期间无法快速弹性，业务受损

56、。峰值过后资源无法得到释放，大量资源长时间低效运行产生很大的资源浪费，成本高，运营效率低，PolarDB弹性能力，保证高性能同时，大幅降低集团采购成本。针对OLAP场景，AnalyticDB 在双11中，支持了集团的核心交易链路，这对实时高并发写入、在线检索的能力提出了极高的要求。双十一总共超过600亿条订单记录，波峰值达到500万TPS，是日常的100倍。而对于大规模的离线数据的写入链路，压力更是在双11时候更是达到了顶点，以数据银行业务为例，在双11当天，对AnalyticDB的 TPS峰值写到近1000万，写入流量峰值达到1.3GB/s。要这些业务波峰，随之而来的是对数据库资源弹性近乎苛

57、刻的要求。资源必须能够快速部署资源，稳定拓展，稳定高效的承接业务，而在波峰过后，一切资源将随之释放以满足日常负载；面对OLTP业务挑战，阿里通过云化架构提升整体的技术效率和全局资源的弹性伸缩能力，数据库采用了云原生的自研数据库PolarDB提供了高弹性、高性能的云数据库服务，大幅降低了节日大促的保障成本和复杂度。PolarDB全面容器化发挥云的弹性能力，减少自采基础设施的投入客户背景业务挑战产品解决方案18 在双十一前期，结合压测结果，业务预估所需资源按需申请，将原有资源占有时间从1年降低到1月，大幅降低成本。大促期间，serverless能力提供分钟级的规格自动调整，存储计算分离架构增加节点

58、无需搬迁数据，分钟级扩展节点，快速紧急扩容保障用户体验。大促过后，资源自动降配，闲置资源自动释放降低成本。面对OLAP业务挑战，AnalyticDB 通过拥抱云原生，完成了重大架构升级，在公有云上也同步发布了新版弹性模式，让用户拥有极高性价比、极致弹性的新一代数据仓库。AnalyticDB的新弹性模式形态，后端采用了计算存储分离的新架构，提供统一的服务化Serverless存储层，计算层可以独立弹性扩展，同时兼具了预留模式的性能。通过计算与存储的解耦，用户可以灵活地单独对计算资源、存储容量进行扩缩，合理的控制成本。针对计算资源的扩缩，不再需要数据的搬迁，具备更极致的弹性体验。搭配Analyti

59、cDB全新研发的行存引擎，在这个双11首次表现亮眼，可支持千万级QPS在线高并发检索和分析，实现单表点查、聚合及TopN是开源ElasticSearch的2-5倍，存储空间节省50%，写入性能是其5-10倍，并且保证数据的实时可见和数据高可靠。图 11支撑双十一阿里集团电商业务 双十一交易系统全面云化，阿里云自研云原生数据库PolarDB承载了阿里电商核心业务数据库流量，按需资源分配，分钟级弹性扩缩容，支撑双十一亿级访问峰值，CPU利用率平均提升20%以上，单表交易成本下降50%，运营效率提升3倍，保障双十一业务平稳。AnalyticDB通过全面云原生化，成功的在这次双11中为阿里集团的核心业

60、务保驾护航。从核心交易链路的高并发在线检索到复杂实时分析应用场景，表现非常稳定。当天各项指标再创新高，AnalyticDB当天的写入TPS峰值到达2.14亿，通过离在线一体化架构，支持在线ETL及实时查询Job数达到174571个/秒，离线ETL导入导出任务570267个，处理的实时数据量达到7.7万亿行。为核心业务方提供了数据处理ETL、实时在线分析、核心报表、大屏和监控能力，保障了数十万商家和千万消费者的稳定的离在线数据服务。中国联通是目前唯一一家整体进行混合所有制改革试点的中央企业。公司在2021年财富世界500强中位列第260位。作为支撑党政军系统、各行各业、广大人民群众的基础通信企业

61、，中国联通在国民经济中具有基础性、支柱性、战略性、先导性的基本功能与地位作用，具有技术密集、全程全网、规模经济、服务经济社会与民生的特征与属性。客户收益客户背景业务挑战（二）中国联通核心系统省级系统规划做全国大集中，当前数据库架构缺乏弹性扩展能力；系统数量过多，当前面临巨额license费用；传统Oracle数据库架构只支持主备模式，无法支持异地多活。PolarDB分布式扩展能力支撑核心计费CBSS系统；PolarDB弹性变配扩展能力，分钟级完成集群节点变配扩容；异地多活中心架构具备跨域容灾能力，同时降低成本。使用阿里云数据库，替换其原有的传统IT系统架构，该系统是2014年以来构建的，支持全

62、国业务的cBSS系统。目前，这套系统支撑了超6亿用户，是全世界规模最大的电信业务支撑系统之一。“凌晨付款起床收货”成了今年双十一快递时效的新标签。作为天猫官方物流服务提供方，今年菜鸟联合14家快递公司为消费者提供了如任意门般的天猫双十一物流体验。在双11之后，快递配送即将面临业务的高峰。智能运营平台作为菜鸟运配域的数据中台，一直承载着整个运配事业部几乎全部的数据洞察、分析类需求；作为运配事业部运营的眼睛，智能运营平台有将近客户背景（三）云原生数据仓库AnalyticDB助力菜鸟运配平稳过高峰产品解决方案客户收益 菜鸟运配整体业务挑战包括包裹链路长、数据源各异、实操集中发车、数据实时性要求高等。

63、去年双十一和今年618，相继出现过慢SQL、数据导出量过大、SOP遵守率参差不齐等问题，并且大促期间会有大量的临时运营需求需要快速响应和支持，这些对数据链路的存储、抽取、计算都会是非常大的挑战。今年双十一对以下能力提出了很高的要求：1）运配数据洞察要求高并发低延迟；2）运配数据的高度实时；3）满足高吞吐的实时数据写入；4）大促稳定性保障。面对客户的核心诉求，云原生数据仓库 AnalyticDB版联合Lindorm、Blink等构建了包含上千指标的实时数据链路后置汇总业务技术架构，将链路上各个数据源的海量数据实时多流join形成宽表。依托了AnalyticDB产品的弹性灵活性，将计算资源按照需求

64、进行动态调整；同时在 AnalyticDB版在云原生架构下推出的弹性形态下实现了资源组功能，通过新建资源组可以从现有实例划分出部分计算节点，这些计算节点资源只归属该资源组并与用户关联。实现资源组的任务资源隔离，满足云原生多业务租户隔离、混合负载的需求。保证业务间表现稳定，互无资源干扰。在云原生版本下，依托于存算分离架构，灵活的资源弹性，共享存储及完备的资源隔离能力，在整个双11周期中，AnalyticDB 支持菜鸟运配智能运营中台完善支持各个业务间的业务期待，保证了各个业务间的稳定；正是阿里云云原生数据仓库 AnalyticDB 为菜鸟运配的运营决策提供了强有力的数据支撑，使包裹能够通过更优更

65、快的线路到达消费者手中。客户收益业务挑战解决方案（四）PolarDB助力易仓快速扩容，应对业务洪峰 深圳市易仓科技有限公司成立于2013年，是一家以“引领跨境智变”为定位的跨境电商中台服务商，经过7年多的积累沉淀，发展成为跨境软件行业的头部企业，是跨境行业中第一家拥有完整中台系统的服务商。团队一直致力于研发高效可控的跨境管理系统，以跨境电商ERP、国际物流TMS、海外仓WMS和跨境分销M2B等精细化管理系统，服务于中国大中小跨境出口电商。易仓主要做跨境电商业务，租户（卖家）会经常搞大促，特别在黑5、双11等节日，业务流量会突增，MySQL数据库计算资源存储需要支持快速扩容，应对业务洪峰。租户业

66、务也有生命周期，当租户停用下线时，如果数据库存储资源不能自动回收，会导致存储资源浪费，增加资源成本。传统面对这种问题，一般通过迁移新实例或合并实例方式来回收存储资源，但耗时太长，运维成本会比较高。针对易仓业务的不确定业务负载的诉求，阿里云数据库团队对易仓业务进行了详细评估与分析，提供了针对性的Serverless解决方案。PolarDB MySQL采用存储和计算分离的架构，所有计算节点共享一份数据，扩容时不需要迁移底层数据，增减节点可以在分钟级完成，可以满足跨境电商大促时，数据库快速升配的需求。PolarDB存储采用分布式块存储设计和文件系统，使得存储容量不限制于单节点的规格，扩展比较容易，可

67、以支持100TB级别的数据规模，用户不用担心会有存储容量瓶颈。而且存储空间无需手动配置，根据数据量自动伸缩，按实际使用量计费。租户停用下线清理后，存储会自动回收，节约资源成本。PolarDB完美解决了传统本地盘部署时，DBA需要面对的扩缩容及容量管理的挑战，极大降低了运维负担。产品解决方案客户背景业务挑战客户收益 Armbrust,Michael et al.“Above the Clouds:A Berkeley View of Cloud Computing.”Science 53(2009):07-013.Ken Form“Why the Future of Software and Apps is Serverless”Read write(2012)2021年上半年中国关系型数据库软件市场跟踪报告，IDC,2022年1月注释