Что произойдет, если для оператора flink keyBy будет задан отдельный ключ, после которого откроется окно

Question

Мое задание на миг имеет оператор keyBy, который принимает в качестве ключа дату ~ clientId (date в виде ггггммдччММ, MM в минутах, который изменяется через 5 минут). За этим оператором следует акробатическое окно продолжительностью 5 минут. У нас есть ввод кафки в среднем 3 миллиона событий в минуту и ​​около 20 миллионов событий в минуту в пиковое время. Продолжительность контрольной точки и минимальная пауза между двумя контрольными точками - 3 минуты.

Теперь мои сомнения:

1) Сохраняется ли состояние, созданное keyBy, вечно или оно высвобождается через 5 минут.

2) Какие изменения необходимы в случае, если я изменю это окно на 30 минут.

3) Как время контрольной точки зависит от размера окна.

4) Что будет эффект в сценарии, где число отчетливых клиентов за любые 5 минут идет 5-10 раз. Будет ли это создавать перекос данных. Поскольку 1-2 подзадачи в моей работе всегда занимают около 1-2 минут по сравнению с другими 800 подзадачами, которые выполняются за 10-15 секунд.

5) Я получаю одно исключение один раз в каждые 5 -6 часов, которые возобновляют работу Flink. TimerException {java .nio.channels.ClosedByInterruptException} в орг. apache .flink.streaming.runtime.tasks.SystemProcessingTimeService $ TriggerTask. Что может быть вероятной причиной.

Answer 1

Несколько моментов:

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

Вот пример:

Что произойдет в сценарии, в котором количество отдельных клиентов за любые 5 минут увеличивается 5-10 раз. Будет ли это создавать перекос данных? Поскольку 1-2 подзадачи в моей работе всегда занимают около 1-2 минут по сравнению с другими 800 подзадачами, которые выполняются за 10–15 секунд.

Возможно, у вас есть одна или несколько клиенты с гораздо большим количеством событий, чем остальные?

Было бы интересно понять, почему вы выполняете основанную на событии настройку времени, за которой следует время обработки windows, а не время события windows. (Я предполагаю, что вы используете время обработки windows, поправьте меня, если я ошибаюсь.)

Есть ли у вас какие-либо идеи о том, сколько разных таймфреймов одновременно активны? Например, окно для 12: 00-12: 05 будет принимать много событий с отметками времени в диапазоне 12: 00-12: 05, а также некоторые события в 11: 55-12: 00, которые не поступили к 12:00. , И возможно события для более ранних таймфреймов, если такая большая задержка возможна. Трудно думать о перекосе клавиш, не понимая, как выглядит активное пространство клавиш.