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

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

在本地测试中看到一些奇怪的情况（我使用rabbitmq作为输入源），其中消息并不总是得到ackd，并修复了不总是关闭的窗口，我开始挖掘 StackOverflow 和 Beam 代码库。

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

• RabbitMQ 水印不前进：Apache Beam：RabbitMqIO 水印不前进 https://stackoverflow.com/questions/55736593/apache-beam-rabbitmqio-watermark-doesnt-advance
• 对于低容量，PubSub 水印不会前进：https://issues.apache.org/jira/browse/BEAM-7322 https://issues.apache.org/jira/browse/BEAM-7322
• SQS IO 在没有新传入消息的一段时间内不会提前水印 -https://github.com/apache/beam/blob/c2f0d282337f3ae0196a7717712396a5a41fdde1/sdks/java/io/amazon-web-services/src/main/java/org/apache/beam/sdk/io/aws/sqs/SqsIO。 java#L44 https://github.com/apache/beam/blob/c2f0d282337f3ae0196a7717712396a5a41fdde1/sdks/java/io/amazon-web-services/src/main/java/org/apache/beam/sdk/io/aws/sqs/SqsIO.java#L44

（和别的）。此外，似乎还有独立的概念Checkpoints (CheckpointMarks) 与Watermarks.

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

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

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