文 阿里云数据库高级解决方案架构师王林平
摘要：在第十三届中国数据库技术大会（DTCC 2022）上，阿里云数据库高级解决方案架构师王林平从上云路径、云上数据库使用实践及使用进阶等方案深入介绍了阿里云一站式数据库上云最佳实践。
本文内容根据演讲录音以及PPT整理而成。
DTS是帮助上云的有力工具。它孵化自阿里巴巴内部，最初被称为DRC，用于做内部数据流转，包括单元化、双活、多活。2015-2016年，集团业务要上云，面临了一系列的问题，比如数据怎么上云、混合云怎么做灾备和双活等，怎么分析上云。为了解决问题，阿里决定将 DRC 进行商业化，同时在云上为企业客户提供了丰富的能力。
技术上，DTS在某些方已经领先于国内外的友商，比如事务冲突、热点模型的合并、网络带宽的优化、数据校验、双向复制等，拥有企业客户10万+。
该电商客户希望将业务、会员、商城、购物车、计费系统、推荐算法等系统从 IDC 搬到云上。在 IDC 使用的主要为MySQL、MongoDB、Redis，云上提供了RDS、MySQL、MongoDB、PR 持久内存（自研的缓存），也有云 Redis，可与 Redis 完全兼容。整个上云过程可以通过 DTS 实现数据的复制。
上图可见上云过程中存在两条线，绿色线是双向复制。目前从开源的 MongoDB、Redis 复制到云上的MongoDB、Redis 依然是单向复制，而MySQL 支持双向复制的，可以基于双向复制构建无缝的切换方案。
比如某客户的核心业务系统在 MySQL 上，客户不希望 MySQL 在过程中有过多停机。我们为其构建了平滑的数据库迁移上云方案，通过全量和增量复制，将 IDC 机房的数据库连到云上的机房，得益于同城，其延迟较低。同时，在MySQL、 MongoDB和 Redis 上云的过程中提供了数据一致性的校验。
同时，我们对网络提供了较好的支持。得益于双向同步，可以实现秒级、分钟级的回滚。云上业务打开之后，MySQL依然可以回流到 IDC 继续做复制。云上业务正常后，可将 DTS 链路暂停。如果在观察期发现业务出现问题，RDS、 MySQL 回流到IDC的 MySQL 链路依然存在，同时也可以支持过程中的DML，业务发现问题之后可以切回IDC。
总结来说，我们提供了数据平滑上云的能力，也提供了回滚能力，基于 MySQL 的链路可以实现秒级到分钟级的回滚和切换。
实时分析上云方面，我们提供了与 MySQL 兼容的实时分析数据库ADB，经由 DTS 可以将 MySQL 数据库的数据通过走专线、公网、 VPN 的方式同步到 ADB 做实时分析。
DTS双向复制时，数据库从 a 复制到b，复制过的数据再回环复制，会导致一份数据双写，造成数据混乱。因此，我们实现了防循环写，可以支持 MySQL 的双向同步。同时也支持通过DTS将 Redis 和 MongoDB 同步到云上做灾备。DTS 目前与 Hbase 的耦合尚不成熟，因此云上提供了 LTS 双向复制的产品化能力，可以将 Hbase 同步到宽表里做灾备。
云数据库灾备能够为企业客户提供数据备份的能力且延迟极低，网络正常以及没有其他阻碍的情况下可达秒级延迟。由于业务没有做双活，依然在IDC，因此RTO较长。假设IDC出现了网络异常、自然灾害等问题，会保留一份数据，业务需要在再构建一份业务服务器以及相关的资源从而保证业务可恢复。
有了灾备，还需要构建双活。
部分企业客户存在备份低成本上云的需求。传统的方式大多为自己构建一个数据库，将备份存储到自己构建的服务器上，过程中会涉及备份是否冗余；如果没有冗余，是否需要选择分布式存储等。
通过数据管理，可以为研发提效，也提高数据安全和效率。
首先，可以做数据资产管理，实例、数据库和数据都可以通过 DMS 实现数据采集、安全管控、快速查找以及数据安全，数据安全包括脱敏、水印追溯等手段。
其次，对研发、技术团队使用数据库的过程做流程化的管理和规则。比如研发人员a希望将某主管owner的数据库做变更。传统的方式需要先找DBA， DBA 获取到 DML 或DDL变更，上线之后再由 DBA 确认然后才会执行SQL，效率较低。
而如果使用 DMS ，则流程的效率可以得到大幅提高：研发人员a的权限为可以查看，无法更新。发起流程的过程中会有安全规则拦截。研发人员a发起流程之后会发往主管审批，主管确认后发往 DBA 审批，可以由DMS 自动完成审批确认，确认后走 DMS 任务，版主研发完成本次 SQL 变更或DDL。
以上过程包含了SQL审核、表结构设计规范，同时在 DMS 上提供了无锁变更、研发规范、异常变更回滚、变更优化等能力。
在云上使用云数据库时，还需要做问题诊断和优化。DMS能够做自动/半自动/人工的问题发现，可以通过监控、DAS的性能趋势、巡检、异常检测、性能诊断、空间分析来发现问题。发现问题之后，提供了 DAS的诊断分析、会话管理、慢查询、洞察和审计等进行问题的诊断。比如发现某个表没有索引，DAS会给出索引建议。
如果是疑难杂症，则会转交由阿里云的专家进行诊断。其他大部分问题可由DAS进行修复及优化，比如自动的 SQL 优化索引创建、限流等。如果性能诊断优化已经达到极致，可能需要做扩缩容。云数据库拥有优秀的弹性能力，扩缩容十分平滑，尤其是PolarDB，可实现分钟级的扩缩容。
自动SQL限流的流程如下：首先，会进行异常检测，然后通过机器学习的能力获取到全量SQL（目前仅支持云数据库，不支持IDC或云上自建SQL），再进行根因分析、特征提取，如果发现该条SQL与某一类 SQL 比较一致，则将其禁止，做自动限流。
数据库的实例上会有控制台，而控制台的能力是由阿里云背后的DBaaS数据库的资源管理平台提供支持，包括高可用、同城容灾、监控报警。举个例子，做跨机房的HA即由 DBaaS提供。
DBaaS后台的高可用切换HA组件在很多场景下够将Fail Over变为Switch Over。
上图左侧的蓝线代表机房出现问题后的切换线路，绿线为主机出现问题后的切换线路，红线为实例以及数据库本身出现问题后的切换线路。
出现突发业务流量时，需要云数据库、DBaaS、内核、DAS配合来为企业提供自动弹伸的能力。目前，PolarDB MySQL和RDS MySQL 云盘支持 auto-scaling。自动扩容提供了几种不同的策略：其一，基于时间。比如某业务高峰一般为晚上10点，则可以在该时间节点开启自动扩容，一般情况下可在十分钟内完成；其二，自动扩容。基于自定义的规则进行扩容，比如cpu 达到某个阈值即扩容，但该方式存在痛点，需要自行指定规格，规格未达到预期则无法扩容，不够精准。
除了增效之外，阿里云数据库团队也希望能为客户提供降本的能力，包括计算弹性降本、serverless、自动弹伸、分时弹性、资源超卖等。存储层的降本包括支持冷热分层、数据归档、高压缩能力，同时也支持新硬件的红利，比如持久内存的硬件。另外，我们也提供了架构优化的能力，虽然很多细节依然是未知数，但我们在持续努力尝试微企业提供更高性价比的方案。
早期 AnalyticDB只支持 MPP 引擎，无法应对多段 ETL 且中间被打断的场景。如果 SQL 异常则需要重跑所有SQL。
对于运维人员而言，用 SQL 处理数据比用数据库处理数据更高效，而PolarDB4AI支持了算法的 SQL 态化，提供了三种特性：
未来，我们期望数据库上云能够更快、更稳、更安全。
其次，期望云上数据库方案变得更一站式、一体化。现有的将 MySQL 通过 DTS 同步到 ADB 的方式依然有些割裂，客户更希望直接暴露一个service， 由service 直接从 MySQL 拉取数据，进行分析。
最后，希望数据上云更智能，实现自动驾驶。
点击「阅读原文」下载演讲PPT
