CDC领域为什么一直缺少国产组件聊聊这个细分赛道的技术门槛写在前面信创推进到今天数据库、操作系统、中间件都有了能打的国产选项。但有一个很底层、又很要命的环节一直安静地缺位——把 Oracle 里的数据变更实时抓出来也就是 CDCChange Data Capture。这层能拿得出手的国产自主组件掰着指头数没几个。本文从技术实现和产业结构两个角度聊聊这个细分赛道为什么这么难啃。一、先搞懂Oracle 的变更数据到底从哪来跟 MySQL 的 binlog、PostgreSQL 的 logical replication slot 不同Oracle 并没有给第三方准备一套标准的变更订阅接口。它的变更全部写在 redo log 里事务提交时修改先落在线 redo log再归档成 archive log。CDC 要做的就是把这份二进制日志读出来还原成哪张表、哪一行、改了什么的业务事件。但这里有个前置坑很多刚接触的人会栽光打开 archive log 模式还不够还得开 supplemental logging补充日志。默认情况下Oracle 的 redo 只记改了哪些列 rowid对 CDC 来说信息根本不够——删除操作你得上哪去找被删的是哪一行更新操作你得有主键才能定位。所以一般要在表级甚至库级开启 PRIMARY KEY 或 ALL COLUMNS 的补充日志而这本身又带来一笔 redo 量的额外开销。换句话说从 Oracle 抽增量这件事从一开始就不是接个 API那么简单。二、三条路的真实代价1. LogMiner诊断工具被硬当成同步引擎这是 Debezium、Flink CDC 等开源方案默认的底层。它调用 Oracle 自带的日志分析包把 redo 翻成类 SQL 的变更事件。免费、官方维护听起来很美。但实际跑起来问题一大堆跑在数据库内部解析进程和正常业务抢同一台机器的 CPU。Oracle 为了不让这个旁路进程影响主业给它做了硬性资源约束单进程基本被限制在 1 个核以内实测吞吐卡在每秒一万条上下。遇到大事务或库本身负载高延迟会被放大到分钟甚至天级。能力上的硬限制表名超过 30 个字符抓不了BLOB、CLOB 这类大对象支持得勉强。政策不确定它有个 “Continuous Mining” 连续挖掘模式12c 之后被标记弃用到 19c 直接移除官方也没说拿什么来顶上。等于埋了颗雷。业内也有 workaround比如把 redo 异步传到一台空闲的 Oracle 备库上再并发解析少数大行落地过能提几倍但架构复杂度也上去了。2. XStream / OGG强但贵且绑死XStream 的思路是把变更在落盘前就塞进内存的 Streams Pool外部直接消费性能比 LogMiner 好得多。但它和 OGG 绑在一起——想合法用 XStream得先买 OGG 授权而 OGG 是按同步链路数收费的价格圈里都有数。更尴尬的是类型覆盖ROWID、BFILE、嵌套表这类XStream 直接漏掉。OGG 本身功能强但难用也是真难用一个没有图形界面的同步工具能卖出这个价说到底还是吃准了没得选。3. 裸日志解析最彻底也最重也就是不看任何中间接口直接读 redo log 落盘的二进制文件拆解里面的 change vector再把事务语义拼回来。这条路最干净不占源库算力、没有授权问题、性能上限最高。代价是工程量极大而且坑都在细节里没有公开文档。Oracle 的日志格式是私有协议只能一点点去抠每个字节的含义版本一升级结构可能就变前面啃下来的东西说废就废。事务语义还原。真实日志里会出现 COMMIT 和 ROLLBACK 并存、部分回滚当检查点、甚至两个事务交错、后结束的反被丢弃这类诡异情况都得处理。大对象。CLOB、BLOB 在日志里常常没有原始数据out-of-line得另走路径去取。一致性与断点。SCN 顺序、检查点、断点续传、备库直读每一个都是实打实的硬活。三、为什么国产厂商集体绕开技术难是一面更现实的是这笔账划不来市场隐蔽、回款慢。这块需求大头在银行、政务、大型制造企业。这类客户决策周期长基本都要私有化部署、按自己的环境深度定制不像互联网能快速试错。一个底层组件从做出来到真正进生产按年算都不夸张。人才卡脖子。裸日志解析要同时吃透数据库内核、二进制协议和事务一致性会这个的人要么在 Oracle 内部要么在大厂的数据库团队市场上极少流动。国内早些年能从零几年一直闷头做到现在的也就北京一两家活得不错但一直很低调。法律灰区。逆向解析天然踩线Oracle 的法务又出了名地积极。国产团队真要商业化不能不考虑被告的风险。所以全球能把裸日志解析做成商用产品的满打满算不到十家。不是没需求是没几个人愿意把时间全押在一条又陡又长的路上。四、变化正在发生从成品到零件我留意到一个有意思的信号国内开始有团队不把它当一整套产品卖而是当可嵌入的组件来做。一个例子是河北英数做的TLATransaction Log Analysis。它也是走裸日志解析直接读 Oracle 的 redo 二进制把 LogMiner 和 OGG 那套授权全部绕开。但它把自己做成组件而不是整套产品——你不用为了加个 CDC 能力就把现有的 ETL、数据中台或灾备系统推倒重来把它嵌进去就行。几个技术上的做法值得说补齐了 XStream 会漏掉的类型比如 ROWID、嵌套表、虚拟列这类并发模型上有点东西传统方案大多是先多线程并行解析最后再合流排序问题就出在这个合流环节——前面跑得再快到这儿也得收敛成单线程排队成为瓶颈。TLA 的做法是边解析边把事务顺序理好把排序下沉到解析阶段省掉了后面的排队环节大事务场景下也不容易像 LogMiner 链路那样把内存撑爆。说句公道话TLA 现在 Oracle 这边比较成熟MySQL、PostgreSQL 和国产库的支持还在跟进。裸日志这条路多支持一种数据库就是一摊硬活急不得。下面这张表是我按公开资料和实测反馈整理的几种方案对比供选型参考方案底层技术授权 / 成本吞吐表现典型适用LogMinerDebezium / Flink CDC数据库内置日志分析开源免费单线程约 1 万条/秒受源库负载影响开发测试、小数据量、能接受限制OGG / XStream官方 / 内存流接口商业授权按链路收费高但贵且挑数据类型预算充足、强可靠要求的生产环境裸日志解析如 TLA直接解析 redo 二进制国产自研无国外授权高不占源库算力国产化替代、需灵活嵌入、被 LogMiner 限制折磨的团队五、写在最后CDC 这层国产程度低不是没人想做是又难、又慢、又有法律风险回报还看不准。但也正因为它门槛高真做出来才值钱——信创再往下推数据库迁移、异地容灾、实时数仓没有一样离得开它。像 TLA 这种组件冒出来至少说明这条路国内是走得通的。这个细分赛道太需要更多自己的团队进场了。