что на самом деле управляет водяными знаками в луче? - PullRequest
1 голос
/ 03 октября 2019

Большая мощь Beam проистекает из его расширенных возможностей работы с окнами, но это также немного сбивает с толку.

Видя некоторые странности в локальных тестах (я использую rabbitmq для входного источника), где сообщения не всегда получали ack d и исправив окна, которые не всегда закрывались, я начал копаться вокруг StackOverflow и базы кода Beam.

Кажется, существуют специфические проблемы с источником, когда устанавливаются именно водяные знаки:

(и другие). Кроме того, кажется, что существуют независимые понятия Checkpoint с (CheckpointMark с) в отличие от Watermarks.

Так что я полагаю, что это вопрос из нескольких частей:

  1. Какой код отвечает за перемещение водяного знака? Кажется, это какая-то комбинация Источника и Бегуна, но я не могу на самом деле найти , чтобы понять это лучше (или настроить его для наших вариантов использования). Это особая проблема для меня, так как в периоды малого объема водяной знак никогда не продвигается, и сообщения не ack d
  2. Я не вижу много документации относительно того, что концептуально является контрольной точкой / контрольной точкой (недокументация Beam-кода не обсуждает это). Как CheckpointMark взаимодействует с водяным знаком, если он вообще существует?

1 Ответ

2 голосов
/ 03 октября 2019
  1. Каждая PCollection имеет свой собственный водяной знак. Водяной знак указывает, насколько полной является эта конкретная PCollection . Источник отвечает за водяной знак PCollection, который он производит. Распространение водяных знаков в нижестоящие коллекции ПК происходит автоматически без дополнительного приближения;его можно грубо понимать как «минимум входных PCollections и буферизованное состояние». Так что в вашем случае, это RabbitMqIO, чтобы посмотреть на проблемы с водяными знаками. Я не знаком с этим конкретным соединителем ввода-вывода, но отчет об ошибке или электронное письмо в список пользователей было бы хорошо, если вы этого еще не сделали.
  2. Контрольная точка - это фрагмент данных, зависящий от источника, который позволяет ейвозобновить чтение без пропущенных сообщений, если бегунок надолго сохранит контрольную точку. ACK сообщения имеет тенденцию происходить при завершении контрольной точки, так как бегун вызывает этот метод, когда известно, что сообщение никогда не нужно перечитывать.
...