GCP Pub/Sub转BigQuery两类Dataflow模板差异及选型咨询

1. 数据源入口逻辑 #

• Topic模板：直接绑定指定Pub/Sub Topic，运行时自动创建临时独占订阅，任务结束后订阅会被自动删除。
• Subscription模板：依赖你预先创建好的Pub/Sub Subscription，任务全程复用这个订阅，任务结束后订阅保留。

2. 消息消费语义控制 #

• Topic模板：默认是**至少一次（At-Least-Once）**消费，临时订阅的特性导致重启、重试可能引发重复处理。
• Subscription模板：支持灵活适配订阅的配置，比如你可以给订阅开启Exactly-Once Delivery，或者配置手动Ack逻辑，更精准控制消息消费的语义。

3. 资源管理方式 #

• Topic模板：适合短期/一次性任务，不用额外维护订阅资源，用完即清理。
• Subscription模板：适合长期运行的流式任务，订阅可以独立于Dataflow任务存在，后续还能调整订阅参数（比如死信队列、过滤规则），甚至被其他任务复用。

4. 启动参数要求 #

• Topic模板只需要指定inputTopic参数，不用管订阅。
• Subscription模板必须指定inputSubscription参数，无需指定Topic。

选Topic模板的场景 #

• 一次性同步Topic历史消息到BigQuery的临时任务。
• 不想额外维护订阅资源，追求轻量化部署。
• 下游BigQuery有去重逻辑，对消息重复处理不敏感。

选Subscription模板的场景 #

• 需要长期持续消费Topic消息的流式管道（比如你的文件上传监听场景）。
• 需要自定义订阅配置，比如给失败消息配置死信队列，或者设置消息过滤规则。
• 希望订阅资源独立于Dataflow任务，避免任务重启导致未消费消息丢失。

你的需求是文件上传存储桶时自动创建BigQuery表，完整链路应该是：存储桶配置Cloud Storage通知，把上传事件推送到Pub/Sub Topic，再用Dataflow消费事件、创建表并导入数据。

这个场景下优先选Pub/Sub Subscription to BigQuery模板，理由：

1. 你的管道是长期运行的，预先创建的订阅能稳定保留，即使Dataflow任务重启，未处理的上传事件不会丢失。
2. 可以给订阅配置死信队列，处理解析失败的事件，避免消息丢失。
3. 用Terraform部署时，能提前定义好Pub/Sub Topic、Subscription和Dataflow任务，整个链路资源通过基础设施即代码管理，更可控。

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