通过Google Cloud Pub / Sub将数据重放到Ap​​ache Beam管道中，而不会导致其他订阅者超负荷

Question

我在做什么：我正在构建一个系统，其中数十个Apache Beam管道以流模式读取一个Cloud Pub / Sub主题。每次部署新管道时，它都应首先处理几年的历史数据（存储在BigQuery中）。

问题：如果我每当部署新管道（如建议here）将历史数据重播到主题中时，该数据还将传递到当前正在阅读该主题的所有其他管道中，这将很浪费并且非常昂贵。我无法使用Cloud Pub / Sub Seek（建议here），因为它最多存储7天的历史记录（更多详细信息here）。

问题：建议使用哪种模式以最小的开销（又不引起事件时间/水印问题）将历史数据重播到新的Apache Beam流管道中？

当前想法：我目前可以想到三种解决问题的方法，但是，它们似乎都不是很优雅，而且我也没有在文档中看到它们（通用模式）中的任何一种（{ {3}}或part 1）或其他地方。他们是：

1. 理想情况下，我可以使用part 2将实时ReadFromPubSub与一次性BigQuerySource合并，但是，我看到了三个潜在的问题：a）我可以不会考虑已经发布到Pub / Sub，但尚未进入BigQuery的数据，b）我不确定如果重新启动管道，是否会无意中重新运行BigQuerySource，并且c ）我不确定BigQuerySource是否以流模式工作（根据表Flatten）。

2. 我为每个管道创建一个单独的重播主题，然后使用here合并主要主题和特定于管道的重播主题的ReadFromPubSub s。部署管道后，我将历史数据重播到特定于管道的重播主题。

3. 我为每个管道创建专用主题，并部署一个单独的管道来读取主要主题，并将消息广播到特定于管道的主题。每当需要重播时，我都可以将数据重播到特定于管道的主题中。

Answer 1

您的三个想法中

• 第一个将不起作用，因为当前Python SDK不支持从有界源进行无界读取（这意味着您无法向流传输管道中添加ReadFromBigQuery）。

  < / li>

• 第三个听起来过于复杂，甚至可能代价很高。

我相信，目前最好的选择就是按照您所说的，将表重播为一个额外的PubSub主题，正如您正确指出的那样，您可以将该主题平铺到主主题中。

我将检查是否有更好的解决方案，但是目前，选项2应该可以解决问题。

---

此外，我想带您到interesting talk from Lyft on doing this for their architecture（在Flink中）。