使用历史数据回填 Beam 管道

如何解决使用历史数据回填 Beam 管道

我有一个 Google Cloud Dataflow 管道（使用 Apache Beam SDK 编写），它在正常操作模式下处理发布到 Cloud Pub/Sub 的事件数据。

为了更新管道状态并创建正确的输出，必须首先处理大量历史事件数据。此历史数据可通过 JDBC 获得。在测试中，我能够使用 JdbcIO.Read PTransform 读取和处理所有历史状态，但我想使用此 JDBC 事件数据初始化我的生产管道，然后干净地转换为从 Pub/Sub 读取事件.如果以向后不兼容的方式更改流水线逻辑，那么将来可能会再次发生相同的过程。

请注意，在此历史读取发生时，新事件继续到达 Pub/Sub（这些事件也最终进入数据库），因此应该只从 JDBC 读取的历史事件中进行干净的转换，并且只有从 Pub/Sub 读取的较新事件。

我考虑过的一些方法：

有一个从两个输入读取的管道，但在某个时间戳之前从 JDBC 过滤数据，在某个时间戳之后从 pub/sub 过滤数据。一旦管道被赶上，就部署一个更新，删除 JDBC 输入。

我认为这行不通，因为删除 I/O 转换不向后兼容。或者，管道的 JDBC 部分必须永远留在那里，无缘无故地消耗 cpu 周期。
编写一个一次性作业，用完整的历史数据填充 pub/sub，然后启动主管道仅从 pub/sub 读取。

这似乎使用了比必要更多的发布/订阅资源，而且我认为在管道中交错的新数据与更旧的数据会导致水印过早提前。
选项#2 的变化——在处理历史数据之前停止创建新事件，以避免弄乱水印。

这需要停机。

似乎将历史数据回填到管道中是一个常见的要求，但我一直找不到一个好的方法。

解决方法

您的第一个选项，从有界源（过滤到时间戳截止）读取应该很有效。

因为 JDBC.Read() 是一个有界源，它会读取所有数据然后“完成”，即不再产生任何数据，将其水印推进到+无穷大，并且不再被调用（所以没有问题关于它消耗 CPU 周期，即使它存在于您的图表中）。