随着互联网的持续快速发展，云计算已经成为 IT 主流的基础设施提供方式。云计算支撑了城市大脑、冬奥会、天猫、淘宝、优酷等，与每一个人的生活息息相关。
阿里集团的很多企业都已经将 IT 基础设施搬到云上，云计算在国内得到了蓬勃发展，为企业带来快捷的能力，实现了增效。
01. 上云路径
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，将多个业务库的数据同步到 ADB ，在 ADB 上做数据分析。ADB 也支持通过SQL或定时任务的 ETL 对数据做处理，处理完后的数据还可通过专线再回流到IDC。
DTS双向复制时，数据库从 a 复制到b，复制过的数据再回环复制，会导致一份数据双写，造成数据混乱。因此，我们实现了防循环写，可以支持 MySQL 的双向同步。同时也支持通过DTS将 Redis 和 MongoDB 同步到云上做灾备。DTS 目前与 Hbase 的耦合尚不成熟，因此云上提供了 LTS 双向复制的产品化能力，可以将 Hbase 同步到宽表里做灾备。
云数据库灾备能够为企业客户提供数据备份的能力且延迟极低，网络正常以及没有其他阻碍的情况下可达秒级延迟。由于业务没有做双活，依然在IDC，因此RTO较长。假设IDC出现了网络异常、自然灾害等问题，会保留一份数据，业务需要在再构建一份业务服务器以及相关的资源从而保证业务可恢复。
有了灾备，还需要构建双活。
某客户希望 IDC 到云上能够支持双活，需要在云上再构建一份业务的服务，业务服务与 IDC 完全对等。资源出现异常后，可以将流量从 DTS 切到云上。数据库和应用服务器都可以快速弹升，如果企业客户使用了K8s，弹性能力会更好。
部分企业客户存在备份低成本上云的需求。传统的方式大多为自己构建一个数据库，将备份存储到自己构建的服务器上，过程中会涉及备份是否冗余；如果没有冗余，是否需要选择分布式存储等。
而DTS能够为备份提供低成本的上云方案，同时它支持压缩、加密、流控，可以保证数据上云、备份上云的安全性。它也可以将数据恢复给云上的数据库实例，若出现异常情况时可以将数据恢复，快速验证备份是否可用。过程中提供了低成本的存储，甚至未来可能会对接到自有存储，能够实现非常灵活的备份上云和恢复。
02. 云上数据库使用实践
随着数据库的量和研发人员越来越多，而DBA 人不够多，无法随时支撑研发时，可能会影响工作。如果对研发人员管理的能力和权限放大，可能会出现数据安全性、可靠性和稳定性出现问题。
通过数据管理，可以为研发提效，也提高数据安全和效率。
首先，可以做数据资产管理，实例、数据库和数据都可以通过 DMS 实现数据采集、安全管控、快速查找以及数据安全，数据安全包括脱敏、水印追溯等手段。
其次，对研发、技术团队使用数据库的过程做流程化的管理和规则。比如研发人员a希望将某主管owner的数据库做变更。传统的方式需要先找DBA， DBA 获取到 DML 或DDL变更，上线之后再由 DBA 确认然后才会执行SQL，效率较低。
而如果使用 DMS ，则流程的效率可以得到大幅提高：研发人员a的权限为可以查看，无法更新。发起流程的过程中会有安全规则拦截。研发人员a发起流程之后会发往主管审批，主管确认后发往 DBA 审批，可以由DMS 自动完成审批确认，确认后走 DMS 任务，版主研发完成本次 SQL 变更或DDL。
以上过程包含了SQL审核、表结构设计规范，同时在 DMS 上提供了无锁变更、研发规范、异常变更回滚、变更优化等能力。
DMS 为研发和 DBA 提供了桥梁和平台。DBA的一些日常比较琐碎但是又必须做的工作，可以通过流程化和规则的方式为研发提效。未来，我们将着眼于资产的治理、安全的体系化、逻辑数仓的建设以及场景化的方案等。
在云上使用云数据库时，还需要做问题诊断和优化。DMS能够做自动/半自动/人工的问题发现，可以通过监控、DAS的性能趋势、巡检、异常检测、性能诊断、空间分析来发现问题。发现问题之后，提供了 DAS的诊断分析、会话管理、慢查询、洞察和审计等进行问题的诊断。比如发现某个表没有索引，DAS会给出索引建议。
如果是疑难杂症，则会转交由阿里云的专家进行诊断。其他大部分问题可由DAS进行修复及优化，比如自动的 SQL 优化索引创建、限流等。如果性能诊断优化已经达到极致，可能需要做扩缩容。云数据库拥有优秀的弹性能力，扩缩容十分平滑，尤其是PolarDB，可实现分钟级的扩缩容。
未来，我们计划在DAS上实现自发现、自优化、自修复的全面能力。
另外，我们正在从DAS入手构建批量的智能运维能力，包括实例监控、实例盯屏、异常发现、自动优化、自动修复、容量评估、安全审计。最近上线了复制延迟、OOM自修复、SQL Review辅助，未来也会提供异常根因分析、自动优化增强、自动修复、增强内存报警等能力。
自动SQL限流的流程如下：首先，会进行异常检测，然后通过机器学习的能力获取到全量SQL（目前仅支持云数据库，不支持IDC或云上自建SQL），再进行根因分析、特征提取，如果发现该条SQL与某一类 SQL 比较一致，则将其禁止，做自动限流。
完成自动限流之后， DAS会对某些 SQL 提出自动优化的建议。后续如果发现不再需要自动限流，则进行超时设置，形成闭环。
数据库的实例上会有控制台，而控制台的能力是由阿里云背后的DBaaS数据库的资源管理平台提供支持，包括高可用、同城容灾、监控报警。举个例子，做跨机房的HA即由 DBaaS提供。
DBaaS是云数据库最底层的云数据库操作系统，云数据库的通用能力都由DBaaS提供，包括实例的数据安全、白名单加密、异常事件。DBaaS提供的能力会对云数据库生命周期里的各个流程环节做打点，采集日志，以判断数据库在各个过程中是否出现异常。同时也提供了自愈能力。
跨机房切换时，可以通过 SLB 连到主节点，同时会有隐藏的备节点。出现问题之后，主备节点会做切换。切换完成后，暴露的SLB和域名不变。正常情况下，切换一般只需20-30s，但不排除极端情况会对业务造成影响。
DBaaS后台的高可用切换HA组件在很多场景下够将Fail Over变为Switch Over。
上图左侧的蓝线代表机房出现问题后的切换线路，绿线为主机出现问题后的切换线路，红线为实例以及数据库本身出现问题后的切换线路。
技术人员不希望出现fail over，因此会尽量将 switch over 线扩大。通过 DAS和DBaaS的能力，做异常检测、 SQL 限流，尽量地让实例能够主动切换，避免fail over。
03. 云数据库使用进阶
出现突发业务流量时，需要云数据库、DBaaS、内核、DAS配合来为企业提供自动弹伸的能力。目前，PolarDB MySQL和RDS MySQL 云盘支持 auto-scaling。自动扩容提供了几种不同的策略：其一，基于时间。比如某业务高峰一般为晚上10点，则可以在该时间节点开启自动扩容，一般情况下可在十分钟内完成；其二，自动扩容。基于自定义的规则进行扩容，比如cpu 达到某个阈值即扩容，但该方式存在痛点，需要自行指定规格，规格未达到预期则无法扩容，不够精准。
Auto-scaling在基于 CPU 使用率的场景已经卓有成效，CPU 使用率超过70%就增加读节点也属于 Auto-scaling 范围内。如果 CPU 使用率超过70%，也可以弹升，进行垂直升配，只需 5- 10 分钟，业务不受损。
如上图所示，最初业务较平稳，业务流量突然增加以后，业务发生了一次抖动。触发了Auto-scaling自动弹升，自动升配并在分钟级完成自动升配，弹升后尽管并发依然较高，但CPU使用率已经下降。
除了增效之外，阿里云数据库团队也希望能为客户提供降本的能力，包括计算弹性降本、serverless、自动弹伸、分时弹性、资源超卖等。存储层的降本包括支持冷热分层、数据归档、高压缩能力，同时也支持新硬件的红利，比如持久内存的硬件。另外，我们也提供了架构优化的能力，虽然很多细节依然是未知数，但我们在持续努力尝试微企业提供更高性价比的方案。
同时，我们对PolarDB支持了多主集群，通过多节点写提升大集群的写能力。此前，出现写瓶颈时只能垂直扩容，扩容到极限后进行拆分，也包括水平拆分。多主集群的能力更适合做垂直拆分，同时我们也提供了基于多主的水平拆分方案。
PolarDB Serverless已经公测，支持跨机的 scale up 和 scale out 了，针对实际需要将资源根据 QPS 进行弹升。如右图所示，两个曲线非常吻合，能够大幅节约资源，支撑业务流量的抖动。
早期 AnalyticDB只支持 MPP 引擎，无法应对多段 ETL 且中间被打断的场景。如果 SQL 异常则需要重跑所有SQL。
AnalyticDB的湖仓版引入了spark引擎，可以做多段的 ETL 批处理，但底层共享一份数据，一份数据同时支持 MPP 的 OLAP 引擎，也支持批处理的引擎。比如基于 spark 的能力做完批处理后，数据存到底层存储，实时分析的 MPP 引擎也可以读取该份存储。同时， MPP 和 spark 可以交互的，可以共享计算成果，并且提供了一体化的体验，包括计费数据的通道、数据管理、数据访问等，为企业提供了更广泛的实时分析场景，使用也更方面。
对于运维人员而言，用 SQL 处理数据比用数据库处理数据更高效，而PolarDB4AI支持了算法的 SQL 态化，提供了三种特性：
第一，利用SQL语言高效建模、训练、评估、推理，方便用户进行特征及模型全生命周期的操作和管理，缩短算法上线时间（2周降低至2天），降低人工智能门槛。
第二，实现了模型上传和SQL态模型训练推理平台，用算法模型在 PolarDb4AI 上运转，进一步加速模型的上线速度。
第三，场景化数据智能解决方案。比如针对电商提供端到端的 PolarDB4AI 的 SQL 态的算法解决方案，实现大幅提效。
未来，我们期望数据库上云能够更快、更稳、更安全。
其次，期望云上数据库方案变得更一站式、一体化。现有的将 MySQL 通过 DTS 同步到 ADB 的方式依然有些割裂，客户更希望直接暴露一个service， 由service 直接从 MySQL 拉取数据，进行分析。
最后，希望数据上云更智能，实现自动驾驶。
下载地址：https://developer.aliyun.com/topic/download?id=8827
/ End /
