我们有一个从Pub/Sub消费的数据流，并在流式传输中写入bigquery。由于许可问题，管道卡住了，消息没有被消费，我们重新启动了管道，将未确认的消息保存在快照中，重放消息，但它们被丢弃了
>
我们解决了这个问题，使用对主题的新订阅重新部署了管道，并且所有事件都在流式传输中消费而没有问题
对于第一个订阅中累积（20M）的所有未解密消息，我们创建了一个快照
然后使用重播消息对话框通过UI将此快照连接到新订阅
在指标仪表板中，我们看到未更新的消息尖峰20M，然后它们被消费订阅尖峰
但是事件不会发送到BigQuery，检查内部数据流作业指标，我们能够看到从pubsub步骤读取的重复消息计数的峰值Dataflow重复计数器
这些消息是
该管道使用Apache BeamSDK2.39.0和python 3.9，并启用了streming引擎和v2运行器。
处理Pub/Sub消息需要多长时间，这个过程很长吗？
在这种情况下，Pub/Sub可能会根据订阅配置/延迟重新传递消息。请参阅订阅重试策略。
数据流可以解决这个问题，因为它在成功洗牌后从源确认。如果您添加GroupByKey（或人为地，Reshuffle）转换，它可能会解决源重复。
更多信息https://beam.apache.org/contribute/ptransform-style-guide/#performance
