共计 6557 个字符，预计需要花费 17 分钟才能阅读完成。
前言
数据时代，企业对技术创新和服务水准的要求一直进步，数据已成为企业极其重要的资产，数据同步也成为企业数据开发和应用一个绕不过来的技术需要。可能某一天会上，一项数据同步的需要就从产品同学或者领导口里蹦出来，而后加到你的工作工作里边。那么，什么时候咱们须要进行数据同步，甚至是实时同步呢？目前又有什么实时同步计划？
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 的同学应该比较清楚，数据库都有一个日志来记录数据库的事务操作，这种日志在数据库复原上十分有帮忙。
基于数据库的日志，加上一些解析的能力，能够做到数据的实时读取，实时的在异地回放和落地。当初常见的一些商业化产品，基本上都会基于这样的能力做更多的开发。
综合比拟下来，不论是从开发的角度，还是从技术实现的角度，咱们会发现每一种形式都有本人的优劣势。比如说工夫戳是最简略的，很容易实现但不反对增量数据捕捉。基于触发器的形式，或者基于数据库日志的形式，实时性足够高，然而触发器不是一种性能特地好的形式。基于数据库日志，如果说咱们有技术实力，或者有更牢靠的这种商业软件来撑持，是咱们目前最适宜去做实时数据同步的一种形式。
技术选型考量因素
咱们本人在做产品的时候也在思考一个问题，选用哪种底层技术能够更好地保障用户用好数据同步的能力，可能保障它的业务可能继续稳固的运行？须要思考的因素有哪些？这里我简略列了几个问题，在大家日常的工作中，我感觉大家必定会碰失去：
- 如何在多样化数据源的状况下，升高同步治理的复杂度？
生产环境里咱们有很多不同类型的数据库，比方 Oracle、MySQL,DB2，有 PG，MongoDB 等。如果须要对这些数据同时做不同的同步解决的话，依照现有的开源软件的形式，可能每一种数据库都有本人的一套软件来去实现，咱们须要离开去做治理。商业化的数据同步产品可能反对的也不是很全面的，比如说像 MongoDB, 其实很多传统的数据同步软件反对不是特地好。
- 如何实现异构数据库之间的实时同步？
DBA 同学可能分明一点，很多时候做迁徙，其实是做了一个同构到同构的迁徙，但当初咱们会遇到一些很多新的场景，比方像方才我也提到做读写拆散减速的场景，咱们心愿把数据库里的比如说 MySQL 的数据，我心愿把它同步到我的 ES 外面去做这种更高效的检索和查问。或者说一些传统的 MySQL 等关系型数据库，我感觉它的查问性能不好，也不不便我去做治理，我要把它放到 MongoDB 外面。用传统的备份和复原的形式根本是不可行的，因为数据的构造，字段类型，甚至一些要害的配置都是有差别的。像咱们最近在接触的一些客户，从 MySQL 迁徙达到梦外面去，这个货色如果说咱们要手工去做，DBA 同学会很解体的。
- 如何保障稳定性和可靠性？
当咱们解决了后面两个功能性的问题，咱们又会有进一步的需要：工作如果是在跑，我怎么可能保障它稳固在运行？如果出了谬误，我能不能及时晓得？之前有一个同学在跟咱们去聊这个话题的时候，他就提到说他们当初用的产品性能上应该是 ok，然而稳定性不是特地好，出了问题也不晓得，须要人工去查看巡检。然而这个性能又不太容易做二次开发，所以就用起来很麻烦。这个个性其实企业级产品一个十分要害的个性。
- 如何验证数据的品质？
好了，咱们做了数据同步，从 MySQL 同步到 MongoDB 外面，从 MySQL 同步到 ES 外面，我怎么保证数据在同步过程中不会呈现偏差呢？我有没有方法去验证，甚至说再往下我是不是如果真的呈现了偏差，我是不是能够去纠正的？这都是咱们一系列在真正去解决这个问题的时候，咱们须要去思考的点。
- 同步实现是否须要简单的代码解决？在同步的过程中，须要做些解决，如何来实现？
咱们在同步的过程中是不是要花大量的工夫，比如说我要不要去写 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 技术博客 ↓↓