Tapdata 肖贝贝：实时数据引擎系列(四)-关于 Oracle 与 Oracle CDC

 

摘要：想实现 Oracle 的 CDC，排除掉一些通用的比如全量比对, 标记字段获取之外, 真正的增量形式获取变更, 有三种办法: Logminer 、XStream 、裸日志解析，但不管哪种方法都会导致 Oracle 的同步变得工程量巨大, 而使用 Oracle 的客户, 又大多对数据的准确性要求非常严格的, 这里形成了一个非常庞大而传统的市场。

 

前言

在之前的文章里（实时数据引擎系列文章一 、 实时数据引擎系列文章二 、 实时数据引擎系列文章三）, 我们在宏观层面讲了很多 CDC(实时数据变更获取) 的事情, 这篇文章里我们聚焦一下, 针对一个数据库 Oracle, 来讲解一下他的 CDC 的前世今生。

 

Oracle 的 CDC 是很难的, 他的难度不在于一个具体的算法或者场景问题实现多困难, 而是 Oracle 作为一个商业数据库, 并没有计划把他这方面的接口暴露给第三方用户, 闭源 + 无接口, 让很多开发者无从下手, 开发实际上变成了逆向工程的工作, 这个投入是巨大而且成效不明显的, 这也是很多开源的数据集成没有很好地支持 Oracle 的原因。

 

虽然困难客观存在, 但是需求同样存在, 在巨大的利益驱使下, 为了解决这个困难, 各路兵马可谓是八仙过海各显神通, 发展到现在, 出现了 捡剩饭, 挂壁 和 奋斗逼 三大门派, 围攻 Oracle CDC 光明顶。

三大门派

想实现 Oracle 的 CDC, 排除掉一些通用的比如全量比对, 标记字段获取之外, 真正的增量形式获取变更, 有三种办法:

1. Logminer: 捡剩饭套路, Oracle 官方提供的一个日志分析工具, 可以将内部的日志解析成事件输出出来, 也是目前超过 99% 的开源工具集成的方案, 集成最简单, 问题也最多
2. XStream: 挂壁套路, Oracle 内部接口, 将事件变更通过内存流池共享丢出去, 有严格的 License 限制, 普通人自己用用还可以, 如果商用, 坐等律师函
3. 裸日志解析:
   1. 官方日志解析: OGG 的实现模式, 有源码支持, 兼容性最好, 速度远胜于 Logminer
   2. 三方日志解析: 奋斗逼, 逆向工程, 这里的点很多, 奋斗逼也分等级, 顶级的工程师背后的公司财大气粗, 购买了 Oracle 部分版本的源代码, 在这个基础上开发了解析工具, 有一些工程师本来就在 Oracle 工作, 通过一些不太干净的手段拿到了一些源码, 做了一些工具出来, 有些工程师啥都没有, 凭借一些日志导出工具和顽强的毅力, 逐个猜测每个二进制位的含义, 不断尝试, 去完成逆向解析, 但是这个方案现在能做到商用的非常少, 全世界范围内也不超过十家

Logminer

Oracle 开发 Logminer, 最初的目的是提供一个日志分析工具, 可以让系统管理员或者 DBA 在不侵入数据库的情况下, 对数据库的过往的一些事件做一些探查分析, 本意上并没有计划将这个工具用作更广泛的用途, 但是在那个什么都没有的年代, 唯一的这个选择即使不那么完美, 也依然迅速成为 Oracle 日志解析的最火热的选择, 第三方的开源框架, 比如 debezium, 也默认使用了这种模式

 

Logminer 最大的问题在于其性能, 他运行在 Oracle 内部, 并且运行在日志落地之后, 不可避免地需要消耗数据库的算力去完成云端工作, 为了降低这个不在主流程的进程的资源消耗, Oracle 对 Logminer 做了非常严格的资源限制, 每个 Logminer 进程, 他的资源消耗都不能超过 1 个 cpu 核心, 在大多数场景下, 这个将 Logminer 的日志解析速度限制在 1w 条每秒以下, 在一些严肃的场合, 这个速度是远远不够的, Oracle 是一个事务数据库, 一个大的 Update, 可能会带来数十万上百万的更新, 在这种情况下, 每秒 1w 的解析速度会使得下游延迟增大到数分钟级别, 更糟糕的是, 在数据库本身负载较高的情况下, 由于 Logminer 的解析与数据库共享负载, 会让解析速度进一步下降, 在很极端的情况下, 延迟会放大到天级别, 失去了实时获取数据的本意

 

在工程上, 这个问题也有办法可以解决, Logminer 本质上只是一个日志解析工具, 如果开发者在外部自己管理 Logminer 进程, 将不同的日志通过不同的 Logminer 进程并行解析, 理论上可以通过消耗更多的 CPU, 来实现更快的解析, 但是这个也导致了数据库的资源被进一步消耗, 最终速度是否达到预期并不是想当然的事情

为了解决 Logminer 与数据库争夺资源的问题, 还有一个异步解析的方案, 首先通过 Oracle 的机制, 将 redo log 异步传输到另外一台没有业务压力的 Oracle 实例上, 然后在另外一台机器上开启并发解析, 这个在国内的实现上, 有极少数大的银行落地了这个方案, 达到了数倍的性能提升

 

Logminer 第二的风险在于政策的不确定性, Logminer 有一个模式, 叫 "Continuous Mining", 可以让用户不关心日志解析的细节, 直接接收输出的事件流, 对于使用方非常方便(虽然他并不能解决性能问题), 但是这个特性在 Oracle 12 版本被标记为弃用, 并在 19 版本去除, 我们看 Oracle 官方的去除说明, "这个方法没有其他方法可以替代", 如此霸道, 难免让人怀疑如果有一天, Oracle 在新的版本里直接把 Logminer 整个接口关闭, 或者修改为付费 License, 也完全不是不可能的事情, 到那一天这些当前的方案应该如何进行, 将是一个很大的问题

XStream

讲 XStream 就不得不提 OGG, 这个从 1995 年创立的公司, 专门做 Oracle 的数据同步, 在 2009 年被 Oracle 收购之前, 他们的日志解析也是通过 Logminer 的方式进行, 效率也不高。

 

在被收购之后, 应 OGG 的要求, Oracle 内部开始开发一个新的接口支持, 叫做 XStream, 与日志解析不同, Oracle 在事务事件发生之后, 将事件在落地之前, 直接缓存到内存的一个结构里, 外部消费者可以直接消费内存结构的事件获得变更, 这个过程去除了日志落地与解析的全部环节, 是效率很高的方式。

 

不过有意思的是, 虽然这个接口是因为 OGG 产生的, 但是在后续 OGG 的开发中, 并没有使用 XStream 的接口模式, 而是选择了直接解析日志, 甚至于 XStream 这个接口已经被定义为丢弃。

 

这个方式最大的问题在于, 使用方没有办法单独获得这个接口的使用授权, 需要购买 OGG 的 License 才能合法使用, 而 OGG 的授权贵到令人发指, 即使是国内的大户, 大部分也是象征性买一两条链路(对, OGG 是按照同步链路收费的), 然后自己偷偷用。

 

By The Way , OGG 不但贵得令人发指, 也难用得令人发指, 一个没有 UI, 没有管理的同步工具, 竟然可以卖到一个任务每年 N 万, 这就是闭源商业化的力量。

这个也导致了 Oracle 最赚钱的部门是法务部这个说法的出现, 放任不管的时候当然舒服, 哪天律师函发到公司的时候, 除了乖乖交钱还能怎么办呢?

裸日志解析

既然 redo log 要落盘, 那我们直接根据落盘文件去反向解析出事件, 是不是就没有了这些问题, 这个思路下衍生了非常多的套路选手。

 

比如OGG, 官方选手, 有源代码支持, 可以直接开发解析工具, 比如某云, 据说购买了 Oracle 8 的源码, 然后在此基础之上开发了自己的同步工具, 比如在 14 年偷偷叫卖 Oracle 日志解析源码的某内部员工, 比如某些毅力码农在线逆向, 坚持不懈 N 年终于发了一个版本的某项目, 都是这个方向的选手。

 

与前两个不同, 这种方案最大的问题在于工程量, Oracle 的日志格式都是没有任何文档可以查的, 要想知道里面的格式, 即使有部分源码可以查看, 还有大量的工作需要尝试和猜测, 同时还要面对 Oracle 版本升级带来的格式变动, 之前的工作需要重来一遍的风险。

 

但是这个方案的好处是很明显的, 首先是解析上不再依赖 Oracle 数据库的算力, 将性能彻底释放出来, 同时有没有 License 的问题, 在全球范围内, 有少数几家专注做数据同步的方案提供商提供了这种方案, 在国内这种方案做得比较好的只有北京的一家, 从零几年开始做, 现在也是几百人的现金流良好的公司。

 

一个小插曲是北京这家公司的一个员工, 在几年之后拿着研发成果偷偷跑出来, 跟他媳妇创立了另外一家做数据同步的公司, 也拿来做生意, 这个员工被告了, 判了三年多, 然而这家公司目前似乎还在运作, 足以看出在 Oracle 数据同步这个市场, 需求有多强烈。

一些通用问题

不管是用哪种套路, 都不可避免要面对 Oracle 本身的一些问题, 比如 Oracle 的一些奇怪的事务日志, 会出现 COMMIT + ROLLBACK 并存的情况, 有些时候是表明整个事务无效, 有效是作为检查点, 回滚部分事务, 有时候也会出现更诡异的日志, 比如事务运行期间出现了同行的另一个事务, 从序号上, 反而是后结束的事务被丢弃了的情况。

除此之外, 还有一些无效提交, 无效回滚, 自己一些特殊的数据类型(CLOBS, BLOBS 在日志里没有原始数据), 这些情况需要处理。

 

林林总总的问题导致 Oracle 的同步变得工程量巨大, 而使用 Oracle 的客户, 又大多对数据的准确性要求非常严格的, 这里形成了一个非常庞大而传统的市场, 潜伏在火热的互联网之下, 保留着自己最原始的技术形态。

TAPDATA 的解法

TAPDATA 在产品体验中, 对全部的数据库使用了同一种拖拉拽操作体验的同时, 对用户屏蔽了 Oracle 实时数据来源的区别。

 

 

 

 

（Tapdata Cloud 数据实时同步监控界面）

 

 

在实现上, 默认提供了 Logminer 的解析模式, 在数据库增量小于 1w 每秒(具体取决于客户的宿主机性能) 时, 提供了开箱即用的能力。

 

在数据库增量比较大的情况下, 对于土豪用户, 提供了 XStream 的集成方式, 这个需要客户有 OGG 的授权许可, 对于一般用户, 提供了基于并发 Logminer 解析的第二种实现方式, 可以在不做任何部署修改的情况下, 提供 N(并发数) 倍的增量事件捕获能力, 当然这是一个占用数据库原本资源的折衷选择。

 

除此之外, TAPDATA 还提供了基于裸日志解析(对的, 我们就是没有背景, 全靠蛮力做逆向的奋斗逼) 的方案, 这个方案需要通过一个部署在数据库的代理进程, 将日志文件传输到引擎所在的机器上做解析, 这个方案单核性能可以达到 30 倍 Logminer 的解析速度, 最大的瓶颈在网络带宽和存储 IO 上, 是世界范围内最快的解决方案之一。

 

进一步了解Tapdata 实时数据服务平台，更多技术文章可前往 Tapdata 技术博客。Tapdata 自研的异构数据库实时同步工具—— Tapdata Cloud ，现已免费开放给技术开发者使用，目前支持 Oracle、MySQL、PostgreSQL、SQL Server、MongoDB、Elasticsearch 、达梦、Kafka等主流库之间的数据迁移和同步，即将支持 DB2、Sybase ASE、Redis、GBase、GaussDB 等。

 

本文作者：Tapdata 技术合伙人肖贝贝，源文地址。