用了三年数据同步软件，我想好好聊聊KFS这套东西到底强在哪（上）

兼容是对前人努力的尊重是确保业务平稳过渡的基石然而这仅仅是故事的起点

标题党一下，但内容不糊弄。

干这行久了，"数据同步软件"这四个字我是真听麻木了。早年干项目，业务部门一句话------"把A系统的数据弄一份到B系统"，听着简单吧？实际能把人折腾死。我最早就是写脚本，写个存储过程定时抽数，或者干脆exp/imp手工导。那时候不觉得有啥问题，直到有一次，财务月结，我导数据导了一晚上，第二天早上对账差了几万块，全公司就等我一个人找原因。找到最后发现是中间源库又写进去了一批，我的快照是凌晨两点的，人家三点还在下单。

从那以后我就认准了，数据搬运这事儿，靠人、靠脚本、靠定时批处理，迟早出事。后来接触了CDC这一类实时同步的产品，再后来项目里开始大规模用KFS，算是把这条路走明白了。这篇不写某个具体功能怎么调（前几篇我写过并行、写过校验、写过目标端入库），这篇想站在更高一点的角度，把这套数据同步软件的"产品力"拆开揉碎聊聊------它凭什么能干那些脚本干不了的活，凭什么能对标OGG。

还是老规矩，想到哪写到哪，可能有点乱，你们将就看。

先说说我对"数据同步"这件事的理解变迁

这个话题我得多说两句，因为我发现很多人对同步软件的认知还停留在我十年前的阶段。

最早大家怎么做数据交换？ETL。抽、转、载，定个时，比如每天凌晨跑一轮。这个模式在那个年代是够用的，因为业务对时效性没那么敏感，T+1甚至T+2都能接受。但现在不行了，你搞个实时大屏，数据滞后一天，那大屏放那儿就是个笑话；你做容灾，RPO要求秒级甚至零丢失，批处理根本不可能满足。

所以后来才有了CDC，变更数据捕获。这东西的核心思路转变特别关键------从"定时把整张表捞一遍"，变成"我盯着数据库的日志，你每提交一个事务，我立刻就知道"。这个转变，我个人觉得是数据集成领域这些年最有分量的一次范式转移。早期业界围绕CDC其实有过不少争论，一拨人觉得日志解析侵入性太强、跟具体数据库版本绑定太死，不如触发器或者查询列来得通用；另一拨人则坚持日志捕获才是唯一对生产零干扰的路子。吵了好几年，最后是现实投票的------凡是上了规模、对延迟敏感的场景，几乎清一色倒向了日志解析。因为触发器要改表结构、对写入性能有损耗，这个在核心系统上根本没法接受；而基于更新时间戳轮询的方案，删数据抓不到、中间状态也抓不到，硬伤太明显。

KFS就是站在日志解析这条路线上的。我翻资料的时候注意到一个说法，它是基于增量日志解析技术做的，特点是性能高、时延低、资源占用少。这几个字看着像宣传语，但你们看完后面就知道，每一个词背后都是有具体东西撑着的。

日志解析到底是个啥，为啥说它"资源占用极少"

不搞技术的可能对"解析日志"没概念，我打个比方。

数据库干任何修改，为了崩溃了能恢复，都会先把"我要改什么"写进一个日志文件（Oracle叫redo，MySQL叫binlog，各家叫法不一样，原理相通）。这个日志本来就是数据库必须写的，不是为同步软件额外生成的。CDC软件要做的，就是蹲在旁边把这个日志读出来，还原成一条条的插入、更新、删除操作，再搬到目标库。

异构，异构，异构------重要的事说三遍

光能读日志还不够，真正难的是异构。

你想想现实里一个稍微上点规模的单位，IT系统是怎么长出来的。ERP可能是十几年前上的Oracle，财务系统是SQL Server，新搞的互联网业务用MySQL，后来信创又上了国产库，再有一堆历史遗留的Sybase、DB2......这些库的数据类型不一样、SQL方言不一样、事务模型不一样、日志格式更是天差地别。数据同步软件要是只支持一两种源，那基本没法在这种客户那儿立足。

这是我觉得KFS产品力里最硬的一块------源端支持得是真全。资料里说支持30余种数据源，国内外常见的都能接。我自己项目里实际碰到过的Oracle、SQL Server、MySQL、国产那几家主流的，都没问题。而且它不光能把国外库同步到国产库，国产库之间、国产库作为源往别的地方送，这些方向都能走。

异构最难啃的是数据类型和语法的转换。这个我在上一篇讲目标端入库的时候提过一嘴，这里展开说。举个最简单的例子，Oracle的NUMBER类型是个"万能类型"，精度标度都可变，迁到别的库到底映射成INT、BIGINT还是DECIMAL，得看实际定义；再比如SQL Server的DATETIME和别的库TIMESTAMP的精度范围差异，字符串空值和NULL的语义差异，这些坑一个接一个。

sql 复制代码

-- 源端 SQL Server 的写法
CREATE TABLE orders (
    id BIGINT IDENTITY(1,1) PRIMARY KEY,
    remark NVARCHAR(500) NULL,      -- 允许NULL
    created DATETIME DEFAULT GETDATE()
);

-- 目标端 KES，IDENTITY得换成序列/自增，函数也不同
CREATE TABLE orders (
    id BIGSERIAL PRIMARY KEY,
    remark VARCHAR(500) NULL,
    created TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

这种结构层面的差异，成熟的同步工具会在初始化阶段自动做类型映射，再配合迁移评估工具（KDMS那一套）提前标出哪些对象不能自动转。我前面写KDMS的文章时讲过，自动化转换率能到百分之九十几，但总有那么百分之几的尾巴要人去收。KFS在运行期负责实时数据这条链路，结构和应用改造是另一条线，两条线配合着来，这点我后面还会提。

再说说语法和函数。异构同步不只是搬数据，很多场景中间还要做转换、过滤、计算。KFS有自己的一套表达式和映射配置，能在同步过程里做字段拼接、类型转换、条件过滤。我写个示意：

javascript 复制代码

// 同步映射的伪代码，感受一下能在链路里干啥
TABLE_MAP:
  source:  src.orders
  target:  dwd.orders_detail
  FILTER:  order_status != 'TEST'          // 测试单不要
  COLUMN:
    full_name = CONCAT(first_name, ' ', last_name)
    amount_yuan = amount / 100             // 分转元
    etl_time   = NOW()

能在管道中间做ETL这件事很重要，它意味着数据到了目标库基本就是干净的、可用的，不用再倒一手。当然啦，别拿它当完整的ETL平台用，复杂的多表关联、窗口计算还是得专业的数据集成工具干，它的强项是"轻量级转换+实时搬运"。这个边界我得说清楚，免得有人期望错位。

拓扑能任意组合，这个在实际项目里太重要了

很多人理解同步就是"A库搬到B库"，一对一。真到了企业现场，一对一远远不够。

我把资料里列的几种拓扑结合实际给你们讲讲。

第一种，一对多，实时分发。典型场景是总部一套核心库，要把数据同时发给好几个分支机构、好几个下游系统。你要是建N条独立链路，源库压力和运维成本都得翻N倍；好的同步软件支持一份日志、多路投递，源端只采一次。

css 复制代码

              ┌──→ 分公司A库
总部核心库 ──→ ├──→ 分公司B库
  (一份采集)   ├──→ 数据分析平台
              └──→ 灾备库

第二种，多对一，实时汇聚。这个这几年特别火，做数据中台、数据湖的刚需。N个业务系统（交易、订单、用户、库存......）实时往一个分析型大库里灌，上面再接BI、接治理平台。我之前文章里写过的那个医疗云汇聚，几十个医学中心的HIS、LIS、电子病历数据全汇聚到数据仓库，就是典型的多对一。

第三种，级联。先汇聚再分发，或者A到B、B再到C，一层层往下传。资料里的原话是拓扑可以一对一、一对多、多对一、双向为基础任意组合、无限延伸。"无限延伸"这词有点大，但意思我懂------就是链路能像搭积木一样接起来。

scss 复制代码

各交易系统 ──→ 汇聚库 ──→ 总部分发库 ──→ 多个区域库
(多对一)        (级联)        (一对多)

这里面有个特别要命的技术点：事务一致性。数据可以乱序搬吗？不行。你想，源库一个事务里同时插了订单主表和订单明细，要是目标端明细到了、主表没到，中间这一瞬间查出来的数据就是"脏"的；更别说外键约束直接给你报错。所以KFS强调端到端的事务级完整性，意思是源端一个完整事务，到目标端要么整体提交、要么整体不提交，不会提交一半。在多通道并行的场景下保证这个，技术上是有难度的（我下篇讲路由的时候会再展开），但它必须做到，否则实时同步就是制造数据混乱。

给你们看个一对多投递的简化配置：

properties 复制代码

# 一份源端采集
[extractor]
source = oracle_prod

# 多路目标端投递，共用同一份捕获
[applier_dr]      # 灾备
target = kes_dr

[applier_dw]      # 数仓
target = dw_cluster
filter = active_only

[applier_branch]  # 分支机构
target = kes_branch

亚秒级延迟是怎么做到的，顺便聊聊它和OGG的定位

延迟这块，资料给的是"亚秒级"。我不纠结这个数字在极限压测下是多少毫秒，我更关心稳态下它靠什么机制把延迟压住。核心就三点：一是日志是顺序读、持续推送，不是定时轮询，事务一提交很快就能被捕获；二是中间靠消息队列/流水线解耦，采集和入库各跑各的，互不阻塞；三是目标端并行入库（这个我专门写过一篇，批量提交、多通道路由那一套）。三段都快，端到端才能压到亚秒。

定位上，我看FAQ里写得很直白，KFS就是对标OGG的。这话怎么理解？OGG（Oracle GoldenGate）在同步这个领域是老牌强者，金融、运营商里用了很多年，能力确实强，但问题也明摆着------贵，而且国产化这波浪潮下，国外软件在信创场景里天然受限。KFS想做的，就是在能力上对齐OGG这一档，同时补上自主可控、对国产源端支持、成本这些OGG的短板。

不过我个人有个不一定成熟的看法：对标不等于处处一样。OGG这么多年沉淀下来，在一些极端异构组合、极老旧版本兼容、超大客户复杂拓扑上的积累，是靠时间和无数case喂出来的，国产产品要全面追平需要时间和项目历练。但反过来说，在"国产库作为源/目标""国密合规""本地化服务响应""成本"这些维度上，OGG反而是劣势。所以选型不是简单的谁替代谁，而是看你场景的天平往哪边倾。这个话题我下篇对比竞品的时候会详细说。

几个典型场景，对号入座看看你在哪个里

聊了这么多技术，落回到场景。资料里归纳的场景我结合自己经历给你们过一遍，你们看看熟不熟悉。

平滑迁移+双轨并行。 这个是信创项目里最常见的。老库要换国产库，但业务不能停。KFS在老库和新库之间架一条实时链路，老库全量初始化过去之后，增量持续追平，等两边数据完全一致了，挑个业务低峰把应用切到新库。资料里有个比喻我特别喜欢------"就像给一辆飞驰的汽车更换轮胎"。更妙的是双轨并行，切过去之后链路别拆，反向也留着，万一新库出问题，随时能切回来，这就是给了一颗"后悔药"。这种"可回退"的设计，在迁移项目里价值怎么强调都不过分，因为它直接决定了领导敢不敢签字割接。

实时容灾备份。 同城、异地，同构、异构，单活双活多活。这个不用多解释，核心系统都得有。KFS这套日志级实时同步，RPO能压到很低，比传统的存储复制、定时备份强在它是逻辑级的、能做到异构。

实时集成。 就是前面说的分发、汇聚、级联，喂数仓、喂数据中台、喂下游业务系统。

我自己感触最深的是第一个。干迁移最怕的不是技术难，是"停机窗口"这四个字。以前没有实时同步工具的时候，迁移就得停机，停机时间=全量数据导出传输导入的时间，库大一点就是一整个周末甚至几天，业务部门脸都绿了。

1套管理平台能下辖好多个源端和目标端。

scss 复制代码

                    ┌── KFS 源端A (Oracle)
                    ├── KFS 源端B (MySQL)
KFSMC 管理平台 ──── ┤
  (一套管全部)       ├── KFS 目标端X (灾备库)
                    ├── KFS 目标端Y (数仓)
                    └── ...
        统一监控 / 告警 / 启停 / 升级

资料里原话是"可视化快速部署""全生命周期管理"。我理解这背后其实是降低了使用门槛和运维成本。一个产品再强，如果只有原厂专家能玩转，客户自己的运维团队接不住，那交付完就是个烫手山芋。图形化部署加监控，至少让客户自己的人能看得懂、管得住，这个对产品能不能真正落地、能不能规模化很关键。

说到规模化，我看到一组数字挺有说服力------这产品从诞生到现在规模化交付了5000多套，服务了500多家客户。这个量级意味着它不是实验室产品，不是只在三五个标杆客户那儿跑过的demo，而是经过了大量真实环境、各种奇葩组合捶打过的。同步软件这种东西最怕没见过的极端case，而case只能靠装机量去喂。客户名单里还有人民银行征信中心、国家外汇交易中心、国家电网、南方电网、三大运营商、中石化中海油、一汽这些，金融、能源、电信这种对稳定性最挑剔的行业都在用，分量你们自己品。

再顺带说个技术文章里很少有人讲、但真选型时绕不开的问题------这东西怎么卖、怎么买划算。我是项目里真参与过报价才搞明白的，分享给你们，免得被商务绕晕。

KFS就三个组件：源端、目标端、管理平台。报价单位是参与同步的源物理实例量，有数据流出的算源端，有流入的算目标端。比如系统A（Oracle）和系统B（MySQL）往系统C（国产库）汇总，那就是2个源端加1个目标端，共3套。管理平台单独算，1套能管下面一堆源和目标。

scss 复制代码

A(Oracle) ──┐
            ├──→ C(国产库)   → 源端2个 + 目标端1个 = 3套
B(MySQL) ───┘                  KFSMC管理平台 1套（按需）

授权分永久和订阅（按年）两种，订阅价大概是永久价的三分之一一年。这个区分我觉得挺合理：你要是长期实时集成、长期容灾，链路一直要跑，买永久；要是就为一次平滑迁移加双轨并行，或者短期做一轮校验修复，用完就拆，那订阅划算多了。我见过有客户迁移项目非买永久，结果割接完链路一拆，授权搁那儿吃灰，纯浪费。