究竟是什么在管理光束中的水印？

Question

Beam 的强大功能来自于它先进的窗口功能，但它也有点令人困惑。

在本地测试中看到一些奇怪的地方（我使用rabbitmq作为输入源），其中消息并不总是被发送ack，并且固定的窗口并不总是关闭，我开始挖掘StackOverflow和Beam代码库。

似乎对于何时设置确切的水印存在特定于源的问题：

（和别的）。此外，似乎存在与相对的Checkpoints ( s) 的独立概念。CheckpointMarkWatermarks

所以我认为这是一个由多部分组成的问题：

什么代码负责移动水印？它似乎是源和运行器的某种组合，但我似乎无法真正找到它来更好地理解它（或根据我们的用例调整它）。这对我来说是一个特殊的问题，因为在流量较低的时期，水印永远不会前进，并且消息不会被ack删除。
我没有看到太多关于检查点/检查点标记概念的文档（非代码 Beam 文档没有讨论它）。CheckpointMark 如何与 Watermark 交互（如果有的话）？

Answer 1

每个 PCollection 都有自己的水印。水印指示特定 PCollection 的完整性。源对其生成的 PCollection 的水印负责。水印到下游 PCollection 的传播是自动的，无需额外的近似；可以粗略地理解为“输入PCollections和缓冲状态的最小值”。所以就你的情况来说，就是RabbitMqIO要检查水印问题。我不熟悉这个特定的 IO 连接器，但如果您还没有这样做的话，向用户列表发送错误报告或电子邮件会很好。
检查点是特定于源的数据片段，只要运行程序持久保留检查点，就可以恢复读取而不会丢失消息。消息 ACK 往往发生在检查点终结中，因为运行程序在知道消息永远不需要重新读取时调用此方法。