1    数据库迁移面临的挑战

根据大数据技术标准推进委员会今年 7 月发布的《数据库发展研究报告（2023 年）》，我们可以看到，去年国内的数据库市场规模约为 400 亿，今年预计可以达到 540 亿，预计到 2027 年，国内数据库市场规模可达 1280 亿。未来几年复合增长率预期可以达到 26% ，市场潜力非常大。

进一步看市场结构，我们可以发现一个明显的趋势：公有云在国内数据库市场中开始逐渐占据主导地位。近三年，国内公有云数据库市场规模的增速在 50% 左右，远高于本地部署市场的 15%。预计今年公有云数据库整体占比可达到 60%。

相较于本地部署的方式，公有云数据库通过全托管服务、云原生数据库等形态，在弹性、成本、易用性上更加具有优势。所以在过去十年，越来越多的企业客户选择数据库上云。

数据库上云面临的技术挑战非常多，主要体现在以下四个方面：

第一，数据库上云的选型。企业需要考虑在云上数据库使用的引擎、选用单机还是分布式的架构、以及选用何种套餐，同时还要结合业务特点对数据库做针对性调优。如果遇到异构迁移或者跨版本迁移，还需要评估结构对象的兼容性，给出业务 SQL 的改造方案。

第二，云上迁移流程较长。

• 首先，我们需要打通云上云下的网络，把数据库的账号/角色、结构、存量、增量数据完整地搬迁上云。

• 然后，对两端的数据一致性做校验。在一致性校验通过后，业务方把流量从云下割接到云上。

• 最后，需要把云上数据库的增量写入内容反向同步回云下环境，以保留云下环境用于迁移后的灾备。

第三，迁移过程中的效率和容灾。迁移过程对业务的影响要尽可能少，迁移链路本身也应当具备容灾能力。

第四，迁移的数据一致性保障。数据库承接的往往是在线服务，少一条数据都可能给业务带来严重影响。因此，迁移链路自身要保证两端数据的最终一致性，同时也要提供校验工具用于检查确认两端实例的数据一致性。

百度智能云在多年的数据库上云迁移实践中积累了丰富的经验。我们认为，在数据库上云迁移中，平滑和可靠是客户的核心诉求，也是对迁移服务的必然要求。

1. 平滑主要体现在易用性、兼容性和业务影响上。

• 易用性：迁移服务要开箱即用，能够托管迁移全流程。

• 兼容性：能够兼容源和目标不同引擎、不同架构、不同版本和不同网络环境，尽可能地降低业务改造成本。

• 业务影响：支持账号、结构、存量、增量的不停服迁移上云，将业务影响降到最小。

1. 可靠主要体现在一致性、可回滚和高可用上。

• 一致性：保证源和目标的数据一致性，并提供校验能力。

• 可回滚：支持割接后的反向回滚同步，保留云下环境用于灾备回滚。

• 高可用：迁移和回滚链路要具备故障恢复能力，尤其是当上下游数据库发生主从切换后，迁移链路要具备自愈能力。

在数据库上云后，我们看到客户在使用数据库时仍然有很多数据传输的新场景，其中有三个典型场景：

• 异地多活：当客户的服务部署在全球多个机房时，机房间的通信延迟最长可达秒级。如果数据库架构依然是单点写入，请求耗时就会变得非常高。但如果拆分数据库，则会牺牲数据的全局一致性，不满足业务需求。较为理想的架构应当是每个地域的数据库本地读写，然后通过数据同步工具同步至异地节点，最终实现数据全局一致。

• 多云灾备：近几年来，基于服务可用性的考量，越来越多的客户选择多云部署。在生产云出现故障时，客户可以将流量切到灾备云上，以保证服务无损。数据库是有状态服务，因此需要数据同步工具将生产云的实时增量写入同步到灾备云上，以保证两端数据一致，满足灾备需求。

• 数据集成：对用户行为的学习、分析和推理可以帮助企业快速决策，并进一步为用户提供个性化服务。通过数据集成工具，企业可以将数据从生产域实时准确地集成到分析域，从而实现数据深层价值的挖掘。

基于上述的客户需求，百度智能云推出了一站式数据库上云迁移、同步与集成平台 DTS。

在上云迁移方向，DTS 基于百度多年实践总结出一套成熟的数据库上云迁移方案，围绕该方案提供一站式上云迁移体验。

在同步/集成方向，DTS 聚焦业务场景，基于场景需求的关键特性打磨产品，提供易用稳定的一站式同步/集成服务。

2    上云迁移方案

数据库上云迁移是一个复杂的系统性工程，需要客户和云服务商共同配合完成。

我们将上云迁移分为三个阶段：迁移前、迁移中、迁移后。

• 迁移前的工作主要是做数据库选型和迁移可行性的评估。数据库选型的维度包括：产品、套餐、架构和存储介质等。选型的过程往往需要对相关的云上数据库产品做功能和性能测试以验证是否满足业务需求。迁移评估则是检查待执行迁移的源端和目标端数据库实例及其宿主和网络环境，得出迁移的可行性结论。

• 在完成了迁移前的选型和评估工作后，就是数据库上云迁移过程。DTS 支持将源端的账号/角色、结构对象、存量数据、增量写入迁移至目标端，迁移过程中无需客户停服。在增量延迟追平后，DTS 支持对两端数据一致性做校验。通过一致性校验后，客户可以将业务流量割接到云上。在验证业务的同时，客户可以使用 DTS 的一键反向功能，快速拉起云上同步回云下的反向回滚链路，将云上的流量反向同步回云下，保留云下环境用于迁移后的灾备。

• 数据库迁移到云上后，百度智能云也提供了数据库智能驾驶舱（DSC）帮助客户管理、审计和调优云上数据库。

下方全景图中标蓝的步骤由 DTS 提供支持，我们可以简单总结为四步：评估、迁移、校验、回滚，下面我将详细介绍每个步骤的方案设计。

2.1    迁移评估与网络接入

迁移前的第一个准备工作是迁移评估。

DTS 迁移任务在启动迁移前，会先执行前置检查，包括检查迁移对象、数据兼容性、两端数据库配置等，最终输出迁移可行性评估结论。对于不通过的检查项会给出修复建议。

此外，DTS 还提供了本地迁移评估工具，支持在本地环境执行，支持对多个实例执行批量评估。

迁移前的另一个准备工作是网络接入。

当前，DTS 支持通过公网、专线、VPN、云自建、云服务等方式接入，通过控制台或 OPENAPI 一键完成网络接入，无需人工部署。

此外，对于上云迁移高频依赖的专线或 VPN 接入，DTS 进一步优化了网络接入方式，支持客户将数据库内网域名作为任务端点，保证迁移链路具备切换自愈能力。当云下数据库实例发生主从切换时，只要实例域名保持不变，DTS 任务就可以快速自愈恢复。

2.2    数据迁移原理

下面介绍 DTS 数据面的数据迁移原理。

数据面整体遵循 ETL 插件式设计，支持不同插件的自由组合，以满足不同数据流的迁移需求。

• 数据抽取（E）：通过不同的数据抽取插件，DTS 数据面可以支持采集账号/结构、全量、增量等数据。其中，全量数据抽取由于数据量较大，因此我们通过并发抽取、大表分片等优化手段进一步提升整体吞吐。增量数据则基于 CDC 异步捕获变更，可以让源端负载更少，同时传输实时性更好。性能的相关优化我们在后面会具体介绍。

• 数据转化（T）：完成数据抽取后，源端的原始数据会被归一化为统一的抽象数据结构，这样就实现了异构数据源上下游解耦和端到端自由组合；然后再由数据转化插件对抽象数据结构做数据加工（如：库/表/行/列的过滤和映射）；最后再将数据格式改写为目标端数据源支持的协议。

• 数据加载（L）：数据加载插件将完成协议转换的数据并行批量加载到目标端数据源中。为了进一步提升加载性能，数据面往往通过多线程并行加载数据。但增量同步需保证数据加载的时序与源端严格一致。因此，DTS 支持按表或主键粒度并行分发，属于同一个表或主键的数据会被分配到同一个加载线程串行执行，不同表或主键的数据则可能分配到不同线程上，在保证时序的前提下进一步提升了性能。

2.3    数据一致性校验

整体的数据迁移流程遵循先结构、再全量、后增量的顺序。

考虑到各类数据库中的 CDC 日志通常是易失的，如：MySQL 的 binlog、MongoDB 的 oplog、Redis 的 backlog 等。数据库往往通过固定缓冲区、定时或限制容量清理等方式限制 CDC 日志的存储用量。

DTS 针对该问题优化了迁移流程编排。在进入全量迁移过程后，DTS 除了导出和加载全量数据外，还同时导出增量数据，将其缓存到 DTS 的内部存储中，以避免尚未迁移的增量数据被源端数据库清理。待进入增量迁移阶段后，再将缓存的增量数据加载到目标端。

增量同步延迟追平后，即可执行数据校验检查两端数据一致性。由于 DTS 增量同步是异步加载，因此源端和目标端的数据版本实际上存在毫秒级的延迟。因此数据校验可能会因为同步延迟出现误报。我们引入了 X Round Recheck 的方案进一步降低了误报概率。在后面的内容里会专门介绍数据校验的原理。

DTS 以数据不丢为基础，进一步实现了数据的不丢不重，以保障数据的一致性。

数据不丢（At-Least-Once）：依赖于 DTS 数据面的低水位进度管理机制。如下图所示，每一条数据都会关联一个单调递增的版本号，这些版本号组成了一个单调递增的进度序列。当某条数据写入下游并收到了确认写入成功的响应后，该数据对应的版本号会被标记并在进度序列中更新状态。此时，进度管理线程会检查进度序列的水位。

在下图中 1、2、3、4 都已经被标记，但 5 尚未标记，因此版本号 4 是低水位里的最大版本号。所以将 4 作为最新进度保存到外部存储中。一旦此时任务容灾恢复，恢复后的任务将以外部存储中记录的最新进度 4 作为断点重新执行迁移。

At-Least-Once 机制可以保证数据不丢，但无法保证数据不重。我们在下图中可以看到，6、7 此时都已写入下游，但并未记录到最新进度中，一旦任务以 4 作为断点重新执行，则 6、7 对应的数据会重复迁移。

为了实现数据不丢不重（Exactly-Once），DTS 的思路是基于目标端数据库特性去重。对于关系型/文档数据库、数仓来说，表中主键列或唯一键列具有唯一性，因此，我们可以改造 SQL。利用唯一约束实现幂等写入。

而对于 Schema-less 的消息队列、分布式文件系统等，DTS 会在投递的消息中加入 UUID，目标端消费方可以基于 UUID 自行去重。

最后对于键值数据库（如 Redis），DTS 的思路是将不满足幂等写入的命令改写为满足幂等性，比如累加、累减、插入队列等改为覆盖写。

除了迁移系统本身的一致性保证外，DTS 还提供了独立于迁移系统的数据校验功能。数据校验与数据迁移由不同的任务独立执行，以保证校验结果的可信。

数据校验的流程可以拆解为：抽取、转化和校验。

其中，抽取与转化的实现原理与数据迁移的对应模块实现类似，这里不再赘述。下面重点介绍一下数据校验插件的原理。

• 首先，校验插件在收到待校验数据后会根据主键或唯一键实时查询源端和目标端最新的数据。

• 然后，根据数据加工规则对源端和目标端的数据做归一化，对齐数据元信息。

• 最后，根据不同的任务配置，比对规则校验数据一致性，并将校验结果保存到外部存储中。

这套流程在实践中存在小概率误报，原因是在执行数据校验的同时，源端还在持续写入。因此，源端与目标端的数据版本会存在毫秒级的同步延迟，正是这一延迟导致了少量数据的校验误报。

因此，DTS 引入了 X Round Recheck 机制。在数据不一致时，会等待一段时间后进入下一轮比对，重新读源端和目标端的数据后再次比对。只有当多次重复比对均不一致的数据会被记录为不一致数据上报。

X Round Recheck 大大降低了数据校验的误报频率。经测试，校验误报频率从约千分之一下降到小于百万分之一。

2.4    反向回滚

在完成数据一致性校验后，客户就可以把流量割接到云上了。

完成切流后，我们观察到客户往往需要保留云下环境用于容灾回滚。当云上生产环境不可用时，可以将流量快速切回云下灾备环境，服务快速恢复。针对这一痛点，DTS 推出了一键反向功能，支持在流量割接后快速拉起反向回滚任务，将云上流量反向同步回云下。

如下图所示，客户在 T1 时刻执行流量割接，此时正向迁移任务运行中，而反向回滚任务处于挂起状态。在 T2 时刻，客户完成割接，此时业务流量已切到目标端数据库，此时执行一键反向，DTS 会将正向迁移任务挂起，反向回滚任务启动，从客户指定的 T1 时刻开始将目标端的业务写入实时同步回源端。从而完成正向迁移到反向回滚的切换。

3    同步/集成方案设计

我们在前面介绍了同步/集成方向的三个典型业务场景：异地多活、多云灾备和数据集成。其中，高可用和高性能是这些场景共同需要的关键能力。

• 异地多活和多云灾备属于在线数据库的实时同步需求。因此支持数据库多主架构和数据一致性的有保证/可校验能力是同步场景的核心痛点。

• 数据集成场景的痛点在于，传统的集成方式中，流批架构不统一、不同数据源使用的集成工具比较繁杂，ELT + ODS 的数据预处理方案实时性差/复杂度高等。

3.1    DTS 的高可用和高性能

接下来，我们分别介绍 DTS 针对上述痛点的方案设计。

首先介绍高可用能力。

DTS 的高可用设计目标是满足长期不间断的生产级数据同步需求。方案设计可分为三个方面：断点续传、实时容灾和数据库切换自愈。

• 断点续传。DTS 会将传输进度做定期 checkpoint 并持久化到外部存储中。目前 DTS 大部分数据流的全量和增量迁移都支持断点续传。同时，DTS 基于之前介绍的低水位进度管理机制，可以保证断点续传前后数据不丢失，基于目标端的唯一约束可以实现数据不丢不重。

• 实时容灾。DTS 数据面模块支持故障秒级接管和恢复。并且支持对极端脑裂场景的自动检测和恢复，保证脑裂恢复前后的数据最终一致性。

• 切换自愈。DTS 支持在源端、目标端数据库实例发生故障切换时，自动发现新的可用节点。当不同节点的传输位点发生变化时，DTS 可以基于时间自动定位新节点的传输位点，保证切换后数据不丢。

经过百度智能云内外部数据传输场景的长期实践打磨，DTS 承诺的任务可用性为 4 个 9。

接下来让我们再看高性能。DTS 在性能方向的设计目标是追求高吞吐和低延迟。

首先是高吞吐，DTS 具有如下的特点：

• DTS 支持预读取全量数据。当遇到大表时，DTS 支持将大表分片并行读取，解决大表长尾的问题。

• DTS 支持按照表、主键粒度并行转换和回放。

• DTS 对数据回放的单线程写入性能做了优化。比如当写入 1000 条数据时， DTS 将 1000 条 INSERT 合并为一条 INSERT，提升了目标端数据库的 SQL 写入效率。

• 写入语句批量执行，网络延迟均摊。

其次是低延迟，DTS 提供了如下的能力：

• DTS 自身基于 CDC 实现增量数据捕获，无需扫表，实时性更好。

• DTS 采用了数据流式传输模型，全程流水线作业。

• DTS 选用消息队列缓存和回放增量数据，端到端的同步延迟更低。

• DTS 针对热点数据，支持基于逻辑的事务合并。在保证最终一致性的前提下，压缩了同步的数据量。

以 MySQL 同步为例，全量吞吐峰值约为 20W 行/s，增量吞吐峰值约为 1W 行/s，延迟可以达到毫秒级别。

3.2   异地多活场景

异地多活场景的核心特性是双向同步，可以支持两端数据库写入相互同步，从而实现数据库多主架构。

双向同步由正向和反向两个 DTS 同步任务实现，每个任务在同步数据时会通过加入特定的 DML 将该数据所在的事务染色；而另一方向的同步任务在读到染色事务时会直接过滤，从而避免了数据的同步回环。此外，双向同步支持级联，客户可以通过搭建多条双向同步链路实现 N 个地域的数据库多主架构。

不过双向同步的使用也有一定限制：

• 业务需避免在两端同时变更主键/唯一键相同的行记录，尤其是避免同时执行 UPDATE，否则可能产生冲突，造成数据不一致。因此，我们推荐业务层面支持流量单元化。

• 表中不能使用自增主键，这是为了避免主键冲突导致的数据不一致。

• 仅有正向同步任务支持同步 DDL，反向同步任务仅同步 DML，因此若需执行 DDL 建议在正向同步任务的源端执行。

3.3   数据集成场景

经典的 Lambda 架构包含定时和实时两套架构，分别处理流和批两种不同的数据。架构不统一会带来运维迭代成本高、流批产出数据不一致等问题，所以现在业界都在逐渐转向流批一体。

DTS 的架构天然支持流批一体，源端无论是有界数据（数据库快照，指定区间的增量）还是无界数据（持续的数据库流量），都会通过数据切片的方式切分为无数个 Micro-Slice，通过流水线作业最终同步到目标端的仓、湖或流式计算框架。

目前 DTS 目标端支持 Doris、Elasticsearch 等数仓，以及百度智能云数据湖 EDAP，支持通过消息队列将数据推送到 Flink 等流式计算框架中。

在面对上下游异构数据源时，解耦上下游的架构设计能够为系统提供更高的灵活性和可扩展性。这种设计使得 DTS 能够支持端到端的任意组合，组合复杂度从 M*N 降低到 M+N，并能够快速扩展支持新的数据源。

DTS 定义了抽象数据格式 DTS Record，可以将源端各类数据库的数据转换为标准的 DTS Record（Any To One），然后再将 DTS Record 转换为目标端数据源接受的数据格式（One To Any）。

当 DTS 需要接入新的数据源时，只需要定义新数据源到 DTS Record 的转换规则，即可快速支持现有全部数据源到新数据源的异构数据传输。

当然，在异构字段映射的过程中，部分数据可能会因为浮点数精度/字符集不同造成数据精度损失。因此，DTS 优化了同构字段映射规则。当上下游数据源同构时，源端数据能够无损映射到目标端。

接下来我们看下数据集成的预处理环节。

当前业界的主流集成架构是 ELT+ODS。即将数据通过 Sqoop、Spark 等工具，几乎不做 join 或 group 等复杂转化，直接抽取到数据仓库里的贴源层（ODS），再在数据仓库中通过 SQL/H-SQL，将数据从贴源层（ODS）加载到数据明细层（DWD），最终汇总到数据汇总层（DWS）和数据集市（DM）。

ELT+ODS 架构的思路是利用数仓的 MPP 高性能计算做 ODS 到 DWD 的大数据预处理。但这仅适用于数据源模式比较简单的情况。当 ODS 到 DWD 规范化复杂度比较高时，往往需要引入 Spark/MapReduce 等框架专门处理。

另外，ELT+ODS 架构的实时性较差，难以满足实时分析场景和即时查询的需求。ODS 与 DWD 的数据重复率也比较高，需要付出额外的存储成本。

DTS 基于业界最新提出的 EtLT 架构推出了支持实时数据加工的集成方案。它可以将数据从在线域直接集成到 DWD，在集成阶段即可完成实时的数据规范化，无需维护额外的 ODS 层。EtLT 架构的实时性要优于 ELT+ODS 架构，可以支持实时的数据分析和查询统计，让复杂的数据抽取、规范化和加载的过程对数据分析过程透明，帮助其更加聚焦业务。

DTS 支持实时数据加工的集成方案预计会在 2024 H1 开放公测，大家可以期待一下。

4    DTS 落地实践案例

第一个案例是某国内大型在线视频服务公司，DTS 支持了该客户的数据库上云迁移和多活同步的需求。

该客户的业务痛点主要包括三个方面：

• 迁移规模大：在线服务数据库（MySQL/Redis/MongoDB）中，涉及到上百条业务线的 1.5W+ 集群迁移上云，过程管理难度大。

• 高可用需求高：需要支持数据库不停服迁移、支持切换自愈、支持反向回滚、支持监控指标推送。

• 异地多活：需要支持跨地域多活同步（单元化）、低延迟（<100ms）。

针对该客户的三个痛点，百度智能云提供了如下的解决方案：

• 客户业务使用自助上云平台完成上云迁移：平台集成 DTS 服务。DTS 迁移全流程（评估、迁移、校验、回滚）100% 接口化（支持控制台操作），无人工干预。

• 客户 IDC 自建实例切换自愈：DTS 支持专线/ VPN 域名接入，数据库故障切换断点自愈恢复。

• 跨地域多活同步：DTS 支持 MySQL/GaiaDB 双向同步。

最终，百度智能云帮助该客户跑通了数据库上云迁移的全流程，并支持客户自助上云迁移，目前已经支持 2000+ 集群的迁移，单集群的迁移周期缩短到 3-4 天。

第二个案例是某国有控股大型商业银行，DTS 支持了行方的实时数据分析和跨机房容灾的需求。

该客户的业务痛点主要包括两个方面：

• 高吞吐：行方核心业务（存/取款明细）涉及到 64 分片集群每月集中跑批， TPS 峰值达到 50W+，要求数据同步延迟分钟级。

• 高可用：数据库及生态产品（DTS）整体具备跨机房容灾能力，故障恢复要求为 RPO = 0，RTO < 1min。

针对该客户的这两个痛点，百度智能云提供了如下的解决方案：

• 端到端吞吐优化：CDC 异步拉取/并行解析，表/主键粒度并行转换/加载，数据打包写入。

• 跨机房容灾：基于 load checkpoint 的段点续传（RPO）和数据库拖段服务切换自愈（RTO）实现了任务实时容灾恢复。

最终，百度智能云帮助该行落地了实时风控、监控大屏、收支分析等业务场景，线上长期同步任务 900+；同时，支撑行方核心业务（存/取款明细）集群数据同步需求，同步延迟秒级。此外，DTS 服务支持同城双活，机房级故障恢复实现了 RPO = 0，RTO < 30s。

第三个案例是某国内大语言模型服务，DTS 支持了业务方的事实数据分析和检索的需求。

该客户的业务痛点主要包括两个方面：

• 同步性能：包括大语言模型对话数据、模型 Trace 日志实时分析等，部分业务场景要求数据同步延迟达到秒级。

• 快速迭代： 大语言模型功能迭代速度快，在线数据库表结构更新较为频繁。

针对该客户的这两个痛点，百度智能云提供了如下的解决方案：

• 低延迟调优：自适应写入性能调优，数据打包窗口动态调整。

• 整库同步：DTS 支持库级别同步，目标端 Doris 支持增量同步 DDL，支持增量阶段新增/删除同步对象。

• 数据规范化：支持库表行列过滤、库表列名映射等功能。

百度智能云支撑了该大语言模型中服务日志实时分析与实时报表的需求，同时也满足了业务快速迭代带来的整库同步、表结构更新同步等需求，最终实现了长期同步任务 470+，同步延迟最低达到秒级的业务效果。

我们对 DTS 的所能支持的各类业务需求归纳为 8 种典型的场景，供大家参考。分别是：不停服迁移上云、异地多活、多云灾备、业务事件驱动、信创迁移、缓存更新、实时分析、实时入湖/仓。

最后，我们对今天的分享做个总结，我们分享了百度智能云在数据库上云迁移和数据同步/集成方向的设计思路和落地实践。

在上云迁移部分，百度智能云提供了平滑可靠的一站式上云迁移服务。

• 迁移服务开箱即用，支持评估、迁移、校验、回滚的全流程托管。

• 兼容源和目标不同引擎、架构、版本和网络环境，业务改造成本低。

• 上云迁移无需停服，业务影响小，迁移和回滚链路支持端到端的故障恢复

在同步/集成部分，DTS 可以提供易用稳定的数据同步/集成服务：

• 在异地多活场景中，基于 DTS 双向同步可以支持数据库多主架构，实现全球化服务访问加速，保证数据全局一致。

• 在多云灾备场景中，DTS 支持数据库跨云长期同步，支持端到端容灾自愈，数据一致性有保证可校验。

• 在数据集成场景中，DTS 立足流批一体设计，支持端到端的自由组合，可以实现秒级实时同步，未来计划支持实时数据加工。

以上是今天分享的全部内容。