手头那批同步任务终于可以重新选型了。过去两年我把它们堆在一条比较重的实时链路上Flink CDC 从 MySQL 抓增量先进 Kafka再做几层转换落到数仓。数据量不算大但这套链路里光是常驻组件就有小十个大多数时候都在空转。所以这次整理 2026 年这轮方案时我给自己定的标准很简单能在单机或一两个进程内跑完的就不上集群能用定时任务解决的就不用常驻服务能靠数据和位点恢复的就不依赖复杂运维面板。这篇主要是把“轻量级 CDC 与流处理”的选型思路记录一下包括我实测下来比较顺手的组合、国产数据库环境的适配经验以及踩过几次坑后总结出的判断框架。如果你团队里没有专职流平台或者你只是想在业务代码旁边搭一条不喧宾夺主的增量同步管道这轮盘点会比较对胃口。1. 先把语境对齐同样叫 CDC数据工程师和嵌入式工程师聊的不是一回事1.1 同名概念的“撞车”现场上个月我在即时通讯软件里发了一条消息说“CDC 那边延迟有点高”旁边嵌入式组的同事立刻回了一句你们在做 USB Device当时沉默了几秒钟然后两个人才发现谁都没听懂谁。这个场景在 2026 年一点也不罕见。搜索框里敲 CDC返回结果至少有三个完全不同的技术语境数据工程语境Change Data Capture变更数据捕获把数据库的增删改操作抓出来变成事件流。嵌入式/接口开发语境USB Communication Device Class通信设备类协议。那些搜“STM32F103 CDC 多串口编程”“STM32 HID CDC 复合设备 Cubemx”的工程师在做的是端点描述符和接口枚举处理的是设备驱动与硬件通信。数字逻辑设计语境Clock Domain Crossing跨时钟域。芯片工程师关心的是亚稳态、同步器、FIFO 设计和数据表变更没有关系。还有一个容易混淆的角落OpenCV 相关开发里会出现cdc::drawtext这样的字符串视觉算法工程师理解的 CDC 可能是某个函数命名空间。人和人之间技术栈差距可以非常大但这几个圈子不会同时出现在同一篇技术文档里。1.2 数据工程语境下的 CDC 到底是什么收窄回数据同步这条线。Change Data Capture 的核心思路是不去频繁全表扫描而是直接读取数据库日志或系统提供的变更接口把每一笔插入、更新、删除翻译成一条带结构信息的变更事件。不同数据库提供的能力路径不太一样MySQL 走 binlog。最常用的是 row 格式binlog 里记录每行变更前后的完整映象。PostgreSQL 走 WAL 与逻辑复制。发布订阅机制可以把表的变更推给订阅端。SQL Server 有内置的 CDC 机制通过系统表记录变更Oracle 则可以通过 LogMiner 或第三方解析日志。像达梦、人大金仓这类国内数据库环境适配逻辑就更需要先确认日志接口和兼容模式后面我会单独展开。所以当我们在谈“轻量级 CDC 与流处理”时真正谈的是这样一条链路源库日志产生变更事件采集端解析事件中间可能做过滤和格式转换最后进入目标库或流处理端。采集只是起点后面每一步都可能成为坑。开始选型之前我建议做任何搜索时都养成一个习惯不要把 CDC 当成独立关键词往前或往后加限定词。找数据同步方案就写“Debezium CDC”“Seatunnel 达梦 CDC”“Flink CDC 选型”找嵌入式内容就写“USB CDC 驱动”。搜索引擎不会替你判断语境只有限定词能帮你把不同圈子的内容隔开。2. 轻量级不是“功能弱”而是把资源花在真正需要的地方2.1 先看看重量级方案是怎么变重的我过去维护的那套链路严格来说是从很朴素的需求长出来的MySQL 里的订单表产生变化希望几分钟内同步到分析库。最初方案看起来也很简单Canal 监听 binlog投递到 Kafka再让 Flink 消费。可是等这套东西真正跑起来日常需要照顾的组件变成了Kafka Broker 少说两个节点算上 ZooKeeper 或 KRaft 模式下的控制器Canal 的 server 和 adapterFlink 集群的 JobManager 和 TaskManager外部化的状态后端存储用于监控的 Prometheus、Grafana 和一堆告警规则。到了这一步哪怕原始需求只是同步几十张表你已经默认背上了一个“小平台”的运维负担。而大部分时间这些组件的资源利用率都很低。2.2 轻量级方案的三种常见形态我理解中的轻量级不是把所有功能塞进一个进程而是砍掉与核心需求无关的组件让复杂度降到一个人能扛住的程度。当前生态里常见的轻量形态有三种第一种嵌入式引擎。典型代表是 Debezium 的 Embedded Engine。它把自己作为库集成进你的 Java 进程应用启动时同步启动源库监听不需要部署 Kafka Connect 集群也不需要单独管理 connector 的 REST API。适合的场景是业务服务里有一个明确的后台任务比如订单变更后同步到缓存或搜索索引。第二种批流一体的工具但只跑本地模式或单机模式。Seatunnel 这类工具给人的第一印象往往是“数据集成平台”但它同样可以只作为命令行任务运行启动时读取配置执行完同步后进程退出或者在一个常驻服务里按调度周期执行 job。对大量“周期增量同步”的需求来说这远比维护一套常驻采集集群合适。第三种纯轮询或定时脚本。通过记录源表更新时间戳或自增主键来抓增量。本质上不是标准意义上的 CDC因为它读不到被删除的行但在某些无法开放日志权限的数据库场景里这是最现实的手段。后面讲达梦、人大金仓适配时会再提到它。2.3 什么情况才真正适合轻量级判断该不该走轻量路线不要凭感觉可以先回答下面几个问题数据量级单表日增百万级以下还是千万级以上延迟要求目标是秒级延迟还是分钟级甚至小时级容忍度下游复杂度只需要把变更落到另一张表还是需要做复杂窗口聚合、多流 join运维资源团队有没有专职实时计算开发出问题时是否有人能在半小时内定位如果答案偏向“日增可控、延迟要求不极端、下游是库到库同步”那轻量级方案通常完全够用而且恢复起来比大集群快得多。真正不适合轻量级的场景也有比如需要支撑实时大屏的秒级指标、需要跨多源做实时宽表 join、单表日变更量过千万并伴随超大事务。这类需求还是老老实实走集群化路线别为了省事把核心业务放到单机上赌运气。3. 实测下来比较顺手的几套轻量级 CDC 与流处理组合3.1 Debezium Embedded Engine适合“寄生”在业务进程里的采集方案我对 Debezium 嵌入式引擎的评价是如果你能接受 Java它是目前把“资源占用”压到最低的成熟方案。它不需要独立部署而是作为一个库和你的业务应用共存。一个最小化的思路大概是这样通过DebeziumEngine构建一个变更消费者传入 MySQL 连接信息和需要监听的表在回调里把每一条SourceRecord转换为目标结构再交给后续处理。启动引擎后它会在内部完成一致性快照和增量监听两个阶段。我把一个简化骨架写在这里帮助理解DebeziumEngineChangeEventString, String engine DebeziumEngine.create(ChangeEventFormat.of(Connect.class)) .using(props) // 包含连接信息、表白名单、offset存储配置等 .notifying(record - { // record.value() 里可以拿到 before/after 结构 // 在这里做类型转换、过滤然后写到目标端 }) .build(); // 建议用独立线程启动避免阻塞业务主流程 CompletableFuture.runAsync(engine);使用嵌入式方案时有几个细节必须提前想明白引擎运行在业务进程里如果业务 JVM 因为 Full GC 停顿或重启同步任务会跟着受影响。所以它适合作为后台辅助任务不适合承载那种需要专门 SLA 的实时管道。offset 存储需要显式配置比如写到本地文件或数据库表否则重启后会从头开始或重复消费。下游写入必须做幂等。至少要用目标表主键做覆盖更新避免重复事件造成脏数据。3.2 Seatunnel 本地模式库到库同步里的“轻骑兵”遇到“源库到目标库搬运、不要常驻大集群”的需求我最近使用最多的是 Seatunnel 的本地运行模式。它的任务通常被定义成一个配置文件包含 source、transform、sink 三段。source 负责指定从哪里读比如 MySQL 表或 JDBC 查询transform 负责做字段映射或简单清洗sink 指定目标库连接和写入模式。以本地模式执行时任务跑完进程就退出也可以由调度系统按固定间隔拉起。对于真正的 CDC 增量同步场景Seatunnel 也支持从 binlog 或日志接口读取变更但不同小版本的配置字段和连接器名称会有差异所以我建议在搭建链路时先在测试环境打一个小版本快照确认配置项再上生产。它吸引我的一点是任务终止后不会像常驻任务那样留下一个“不知道状态对不对”的进程你可以随时重新执行从保存的位点恢复。需要提醒的是本地模式依然会占用运行节点的 CPU 和内存。如果源表变更量很大又要求分钟级同步建议给它配一个独立的小规格实例不要和线上业务服务混部。否则一次大事务解析就可能把业务 CPU 打满。3.3 Flink CDC Local 模式只适合少数需要状态计算的场景很多人问Flink CDC 能不能本地单机跑能但我不太建议为了单纯同步去这么干。Flink 体系的真正价值在状态管理和流式计算能力比如用窗口统计五分钟内的订单量、把订单流和商品流做实时 join。如果你的需求只是把 MySQL 的几张表原样搬到 PostgreSQL用 Flink 属于拿大炮打蚊子部署、checkpoint、savepoint、资源隔离的成本比功能收益高得多。我会推荐使用 Flink CDC 的典型场景是同步进来的数据不是直接入库而是需要先清洗、关联、聚合形成实时指标后再写下游。这个时候再考虑 Flink 的单机或集群模式才有意义。否则直接用嵌入式 Debezium 或者 Seatunnel 会更省心。3.4 轻量流处理侧从流数据库到单节点事件流在 CDC 事件落地之后另一个经常被讨论的问题是下游怎么对事件流做低延迟处理如果不想引入完整 Flink 集群可以关注两类轻方案一类是支持单机部署的流数据库比如 RisingWave。它能直接用 SQL 定义物化视图消费来自 Kafka、PostgreSQL、MySQL 等源的事件流计算逻辑写在标准 SQL 里运维负担比 Flink 小不少。单机跑一些中小规模实时指标完全够用。另一类是当事件已经进到单一节点 Kafka 后用轻量流处理引擎做过滤和转换比如 ksqlDB。它的部署形态相对简单SQL 表达力也不错适合“入 Kafka 后再洗一遍”的管道而不是从零开始设计一个流平台。我做个简单对比表格方便你快速判断组合常驻资源外部依赖最适场景Debezium Embedded Engine 自定义代码1 个 JVM 内嵌源库、offset 状态存储业务代码后台同步缓存/搜索索引更新Seatunnel 本地模式 调度任务结束进程退出源库、目标库库到库周期/增量同步批量数据搬运Flink CDC Local至少 1 个常驻 JVMcheckpoint 存储需要状态/窗口计算的实时逻辑单机 Kafka ksqlDB / RisingWave2-3 个进程消息队列事件过滤、轻量流式计算、实时物化视图4. 当源库换到达梦、人大金仓这类环境适配思路也跟着变4.1 现实环境比开源生态文档残酷得多近两年企业内部做数据库替换的情况越来越多我接到过不少“Seatunnel 接达梦 CDC”“Kingbase 做增量同步”的咨询。这类需求最大的特点不是技术本身有多难而是参考资料少、踩坑经验基本靠群里口口相传。MySQL、PostgreSQL 的开源生态很成熟社区文档、Issue、示例遍地都是。但到了达梦、人大金仓这些环境你会发现很多通用工具并没有官方级别的 connector 支持。遇到这种情况第一步不是直接找工具链而是先搞清楚三件事这套数据库的日志/变更捕获接口是否对外开放文档怎么描述它是否提供兼容模式比如某些产品线为了迁移便利支持兼容 Oracle 或 PostgreSQL 的日志接口这意味着你有可能复用对应生态的解析工具。当前账号有没有读取日志或建立逻辑复制所需的权限把这三件事确认完再决定技术路线能省掉后面大量无头苍蝇式排查。4.2 Seatunnel 接达梦这类场景的常用落地做法我没有办法在这里写出一个放之四海皆准的配置因为不同达梦版本、不同表结构、不同权限配置都会影响最终写法。但我可以分享一条我实测过多次、相对稳妥的路线。如果目标业务对实时性要求不高允许几分钟甚至更长延迟最稳的组合是“JDBC 增量查询 定时调度 位点记录”。思路是表里如果有自增主键或最后更新时间字段把它们作为增量游标每次任务启动时从状态表读出上一次同步到的位置执行查询只取增量部分写入目标端后更新状态表。这种做法的缺点是读不到物理删除业务上如果有删除操作需要同步就得配合软删除标记或者在源库端建立删除日志表由业务方在删除时写入一条标记记录。它虽然不优雅但胜在可控、不依赖厂商日志格式的稳定性。如果确实需要更实时、能感知删除的日志级同步就要回到日志接口这条路。以我目前的经验这种场景非常依赖源库版本与工具版本的匹配情况建议先用生产同版本搭建一个测试实例把日志归档开关打开再用你选中的工具链做一轮模拟写入和删除的验证。不要直接在生产库上试错。4.3 人大金仓 Kingbase 的兼容性红利与限制Kingbase 环境里我也被问到过很多次“能不能像 PostgreSQL 一样做逻辑复制”。答案是看具体版本和授权形态。部分 KingbaseES 版本为了兼容 PostgreSQL 生态会提供类似逻辑解析的能力这让 Debezium 的 PostgreSQL 连接器存在一定的复用可能。但从开源工具的角度看不能假设所有版本都开放了同样的接口。部署前至少要做两个检查数据库参数里有没有开放逻辑复制所需配置以及账号是否具备相应角色权限。如果这两项都满足可以尝试走 PostgreSQL 兼容链路如果有限制就退回 JDBC 增量轮询方案。我的原则是在国产数据库这类资料稀缺的环境里能用标准 SQL 解决的问题就不要赌私有日志格式的稳定性。你永远不希望同步任务在凌晨两点挂掉然后发现没人知道这个版本的日志解析行为。4.4 每次适配前先写一份“环境确认单”从踩过的坑里提炼出来的小建议做国产数据库 CDC 适配之前先整理一份环境确认单包含数据库产品名、版本号、部署方式、日志相关开关、账号权限清单、目标端版本。不同人说的“达梦”可能完全是两个形态没有这份单子讨论问题就是在猜谜。5. 位点、DDL、大事务轻量方案最常见的三个翻车现场5.1 增量位点管理是轻量方案的第一道生死线“轻量”带来的最大错觉是组件少了稳定性自动就高了。实际上恰恰相反组件少了原本由框架帮你兜底的工作现在要自己负责了。最典型的就是增量位点管理。我见过不止一次这样的场景一个人用 Debezium 嵌入式引擎写了同步任务重启后发现目标库多了一堆重复数据原因就是 offset 存储配置没落到持久化存储上进程重启后只能从旧位点重新读。还有一个相反的问题业务处理完但 offset 提交太早处理过程中崩溃重启后位点已经越过崩溃时的数据部分记录永久丢失。这里最重要的是想清楚三件事offset 存哪里什么时候提交重启后从哪里恢复不同框架的机制不完全一样但只要你把这三个问题写进设计文档把提交动作和数据处理动作的关系理顺就不会出现最糟糕的“丢数据”或“爆量重复”。目标端的写入也应尽量幂等。最通用的方法是用目标表主键做 upsert这样即使重启导致少量重复消费结果依然正确。5.2 DDL 变更永远会打断天真的同步逻辑另一个高频事故是源表执行了 DDL。比如业务给订单表加了一个字段带默认值。如果下游表结构没有同步变更很多同步工具会直接报错更隐蔽的是有些工具按列位置而不是按列名映射加了字段后整行数据的值全部错位写进了错误的目标列。这类问题的盘查链路通常是这样先看同步任务日志里有没有 schema 相关报错再看任务内部维护的 schema history 是不是和源库结构一致最后对比源表和目标表的字段顺序。很多工具会把 schema history 单独记录在一个状态存储里如果这个存储被清理过就可能出现新旧结构不一致。我目前的处理策略是源表结构变更必须走变更流程先暂停同步任务、更新目标表结构、确认字段映射、再恢复任务。依赖工具自动处理 DDL 的方案不是不能试但至少要在测试环境完整演练一遍而不是上了生产才去验证。5.3 一个大事务就能让同步延迟从秒级拖到半小时还有一种情况很让人头疼日常运行一切正常某天延迟突然飙升。排查到最后往往不是工具坏了而是源库执行了一个超大事务。举个例子某项目的一次夜间批量脚本更新了三十万行数据。因为 binlog 日志里这个事务是一个整体CDC 任务从日志中解析时必须把整个事务的事件按顺序读完并处理目标端又是一个批次一个批次地提交处理这个超大事务期间后续所有变更全部堵在队列里同步延迟瞬间从几秒涨到几十分钟。等旧事务处理完延迟才慢慢回落。定位这类问题有个很实用的思路看到延迟突增不要只盯着消费端所在机器的 CPU 和流量先回到源库查这段时间有没有大事务、慢 SQL、大批量更新。找到责任事务后再决定是否需要对源库侧的大事务操作做拆分或者让目标端监控在出现超大事务时自动调整批次大小。轻量方案下没有调度中心帮你自动伸缩只能靠事前的任务设计和事后的监控报警把影响控制在范围内。5.4 运维再轻也得保留最少四个监控指标轻量方案不需要完整可观测平台但至少保留下面几个指标否则出问题时会连方向都没有监控指标来源建议关注点位点延迟源库日志/复制位点与当前消费位点差值延迟突然变大优先查大事务和网络消费失败次数采集任务日志持续增长往往代表解析或下游写入异常schema history 变化次数同步引擎状态存储排查 DDL 导致的问题时非常有用目标端写入耗时/成功率目标库连接池与写入日志目标库慢查询会反向拖垮同步任务这些指标可以用很轻的方式实现写日志、暴露 Prometheus 端点、或者定时发到内部监控系统不需要做一个大而全的平台。但如果没有它们位点偏移、事务堆积这类问题基本只能等业务方先发现那运维就被动了。6. 选型检验清单和一点长期有用的习惯6.1 把决策流程压缩成三段自问我最后做决策时会走一个很简化的流程分享出来当作可直接参考的清单。第一问需要的是“库到库同步”还是“实时计算”“实时计算”是消耗资源的大户。如果只是表结构搬运、字段映射、格式变更那就不要轻易引入流计算引擎。第二问团队愿意常驻维护几个进程一个 Java 嵌入式引擎、一个单机任务进程、还是一个单节点 Kafka把你能接受的常驻组件数量写下来写完之后你会发现很多“方案选项”会自动被排除。第三问源库的日志接口和账号权限是否可控如果不可控就不要强行追求日志级 CDC改用带更新时间字段的增量轮询方案。可靠性不一定差重点是边界清晰不会在半夜收到“解析日志失败”的告警。基于这套自问我给出的粗略推荐是这样的想在业务服务内做后台同步、更新缓存等优先考虑 Debezium Embedded Engine需要库到库定时或周期同步优先考虑 Seatunnel 本地模式加调度需要简单流式过滤和物化视图并且已有事件流入口可以评估 ksqlDB 或 RisingWave 之类的轻量流数据库需要状态窗口、复杂 join、实时指标再上 Flink且别用“单机本地模式”自我安慰它仍然需要专业的运维约束源库是非主流数据库且资料极少优先走 JDBC 增量轮询加删除标记先把业务稳定跑起来。6.2 长期有用的一项习惯是维护“表结构基线”从这么多年的同步任务维护经验里如果要我选一个最值得长期坚持的习惯我会说为每个接入 CDC 的库维护一份“表结构基线”文档。这份基线不需要多复杂包含每张表的源库名称、主键、需要的增量字段、目标端连接信息、DDL 变更负责人就够了。平时看起来不起眼但每次任务异常、每次新增同步表、每次数据库版本升级它都能救场。很多工具本身也会记录 schema history但你手头那份文档的价值在于它记录的是你们业务侧约定的语义不只是工具内部的元数据。做轻量级方案这几年我越来越倾向于一个观点轻量不是把组件做得更少那么简单而是把每个组件的作用、边界、恢复手段都吃透让系统的复杂度完全暴露在你能管理的范围内。数据库日志级 CDC 很强大但如果你解释不了它的位点文件里每一行含义那它就是不合适的JDBC 轮询很土但如果它在你需要的时间窗口内能稳定完成任务那它就是好方案。希望这轮盘点能帮你少走一些我已经走过的弯路。