数据集成产品能力拆解：形态、零件与验收

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

上个月被拉去一个评审会，评的是数据集成产品。三份方案摆在桌上，报价差四倍。业务方只问一句：下周三合并报表能不能出数。三个供应商都说能。我再问一句数怎么保证对得上，会议室安静了半分钟。

数据集成产品，指把分散在不同系统里的数据按规则搬到位、并保证搬完对得上的软件产品。 安静的那半分钟说明一件事：能搬，不等于搬对。它由连接器、抽取引擎、传输缓冲、转换装载、校验修复、调度管控六部分组成。这篇分两步走。先看市面上的数据集成产品有哪些形态，再把选型拆成六个零件逐个验收。看完你手上那份标书，应该能问出十个以上原来没想到的问题。

一、数据集成产品有哪些形态？四类对照

这个问题我被问过很多次。答案不是一串数据集成工具清单，是四类形态。形态决定了它能干什么，也决定了你要养什么。四类我都上手过，各有各的脾气。

四类不是替代关系，是分工关系。我见过最省的做法，是两类拼着用：库到库那段走数据库侧产品，跨源与入湖那段走平台。反过来配，钱花得多，问题也多。拿这张数据集成产品对照表，和你的链路清单对一遍。八成链路是库到库，重点谈第四行；一半是文件和接口，重点谈前两行。

图1：数据集成产品的四类形态与代表产品对照（ETL 平台 / 湖仓集成 / 云上服务 / 数据库侧产品）

二、数据集成产品的六个零件，缺一个都算半成品

为什么先把数据集成产品拆成零件？因为功能清单可以对得齐，零件能力不行。清单上写「支持 Oracle」，十个产品都打勾。真到实施，版本、字符集、权限、增量方式，每一项都能让那个勾失效。下面这张表，我后来直接拿去问供应商了。

表的用法很简单。左边两列看产品能力，右边两列看你能不能验它。三个零件答不上来，就不用往下谈了。下面逐个零件说，重点讲标书里看不见的部分。

图2：数据集成产品的六个零件与验收要点（连接器、抽取引擎、传输缓冲、转换装载、校验修复、调度管控）

三、零件一：连接器，「支持」三个字最值钱

标书里最容易被糊弄的就是这一段。写一句「支持主流数据库」，听起来很全。我踩过一次，供应商清单写支持某款数据库，实施时才发现只认到旧版本，新版本要等补丁。项目等不起。所以这一项别问总数，要问细到哪一层。

我的问法就三件事。先问这个源支持哪个版本区间，同一款数据库，五年前和今年的日志格式不一样。再问增量是日志级还是触发器级，触发器要动源库，很多业务方一听就否。最后问 DDL 跟不跟，源端加一个字段，链路是自动适配，还是直接报错停掉。三句问完，能答上来的产品不多。我后来更愿意看数据库厂商那一支，它们的连接器跟着内核版本走，版本这件事少一层悬念。

四、零件二：抽取引擎，抓变更的方式决定后面所有事

抽取引擎只干一件事：知道哪几行变了。做法无非四种，日志解析、时间戳、触发器、全表比对。这里不展开原理，只给一个判断：日志解析不改源库，还能保住事务顺序。剩下三种做法，都要在源端或时间上付代价。所以看产品怎么承诺，比看它怎么实现更有效。

我会问三个问题。链路断了，位点存在哪，存内存的进程一挂就得重跑全量。大事务怎么处理，一个几百万行的批量更新，会不会把整条链路堵死。并发上去了，顺序还保不保，这一点最容易被跳过，也最容易在割接那天爆出来。

金仓这一支的抽取引擎叫 Kingbase FlySync（简称 KFS），走数据库物理日志解析。它的定位是异构数据平台之间的实时增量同步。场景写得很实：容灾、迁移替换、数据集中共享、上云。我在意的是它把「位点」当成了产品的一部分。断点信息能反解成数据库的日志位点，出问题时能对回源库的日志文件。这件事看着小，排障时省的是半天。

五、零件三和四：传输装载，吞吐和事务边界是一对矛盾

传输和装载，是产品真正拼工程的地方。参数调得好，链路稳。调不好，两边都难受。以迁移工具为例，一般会暴露三个参数：最大并发数、写缓冲大小、单次提交量。金仓的迁移工具 KDTS 就是这么设计的。

# KDTS 迁移任务的三个关键参数（示意）
最大并发数   = 8        # 执行线程数，按主机 CPU 线程数配
写缓冲大小   = 32       # 单位 MB，单线程一次写入量
数据提交量   = 50000    # 单次提交记录数，默认 50000

这三个参数的关系，KDTS 的参数说明里写得很直白。内存占用等于并发数乘写缓冲大小。我第一次看到就笑了，敢把算式写出来的产品不多。调大提交量，提交次数少，吞吐上去，但事务边界变粗，回滚代价变大。调小，安全和吞吐反过来。这个零件没有标准答案，只有匹配。

这里最容易被忽略的是顺序。搬得再快，事务顺序乱了，业务看到的就是错账。产品有没有把「按提交顺序重组」做进内核，比参数能调多大重要得多。KFS 在这点上是端到端保事务完整性，跨库落地也按源端提交顺序。这一条不写在参数表里，只在出账那天见分晓。

六、零件五：校验与修复，能收尾的那个零件

前四个零件决定数据搬得快不快。这个零件决定你敢不敢签字。我在两个项目里见过同一种场面，迁移做完了，业务说数不对。然后一群人写 SQL，一边源库，一边目标库，一条条比。这种活不证明能力，只消耗耐心。成熟产品会把这件事做成功能，一般分三层。

关键是比对时业务要不要停。要停的，就只能夜里做，做完发现问题也来不及。不停业务也能比对的，才能当日常手段用。真到项目上，我最后是靠产品自带的能力收尾的。查差异、补差异在同一个界面，再挂个定时任务，出差异自动发邮件，值班的人不登录也能看到。金仓这一支也是这个路数，比对和修复在产品里，KFSMC 负责把差异推到人手上。这类能力写不进 PPT，但它决定我下班后能不能睡整觉。

七、零件六：调度与管控，值班的人靠它

最后一个零件，标书里通常一句话带过：提供可视化管理界面。真到生产，它管的是四件事。链路在不在跑。延迟多少。出问题告警发给谁。升级补丁谁来打。我见过最贵的教训，是链路停了三天没人知道。不是没监控，是告警发到了一个离职同事的邮箱。所以这个零件，我会问三个细节。告警能不能精确到链路和表。位点漂移有没有视图看。部署、启停、升级是不是一个界面做完。

这些事听着琐碎，验收时却很好判断。让实施方把管理界面打开，从建链路、看延迟、改告警接收人，到打一次补丁，全程你自己操作一遍。入口齐的产品，交付后团队接得住；入口散在文档和脚本里的，每次升级都得找原厂。金仓这套 KFSMC 就是按这个思路做的，部署、评估、启停、告警、升级都在一个界面里。六个零件说到这里就齐了，下面拼起来看。

八、六个零件拼成一张数据集成产品验收表

把上面的东西合起来，我给一份可以直接带去评审的对比。纵向是六个零件，横向是四种常见形态。四种形态没有谁更先进，只有谁更适合你的链路构成。配错了对，哪一边都费劲。

看这张表的方法只有一条。每一格都要能对应一个现场动作，对不上的格子等于没写。比如「内置比对与修复」这一格，动作就是让实施方跑一次不停业务的比对。除了表里这些，验收时我还会追问四件事。这条链路出问题多久能发现，答案若是「用户反馈」，直接扣分。数据对不上，工具能不能指出差异行，只能给总数的等于没做。源端改表结构，链路会怎样，要手工改配置的，运维成本会翻倍。这套东西三年后还有没有人维护，产品在不在迭代，比参数多好看重要。

九、那次评审最后怎么定的

回到开头那个会。我花了三天做一件事，把26条链路摊开，一条条标注数据源和目标。结果很意外，26条里19条是数据库到数据库，4条是数据库到数据仓库，剩下3条是文件、接口和消息队列。这个比例一出来，答案就清楚了。

19条库到库的链路，不需要通用平台去兜。它们要的是位点、事务顺序、断点续传、比对修复，这些都在数据库侧产品的射程里。另外7条各有各的活。4条入库看重分析侧的吞吐，交给 KFS Ultra 那一支。3条文件、接口的源本来就不在库内，继续走原有采集通道，没必要为了它们换掉整条链路。这套数据集成产品的分工算下来，预算比最贵那份少一半多，比最便宜那份多不到两成。

上线三个月，最管用的还是校验和告警。源端改过一次字段，比对任务先报了差异，KFSMC 的告警邮件第二天早上就到，我们上班直接按差异行去查。这类事放在以前，只能等业务来问。那天我在笔记里写了一句。产品不是买最大的，是买最短的那条路。 路短，出问题时排查的面就小。

十、国产数据集成产品怎么挑

信创项目里，数据集成产品的国产化这一节基本是必答题。我的问法也是四件事，问完心里就有数。先问增量，国产库的日志解析支持到什么程度，是解析物理日志，还是只能靠时间戳字段。前者不改源库，后者源表没那个字段就干不了。再问适配，国产 CPU、国产操作系统、国产中间件，有没有现成的适配清单，别等实施时才发现驱动要现写。

接着问工具链是不是一家出的，评估、迁移、同步、校验、运维，是四家拼的，还是一家给的。四家拼的，出问题先开协调会；一家给的，一个电话找到人。最后问服务，谁做实施，谁值班，故障多久到场。这三条在信创项目里，比参数表上多两个连接器实在。

金仓这四问答得比较齐。评估有 KDMS，迁移有 KDTS，增量有 KFS，校验和管控有 KFSMC。工具出自一家，字符集、驱动、升级节奏不用你自己对。适配清单是现成的，国内外典型 CPU 平台和操作系统都在列，国产化环境里少走一段弯路。

十一、数据集成产品和 ETL 工具、同步工具的区别

数据集成产品、ETL 工具、同步工具这三个词经常被混着用，评审会上最容易吵起来。先说 ETL 工具。它是数据集成产品里的一类，强在转换清洗和批量调度，落点是数仓、数据湖和报表。再说同步工具。它更像六个零件里的两三个，只管把变更搬过去，装载和校验未必包。

所以数据集成产品不等于 ETL 工具，也不等于同步工具。判断方法很简单，看它管不管「搬完之后」。管，就是产品；不管，就是插件。这个区别在选型时不显眼，在出账那天特别显眼。

十二、数据集成产品常见问题（5 问）

问：数据集成产品和 ETL 平台哪个好。答：不是二选一。链路以库到库为主，数据库侧产品更短；链路跨文件、接口、消息队列，平台更全。两类拼着用，是这两年被验证得最多的做法。分不清的时候，先数链路，再谈产品。

问：增量是不是就等于实时。答：不等于。有的产品增量是分钟级拉一次，要亚秒级得日志级解析。这两个词在验收报告里必须分开写，写混了后面全是扯皮。我们内部的验收模板，这两栏一直分成两行。

问：一套要多少钱。答：计价口径有三种，一次性买断、按链路数、按数据量。口径不同，报价能差一倍。谈之前先问清是哪一种，再谈折扣。预算批下来之前，先把链路数量估准。

问：一定要买数据集成平台吗。答：不一定。库到库的链路占多数时，用数据库侧产品更省，位点、顺序、校验都在射程里。跨源多、要 API 服务的，才轮到数据集成平台上场。先算比例，再定形态，别倒过来。

问：上线以后谁维护。答：看第六个零件。告警能不能到人，位点有没有视图，升级谁打补丁。这三件事没落实，产品再好也会烂在值班表上。签约前把这三条写进验收条款，后面省很多事。

十三、避坑清单

数据集成产品的坑，清单不长，三条，都是我自己或同事踩过的。先说比价，我见过按连接器计价的产品，POC 时四条链路很便宜，上线涨到二十六条，授权费翻了三倍。谈合同时先问清计价的口径，是一次性、按链路、还是按数据量。再说校验的时机，它不是验收动作，是日常动作，上线前没跑过全量比对，等于没验收。我们后来定的规矩是，割接前一晚必须跑一次全量比对，差异行清零才允许切。

还有一条是我最近才想明白的。别让集成产品和你的数据库变成两家人。两者不同源，驱动、字符集、类型映射、升级节奏全都要自己对一遍。数据库小版本升级，集成产品要不要跟着升，没人问，但它每年都来一次。这条我吃过亏，一个字符集配置让两条链路的数据多了半个空格，对了三天才查出来。所以选型时多问一句：这套工具和目标库是不是一家出的。

写在最后

回到那个问题，数据集成产品有哪些、该怎么选。答案分两步。先认形态，四类各有各的射程。再拆零件，多数方案在比前四个，项目真正翻车往往在后两个。金仓这一支让我印象深的地方，也正好在后两个。日志解析解决的是「从哪儿接着来」，比对和修复解决的是「错了怎么收场」，这两件事都落在产品里，不用你再拼一套脚本。

再往外看一层，它不止一个产品。往下是 KDTS 管迁移，中间是 KFS 管库到库的增量，往上是 KFS Ultra 接数仓、湖仓和多云，日常那层的部署、告警、升级交给 KFSMC。记成一句话：库到库交给 KFS，入湖多云交给 KFS Ultra，迁移交给 KDTS，日常盯着 KFSMC。四个产品各管一段，拼起来才是完整的集成能力。信创环境里还有一层方便，这些工具和 KES 出自同一家，驱动、字符集、升级节奏都好对齐，省的是逐个对齐的功夫。

你们那套集成方案，是平台为主，还是数据库侧产品为主？评论区聊聊，我看看有没有更省的路子。要是正卡在选型阶段，把链路构成说一句，我帮你算该配哪类。留言里最典型的那套，我下篇单独拆。

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