能否配置Debezium/Kafka实现多表变更消息汇入同一Topic？

核心结论 #

你们之前查阅文档推测的“该能力无法实现”属于常见认知偏差。这套需求完全可以在Debezium、Kafka Connect的原生配置层完成，既不需要在下游开发复杂的自定义双Topic消费逻辑，也不需要获取源数据库的管控权限，完全适配当前的业务约束场景。

可直接落地的配置方法 #

所有操作都在Kafka Connect集群的Connector配置中完成，不需要修改源数据库任何结构或权限配置，也不需要编写复杂的自定义业务代码：

• 方法1：通过Debezium内置的Topic重命名能力做直连路由
  利用Debezium Connector原生支持的topic.rename配置项，直接将两张关联源表的默认输出Topic（默认格式为{连接器名}.{schema名}.{表名}），统一映射到同一个自定义的融合业务Topic上。
  参考配置片段：

  topic.rename = debezium_cdc.public.large_core_table:biz_merged_table_topic, debezium_cdc.public.associated_relation_table:biz_merged_table_topic
  

  这套路由逻辑在CDC采集的最上游执行，消息从采集端生成后直接写入指定的统一Topic，没有额外的中间处理链路。
• 方法2：通过Kafka Connect内置的正则路由SMT做灵活匹配
  如果需要适配批量路由规则（比如按表名前缀匹配多组关联表），可以直接在Connector配置中添加内置的RegexRouter单消息转换规则，匹配两张目标源表的原有Topic名称，统一改写为目标融合Topic。
  相比下游自定义Mapper的方案，这套路由在消息写入Broker之前执行，没有跨组件的额外网络开销。

对现有业务痛点的适配效果 #

这套上游路由的方案，刚好能解决之前提到的下游双Topic消费的固有缺陷：

• 统一Topic入口后，下游只需要部署一套消费映射逻辑，不需要同时维护两个关联Topic的消费位点，整体架构的运维成本、开发复杂度都会显著降低
• 可以在Topic创建阶段设置和业务关联键绑定的分区策略，保证相同业务关联键的变更消息（无论来自核心表还是关联表）被分配到同一个消费分区，从根源上解决跨Topic消费时Upsert效率低、消息插入顺序错乱的问题
• 完全适配无管控源库的场景：所有路由配置都在采集侧完成，源数据库只需要提供基础的CDC读取权限即可，不需要做任何额外调整

落地注意事项 #

• 因为统一Topic内会存在来自两张不同表的变更消息，下游消费端可以直接通过Debezium变更消息自带的source.table元数据字段，判断当前消息的来源表，做对应的字段映射，不需要额外维护消息来源的元数据
• 路由配置完成后要及时调整Topic的分区数、留存策略，保证容量和原有两个表Topic的总吞吐量、消息量级匹配，避免出现消息堆积
• 不要将和业务逻辑无关的零散表盲目路由到该统一Topic，避免增加下游映射的无效计算成本

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