从Pub/Sub流式写入BigQuery时，_CHANGE_TYPE功能失效问题

结合实际排查经验和官方CDC规则，给你几个实用的排查方向：

• 确认Pub/Sub订阅的CDC配置：创建Pub/Sub到BigQuery的订阅时，必须勾选「启用变更数据捕获（CDC）」选项（命令行创建需加--enable-cdc参数）。如果没开这个开关，即使消息带_CHANGE_TYPE字段，订阅也不会识别UPSERT逻辑，导致消息一直处于未确认状态。
• 检查_CHANGE_TYPE字段的严格性：这个字段必须是大写的"UPSERT"，字段名的下划线不能错，也不能用小写或其他拼写（比如ChangeType、upsert都不行）。可以在Pub/Sub控制台查看消息内容，确认格式完全符合要求。
• 验证BigQuery表主键的有效性：确保表的主键确实是id字段且约束已生效。有时候表修改后主键未同步，或者创建表时主键设置有误，会导致UPSERT找不到匹配行，进而处理失败。可以在BigQuery控制台表详情页查看「主键」配置项。
• 排查时间戳格式问题：BigQuery的TIMESTAMP类型严格要求ISO 8601格式（比如"2024-09-02T00:00:00Z"），你示例里的"2024-09-02 00:00:00"属于非标准格式，可能导致数据写入失败，进而消息不被确认。建议改成标准格式测试。
• 检查权限与静默失败：Pub/Sub关联的服务账号需要有BigQuery的dataEditor权限（至少能执行UPSERT操作）。如果权限不足，BigQuery会静默拒绝写入，Pub/Sub不会返回明确错误，只会让消息一直重试。可以给服务账号临时加bigquery.admin权限测试，看是否恢复正常。
• 查看订阅的未确认消息详情：在Pub/Sub控制台的订阅页面，查看「未确认消息」的具体内容和重试次数，尝试手动确认一条测试消息，然后去BigQuery检查表数据是否更新，以此判断是处理逻辑问题还是消息流转问题。

另外，身边有朋友成功用这个功能，他们踩过的坑就是订阅没开CDC开关，还有一次是消息里的_CHANGE_TYPE字段写成了"Upsert"（首字母大写其余小写），导致不生效。

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