摘要:对于 PostgreSQL 的实时数据采集, 业界经常遇到了包括:对源库性能/存储影响较大, 采集性能受限, 时间回退重新同步不支持, 数据类型较复杂等等问题。Tapdata 在解决 PostgreSQL 增量复制问题过程中,获得了一些不错的经验和思考,本文将分享 Tapdata 自研的 TAP-CDC-CACHE,和其他几种市面常见的解决方案的优势和特性。
TAPDATA 的数据复制产品里, 提供了对于 PostgreSQL 的实时数据采集功能, 在客户落地使用时, 遇到了包括 对源库性能/存储影响较大, 采集性能受限, 时间回退重新同步不支持, 数据类型较复杂
等等问题, 在解决这些问题的过程中, 我们逐渐对增量事件应该具备一个缓存中间件有了清晰的认识, 并在之后的时间里做了相应的实现
本文从我们在解决 PostgreSQL 增量复制的问题出发, 在一步步寻找解决方案的过程中, 分享一下我们最终解决方案的过程和对这个问题的一些思考
万变不离其宗, PostgreSQL 捕获增量事件的原理与 Mysql, MongoDB 等数据库类似, 其本质都是基于事务日志进行回放, 这种日志在 PG 里被称为 Write-Ahead Logging(WAL), 通过对 WAL 的解析, 可以得到数据库的逻辑事件变更, 下游的各种消费者可以在这个基础上完成数据复制, 流计算等等各种需求
在具体的实现上, 通常有以下三种技术选型
针对开发者进行数据逻辑复制的需求, PostgreSQL 开放了对于 WAL 的订阅接口, 开发者需要创建一个名为复制槽的结构, 并指定其解码插件, 之后只需要轮询这个复制槽, 即可获取最新的以事务为最小粒度的数据变更
常见的解码器有 decoderbufs, wal2json, pgoutput
等等, TAPDATA 支持的插件, 其对应的数据库版本与特点如下:
除此之外, 还有一些其他插件, 比如: decoding-json, decoder_json, jsoncdc, wal2mongo, postgres-decoderbufs, Bottled Water, osm-logical, pglogical, transicator 等等各式各样的输出格式, 用户可以按照自己的需求选择合适的插件, 也可以自己开发对应的解码器
以 wal2json
为例, 具体的使用命令如下:
## 创建一个 slot, 命名为 tapdata, 用来接收 CDC 事件, 并使用 wal2json 解析
select * from pg_create_logical_replication_slot('tapdata', 'wal2json');
select * from pg_replication_slots where slot_name='tapdata';
select * from pg_logical_slot_get_changes('tapdata', NULL, NULL)
select * from pg_logical_slot_peek_changes('tapdata', NULL, NULL)
select * from pg_logical_slot_peek_changes('tapdata', NULL, NULL) where lsn > '1/47CB8450' limit 10
select * from pg_replication_slot_advance('tapdata', '1/47CB8450')
这个方案的优势是使用便捷, 创建复制槽后, 可以方便使用 SQL 查询增量数据
方案的问题有很多, 我们遇到的列举在下面:
即便问题如此之多, 但是由于其使用的便捷性, 对其进行二次开发的成本很低, 依然成为各大数据集成组件里的首选方案, 这其中包括 debezium, flink-cdc, datax, flinkx 等等
为了解决这些问题, 我们需要能直接解析 WAL 的插件方案
Oracle 数据库有一个叫做 Logminer 的插件, 可以方便对数据库 Redo Log 进行逻辑解析, 对 PostgreSQL 也有一个类似的插件叫 Walminer, 项目地址在: movead/WalMiner
在使用上, 与手动管理的 Oracle Logminer 基本一致, 其具体的使用命令如下:
## 列出 WAL 文件
select walminer_wal_list()
select walminer_wal_add('/opt/test/wal')
select walminer_all()
select walminer_by_time(starttime, endtime)
select walminer_by_lsn(startlsn, endlsn)
select * from walminer_contents
select walminer_stop()
与基于复制槽的解码方案相比, Walminer 有自己的一些优势, 包括:
他的劣势有:
相比复制槽解码插件, Walminer 从根本上解决了很多问题, 并引导我们思考这个方案的通用扩展性
pgwal_dump 是 PostgreSQL 官方提供的 WAL 解析工具, 与 Walminer 相比, 其优势在于不需要安装到数据库中, 且解析不占用数据库资源, 解析后的内容可以输出到文件中供下游消费, 官方提供, 有较好的维护性, 其劣势在于无法使用数据库驱动进行任务管理, 需要额外安装通信 agent 进行任务管理, 且其输出结果无法直接 SQL 查询, 需要自行组织结果数据
除此之外, 其核心功能与 Walminer 基本相同, 可作为备用方案使用
对数据库的设计者来说, 提供数据库事件的回放能力往往基于两个目的:
故障恢复的场景使用低频, 数据实时性要求低, 多手动操作, 对集成性要求不高, pgwal_dump 是一个典型的例子, 对这个工具的集成使用需要额外开发 agent 进行任务管理, 增加了使用成本
主从同步有一个典型的特点是从的数量往往不是很多, 因此所有基于此假设的方案在遇到较多的消费下游时, 会遇到比较严重的性能问题, slot 的方案即是如此, 除此之外, 主从同步往往需要全量数据保持一致, 因此往往不会针对库, 表, 甚至更细致的查询条件进行特异性解析优化, 在使用时往往带来较大的资源浪费
实时数据服务平台的需求打破了上述两个目的假设, 其场景既需要非常高的实时性, 又需要非常好的集成性, 同时对数据的消费数量与业务相关, 繁忙的数据库其消费场景会达到数十, 甚至数百个, 这些数据消费任务对数据的要求各不相同, 具备精细的过滤条件
在实时任务的开发过程中, 将时间回退到某个时间点进行回放是非常常见的调试需求, 已有的方案要么无法实现, 要么以占用较多的数据库资源进行折衷, 在技术上不优雅
针对各种数据库, 以上的困难都不止一次出现在我们面前, 客户在进行任务开发时, 需要小心翼翼设计任务过程, 避免对生产库造成影响, 对用户造成了较大的心智负担
痛定思痛, 作为专注在实时数据开发的产品型公司, 这个问题被客户反复提起, 摆在研发团队面前, 经过多次思考与尝试, 我们使用了自研缓存中间件, 提出了自己的解决方案
在软件开发领域有一个名言, "All problems in computer science can be solved by another level of indirection", 这个场景也不例外
为了解决这个问题, TAPDATA 对于各种来源的数据增量事件的写入和消费需求, 针对性开发了一个高速大容量的缓存层, 其具备以下基本特性:
并针对 CDC 场景进行额外优化, 包括:
这个中间件工作在数据采集层与计算层的中间位置, 屏蔽了数据库增量标准的差异性, 解决了之前方案遇到的各种问题, 为后续对数据的使用提供了足够的功能与性能空间, 为产品提供了独有的竞争力
几个常见的工作模式流程图如下:
以 Oracle 为例, 开发者只需要将单并发实例级别无过滤的 Logminer Redolog 解析结果发送到缓存层, 后续的标准化, 有序性保证, 过滤器均可自动完成, 如下图所示
以 MongoDB 为例, MongoDB 的 Update 需要开启反查才能获取完整前值, Delete 操作不支持变更前值获取, 在流计算场景, 只有一个变更主键是不满足后续数据需求的, 比如对双流 JOIN 场景, JOIN 键不为主键时, 一条记录的删除除了需要知晓主键之外, 他的关联键和具体变更的数据也非常重要
针对这个场景, TAP-CDC-CACHE 的工作模式如下:
在进行包含全量 + 增量的计算场景时, 通常情况下为保证数据的精确一次性, 需要提供源端锁表 + 快照读实现, 锁表带来了业务损失, 快照读对于繁忙的数据库负载很高, 为了解决这些问题, 基于源表无锁范围并发读取 + 部分增量合并操作的 CDC 相比之下成为更优良的方案选择
但是在具体实现上, 开发者的负担更重, 为解决这个问题, TAP-CDC-CACHE 将复杂逻辑抽象在中间件中, 开发者只需要简单将全量/增量数据, 按照不同的生产者灌入到存储中, 后续的全部操作均由中间件完成, 其工作模式如下:
提到数据流存储, 会有一些同学有为什么不使用 kafka, pulsar, 或者 pravega 这种产品的疑问, 处于解决问题成本最低的考虑, 一开始确实有考虑使用流存储, 与 Stream API 去开发一些处理算子来实现需求, 但是流存储这些开发接口, 本质上是对流做逐条变换, 一些核心的需求, 比如:
这几个问题的技术抽象使用逐条读取流已经很勉强, 实现出来的效果并不好, 我们不得不对一些特定的流做一些二级索引的维护, 这本身又需要单独一个组件来做, 这引入了一些额外的复杂性, 再考虑到:
我们认识到自己的需求可以被更优雅和专业地解决, 于是有了这个产品的雏形,本质上来讲, TAP-CDC-CACHE 是一个特定场景下优化的数据库。
Tapdata 是一款基于数据即服务(DaaS)架构理念,面向 OLTP 业务或场景的实时数据服务平台,具备异构数据实时同步、批流一体数据融合、自助式 API 发布等功能。Tapdata 目前已支持近百个数据源和类型,包括市场主流的数据库,API,队列,物联网等,所有操作均是低代码、可视化方式,无需专业的编程能力就可完成数据实时同步、数据映射与合并、数据建模、数据服务 API 开发,数据实时入湖入仓等。申请试用:https://tapdata.net/tapdata-enterprise/demo.html
本文作者:Tapdata 技术合伙人肖贝贝,原文地址:https://tapdata.net/TAP-CDC-CACHE.html
手机扫一扫
移动阅读更方便
你可能感兴趣的文章