Скользящее окно потока данных против глобального окна с триггером

Question

Я разрабатываю систему отказа от корзины для электронной коммерции.Система отправит сообщение пользователю, основываясь на следующих правилах:

• Нет взаимодействия с пользователем на сайте в течение 30 минут.
• Добавил более $ 50товаров в корзину.
• Еще не завершил транзакцию.

Я использую Облачный поток данных Google для обработки данных и принятия решения о том, следует ли отправить сообщение.У меня есть несколько вариантов ниже:

1. Использовать скользящее окно с продолжительностью 30 минут.
2. Глобальное окно с триггерным механизмом на основе времени с задержкой 30 минут.

Я думаю, что здесь может работать скользящее окно.Но мой вопрос заключается в том, может ли быть решение, основанное на использовании глобального окна с триггером на основе времени обработки и задержкой для этого варианта использования?Насколько я понимаю, триггеры, основанные на документации Apache Beam => Триггеры, позволяют Beam выдавать ранние результаты, прежде чем данное окно будет закрыто.Например, излучение по истечении определенного времени или после прибытия определенного количества элементов.Триггеры позволяют обрабатывать поздние данные, вызывая после того, как водяной знак времени события проходит через конец окна.

Итак, для моего случая использования и согласно приведенным выше концепциям триггера, я не думаю, что триггер может быть запущен послеЗаданная задержка для каждого пользователя (это упомянуто выше - может излучаться только после определенного числа элементов, оно упомянуто выше, но не уверен, что это может быть 1).Вы можете подтвердить?

Answer 1

Я нахожу документ состояния [1] и таймера [2] Apache Beam, который должен иметь возможность обрабатывать этот конкретный случай использования без использования триггера времени обработки в глобальном окне.

Предполагая, что входящие данные являются событиямидействий пользователя, и каждое событие (действие) может быть обозначено user_id.

Хорошее свойство состояния и таймера зависит от ключа и окна.Таким образом, вы можете накапливать состояние для каждого user_id, и в этом случае состояние - это сумма денег в корзине.Таймер может быть установлен в первый раз, когда сумма в корзине превышает 50 долларов США, и таймер может быть сброшен, если у пользователя все еще есть покупки в течение 30 минут во время обработки.

Предположим, что завершение транзакции также является событием с ключом user_id.При обнаружении события завершения транзакции таймер может быть удален [3].

---

update:

Эта идея полностью относится к временной области обработки, поэтому она будет иметь ложные аварийные сообщения в зависимости отпроблема запаздывания в системе.Поэтому вопрос заключается в том, как улучшить эту идею во временной области событий, чтобы у нас было меньше ложных тревог.Одной из возможностей является таймер, основанный на времени события [4].Мне не ясно, что означает таймер, основанный на времени события, в данный момент.

[1] https://beam.apache.org/blog/2017/02/13/stateful-processing.html

[2] https://docs.google.com/document/d/1zf9TxIOsZf_fz86TGaiAQqdNI5OO7Sc6qFsxZlBAMiA/edit#

[3] https://github.com/apache/beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/state/Timers.java#L45

[4] https://github.com/apache/beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/state/TimeDomain.java#L33

Answer 2

Оба ответа 1 - Скользящие окна и 2 - Глобальное окно неверны

Скользящие окна не верны, потому что - при условии, что для каждого пользователя есть один ключ, сообщение будет отправлено через 30 минут после того, как они впервые начали просмотр дажеесли они все еще просматривают

Глобальная Windows неверна, потому что - она ​​будет заставлять отправлять сообщения каждые 30 минут всем пользователям независимо от того, где они находятся в их текущем сеансе

Даже Фиксированная Windowsв этом случае будет неправильным, поскольку при условии, что для каждого пользователя существует один ключ, сообщение будет отправляться каждые 30 минут

Правильный ответ будет: - Используйте окно сеанса с интервалом в 30 минут Это правильно, потому что он отправит сообщение каждому пользователю после того, как этот пользователь неактивен в течение 30 минут

Answer 3

Я думаю, что скользящее окно - правильный подход из того, что вы описали, и я не думаю, что вы можете решить это с помощью триггера + задержки.Если скользящее оконное окно событий имеет смысл с точки зрения вашей бизнес-логики, попробуйте сначала использовать его, вот для чего оно.

Насколько я понимаю, хотя вы можете использовать триггер для получения ранних результатов, он не гарантируетзапускать в определенное (серверное / обрабатывающее) время или с точным количеством элементов (полученных до сих пор для окна).Условие триггера позволяет / разблокирует бегуна для выдачи содержимого окна, но не заставляет его делать это.

В случае времени события это имеет смысл, так как не имеет значения, когда событие приходит иликогда срабатывает триггер, потому что если элемент имеет временную метку в окне, он будет назначен правильному окну независимо от того, когда он прибудет.И когда триггер сработает для окна, элемент будет гарантированно находиться в этом окне, если он прибыл.

Со временем обработки вы не сможете этого сделать.Если событие прибывает поздно, оно будет учтено в это время и будет выпущено в следующий раз при срабатывании триггера.А поскольку триггер не гарантирует точный момент его срабатывания, вы потенциально можете получить неожиданные данные, принадлежащие неожиданным испущенным панелям.В целом, полезно получить ранние результаты, но я не уверен, что вы можете рассуждать об этом на основе окна.

Кроме того, задержка запуска только добавляет задержку срабатывания (например, если она должна была срабатывать в 12 часов вечера)., не сработает в 12.05), но не позволяет надежно распределить несколько срабатываний триггера, чтобы он срабатывал через определенные интервалы.

Вы можете посмотреть документацию по проектированию для триггеров здесь: https://s.apache.org/beam-triggers, и, возможно, запоздалый документ также может иметь значение: https://s.apache.org/beam-lateness

Другие документы можно найти здесь, если вы заинтересованы: https://beam.apache.org/contribute/design-documents/.

Обновление:

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