Debezium Postgres连接器如何将关联表变更推送至同一Kafka主题

核心结论 #

Debezium默认遵循单表对应独立主题的路由规则，主题命名格式为{连接器名称}.{数据库名}.{Schema名}.{表名}，默认不会自动将子表变更推送到主表对应主题，但可以通过两种低复杂度方案实现需求，无需为每个关联表创建单独消费者。 #

可行方案 #

方案1：连接器层自定义SMT路由（推荐，复杂度最低） #

通过Debezium内置的单消息转换（SMT）组件RegexRouter，可以将所有关联表的变更消息统一路由到同一个自定义主题，仅需一个消费者即可处理所有关联表变更：

1. 连接器配置中添加所有需要捕获的关联表：

table.include.list=sch.list,sch.item,sch.其他关联表名

2. 添加路由SMT配置，将匹配的关联表消息都转发到同一个主题：

transforms=route
transforms.route.type=org.apache.kafka.connect.transforms.RegexRouter
transforms.route.regex=my_local_database.test_db.sch.(list|item|其他关联表名)
transforms.route.replacement=list-aggregate-changes-topic

3. 消费list-aggregate-changes-topic主题时，通过消息内的source.table字段区分变更来自哪张表，自行实现关联逻辑组装完整的List实体即可。

方案2：流处理聚合（适合需要直接拿到完整聚合实体的场景） #

如果不想自己在消费层写关联逻辑，可以通过Kafka Stream/ksqlDB做流关联聚合：

• Debezium照常为每个表生成独立的变更主题
• 编写流处理任务，将Item等子表的变更流和List表的全局状态表做外键JOIN，直接输出包含对应List数据和Item变更的完整聚合消息到统一主题
• 业务侧仅需消费最终的聚合主题即可，关联逻辑由流处理组件统一维护，即使有20个关联表也仅需维护一个流处理任务

实践注意 #

不建议直接修改Debezium核心逻辑在CDC阶段做关联查询，Debezium的定位是轻量变更捕获工具，关联逻辑放在路由层或下游流处理层性能更稳定，也不会影响CDC任务的容错能力。

内容的提问来源于stack exchange，提问作者rm12345