日志级CDC异构数据同步实践：增量捕获、断点续传与数据校验

大家好，我是数据库小学妹 👋 我踩过的坑，你别再踩。

先说上周的事。周一早上九点，运营要周报，财务说ERP和报表库对不上账，开发同事一脸无奈：ETL昨晚又没跑完，字段映射错了，还在补数。三个系统、三套口径、一个早上，全乱了。这种"数据打架"的场面我太熟，几乎都长一个样：源端不止一种数据库，中间靠脚本硬搬，搬完没人敢保证两边对得上。

一、先说清楚：异构数据集成是什么

异构数据集成，就是把分散在不同系统、不同格式、不同结构的数据，统一抽取、转换、加载到目标端，形成一致可用数据的过程。

这些散落在关系库、非关系库、文件、API、消息队列里的数据，就是常说的多源异构数据。来源越多，"异构"两个字越沉。它不是某个工具一键能搞定的事，而是一整套工程问题。企业做数据仓库、商业智能，或者国产化迁移时，几乎都会撞上它。这类文章网上不少，定义都差不多，落地却坑坑不一样。这篇我不背概念，只拆技术。

二、为什么异构数据集成这么疼

在动手整合多源异构数据前，多数团队低估了三件事。

第一件，数据孤岛是历史欠账。ERP在Oracle，CRM用MySQL，报表库是SQL Server，后来分析平台又上了Hadoop。每套系统当年都是按需采购的，没人会提前设计"以后要互通"。等想打通时才发现，连"客户"这个字段，各系统叫法都不一样。

第二件，异构差异全藏在细节里。数据类型映射（Oracle的NUMBER到MySQL）、字符集（UTF-8与GBK混存，中文变乱码）、时区（交易时间差8小时，报表全错位）、字段语义（A系统的"状态1"和B系统的"状态1"不是一回事），光看建表语句根本发现不了。我踩过最典型的：同一笔订单，交易库叫 order_id，数仓叫 order_no，Excel里叫"订单号"。为了对齐口径，光映射表就开了三次会。

第三件，定时同步撑不起实时业务。ETL每天凌晨跑批，第二天早上看到的，是昨天的数据。可业务要实时看板、风控要实时拦截、库存要实时扣减，"昨天的数据"在这些场景里基本没用。

三、先选路线再看工具：五种技术路线一张表

做异构数据集成，市面上所有方案，本质是下面几条路。

这张表看下来，没有哪条路是万能的。选型的关键不在"哪个工具火"，而在两条：你要多快的数据，源端复杂到什么程度。我见过不少团队一上来就上大数据平台，报表需求没跑通，先把运维累趴了。

四、实时同步的分水岭：增量数据到底怎么抓

定时批处理和实时同步，本质区别只有一个：增量怎么识别。业界做增量，无非三种路子。

第一种，时间戳/增量字段。靠 last_update_time 这类字段把新增捞出来。实现最简单，但源表没这字段就抓瞎，delete操作抓不到，高并发下还容易漏数据。第二种，触发器。在源库建trigger，把变更写进一张日志表。增删改都能抓到，但要动源库、有性能开销，很多业务方根本不允许。第三种，日志解析，也就是常说的CDC。去读数据库自己的日志，Oracle读redo log，MySQL读binlog，PostgreSQL读WAL，把变更一条条解析出来，再应用到目标端。

第三种为什么越来越主流？因为它不侵入源库，又能拿到完整的事务顺序。数据库本来就要靠这些日志做崩溃恢复，日志里记录着每一次增删改的完整现场，按顺序重放，一致性天然有保障。

日志还有个关键属性：带位点。MySQL里是binlog文件名加偏移量，Oracle里是SCN，PostgreSQL里是LSN。工具把"读到哪了"记下来，链路断了重启，就从上次的位点接着读，不重复也不漏。这个能力叫断点续传，生产环境全靠它兜底。

全量和增量怎么衔接，也是门学问。严谨的做法是：先对源库做一致性快照，同时记下快照那一刻的日志位点；全量搬完后，从那个位点开始补增量，等两边差距追到零，再安全切换。要是先跑全量、后开增量，中间漏掉的那一段，就是日后对不上账的伏笔。

日志解析也不是银弹。各家日志格式私有，解析器要一家家适配；DDL（比如加字段）得单独处理；异构字段转换，照样要配映射规则。所以判断一套实时同步方案靠不靠谱，别看它能不能跑通，要看三件事：支持多少种数据源、断点能不能续传、数据对不对得上。

五、案例复盘：Oracle、MySQL迁向国产库，异构数据集成怎么落地

聊个我做国产化替代时很典型的场景。客户核心交易在Oracle，周边业务在MySQL，还有SQL Server老系统，目标是把数据逐步集中到国产库金仓（KingbaseES）上，业务不能停。这种迁移本质就是一次大型异构数据集成。我们当时用的，是金仓异构数据同步软件Kingbase FlySync（简称KFS）。

这套方案我总结成三个字，好记：搬、追、对。

• 搬（全量迁移）：历史数据先搬过去，到TB级也不用停业务。
• 追（增量追平）：全量开始那一刻，KFS同时记下日志位点。迁移窗口里的新变更，从那个位点往后追，持续同步到目标端，直到两边追平。
• 对（数据校验）：KFS支持业务不停机做数据比对，自动发现源端和目标端的差异并修复。

我为什么把"对"单独拎出来？因为市面上不少同步工具只做到"搬"和"追"，对不上账全靠人肉去查。KFS把数据校验做进了同步链路里，这一点在国产化项目里尤其值钱。真做校验时，通常是先比行数，再按主键分片做校验和（checksum），最后才对差异数据逐条订正。全表一行行比，数据量上来根本不现实。官方公开的案例里，某中煤生产运营项目50多个系统从MySQL迁到金仓，应用侧基本零改造就完成平滑过渡；另一个案例，从SQL Server AlwaysOn集群往独立库同步300多张关键表，靠的也是同一套机制。

它支持的同步拓扑也全：一对一、一对多、多对一，级联和双向都行。信创项目常要求国产芯片和操作系统，官方公开的能力是支持30多种数据源，在仅分配1核CPU、2G内存的最小资源下，同步性能可达50GB/天以上，延迟亚秒级。

六、工具怎么选：先答5个问题

被问最多的永远是"到底选哪个工具"。我的回答是先答5个问题，答案自己会出来。

1. 要实时，还是能接受T+1？这决定你走ETL还是实时同步。
2. 数据源有哪几种？包不包括国产库？先数清楚源端，再看工具的兼容列表。
3. 要不要双向同步或容灾？单向搬家和主备/双活架构，要求完全不是一个量级。
4. 谁来运维？图形化监控和脚本日志，对团队的要求差很多。
5. 有没有信创要求？要跑在国产芯片和操作系统上，选型范围立刻变窄。

七、异构数据集成避坑清单

踩过的坑不少，最想叮嘱的就三条。

全量搬完别以为就结束了，增量才是天天要跑的链路。上线前一定把增量链路压测扎实，重点看链路断了、重启之后，位点能不能接着上次续上，不重也不漏。

两个系统里"同名字段不同含义"是常态，光看字段名根本发现不了。所以同步前，先把两边的枚举值、单位、编码规则这些字典对齐。不然数据搬过去长得一样，用起来全不是一回事。

还有一条最容易被忽略：一致性靠校验，不靠感觉。别信"应该没问题"。定期拿源端和目标端做数据比对，对不上就早发现早处理，别等业务先撞见对不上的那天。

写在最后

异构数据集成没有银弹。先定实时性，再选技术路线；要实时，就认真研究日志解析方案；做国产化迁移，就把数据校验当底线。

回头再看开头那场"对账事故"，根子不在工具，在没人把一致性当回事。工具层面，如果你正卡在国产化这关，金仓的Kingbase FlySync可以多看两眼。它全量搬、增量追、还能自动对账，帮你省掉的是半夜爬起来对数的命。但工具终归是工具，把"搬、追、对"想清楚，第一步才算走对。

你们做异构数据集成时，踩过最深的坑是什么？评论区聊聊，说不定能帮到正在填坑的同行。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见 👋