Лучше всего начать с руководства по триггерам и windows (и переход по ссылкам оттуда). В частности, в нем говорится, что, хотя триггер по умолчанию срабатывает каждый раз, когда поступают поздние данные, в конфигурации по умолчанию он по-прежнему эффективно срабатывает только один раз, отбрасывая поздние данные:
если вы используете как конфигурацию окон по умолчанию, так и триггер по умолчанию, триггер по умолчанию срабатывает ровно один раз, а поздние данные отбрасываются. Это связано с тем, что конфигурация окон по умолчанию имеет допустимое значение задержки 0. См. Раздел Обработка поздних данных для получения информации об изменении этого поведения.
Подробности
Концепция окон в Beam в целом включает в себя несколько вещей, в том числе назначение окон, обработку триггеров, обработку запаздывающих данных и многое другое. Однако эти вещи назначаются и обрабатываются отдельно. Отсюда это быстро сбивает с толку.
Как элементы назначаются окну, обрабатывается WindowFn, см. здесь. Например, FixedWindows: ссылка. Это практически единственное, что там происходит (почти). Назначение окна - это особый случай группировки элементов на основе временных меток событий (вроде). Вы можете думать о логике, подобной назначению вручную настраиваемых ключей элементам на основе временных меток с последующим применением GroupByKey.
Запуск - это связанное, но отдельное понятие. Триггеры (грубо говоря) просто предикаты, указывающие, когда бегуну разрешено выдавать данные, накопленные на данный момент в окне (source). Я думаю, что это больше всего похоже на исходную проектную документацию для триггеров: https://s.apache.org/beam-triggers
Задержка - это еще одна связанная часть конфигурации, которая также является несколько отдельной (ссылка). Несмотря на то, что триггер может позволить бегуну выдавать все запаздывающие данные навсегда, конвейер может быть настроен так, чтобы не разрешать любые запаздывающие данные (что является поведением по умолчанию) или разрешать только запоздалые данные в течение некоторого ограниченного времени. Это приводит к описанному выше поведению триггера по умолчанию. Да, это сбивает с толку. По возможности избегайте использования сложных срабатываний и опозданий, скорее всего, это не сработает так, как вы ожидаете.
Таким образом, классы окон обрабатывают только логику группировки, то есть какие элементы имеют одинаковый ключ группировки. Эти классы не заботятся о том, когда вы захотите выдать накопленные результаты. Это зависит от вашей бизнес-логики, например. вы можете захотеть обработать вновь поступившие элементы или отказаться от них, это не часть окна. Это означает, что нет специальных триггеров для FixedWindows или других окон, вы можете использовать любой триггер с любым окном (даже если логически какой-то конкретный триггер не имеет смысла в контексте какого-либо окна).
Триггер по умолчанию - это просто то, что установлено по умолчанию. Вы должны назначить свой собственный триггер, если он вам не подходит. И, скорее всего, не будет, за исключением некоторых основных случаев использования.
Обновить
Пример использования FixedWindows с триггерами.
person
Anton
schedule
11.01.2019
