数据同步工具天花板？支持MySQL、Oracle、SQL Server等主流数据库

很多企业的数据问题，表面看是“数据取不到”，往深了看，其实是：

系统越来越多，但数据在系统之间流不动。

订单系统用MySQL，ERP跑Oracle，老系统还留着SQL Server，数仓又可能使用PostgreSQL、Doris、StarRocks等数据库。

再往外，还有API、Excel、CSV、消息队列以及各种业务系统。

平时这些系统各自运行，好像没什么问题。

可一旦企业开始做统一数仓、经营分析或者数据中台，麻烦马上出现：

• 财务要收入数据，要去ERP找；

• 运营要订单数据，要从业务库取；

• 管理层要一张经营报表，背后可能要拼五六套系统。

所以数据同步真正解决的，从来不只是：

“怎么把一张表复制过去？”

而是：

几十套异构系统里的数据，怎么长期、准确、稳定地流到需要它的地方。

正式展开之前，也整理了一套《数据仓库建设解决方案》，里面涉及常见数据架构、同步方式和项目实践。正在做数据平台、数仓或者数据治理的，可以拿去参考。

需要自取：https://s.fanruan.com/7igmg（复制到浏览器）

一、支持MySQL、Oracle、SQL Server，只是第一道门槛

选数据同步工具时，很多人第一眼都会看：

支持多少种数据源？

这个指标当然重要。

因为现实里的企业IT环境几乎不可能只有一种数据库。

新业务可能跑MySQL，核心系统可能还在Oracle，一批历史应用留着SQL Server，分析平台又使用另外一套数据库。

如果每增加一种数据源，就重新开发一套取数程序，最开始感觉不到什么。

等到系统越来越多，就会慢慢出现一种典型的数据架构：

MySQL一批脚本，Oracle一批存储过程，接口数据单独写程序，Excel再放进某个定时目录。

每条链路单独看都能运行，但放在一起以后，开发方式、运行日志、异常处理、任务依赖完全是割裂的。

最麻烦的还不是代码多。

而是某一天一个开发人员离职，大家突然发现：

这条数据到底从哪里来的，没人敢动。

所以数据源覆盖真正解决的，不只是“有没有某个连接器”，而是企业有没有机会把分散的取数方式重新收回来。

实际搭数据链路时，MySQL、Oracle、SQL Server以及其他数据库、文件、接口等来源，可以直接进入 FineDataLink 5.0 的数据集成链路，后面的抽取、加工和写入继续沿着任务往下走。以后新增一个数据来源，更多是扩展已有数据流，而不是再单独养一套取数程序。当前产品支持范围也覆盖多类传统数据库、大数据及其他数据源。

但企业做到这里，其实才刚刚开始。

因为：

连得上数据库，不代表数据真的能同步好。

二、异构数据库最难处理的，其实是“数据语义”

很多人理解的数据同步是：

SELECT出来，再INSERT进去。

同一种数据库之间可能还比较接近。

一旦从Oracle迁到MySQL，从SQL Server写进其他数据库，事情就开始复杂了。

比如

• Oracle里的NUMBER，在目标端应该对应BIGINT还是DECIMAL？

• 源端VARCHAR长度和目标端规则不同怎么办？

• DATE写入另一个数据库以后，时间精度会不会发生变化？

• 金额字段原来保留六位小数，目标表只有两位，会不会悄悄丢掉精度？

还有NULL、默认值、字符编码、大字段、主键、唯一约束……

这些细节单独看都很小。

但数据同步有一个特点：

错误会被批量复制。

假设一条金额字段映射规则错了，每天进入500万条数据。

一天以后是500万条问题记录；

一个月以后可能已经变成上亿条。

这就是为什么真正测试数据同步工具时，不能只准备一张几十列、几万行的简单Demo表。

最好直接拿真实业务中的复杂字段去测试：

金额、时间、空值、特殊字符、大文本、联合主键，以及各种边界值。

因为异构同步真正需要验证的不是：

数据有没有过去。

而是：

数据过去以后，业务含义有没有发生变化。

很多数据质量问题，其实不是在报表层产生的。

从数据离开源系统的那一刻，就已经埋下了。

三、数据量上来以后，“每次全量”一定会出问题

假设订单表只有10万行。

每天凌晨全部同步一遍，没什么问题。

三年以后，订单表已经20亿行。

每天真正新增和修改的，可能只有500万行。

这时候如果为了获得500万条变化，仍然每天重新扫描20亿条数据，会发生什么？

• 业务数据库IO升高；

• 同步窗口越来越长；

• 网络传输量越来越大；

目标端还要重复处理大量没有变化的数据。

所以数据同步规模一旦上来，核心问题会从：

“数据怎么搬？”

变成：

“我怎么知道哪些数据发生了变化？”

这才是增量同步真正解决的问题。

而且“增量”本身也不是一种技术。

地区编码、组织架构这种低频变化的小表，直接全量覆盖可能就够了；

持续新增的流水数据，可以按时间或者递增ID读取；

同时存在新增和修改的数据，可以通过更新时间等条件获取变化；

订单状态、库存、账户流水这类高频更新的数据，还会进一步涉及CDC，根据数据库日志捕获INSERT、UPDATE、DELETE。

所以真正的数据同步架构，本来就是混合的。

落到 FineDataLink 5.0 里也可以按照这个思路拆：变化不频繁的数据按周期更新，普通业务明细只取新增或变化部分，需要持续跟踪增删改的数据再放进数据管道。它的实时管道能够基于MySQL Binlog、SQL Server CDC等方式捕获数据库变化。

这里真正值得记住的其实只有一句话：

不要先决定同步技术，再去套业务数据。

先问清楚：

• 数据量多大？

• 一天变化多少？

• 允许延迟多久？

• 有没有UPDATE和DELETE？

再决定到底应该全量、普通增量还是CDC。

很多数据链路成本过高，本质上就是一开始同步策略选错了。

四、数据同步真正的分水岭，在第一次故障以后

做POC的时候，绝大多数同步工具看起来都不错。

选源表，选目标表，点击运行。

几十万、几百万条数据很快过去了。

但这只能证明：

正常情况下，它可以运行。

而企业生产环境最不缺的就是“不正常”。

数据库重启、网络闪断、连接超时、目标库锁表、磁盘空间不足、字段异常、脏数据……

假设一个10亿行的数据迁移已经完成8亿行，这时候突然网络中断。

• 恢复以后怎么办？

• 是重新从第1条开始？

• 还是从8亿条以后继续？

如果下午2:03实时链路中断，2:10重新恢复，那么还有几个问题必须回答：

• 2:03到2:10发生的数据变化有没有保留下来？

• 重新启动以后，从哪个位置读取？

• 之前已经写过的数据会不会再写一次？

• 如果同一条订单UPDATE执行两次，会不会影响最终结果？

所以数据同步做到生产环境以后，必须开始考虑：

断点、重试、幂等、错误数据处理和恢复机制。

这时候，链路里真正有用的往往不是又多了一个“开始同步”的按钮，而是故障以后还能知道自己停在哪里。像 FineDataLink 5.0 的数据管道会保留同步进度，全量阶段完成以后发生中断，可以继续从已有断点恢复；任务运维里还能继续查看运行状态和记录。

规模小的时候，任务失败一次，人工重跑就行。

规模大以后，如果每天1000个任务里有20个异常，每个都需要开发人员手动查数据、找位置、补脚本，运维成本会非常恐怖。

所以判断一个同步工具是否成熟，不妨观察一个很简单的场景：

把网络断掉，再看看它怎么回来。

五、比断网更隐蔽的问题，是源表自己变了

还有一种问题特别容易被低估：

Schema Change。

数据库里的表并不是永远不变的。

今天订单表30个字段。

业务上线优惠券，增加一个：

coupon_amount

后来会员体系调整，又增加：

member_level

还有可能把某个INT改成BIGINT，或者把字段长度从50扩到200。

问题来了：

源表发生变化以后，下游知道吗？

如果数据链路完全按照上线第一天的结构运行，常见结果无非几种：

• 直接报错；

• 新增字段没有同步；

• 目标表结构不匹配；

• 下游SQL继续按照旧字段运行。

真正麻烦的是第二种。

任务每天还是绿色，所有人都以为数据正常。

一个月以后业务才发现：

新字段从来没有进入数仓。

然后开始补表结构、补同步任务、补历史数据、重算指标。

数据链路规模越大，这类问题越难靠人解决。

1000张表，不可能每天让开发人员逐张检查有没有增加字段。

所以成熟的数据同步已经不能只关注“数据有没有移动”。

还要开始关注：

数据结构发生变化以后，变化如何向下游传播。

再往后就是血缘。

一个源字段改变，究竟影响了哪些同步任务、哪些明细表、哪些指标、哪些报表？

数据集成做到最后，其实会和元数据、数据质量、数据治理逐渐连起来。

六、任务显示成功，不代表数据真的正确

很多公司的数据同步监控页面非常漂亮。

一眼看过去：

全部绿色。

但绿色代表的通常只是：

程序执行成功。

它不能证明数据一定对。

假设源库今天有1000万条订单。

目标库最终写入998万条。

任务有没有可能显示成功？

有。

源端销售额合计1.26亿元。

目标端只有1.25亿元。

任务有没有可能还是正常结束？

同样有可能。

这就是数据同步里最危险的一种情况：

技术链路没报错，业务数据已经错了。

因此，核心数据同步后最好至少检查四件事：

1. 数量是否一致：源端读取多少条，目标端实际写入多少条；

2. 关键指标是否闭合：金额、库存、余额等重要字段汇总结果有没有偏差；

3. 具体记录是否一致：根据主键抽样检查字段值；

4. 数据是否足够新鲜：源端和目标端最大业务时间相差多久。

如果是一条关键财务链路，还可以继续检查每日借贷发生额；

如果是库存数据，可以检查SKU数量和库存总量；

如果是订单，则可以按照日期、渠道、状态分别核对。

所以校验规则不能只有技术口径，还应该加入业务口径。

数据链路跑完以后，这些检查也可以继续接进 FineDataLink 5.0 的数据检测和任务运维环节：数量、字段以及业务规则出现异常时，比单纯盯着“任务成功”更容易提前暴露问题。当前版本的数据检测覆盖MySQL、Oracle、SQL Server、PostgreSQL等多类数据源。

这一步很重要。

因为企业真正需要交付的，从来不是：

一个成功运行的同步任务。

而是：

一份下游敢直接拿去分析的数据。

七、以后再选数据同步工具，别只数数据库数量

所以再看到一款工具宣传：

支持MySQL、Oracle、SQL Server……

当然可以看。

但不要看到这里就结束。

真正做选型时，可以继续问七个问题：

• 数据源越来越多以后，能不能统一管理？

• Oracle、MySQL等异构数据库之间，字段类型怎么映射？

• 大表到底是全量、普通增量还是CDC？

• 上百张甚至上千张表，能不能批量建立和维护链路？

• 网络中断、数据库重启以后，任务从哪里恢复？

• 源表新增字段或者修改结构以后，下游会发生什么？

• 最终如何证明源端和目标端的数据真的一致？

这七个问题，基本覆盖了一套数据同步系统从：

能用 → 好用 → 能长期运行

的完整过程。

真正进入生产环境以后，一款同步工具面对的是：

几十种数据源、成百上千张表、亿级数据量、持续变化的数据、不断调整的表结构，以及随时可能发生的各种异常。

数据库能不能接，只决定项目能不能开始。

同步策略是否合理、故障以后能不能恢复、结构变化能不能处理、最终结果能不能验证，才决定这条数据链路一年以后还敢不敢继续用。

企业真正需要建设的，也从来不是一堆：

“把A表搬到B表”的任务。

而是一套能够持续运行的数据流动体系。

数据从哪里来、怎么变化、什么时候到、出了问题怎么办、最后是否可信——

这些问题都能回答清楚，数据同步才算真正做完。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/oOBubbleX/article/details/166373390