【技术分享】阿里海量数据迁移架构及最佳实践

数据库技术大会 2016-05-30

506

本文整理自DTCC2016主题演讲内容，如需转载，请先联系本公众号获取授权！

演讲嘉宾

付大超

阿里巴巴数据库团队技术专家

2012年加入阿里巴巴，目前负责DTS团队研发工作，曾负责阿里HBase的开发及维护工作，开发了阿里HBase集群高用性系统，曾先后实习及工作于IBM、Cisco、淘宝。

分享内容

大家下午好，我是来自阿里巴巴的付大超，今天分享的主题是《阿里海量数据的迁移同步架构及最佳实践》。

目前我负责公司内部云产品DTS研发工作，今天分享的内容主要是DTS的对外使用，我的分享分为以下四个部分：

痛点：

我们遇到的问题来自阿里云上搜集的用户需求。是一些具有普遍意义的问题：

1、上云难：云计算时代，上云可能是一个必须要走的路。对于很多传统企业，上云是很困难的。

2、单点故障：数据发到云上可能会有一些单点故障。阿里云在海外比如美国，部署架构就可能遇到单点问题。

3、系统间数据流动难：今天企业积累了大量的业务数据，应该如何进行分析，获得数据入口拿到数据。

4、跨地区访问延迟大：国内到美国的网络还不是很好，很多公司希望在美国他们的数据也可以很好的发挥作用，而中美之间的网络是一个比较现实的问题。

阿里典型业务挑战：

1、一键建站

2、异地多活：在异地多活的过程中，把数据和应用迁移到一个新的站点，比如深圳。阿里在深圳部署双十一整个的交易单元，要有一套程序和机制把这件事做起来。阿里云在2015年双十一的时候就有异地多活，号称是给正在飞行的飞机换个引擎，就是这个意思。

3、异构：阿里本身就有各种类型的数据库，数据之间的交换是一个实际问题。

4、中美秒级同步：中美之间的网络很大，我们要获取各个数据之间的增量数据，需要做一些大数据的分析和计算。

5、增量订阅服务。

DTS简介：

这些问题逼着我们开发一个产品来解决。因此有了DTS数据传输服务。主要解决关系数据库之间的传输和同步服务。目前支持大部分现代商业数据库之间的迁移，支持同异构数据源之间的迁移同步。全量迁移数据高达70MB/S，具体数据可以参照下图：

DTS功能：

DTS的功能可以在阿里云使用。几大功能如下：

1、数据迁移功能。支持多种类型的数据库。如果是数据库相关人员，迁移实际上是非常常态化的东西，每天也都会遇到许多问题。

2、数据同步功能。双十一整个过程都是基于数据同步实现的。异地多活则是基于底层实现的，包括中美同步问题。

3、数据订阅功能。把数据开放出去，支持RDS多数据存储产品的增量数据实时订阅。

4、完善的监控体系。

DTS介绍：

以上是从用户角度看的一个架构。我们提供了一些场景，首先是我们自己的AliCloud DB，阿里云提供各种类型的数据库。DTS应用的范围，一个是AliCloud DB，一个是用户使用ECS构建数据库系统。我们也提供用户自建DB，用户在自己的数据中心创建，不是阿里云的产品构建的。比如说银行可以在自己的数据中心构建这类系统。最后，OceanBase如今也在阿里云上提供服务。阿里基于这个场景提供了迁移，同步订阅和评估。我先简单介绍一下评估，今天很多用户要把他的数据迁移到阿里云或者是其他地方，这需要做很多工作。很多传统企业甚至连DBA都没有或者是依赖于几年前的某某咨询机构帮其做的一套系统，如今这个系统运营情况怎么样以及他的数据库目前是不是有什么问题，各种限制是不是能够迁移到目的端，没有人知道。如果有相关的同事做过这类事情就知道这种事情很痛苦，尤其是大的银行系统或者传统企业，或者是电信。他们的系统非常复杂，需要深入理解。我们所提供的这套程序可以自动化评估各类数据库的运行情况，根据目前正在运行的业务异构情况计算成本，根据系统基本情况推荐相应架构。

目前的DTS架构：

目前DTS 的基础架构如上图所示。用户要创建一个任务，这个任务会进入调度系统，具体的下派给比较核心的系统去干活，干活的系统基本上是评估迁移，订阅和同步。他们最终产出的东西也不一样，评估产出的是一份报告，如果是给一些传统企业做的话，这个报告会拿给甲方的老板看，这份评估报告可以告诉他成本有多少。订阅是我们提供一个DTS client给用户，通过这个开发包能够拿到增量数据。

除了核心的订阅系统还有底层的运维系统，比如说监控系统。每个任务过来我们都有一个预检查系统，针对不同的用户有不同的选择，我们会有相对比较简单直接一点的预检查系统，告诉用户最终你的问题出在什么地方，错误原因是什么。比如说权限不够的问题，我们不会告诉你加个什么权限，我们会直接给你一个SQL，你直接执行就可以了。

DTS结构迁移：

DTS功能由几个模块组成，比如说迁移就会有几个模块，第一个是结构迁移，实际上我们就是要把用户源库的各种库表迁移到目的端，也支持各上异构数据库之间的迁移，比如Oracle到MySQL等。

DTS全量迁移：

我们也支持各种异构或者其它类型，比如通过DTS把源和目的端之间对应的映射关系类型转换之后迁到目的端，这个过程用户是没有什么感知的，基本上点几下就完了。

我们更重要的功能是把我们的数据真实迁移，今天要上云或者是各个公司内部迁移，实际上都要基于这套去做，如果我们要求完全的一对一匹配的话，我们的开发压力会非常大。所以我们就开发了一个DTS的标准格式，做一个中间的转化，这样我们就可以把所有的源都转化成中间格式，在把中间格式转化成其他东西，我们的开发代价就比较少。这是我们实现整个迁移的基础核心。

我们各种异构数据迁移完全是自己开发的，今天的开源产品我们都不会用，完全是重新开发。还有一个功能是今天很多用户会做全量迁移，把全量数据迁到目的端。当你做完全量之后，我们会提供增量服务，让源端服务不停，用户基本不会感知到延迟，只有在切换的时候会有一些变化。而且我们会把这个数据延迟做到毫秒级。

DTS增量&同步技术实现：

我们的增量实施一般都有源库，我们通过日志解析这种商业数据库是非常难的。我们在这方面做了很多工作尝试把这些日志解析出来，最后取得了一些结果，目前来说正在最后的测试阶段。我们会把这个log拿出来解析写到store里面去，它会把数据解析出来放在内存里面，如果内存放不下会放到磁盘上。我们也开发了一系列的组件。我们把这些日志数据存储起来之后有很大的好处，比如说源库挂了，用户的数据也是可以恢复的，甚至可以指定时间，比如说二十四小时或者是七天。这样就可以把用户增量的数据都缓存起来解决源库挂了的问题。

今天我们做一个增量迁移，简单的做法可以从一个单线程写到目的库，但要想做一些事务并发就比较困难了。我们很早就实现了事务并发，在内部其性能是很高的。其实刚刚说的DTS数据格式在这个地方就会发挥作用。通过并发写给目的端，增量和同步的实现方式基本上都是一样的，只是增量是短期行为，同步是长期行为，对于可用性的要求是不一样。

DTS增量&同步技术实现事例：

对于增量和同步的实现中，事务1有A表和B表，事务2是C表，事务3是A表和B表，这三个事务中1和3实际上是有冲突的，如果简单实现，直接用一个线程顺序写入目的库就可以解决，但是DTS不一样，我们会有一个事务输出算法把它切成一个并行执行的，算法会判断出事物1和事务3是冲突的，事务2是不冲突的，就可以快速的并发执行下去。

DTS订阅技术实现：

DTS订阅技术的不同之处在于我们提供的client端把增量解析能力通过client开放出去，用户可以使用我们的SDK解析出源库的数据，写在各种类型的数据中心。

DTS可用性：

DTS是分布式系统，整个系统升级的话，用户是感觉不到的，用户原有程序是正常运行的。

DTS容灾：

有几个情况阿里是比较关心的，比如我们的物理机挂掉了，运行程序的那台机器挂了，这个是很有可能的，我们用的就是一个非常普通的PC机。如果出现上述情况，我们会迁移到其他机器，用户基本不会感知到。

DTS使用概况：

目前DTS在公有云是已经发布的产品，用户可以直接使用。包括在美国、香港等地。有一些用户的某些数据很重要，认为放在云上不安全，可以考虑使用我们的专有云。阿里和蚂蚁在我们的集团内部，提供多套服务，包括交易上的单元化，目前大概有一万多个DTS任务在阿里内部运行。最多需要三天，我们就可以把所有的核心交易数据全部从上海迁移到深圳。

阿里核心场景实践：一键建站

如今的双十一，我们可以在深圳重新搭建一个站点，所有的数据和业务全部重新搭建，把整个服务全部跑起来，跟真实的线上数据连接，

所以我们有一键建站这样的项目，底层用DTS把上海的数据迁移加同步自动切换到深圳，数据量很大，达到PB级。在这个过程当中我们也会有一些辅助的功能，比如校验功能等。这之中会涉及到单元化配置管理、TDDL配置、实例资源、告警管理等。

阿里核心场景实践：异构迁移

这部分有些是阿里之前做的，比如Oracle的异构迁移，我们现在正在做的比如OceanBase，我们认为这也会是未来的一个方向。PetaData是我们的一个云产品，有兴趣也可以尝试使用。

阿里核心场景实践：上云迁移

迁移之前我们会做预检查，预检查通过之后进行结构迁移，之后进行全量迁移，在全量迁移之前我们会记录全量迁移的时间点，启动一个增量数据，对增量数据持续读取并解析直到全量迁移完成之前，记录第二个时间点，启动增量或同步功能，把数据全部回放到目的端。迁移数据是非常严肃的问题，今天我们保证这个迁移是对的。

比如说银行数据库挂了切不能切，肯定要有一些比较严格的判断，我们有一个数据校验功能，包括全量校验和增量校验，全量校验是把数据每一行的每一列拿出来全部校验，这是严格的校验。当增量程序已经把用户写入的数据追上了，我们就会先启动全量校验把所有数据全部校验。第二个是增量校验，实际上实时的数据校验。通过这套机制保证迁移是绝对可靠的。

阿里核心场景实践:异地多活