Все примеры окон, которые я вижу, включают определение окон.Например, падающие 1-минутные окна или 1-минутные скользящие окна и т. Д. В моей ситуации все мои данные имеют метки времени, но это не основной интерес.
У всех моих данных также есть связанный период , который я не могу контролировать.Это желаемое окно в моем случае.Периоды основаны на времени, но они варьируются от 2-3 недель, примерно.
Итак, если я посмотрю только на период потока значений, это может выглядеть так (почти все из текущего периода, несколько отставших от последнего периода в начале текущего периода),
... PERIOD 6, PERIOD 5, PERIOD 6, PERIOD 6, PERIOD 6, PERIOD 6, ...
Мне не понятно, как справиться с этой ситуацией с точки зрения водяных знаков / триггеров / и т. Д.?Если я правильно понимаю всю эту терминологию, я подумал о чем-то вроде этого: водяной знак для PERIOD N появляется при обработке первого события с PERIOD (N+1).Горизонт запаздывания (для состояния сбора мусора) для окна PERIOD N может составлять 1-2 дня после отметки времени первого события с PERIOD (N+1).Я хотел бы, чтобы триггеры были accumulating и каждые 5 минут (в идеале, я бы хотел, чтобы длительность этого триггера увеличивалась: чаще в начале окна, реже с течением времени).
Iя пытаюсь использовать терминологию из этой статьи, https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-102 извините, если она неверна
Меня особенно смущает то, как водяные знаки кажутся непрерывными и основаны на времени события.В моем случае у меня есть и время события (метка времени) и время события (период).Если я правильно понимаю, кривая моей ситуации (как в приведенной выше статье) будет выглядеть как пошаговая функция?
Я еще не выбрал инфраструктуру потоковой обработки для использования.Имеет ли смысл моя ситуация для кого-либо из них?Требует ли это много пользовательской логики?Делает ли это какие-либо рамки легче?Это известная проблема с именем?
Любая помощь приветствуется.