1. 概述

数字化已经成为企业提升业务效率、市场竞争力、管理能力的关键，后疫情时代经济复苏和企业重新起航需要较长时间，大部分企业在这段时间的核心策略是“收缩战线，精兵简政”，企业在上云、用云过程中，面临增效降本的诉求，作为数字化的核心技术---数据库如何增效降本，和企业一起度过困难的阶段，是很多企业关注的话题。

阿里云瑶池数据库一直在思考如何给企业提供高效稳定的数据库解决方案，同时帮企业节约IT成本，并持续建设和构思增效降本的方法和路径。

2. 业务痛点和应对思考

2.1 企业上云、用云面临的数据库增效痛点

企业业务由小壮大过程中，业务逐步复杂、业务类型日趋多元化、数据量逐步变大、数据库实例数逐步增加，需要构建高性价比、低成本的数据库方案；数据库方案要具备高稳定性、高性能、健壮性好、架构简单易维护等特点；不同类型业务对数据库计算资源使用特点不同，需要具备灵活、高弹性、适配性好计算资源提供方式以满足不同类型业务个性化使用需求；随着数据量从较小逐步增大，数据存储如何更低成本、更便捷地存储和访问以及可持续支撑业务，也是数据库方案的重要关注点；随着研发团队的人员日趋增多和数据库实例的不断增长，如何给研发团队提供安全、高效、低使用成本的数据库方案的也成为企业负责人关注的重要话题。面对企业这些诉求，云数据库如何在产品、方案侧应对的呢？

2.2 构建增效降本能力、策略和思考

我们首先思考一个问题：将数据库定义为一种服务，对一个上云、用云企业，云数据库直观成本包括哪些？

硬件成本：云厂商承载数据库实例的服务器、网络、存储以及IDC基础设施成本。
软件成本：云厂商研发、迭代数据库软件的人力成本，部分服务有软件采购成本。
使用和维护成本：企业使用数据库的人员花时间学习、掌握技能，数据库需要技术人员维护。
时间成本：企业采用复杂方案、低效方案、不稳定方案方案，有较长的学习时间成本和试错成本。
数据处理成本：为提高数据资产价值，企业探索数据使用方式和数据流转方式需要较大人力成本。

对企业来说数据库成本包含两个维度，一个是云厂商提供可持续服务的成本，一个是企业使用和维护数据库的人力成本和时间投入成本；增效降本方案需要“降低”软硬件成本，并通过优势方案提高数据库使用人效、降低人力成本和时间成本。

3. 构建云原生数据库增效降本方案

3.1 数据库增效降本框架

云数据库实现增效降本，提供几个层面手段和方案：

1.数据库计算资源弹性，通过快速弹性升降配、自动弹性升降配、Serverless等方式提高弹性能力，充分利用云的弹性能力降本。

2.数据库存储资源，提供数据透明冷热分层、数据平滑归档、存储高压缩比、新硬件增效降本等应对海量数据存储和访问的高性价比方案。

3.数据库架构优化，提供数据库HTAP解决方案、多源汇聚库、低成本多级数仓等架构优化方案，降低使用成本、开发维护成本。

4.建设运维、研发增效方案，基于DMS的数据库DevOPS方案，基于DAS的构建数据库“自动驾驶”方案。

从下图可以看出云数据库提供的增效降本方案覆盖了数据计算、数据存储、数据流转、数据分析、数据管理维护等不同业务阶段供企业选择。

3.2 计算弹性增效将本

弹性是云原生数据库核心优势，能有效降低计算成本，阿里云数据库一直致力于提供弹性能力更强方案给企业客户，云数据库的弹性能力经历了三个阶段：

第一阶段是高弹性能力，将天、小时级弹性提速到分钟级。第二阶段是自动弹升，支持基于预测的自动弹性伸缩和定时自动弹性伸缩提高弹性能力。

第三阶段是建设和持续演进数据库Serverless能力，进一步提升资源利用率。

传统主从复制架构数据库升降配和增加节点需要复制数据，耗费时间和数据物理大小有关。PolarDB借助RDMA高速网络和共享存储能力，升降配增加节点与数据库大小解耦，分钟级即可完成，可构建“流量突发型业务库”提效方案提升企业数据库弹性能力。

部分企业业务复杂度高、多样化强、异常流量无法预测，对弹性方案提出了进化要求，数据库自治服务DAS的自动性能扩展结合PolarDB分钟级弹性提供分钟级自动弹升能力，很多企业客户借助该能力规避性能风险。云数据库RDS MySQL也支持性能自动扩容能力，云原生数仓AnalyticDB通过分时弹性支持定时自动弹升能力。

Serverless技术给资源弹升和计费带来更灵活的能力，PolarDB攻坚了Serverless技术难点：资源解耦、自动弹性伸缩、按使用量计费、秒级弹性扩展等。支持无感BP Resize的本地Scale Up、跨机ScaleUp、跨机ScaleOut。云数据库RDS MySQL、云原生数据仓库AnalyticDB、云MongoDB也都具备了Serverless能力。

3.3 存储透明冷热分层、压缩增效降本

数据存储是数据库的核心能力，云数据库借助云基础设施构建和支持不同技术指标、不同成本、使用灵活的存储方案。企业的业务数据类型、业务数据量、数据物理大小随着业务发展到一定阶段和量级面临以下痛点：单实例存储量大、存储成本高、实时业务数据高性能访问、海量数据高性能访问诉求等。

云数据库通过以下几种技术方案来实现数据存储方面的提效和降本：

数据透明冷热分层存储读写
数据存储压缩
自研X-Engine引擎历史库
硬件压缩盘（Smart-SSD）
Tair PMEM持久内存

3.3.1 透明冷热分层方案

冷热数据分层存储是应对大量数据存储常见方案，根据数据使用频率、文件大小、文件类型等特征做数据冷热分层，采用适配的存储介质存储，满足存储海量数据、延长保存期限、降低存储成本、提高数据访问效率等诉求。

数据冷热分层的关键是透明冷热分层存储策略、冷热数据透明读取以及无感数据过期迁移，通常以时间字段作为区分冷热数据依据。如在Lindorm上，在表上配置数据冷热时间分界点（COLD_BOUNDARY），Lindorm根据数据写入时间戳(毫秒)来判断数据冷热。数据写入时优先存储于热存储，写入时间超过冷热时间分界点，major_compact时归档冷数据到冷存储介质。数据读取时自动根据查询时间范围条件决定查询热区、冷区还是冷热都查。

除了Lindorm，Clickhouse、PolarDB MySQL、AnalyticDB MySQL也支持数据冷热分层存储和读取。

3.3.2 数据存储压缩方案

除了将冷热数据分别存储到不同介质外，很多数据库支持引擎层面采用压缩算法来减少空间占用，如PolarDB X-Engine引擎，对比InnoDB引擎，最高可节省50%的存储空间；Lindorm内置深度优化的压缩算法，数据压缩率高达10:1以上。

X-Engine引擎行存数据压缩

业界根据MySQL可插拔存储引擎能力提供了RocksDB、Tokudb、Infobright等具备压缩能力的存储引擎应对关系型数据增长问题。阿里云X-Engine也是为解决海量关系型数据存储的数据引擎。X-Engine在LSM-Tree分层存储架构基础上进行了重新设计，根据数据访问频度(冷热)的不同将数据划分为多个层次，针对每个层次数据的访问特点设计对应存储结构，写入合适存储设备。使用Copy-on-write技术，避免原地更新数据页，对只读数据页面进行编码压缩，可以将存储空间降低至10%~50%。

Lindorm高压缩能力

Lindorm在数据压缩方面也提供了非常优秀的能力，提供超10倍数据压缩比。

字典压缩：Lindorm宽表基于LSM-Tree引擎构建数据存储，通用压缩算法上结合ZSTD深度定制，推出字典压缩能力—自动提取数据样本采样分析，根据数据特质，智能选择合适的编码压缩参数，提取公共字典消除字典结构带来的额外开销，进一步提升了数据的压缩比率与压缩速度。
时序数据专用压缩算法：Lindorm时序引擎借助TSM架构实现时序数据的高效写入，采用定制时序压缩算法提高压缩比，最高可达15:1的压缩率比。
本地盘HDD与ESSD异构副本：Lindorm通过LindormDFS异构副本实现1副本ESSD+2HDD冗余，通过HDD盘低成本优势结合冷热分层显著降低存储成本。

3.3.3 新硬件新技术方案

硬件压缩盘（Smart-SSD）PSL4

PolarDB引入阿里巴巴自研Aliflash Smart-SSD技术，在物理SSD磁盘层面压缩、解压缩存储的数据，实现性能零损耗下数据存储成本最高下降 60%。硬件压缩盘的压缩引擎集成在盘片内部，通过FPGA/ASIC提供专用算力在数据读写过程中实时压缩、解压缩数据，从而节省存储空间。

Tair持久内存

Tair是阿里云自研云原生内存数据库，完全兼容开源Redis，除了纯内存的产品形态，Tair借助于新型存储介质——Intel 傲腾（AEP）持久内存技术，实现成本低于于内存（DRAM）30%以上。

Tair持久内存实例中，每条记录都确保写入AEP并且持久化才返回，极大提升数据可靠性，可以做到RPO=0；读取路径上使用Dram缓存如索引、数据结构、元数信息等热点数据，加速数据访问。

3.4 技术架构优化增效降本

随着业务规模、用户量、业务复杂度的提升，企业使用数据库的场景日趋复杂，自建数据库服务面临着构建更多周边服务降低使用、学习成本，云数据库提供多种技术架构优化方案，本段介绍HTAP解决方案、多源汇聚库方案、基于湖仓一体的多级数仓方案。

3.4.1 HTAP解决方案

HTAP是数据库技术领域新概念，是在线事务（OLTP）和在线分析（OLAP）合称简写。HTAP的最大优点是可以在一个数据库中支持OLTP和OLAP业务，系统具备完整事务能力，支持实时插入、实时删除、单条更新、批量导入、按索引查询、海量数据实时分析等能力。

阿里云PolarDB MySQL通过列存索引IMCI和弹性多机并行ePQ使得PolarDB具备HTAP能力，支持OLTP高并发读写的同时，大幅提升PolarDB在大数据量复杂查询性能。优化器支持基于代价的执行计划选择，从IMCI->ePQ->MySQL原生串行查询，保证SQL 100%可解析执行。IMCI(In-Memory Column Index)节点和行存只读节点基于物理复制保证延迟在毫秒至秒级，提高数据访问的实时性。适用于亿至百亿业务数据复杂查询提速、原生MySQL查询慢、业务混合负载业务查询提速。PolarDB HTAP方案在实际业务场景使用中最高可以达到百倍慢查询提速，畅捷通、金万维等客户都借助HTAP方案为业务提速。HTAP方案业务架构图如下：

PolarDB IMCI通过列式存储高压缩存放、按需读取需要分析列、执行器算子并行执行、单个线程内算子数据交互以Batch为单位降低函数调用开销等技术结合配合弹性多机并行使得PolarDB成为一个真正的HTAP数据库系统。

弹性多机并行ePQ可以利用多计算节点资源进行并行查询，提速TB级别甚至单表10TB以上多表关联复杂查询，突破单机CPU/IO瓶颈将多个节点计算资源打通，利用全局资源提速大量数据复杂查询。

3.4.2 多源汇聚库

多源汇聚库是泛互联网企业做微服务拆分、数据库垂直拆分后常见的跨实例数据访问、数据抽取、数据流转方案，为降低研发成本考虑采用汇聚库方式做拆分后跨库数据查询和数据流转。传统多源汇聚库方案通过开源或商业数据复制工具将多个业务库数据复制到汇聚库，汇聚库结合代理软件向不同业务侧提供数据库服务，支持跨库查询、数据抽取、数据下有复制等，常见架构如下：

该方案满足跨库查询需求、数据向下游流转、慢查询导致业务库性能抖动问题，存在以下不足：数据复制延迟大影响数据访问质量、存储成本高、开源代理不稳定维护成本高、汇聚库以及数据流转任务恢复成本高DBA维护压力大。

阿里云数据库提供基于PolarDB多主集群的多源汇聚库方案，多主集群支持一个集群多个主节点，任意主节点都可访问共享存储内所有数据，并可以在任意主节点读写。不同主节点可以承载不同数据库支持任意主节点之间秒级切换数据库，可以通过全局读节点结合智能代理替代汇聚库，支持流量自动转发读写和负载均衡，架构如下图：

基于PolarDB多主集群构建的多源汇聚库方案具备以下业务收益：

1.提高跨库聚合查询和数据向下游流转效率。

2.降低存储成本：存储成本占比高(50%以上)相对自建数据库可降本10%以上，某交易属性客户迁移后降本20%。

3.提高数据访问质量：复制延迟毫秒至秒。

4.提高异常恢复速度：级扩容写节点、全局读节点高可用、分钟级新增几点。

5.DBA工作量低：异常切换恢复操作便捷、数据流转方便、方便授权。

3.4.3 基于湖仓一体的多级数仓方案

随着业务数据不断增长和多样化，可以把数据大致分为两类，一类是结构化数据，另一类是非结构化数据。结构化数据最具代表性的数据库有Oracle和Teradata，但面临维护成本+政策风险双重压力；半结构化或非结构化数据根据数据特征可以分为宽表、时序、图、key-value、文档等，这两类数据存储读取典型代表是Hadoop，但技术栈繁多、复杂依赖个人能力，维护成本过高。数据业务特性随着时间发展从传统商业业务数据，到互联网平台业务数据，再到万物互联的业务数据，数据规模也从GB级，到PB级，再到EB级。

数据作为企业的核心资产，随着企业之间商业竞争日益激烈，数据流动越快产生价值越大企业竞争力越强。传统数仓面临挑战越加严峻，大数据发展也从传统数仓发展到离线大数据时代来满足大数据量和数据多样化的诉求，企业对数据实时性要求越来越高，需要通过实时数仓以及湖仓一体来解决所面临的痛点。下面介绍基于阿里云构建实时数仓和湖仓一体的多级数仓方案。

如何构建实时数仓

数仓一般分为ODS层、DWD层、DWS层和ADS层，数据分层越多，数据的实时性受影响越大。要构建实时数仓需要减少数据端到端的层数和并提高数据处理速度，数据分层结合数据业务需求，额外构建一套实时数仓，来满足实时业务场景。

根据现有数仓体系演进的架构就变成标准数仓分层+流计算+批处理，具体架构变成如下：

基于该设计理念衍生到阿里云实时数仓解决方案：

选择数据传输服务DTS支持业务数据到实时数据的数流转，实时数仓选择云原生数据仓库AnalyticDB MySQL数仓版，湖仓一体方案选择AnalyticDB湖仓版支持，通过数据管理DMS支持任务编排、数仓开发、ETL等功能，同时DMS还支持流式ETL。

为何选择DTS做数据实时流转

数据传输服务DTS支持关系型数据库、NoSQL、大数据(OLAP)等数据源数据实时同步，提供功能丰富、操作便捷、数据实时复制、传输性能强、支持断点续传、易用性高、安全可靠的数据传输服务，简化数据流转工作，使数据开发人员可以专注数据业务开发。

为何选择AnalyticDB？

云原生数据仓库AnalyticDB MySQL版是新一代云原生数据仓库，AnalyticDB支持高吞吐数据实时增删改、低延时实时分析和复杂ETL，兼容上下游生态工具，可用于构建企业级报表系统、数据仓库和数据服务引擎。AnalyticDB具备以下优势：

兼容MySQL：高度兼容MySQL协议以及SQL 92、SQL 99、SQL 2003标准。
多租户：通过资源组实现计算资源隔离满足不同类型租户业务需求。
分时弹性：支持定制弹性计划（每天定时、每周定时），业务高峰期来临前自动扩容满足业务流量增长需求，业务高峰过后缩容降低IT成本。

AnalyticDB湖仓版

基于AnalyticDB湖仓版构建湖仓一体方案，内部存储支持在线数据处理和查询，开放式存储支持离线数据处理，能够识别加载多种数据格式文件。具备云原生、自动数据冷热分层能、多租户、多种计算引擎等能力，支持PB级数据实时、离线分析，秒级到分钟级出结果，湖仓版架构图：

3.5 运维、研发流程增效方案

云数据库帮助企业解决了资源弹性、高可用、备份、监控等基础运维问题，随着业务发展、公司规模扩大，数据库运维团队面临着数据库集群规模化、研发流程化以及运维智能化建设需求。云数据库提供运维、研发流程增效方案：数据库DevOPS方案、数据库自治管理方案。3.5.1 数据库DevOps方案传统数据库研发模式通常会面临研发效率低、数据安全无保障、变更风险大等问题，比如新业务上线层次审批后因“还没到窗口发布期”不得不推迟几个小时；多项目共用库表发布顺序问题；新项目上线结构不合理慢SQL激增影响到生产环境。数据管理DMS提供了平台化、流程化数据库协同开发能力，使得构建、测试、发布数据库变更更快捷、安全和可靠。

数据库开发设计阶段：表结构设计中，引入数据库设计规范。比如表名/列名带业务含义、必须有主键或UK等。DBA根据业务重要级别设置不同审批发布流程，比如非核心库研发TL审批、核心库必须DBA审批，一方面适当放权另一方面提升生产系统稳定性。
SQL审核阶段：项目正式发布前，避免不符合数据库开发规范的SQL（比如建表语句不含主键、索引过多等）发布到线上影响生产服务，需要审核SQL语句、提出相关优化建议。
发布阶段：结构设计及测试完成、SQL审核后，进入结构发布审批流程。由系统做风险识别，比如表数据量、索引数量、是否会锁表变更等，由审批人员（通常数据库owner或者DBA）审批确认，审批通过后由研发选择自动执行或者手动执行。
变更执行阶段：在执行阶段，需要一些策略来降低变更风险，比如对添加唯一索引、变更主键等需要采用无锁表结构变更、限制DDL并发数降低对系统影响等。也需要根据业务类型级别设置不同变更窗口，比如交易相关数据库变更时间设定在凌晨执行。
运维调优阶段：上线之后，要对变更内容进行持续关注，比如查询性能、会话并发数等等，需要从多个角度了解、并及时定位并解决数据库存在问题，保障服务安全性和稳定性。

除了数据库DevOps相关功能外，DMS也提供了更加细粒度的安全策略：比如行级别访问权限控制、防泄露数字水印、敏感数据脱敏保护、操作审计等，对数据库进行全方位保护。

3.5.2 数据库自动驾驶方案 DAS

随着业务的发展，企业数据库集群不断增长，运维人员数量没有按比例增加，数据库运维平台化、自动化、智能化要求也是越来越高。人工智能、机器学习技术的发展，给数据库运维智能化带来新能力。如在SQL诊断与优化场景，数据库自治服务DAS便基于机器学习和专家经验，实现数据库“自感知、自修复、自优化、自运维及自安全”能力，企业可以“辅助驾驶”数据库，降低维护成本。DAS具备以下核心能力：

异常事件：系统收集各种指标和事件，如QPS、TPS、CPU、IOPS等等，并对指标数据进行实时和离线分析，能秒级获取到异常事件。
诊断发起：自动SQL优化服务从事件中心收异常事件，完成实例初步判断，向诊断引擎发起诊断请求并处理诊断结果，完成有效性评估，生成新的优化事件驱动下一步优化。
建议推送或自动优化：根据用户设置的自治策略，事件中心推送SQL优化建议给DBA判断执行，或在用户授权下自动执行优化，并确认执行情况。
效果跟踪和衡量：优化执行后，决策引擎启动跟踪任务，跟踪被优化SQL及相关SQL性能，如性能出现衰退，则自动回滚。

DAS已具备“7 x 24实时异常检测、故障自愈、自动优化、智能调参、自动弹性、智能压测”等能力。并会持续发展自动化、智能化能力，数据库运维由目前的“辅助驾驶”升级为真正的“自动驾驶”。