干货打包！最新实时同步 5 大应用场景，4 种实现方案分享（有彩蛋）

前言

数据时代，企业对技术创新和服务水准的要求不断提高，数据已成为企业极其重要的资产，数据同步也成为企业数据开发和使用一个绕不过去的技术需求。可能某一天会上，一项数据同步的需求就从产品同学或者领导口里蹦出来，然后加到你的工作任务里边。那么，什么时候我们需要进行数据同步，甚至是实时同步呢？目前又有什么实时同步方案？

Tapdata 产品合伙人徐亮有着丰富的大数据产品及项目经验，本次为我们分享了实时同步的 5 大典型应用场景以及目前的 4 种实现方案，并对实现方案进行了解读和考虑要点。在此基础上，分享了新一代异构实时数据同步产品 Tapdata Cloud （小重点：免费开放使用）的实现方案，我们也把研讨会 PPT 分享出来，有需要的同学可以点击下载。

典型的实时同步应用场景

1 数据库异地灾备

以传统金融机构数据中心为例，单数据中心由于地理约束等不能抵抗不可预知与控制的风险，已不能满足金融监管要求和企业业务敏捷的诉求，灾备甚至双活成为一个典型的刚性需求。实时数据同步是实现异地灾备的核心能力。早期我们更多是基于 DB2 的 hadr 技术，或者 oracle 的 data guard 技术，应用在数据库灾备的这样一些场景。当然我们会发现，基于这样一些产品，要做整个数据中心的战略，会是一个非常高成本的投入，今天我们遇到越来越多的用户在考虑数据库灾备的建设，考虑投入产出比，实时数据同步工具或许是一个不错的选择。

2 不停机迁移数据库

系统升级迁移是运维同事的日常工作之一。传统的方式，需要对存量的数据库做一个迁移，耗时非常久。举个例子，在 2010 年左右，当时某行 sap 系统，数据量也不大，大概 500G 到一个 T 的样子，进行数据同步的时候，需要先把应用新部署一套，然后数据库在新的服务器上装好，基于原来的数据库做一个全量的备份，此后在目标机器上做一个全量的恢复，同时把一些对应数据库的归档日志拷贝到目标机器上，然后在特定的时间窗口，进行停机恢复。

听起来这个事情特别复杂。做这样一个规模的数据库迁移，整个的进程安排的时间窗口需要 12 小时。这对于做离线的管理系统可能还好，而对于正常的在线业务是不可接受的，但又没有特别好的方式来解决这个问题。

如果基于这种实时同步这种模式，且有相应的产品去做支撑，就能保证我们的数据在迁移和做应用切换的时候，可以进行平滑的调整，把窗口尽量压缩，从小时级缩短到分钟级。

3 数据实时入仓/湖

在做数据仓库建设时，我们需要将大量业务系统数据持续集成到数据仓库/数据湖。我们要把数据从原有的各种各样的数据库里面，就像这张图上列出来的，把它能够放到数据仓库里面去。目前我们大多数都是用的各种各样的数据集成工具，比如说开源的 kettle。我们做了大量的工作，使用 SQL 写了编写数据处理的业务逻辑，通过定时的调度，来完成数据的转移。

这种方式最大的一个问题是对原系统的压力会特别大，当年在某行的时候，我们整个跑一个调度数据入仓，比如说主机的交易数据，用户的数据，我们通常是安排在晚上的 9 点甚至更晚一点，为什么要这么做？因为它对原系统会造成压力，我们抽取数据就会产生很大的压力，于是只能安排在低峰期。

此外，整个数据同步的时间会非常久。正常情况一个用户的交易记录数据表，完成抽取可能要到第二天凌晨甚至早上，才能够加载完成。如果数据要被用到分析和应用场景，延迟不是一个小时两个小时，而是以天计，极大限制了数据价值的发挥。

因此数据仓库更多是用来出报表，而不是去支持在线业务，这也是为什么近几年企业会越来越希望通过数据中台或者这种类似的实时数据能力，去加速整个数据在企业内的应用和流转。

4 读写分离

数据读写分离为什么需要数据同步？举个银行账单系统的例子。我们平常去刷信用卡，我们刷一笔，银行同时会记录一笔，同时我们可能还会不定期的去查询交易记录，这样的话从技术角度上来说，读和写我们需要能够分离，去保证整个系统的效率最大化。

这种情况下，我们能不能用数据库的从库来去实现它的读写分离，甚至基于一些新兴的数据检索技术，例如 es 这种检索查询效率更高的技术，是不是可以放到第三方的数据存储？当然可以。实时同步可以帮助我们解决更多类似的实际的业务问题。

5 业务异步解耦

以某智慧校园场景为例。现在学校的信息化也挺发达的，校园里方方面面的事务，会去变成线上化的系统。一个典型的问题就是所有的系统都会形成一个个孤岛，但业务是需要联通的，这个时候需要打通不同的系统之间的数据。但是我们发现，系统是由不同的服务商开发的，需要找相关的服务商来去处理系统间的扩展，这样成本非常高。大家现在多会怎么做呢？

比较简单的方式，使用一些脚本，比如用 Python 从人事系统里面抽取数据，然后做一些加工计算的规则去处理数据，之后再写到工资系统或者审批系统，再写一个定时触发器来定期运行脚本。这个是我们常见的，写一个类似同步的工具的方式。

这种方式在一定程度上可以满足简单的需求，但当需处理的范围越来越广时，你会发现这样的链路在业务处理中变得越来越多，而且这个过程并不可控。所以我们就会发现是不是可以用实时数据同步，再加上一定的数据开发的能力，就可以很好的来管理和解决这些问题。

实时同步实现方案

那目前有哪些方案可以支撑我们做这样一些事情呢？这里分享 4 种实现方案。

1 基于时间戳

基于时间戳或者自增字段的识别方式，应该我们平常在做数据开发或者数据处理里面最简单的一种方式，通过周期性的比较找到最新的数据去做这种增量。它的优势在于简单，劣势是我们会发现它不能记录删除操作的数据，也不能识别周期内多次更新的。这种基于调度的方式，也无法实时去捕获发生变化的数据。

2 基于快照

基于快照是基于时间戳或自增字段的一个相对优化的方式。基于快照简单理解就是可以把原表或者原库的这种状态数这种当前的数据做一个快照（会占用额外的存储），拿到快照之后，将快照表和当前表做一个比较，然后去发现当前哪些数据被删除了，哪些数据是新增的，甚至是做了更改的。

从实现方式上，基于快照的模式优于基于时间戳的模式，对于数据的增删改可以完全覆盖到，但是有带来新的问题：它会占用更多的存储，并且会消耗我们额外的计算资源，因为它要去计算差异点在哪里，因此在大数据量的情况下，不是一个特别好的实现方案。

3 基于触发器

基于触发器的方式更多是使用数据库本身的机制，这种机制就像我这张图上大家可以看到的，当我们在源端做一个数据库 DML 操作的时候，我们会在数据库里面增加相应的数据修改，或者删除相应的数据。

利用数据库的触发器的机制，我们可以捕获到数据产生的变化，然后可以把变化的数据存储起来。这样的好处是利用了数据库的机制在数据库引擎层面可以去发现数据的变化，可以做到实时同步。但从 dba 同学的角度，不建议在生产系统上使用触发器，否则会带来系统额外的开销从而容易产生性能问题。

4 基于数据库日志

目前在主流的商业化数据同步软件里面最常用的一种方式就是基于数据库日志的方式。做过数据恢复或者做过 DBA 的同学应该比较清楚，数据库都有一个日志来记录数据库的事务操作，这种日志在数据库恢复上非常有帮助。

基于数据库的日志，加上一些解析的能力，可以做到数据的实时读取，实时的在异地回放和落地。现在常见的一些商业化产品，基本上都会基于这样的能力做更多的开发。

综合比较下来，不管是从开发的角度，还是从技术实现的角度，我们会发现每一种方式都有自己的优劣势。比如说时间戳是最简单的，很容易实现但不支持增量数据捕获。基于触发器的方式，或者基于数据库日志的方式，实时性足够高，但是触发器不是一种性能特别好的方式。基于数据库日志，如果说我们有技术实力，或者有更可靠的这种商业软件来支撑，是我们目前最适合去做实时数据同步的一种方式。

技术选型考量因素

我们自己在做产品的时候也在思考一个问题，选用哪种底层技术可以更好地保证用户用好数据同步的能力，能够保证它的业务能够持续稳定的运转？需要考虑的因素有哪些？这里我简单列了几个问题，在大家日常的工作中，我觉得大家肯定会碰得到：

1. 如何在多样化数据源的情况下，降低同步管理的复杂度？

生产环境里我们有很多不同类型的数据库，比如 Oracle、MySQL,DB2，有 PG，MongoDB 等。如果需要对这些数据同时做不同的同步处理的话，按照现有的开源软件的方式，可能每一种数据库都有自己的一套软件来去实现，我们需要分开去做管理。商业化的数据同步产品可能支持的也不是很全面的，比如说像 MongoDB,其实很多传统的数据同步软件支持不是特别好。

2. 如何实现异构数据库之间的实时同步？

DBA 同学可能清楚一点，很多时候做迁移，其实是做了一个同构到同构的迁移，但现在我们会遇到一些很多新的场景，比如像刚才我也提到做读写分离加速的场景，我们希望把数据库里的比如说 MySQL 的数据，我希望把它同步到我的 ES 里面去做这种更高效的检索和查询。或者说一些传统的 MySQL 等关系型数据库，我觉得它的查询性能不好，也不方便我去做管理，我要把它放到 MongoDB 里面。用传统的备份和恢复的方式基本是不可行的，因为数据的结构，字段类型，甚至一些关键的配置都是有差异的。像我们最近在接触的一些客户，从 MySQL 迁移到达梦里面去，这个东西如果说我们要手工去做，DBA 同学会很崩溃的。

3. 如何保证稳定性和可靠性？

当我们解决了前面两个功能性的问题，我们又会有进一步的需求：任务如果是在跑，我怎么能够保证它稳定在运行？如果出了错误，我能不能及时知道？之前有一个同学在跟我们去聊这个话题的时候，他就提到说他们现在用的产品功能上应该是 ok，但是稳定性不是特别好，出了问题也不知道，需要人工去检查巡检。但是这个功能又不太容易做二次开发，所以就用起来很麻烦。这个特性其实企业级产品一个非常关键的特性。

4. 如何验证数据的质量？

好了，我们做了数据同步，从 MySQL 同步到 MongoDB 里面，从 MySQL 同步到 ES 里面，我怎么保证数据在同步过程中不会出现偏差呢？我有没有办法去验证，甚至说再往下我是不是如果真的出现了偏差，我是不是可以去纠正的？这都是我们一系列在真正去解决这个问题的时候，我们需要去考虑的点。

5. 同步实现是否需要复杂的代码处理？在同步的过程中，需要做些处理，如何来实现？

我们在同步的过程中是不是要花大量的时间，比如说我要不要去写 SQL(这个可能还算简单的)? 是不是在这个过程中我还有需要去写处理业务逻辑的东西？我们的工具是不是很好的去来支撑这个事情？

我们虽然有了非常值得信赖的一些底层的技术方式和一些开源的产品去做这个事情，但是当我们希望把变得稳定、可靠、可用，甚至能够极大提升我们在做利用数据实时同步来去完成我们的业务场景和目标的工作效率时候，我们还需要解决更多的问题。

下面我介绍下我们正在做的一个实时异构数据同步工具。

Tapdata Cloud 如何来解决以上问题？

支持多样化的数据源，完美支持 SQL->NOSQL

Tapdata Cloud 是我们今年推出的一个免费的在线实时异构数据同步工具，现在已经支持了多种数据类型，包括我们常见的一些关系数据库，比如 Oracle，MySQL；也支持一些常见的 NoSQL 数据库，比如 MongoDB，ES,还有消息中间件 Kafka 等,也都在我们的支持范围之内。

这张图上我们大家可以看到我们现在已经支持的一些数据源，还有一部分是我们正在开发即将上线的一些能力，如果说我们同学如果有测试的需求，比如说这里面我有些数据源是没有的，希望我们加进来的，非常欢迎大家给我们提更多的意见和建议，也欢迎大家来做更多的尝试。

低代码配置操作，可视化任务运行监控

我们通过一些简单配置的操作方式，统一的操作流程和和体验能够帮助用户实现同构和异构数据库同步。

Tapdata Cloud 整个配置过程非常简单，除了建数据源之外它只有 4 步，第一步是我们可以去选我们的源和目标，第二步就是设置我们整个任务的属性，比如说是做全量还是做增量，然后在全量和增量里面是不是还有一些特殊的配置，比如说我是不是有可能会出现这种无主键的情况，这个是我们在很多客户场景里面非常典型的一些场景。

第三步就是我们可以选我们要去做同步的表，比如说哪些表我们是希望同步到目标端去，同时我们也支持在选择表的过程中对表去做一些改名。第四步就是针对我们选择的字段，选择的表，我们可以做一些这种调整。为什么会有这样一个环节？当我们在做这种异构数据同步的时候，我们会发现不同的数据库它的字段类型之间会存在很大的差异的。我们做了大量的工作，去保证数据模型的准确性，同时我们也把推演能力开放出来，能够让用户及时准确的去纠正调整字段转换映射。

具体的操作大家可以看直播演示，也可以登录 cloud.tapdata.net 直接上手操作，我们也提供了产品操作文档给大家。

SQL 作为 CDC 补充，满足多样化同步场景

前面我们介绍了 4 种数据同步方式，不管是基于时间戳，基于快照，还是基于触发器或者基于日志的 CDC 的方式，总会在一些实际场景里面会遇到以下情况：我们的数据库其实是没有日志可以用的。我们之前遇到一个客户，他的数据库是跑在阿里云上，数据库使用主从架构，但是不允许我们从主节点访问数据库日志。但我们发现在阿里云上的从节点，即使打开了 binlog 的设置，也不会去记录相应的操作。这个时候我们会提供一种基于 SQL 的方式，在数据表对象设置上，我们会提供这样的一个配置，让用户可以通过 SQL 来实现数据的增量。而这种场景我们在蛮多的用户场景里面遇到。

任务可用性监控

刚才我们也提到了，我有一个工具，我能保证它能解决我基本的问题，但是我们如果希望它能够真正在我们的生产环境真正发挥它的价值，我们除了对它的功能性有要求，稳定性和可用性也是非常关键的考量点。任务出现了问题，同步节点也出现了问题，我能够及时知道并且处理。这样的话我们的工具产品才有可能帮到实际的用户，能够成为它的真正的生产力的工具。现在我们已经支持了短信、邮件和系统通知的监控通知，不过现在我们还不能自主关闭，这个功能已经在排期，在最近的 1~2 个迭代我们会把它加上去。

数据校验

最后我们再看数据校验的能力，刚刚我提到的一个话题就是数据校验。为什么要数据校验？在同步过程中，很有可能会出现偏差，如何解决这个问题？一方面我要保证我的数据同步不会出现偏差，这个是从同步的能力上我们要一直加强的核心功能，但另一方面，我们也必须能够提供到一个让用户确认说我确实是没问题的能力。

Tapdata Cloud 提供的数据校验的能力有三种，比如说我的快速统计数量的校验，源表 100 万，我可以在目标端做一个测试，我发现它是 99 万多一点，我们就可以发现它的差异，至少我知道它是有差异的，这个是第一种快速 count 方式。第二种方式就是就是我们所说的这种表全字段的校验，我可以需要展开做各种各样的这种全字段校验，当然这种校验的效率会比较低，需要比较长的时间。第三种就是我们的关联字段值的校验，其实它类似于全自动，但是它可以提取部分自动去做这样的事情。

创新的实时数据同步技术

彩蛋—— Streaming ETL

最后给大家一个彩蛋。大家都知道传统的 ETL：我们要去做数据开发，要抽取不同的数据，在抽取的过程中要做一些转换和计算，这个就是我们常见的 ETL。ETL 加上这种 CDC 的能力变成这种流的方式，它可以解决什么问题？

Streaming ETL 是我们正在设计开发的功能，这个功能在刚刚介绍数据业务解耦的场景里会遇到的比较多，我们计划是在 10 月底在云版上跟大家见面。

关于 Tapdata

再简单介绍一下团队。Tapdata 团队是 2019 年成立于深圳。在 19 年成立的时候，我们就获得了变量资本等千万级的投资，然后到今年初我们获得了五源资本的投资，我们也是国家流数据库标准委员会的成员，今年也获得了最佳数字中台品服务品牌的奖项。

我们在打造未来企业首选的一个实时数据服务平台，同时我们最核心的最强大的骨干研发力量都是来自于像 MongoDB、百度等 BAT 这样的公司。这里我也打个小广告，如果说对我们做的事情有兴趣，能够跟我们一起来去提升我们整个在数据实时同步，甚至数据服务这块能力的同仁，我们非常欢迎大家来投递简历加入我们。   查看详细岗位介绍

扫描下方二维码，订阅最新 Tapdata 技术博客 ↓↓