当前位置: 首页 > news >正文

Debezium日常分享系列之:Debezium 3.2.0.Final发布

Debezium日常分享系列之:Debezium 3.2.0.Final发布

  • Debezium核心更新
  • Debezium AI
  • Debezium核心功能更新
  • PostgreSQL版Debezium
  • Oracle版Debezium
  • Debezium JDBC Sink(接收器)
  • Debezium for Informix
  • Debezium for Vitess
  • Debezium 嵌入式模式
  • Debezium Server 更新
  • Debezium 平台更新
  • Debezium AI 增强
  • Debezium OpenLineage 集成
  • Debezium Quarkus 扩展

本次更新包含大量新特性,包括与OpenLineage的集成、全新的Quarkus DevService/GraalVM扩展、Qdrant向量数据库接收器支持,以及对Debezium Platform和AI功能的诸多改进!

主要更新内容包括:

  • 重大变更
  • 新功能和改进
  • 其他变更

Debezium核心更新

Kafka 4.0支持

Debezium现已基于Apache Kafka 4.0构建并通过测试(DBZ-8875)。由于Kafka在3.5至4.0版本间引入了多项API变更,我们强烈建议用户查阅Debezium的支持矩阵以确认兼容性。

快照部署迁移
Debezium已从RHOSS Sonatype基础设施迁移至Maven Central(DBZ-9025)。为确保获取最新的快照构建,请使用夜间构建文档页提供的更新链接。请注意,受当前API限制,尽管我们每日会向Maven Central推送多次快照构建,这些链接仅每日更新一次。

移除废弃配置项

Debezium 2.5版本通过DBZ-6907引入了delete.tombstone.handling.mode配置项,并将drop.tombstones和delete.handling.mode标记为废弃。经过充分过渡期后,Debezium 3.2已完全移除对这两个旧配置项的支持(DBZ-6068)。若您的连接器配置仍在使用废弃选项,请替换为delete.tombstone.handling.mode。

优化Schema历史记录存储
此前,TRUNCATE和REPLACE等DDL事件会被记录在Debezium内部的Schema历史主题中。实际上,这些语句并不影响Schema演进,因此从本版本开始,它们将不再被捕获到内部Schema历史主题(DBZ-9085)。

Debezium AI

FieldToEmbedding转换配置项调整

作为Debezium AI模块的新功能,FieldToEmbedding转换的配置项名称原先包含前缀字符串。经评估该前缀冗余,现已移除(DBZ-9056)。

MySQL连接器

增强日志位置缺失校验
当MySQL连接器配置为非when_needed的snapshot.mode且二进制日志位置不可用时,原逻辑会在日志中警告"将从日志最后可用位置恢复",但实际进入流式阶段时却因无法定位日志位置而立即失败。现调整为在验证阶段直接抛出错误,与其他连接器行为保持一致(DBZ-9118)。

Oracle连接器
支持JKS的TLS连接
除Oracle Wallet外,现明确支持通过JKS建立TLS连接。文档已补充如何通过特定配置项向Oracle JDBC驱动提供JKS信息(DBZ-8075)。

IBM i连接器

默认禁用Avro模式命名调整
此前强制使用Avro模式命名调整器(DBZ-9183),现改为可配置选项,行为与其他连接器统一。

日志文件丢失处理优化

旧版本中若所需日志文件不可用,连接器会静默从下一个可用文件恢复,可能导致数据丢失。现与其他连接器行为对齐:当必需日志文件不存在时直接报错(DBZ-8898)。

Debezium核心功能更新

模式历史恢复线程优化

在早期版本中,模式历史恢复操作在连接器主启动线程中执行。当模式历史数据量极大时,恢复过程可能耗时较长。在Kafka Connect环境中,这会导致连接器状态显示异常——即使连接器已启动并正在恢复模式历史,系统仍可能错误地显示为"FAILED"状态。现调整为将恢复操作延迟至Debezium协调线程启动时执行,使Kafka Connect能更快更新准确的连接器状态(DBZ-8562)。

Kafka模式历史恢复性能提升

社区成员发现Kafka模式历史实现中存在优化空间:原恢复流程某些步骤存在不必要的重复执行,导致CPU使用率偏高。优化后这些步骤仅在每次恢复时执行一次,显著降低了CPU和网络资源消耗(DBZ-9098)。

新增快照跳过指标

此前版本中,无论快照是否实际执行(因配置或偏移量存在而跳过),"SnapshotCompleted"指标都会被设置,容易造成误解。现新增"SnapshotSkipped"指标,明确区分"快照完成"与"快照跳过"场景(DBZ-8610)。

删除事件转墓碑事件功能

ExtractNewRecordState转换器新增"delete-to-tombstone"模式,可将删除事件主动转换为墓碑事件。该特性解决了连接器重启时因墓碑事件丢失导致消费者行为异常的问题,同时保持Kafka主题的压缩功能(DBZ-9022)。

日志性能回归修复

3.1版本引入的敏感信息集中日志机制意外导致性能下降。现恢复原有性能水平,同时通过改进实现保留集中化日志的设计初衷(DBZ-8879)。

JMX流式指标重置支持

新增通过JConsole等JMX工具调用"resetLagBehindSource"功能,可手动重置空闲连接器的"LagBehindSource"指标值,避免显示陈旧数据(DBZ-8885)。

JMX注册失败日志增强
当JMX MBean注册失败时(通常因命名冲突),日志现在会输出具体的MBean名称,便于快速定位问题连接器(DBZ-8862)。

PostgreSQL版Debezium

通过配置控制分区表发布

对于PostgreSQL用户,在捕获分区表变更时,默认会使用分区名称而非基表名称发布变更事件。若需将所有分区的变更重新合并到单一主题中,通常需要借助ByLogicalTableRouter将各分区事件重新路由至统一主题,或在数据库层手动调整发布设置。Debezium 3.2通过新增的publish.via.partition.root配置项简化了这一流程(默认值为false,表示使用分区名称作为事件主题)。若设为true,Debezium将自动启用publish_via_partition_root功能,确保所有分区表事件均以基表名称发布(参见DBZ-9158)。

只读模式下禁止写入操作

此前在只读模式中使用PostgreSQL连接器时存在缺陷:尽管配置为只读模式,连接器仍会尝试CREATE或ALTER发布设置,导致SQL异常。该问题已修复,现在只读模式下连接器将不再尝试修改发布配置(参见DBZ-8743)。

Oracle版Debezium

仅使用已提交数据的无缓冲LogMiner适配器

新推出的适配器实现利用数据库内存缓冲区(而非JVM堆或堆外缓存)来管理事务(参见DBZ-8924)。启用方式如下配置:
{ “database.connection.adapter”: “logminer_unbuffered” }
该适配器基于Oracle LogMiner的COMMITTED_DATA_ONLY模式,直接获取已提交的变更,避免了复杂的内存管理需求。但需注意事务内存消耗受PGA_AGGREGATE_LIMIT参数限制,超限时将报错(当前为孵化功能,后续可能调整)。

按CLIENT_ID过滤LogMiner结果

新增以下配置项,支持根据CLIENT_ID字段值过滤事务(参见DBZ-8904):
log.mining.clientid.include.list:指定需捕获的CLIENT_ID值列表
log.mining.clientid.exclude.list:指定需排除的CLIENT_ID值列表

特定场景下的CPU利用率优化
针对约束冲突和保存点回滚处理的交易缓冲方案进行重构(参见DBZ-8860):
堆缓冲处理时间减少90%
堆外缓冲时间复杂度降低97-99%
整体CPU使用率符合预期
online_catalog挖掘策略性能提升
不再包含LogMiner无法解析表名的变更事件(原方案会导致延迟增加),从而降低连接器开销(参见DBZ-8926)。

混合挖掘策略性能优化
针对批量操作中表名解析失败的情况,重构缓存查找机制,显著提升吞吐量并降低CPU占用(参见DBZ-8925)。

增强部分回滚的日志信息
现在日志会记录交易标识符和关联的系统变更号(SCN),便于调试(参见DBZ-8944)。

修复用户名显示为UNKNOWN的问题
跨多个日志挖掘步骤处理交易时,现在能正确获取用户名属性,避免错误地应用用户名排除规则(参见DBZ-8884)。

Debezium JDBC Sink(接收器)

支持列/表命名策略配置

Debezium JDBC接收器提供多种可配置的钩子,包括自定义TableNamingStrategy或ColumnNamingStrategy实现的功能。但此前这些实现无法获取连接器的完整配置,导致灵活性受限。

在Debezium 3.2中,策略实现新增了一个configure方法(DBZ-7051):

@Override
public void configure(Map<String, Object> config) {}

为保持向后兼容,该方法默认为空实现,无需强制修改现有代码。

修复归约缓冲区的强制刷新问题

JDBC接收器支持两种缓冲算法:

默认算法:源系统的每个变更都会在目标系统生成对应的SQL操作,通过维护两个桶(bucket)并定期刷新来实现。

归约算法(Reduction Buffer):分析整批事件并合并操作(例如同一主键的插入、更新、删除会被合并为无操作)。

此前归约算法会错误地像默认算法一样强制刷新缓冲区,导致性能下降(例如本应无操作却执行了2次SQL)。此问题已在Debezium 3.2中修复,归约算法性能显著提升(DBZ-8982)。

Debezium for Informix

支持心跳动作查询
heartbeat.action.query配置项广泛用于确保在高负载的非捕获表场景下,捕获表仍能定期生成事件以避免偏移量过期。Debezium 3.2的Informix连接器现已支持此功能(DBZ-9081)。
Debezium for IBM i

新增BOOLEAN数据类型支持
IBM iSeries数据库V7R5+及部分V7R4版本支持BOOLEAN类型。此前若表中包含此类型,连接器会直接报错。Debezium 3.2现已支持正常捕获(DBZ-7796)。
支持十进制处理模式
decimal.handling.mode配置项用于指定浮点值的处理方式,此前在IBMi连接器中未生效。Debezium 3.2引入以下三种模式(DBZ-8301):
precise:使用java.math.BigDecimal精确表示(二进制形式)。
double:使用double类型(可能丢失精度)。
string:编码为字符串(易处理但丢失类型语义)。

Debezium for Vitess

自定义负载均衡连接策略
新增配置项vitess.grpc.default.load.balancing.policy,支持设置连接负载均衡策略(如默认的pick_first或轮询round_robin)(DBZ-9014)。

Debezium 嵌入式模式

新增轮询开始/结束回调接口

DebeziumEngine 接口已提供多种功能,例如监测连接器或任务的启动/停止状态。但由于连接器以异步方式运行,用户可能需要感知连接器何时进入轮询阶段,以便执行特定逻辑。

为此,ConnectorCallback 接口新增了两个方法(DBZ-8948):

/*** Called after all the tasks have been successfully started and engine has moved to polling phase, but before actual polling is started.*/
default void pollingStarted() {// nothing by default
}/*** Called after all the tasks have successfully exited from the polling loop, i.e. the callback is not called when any of the tasks has thrown* exception during polling or was interrupted abruptly.*/
default void pollingStopped() {// nothing by default
}

使用场景:在初始化 DebeziumEngine 实例时,用户可通过实现 ConnectorCallback 并覆写上述方法,在轮询生命周期关键节点注入自定义逻辑(例如资源预加载或状态同步)。

Debezium Server 更新

Milvus 支持 JSON 数据类型展开
Debezium 源连接器默认将 JSON 数据类型编码为字符串(io.debezium.data.Json 语义类型)。但在使用 Debezium Server 将变更同步至 Milvus 时,此方式可能不符合需求。

新增配置项 debezium.sink.milvus.unwind.json(默认为 false),设为 true 时,JSON 字符串将转换为 JsonObject 对象(DBZ-8909)。

Redis 可跳过心跳消息

Debezium 源连接器通常配置心跳事件以防止偏移量信息过期,但对 Redis 等接收器而言,这些事件可能无实际用途。

新增配置项 debezium.sink.redis.skip.heartbeat.messages(默认为 false),设为 true 时,Redis 接收器将跳过心跳事件(但仍会更新偏移量状态)(DBZ-8911)。

新增 Qdrant 接收器适配器
Qdrant 是一款开源高性能向量数据库,专为高效存储和检索高维向量设计,适用于聊天机器人、文档搜索、图像/视频相似性匹配等场景。

Debezium 3.2 新增 Qdrant 接收器支持,配置方式如下:

debezium.sink.type=qdrant

Azure Event Hubs 动态消息键支持
为适配压缩主题(compacted topics)场景,Debezium 3.2 对齐 Azure Event Hubs 接收器行为(类似 Kinesis),根据记录键(key)选择分区(DBZ-9195)。

NATS Jetstream 接收器支持消息头
此前,转换链(transformation chain)中添加的消息头(headers)不会传递至 NATS Jetstream。Debezium 3.2 起,所有转换过程中添加的头部将自动同步(无需额外配置)(DBZ-9171)。

PubSub 接收器降低最大缓冲区大小
为避免批量发送数据时超过 10MB 限制(导致投递失败),batch.request.byte.threshold 默认值调整为 9.5MB,与其他 Google PubSub 交互的组件保持一致(DBZ-9144)。

Redis 接收器启用主机名验证
新增 ssl.hostname.verification.enabled 配置项,支持在 SSL 连接过程中验证主机名(适用于 Redis 接收器、偏移量存储及模式历史记录)(DBZ-9042)。

Redis 接收器自定义密钥库/信任库
Debezium 3.2 新增多项配置选项,支持为 Redis 接收器指定自定义密钥库(keystore)和信任库(truststore)(DBZ-9082)。示例配置:

debezium.sink.redis.ssl.truststore.path=/path/to/truststore.p12
debezium.sink.redis.ssl.truststore.password=secret
debezium.sink.redis.ssl.truststore.type=PKCS12
debezium.sink.redis.ssl.keystore.path=/path/to/keystore.p12
debezium.sink.redis.ssl.keystore.password=secret
debezium.sink.redis.ssl.keystore.type=PKCS12

Debezium 平台更新

优化数据转换导航与工作流
Debezium 管理平台针对数据转换功能进行了多项改进(DBZ-8328):
新增主导航菜单项 “转换”(Transforms)
优化流水线创建流程,支持动态添加转换规则
支持修改或删除现有转换配置

基础通知通道支持
Debezium 通知子系统可实时推送连接器状态变更事件。在 Debezium 3.2 中,当通过 Kubernetes 部署 Debezium Server 并启用平台功能 时,现提供基础通知支持:
默认通过 日志通道(log channel) 输出通知,管理员可直接在 Server Pod 日志中查看状态变更记录(DBZ-9046)。

Debezium AI 增强

为 Ollama 嵌入模型引入超时控制

在集成 Ollama 模型的 FieldToEmbedding 转换中,新增配置项 ollama.operation.timeout.ms:
用于设定模型操作的最大执行时间(毫秒)
默认值 15,000 毫秒(15 秒),支持按需调整(DBZ-8908)
此功能可防止因模型响应延迟导致转换流程阻塞。

Debezium OpenLineage 集成

OpenLineage 是现代数据驱动系统的元数据和数据血缘(lineage)采集的开放标准,不仅定义了规范,还提供了一系列库来追踪数据在变更数据捕获(CDC)、转换流水线、流处理和数据仓库等系统中的流动。

典型应用场景示例:

  • Debezium PostgreSQL 连接器捕获变更并写入 Kafka
  • Flink 读取 Kafka 主题,进行流处理后将结果写入 S3
  • dbt 对 S3 数据建模并推送到 Snowflake 数据仓库

通过 OpenLineage 可实现:

  • Debezium 发布 CDC 系统的元数据
  • Flink 上报从 Kafka 到 S3 的血缘关系
  • dbt 上报从 S3 到 Snowflake 的血缘关系

在血缘关系界面中,您可以看到从 PostgreSQL 到 Snowflake 的端到端数据流。这为审计、调试和合规性提供了可追溯性基础,同时还能识别 CDC 管道中断等影响。

Debezium Quarkus 扩展

作为 Debezium 生态的最新成员,该扩展旨在:

  • 将 Debezium 作为 DevService 集成到 Quarkus 生态中
  • 支持在 GraalVM 上运行 Debezium

当前主要进展(DBZ-8902):

  • 基于 PostgreSQL 连接器 开发 MVP 版本,后续将扩展更多连接器
  • 未来计划基于此构建 Debezium Server,为 Debezium 平台引入 GraalVM 能力

Debezium 3.2 新增功能:

  • 使用 @Capturing 注解标记变更事件处理器的 Bean 方法(DBZ-8961)
  • 支持 CDI 生命周期事件(启动、轮询、停止等)(DBZ-8959)
  • 通知事件支持(DBZ-8964)
http://www.dtcms.com/a/279100.html

相关文章:

  • MySQL Innodb Cluster配置
  • Ubuntu服务器安装Miniconda
  • VS2019编译使用log4cplus 1.2.0
  • AI数字人正成为医药行业“全场景智能角色”,魔珐科技出席第24届全国医药工业信息年会
  • DataWhale AI夏令营 Task2笔记
  • Linux —— A / 基础指令
  • 【牛客LeetCode数据结构】单链表的应用——合并两个有序链表问题、链表的回文结构问题详解
  • 游戏设备软件加密锁复制:技术壁垒与安全博弈
  • js与vue基础学习
  • 鸿蒙应用开发: 鸿蒙项目中使用私有 npm 插件的完整流程
  • docker-compose 安装Alist
  • Cesium源码打包
  • 数字孪生技术驱动UI前端革新:实现产品设计的虚拟仿真与实时反馈
  • Django Admin 配置详解
  • 【更新至2024年】2009-2024年上市公司华证esg评级、评分数据(含细分项)(年度+季度)
  • 大数据在UI前端的应用深化:基于用户行为数据的界面布局优化
  • 来时路,零帧起手到Oracle大师
  • Faiss能解决什么问题?Faiss是什么?
  • DiffDet4SAR——首次将扩散模型用于SAR图像目标检测,来自2024 GRSL(ESI高被引1%论文)
  • 前端性能与可靠性工程系列: 渲染、缓存与关键路径优化
  • 【Python办公】Python如何批量提取PDF中的表格
  • 【Java笔记】七大排序
  • 基于MaxCompute MaxFrame 汽车自动驾驶数据预处理最佳实践
  • Excel常用快捷键与功能整理
  • QT tabWidget移除页面和隐藏表头
  • RabbitMQ的几个模式
  • Nginx基础
  • 【数据结构初阶】--单链表(二)
  • [spring6: ResolvableType TypeDescriptor ConversionService]-类型系统
  • [笔记] 动态 SQL 查询技术解析:构建灵活高效的企业级数据访问层