Google Cloud Spanner到PubSub/Kafka实时变更数据捕获方案咨询

现有方案点评 #

方案1：Debezium Spanner连接器 #

• 核心优势：完全基于Spanner官方变更日志（Change Stream）实现，满足日志级CDC的优先需求，无数据丢失风险，默认支持至少一次交付语义，可捕获插入、更新、删除全量变更事件，自带schema变更感知能力，输出的Debezium标准事件格式适配成本极低，现有Kafka生态可以直接复用。
• 成本表现：可部署在GKE弹性节点池，低峰期自动缩容降低资源开销，无需额外支付托管服务费用，仅产生底层计算、存储和Spanner变更流读取费用，性价比突出。
• 注意事项：需要自行维护Debezium集群可用性，做好offset持久化和故障转移配置，避免重复消费问题。

方案2：自定义轮询拉取 #

• 核心优势：实现逻辑简单，无需学习第三方组件运维知识，低流量小表场景可快速上线。
• 核心劣势：天然存在丢数风险，高频轮询会额外占用Spanner读配额，实际成本反而高于基于变更流的方案，高写入场景下数据延迟会飙升至分钟级，仅适合对一致性、实时性要求不高的非核心场景，核心业务不推荐使用。

额外高性价比方案推荐 #

Spanner Change Stream + Cloud Function/Cloud Run + PubSub 无服务器方案 #

直接为Spanner对应表开启变更流，配置变更流事件触发无服务器服务（Cloud Function/Cloud Run），在服务内做简单格式转换后写入PubSub，需要对接Kafka的话可额外加一个轻量PubSub到Kafka的转发进程即可。

• 核心优势：全托管无运维成本，按实际调用量计费，低流量场景费用极低，端到端延迟可控制在秒级，完全基于日志实现无丢数风险。
• 适用场景：不想投入精力运维开源组件、流量波动较大的团队优先选择。

补充说明：Cloud Data Fusion目前确实不支持Spanner作为源端的实时CDC同步到PubSub/Kafka，暂无必要投入精力调研该方向。

选型参考 #

• 核心业务、高写入量、已有Kafka技术栈：优先选择Debezium方案
• 非核心业务、对延迟和一致性要求低、需快速上线：可选择自定义轮询方案
• 无运维资源、成本敏感、流量波动大：优先选择无服务器变更流方案

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