FLINK - будет SQL окно гриппа sh элемент на регулярной основе для обработки

Question

Меня смущает, если окно TUMBLE будет рассчитываться через равные промежутки времени и выдавать элементы для обработки. пример У меня есть запрос, который, как ожидается, будет работать с интервалом 10 секунд.

select id, key from  eventTable  GROUP BY TUMBLE(rowTime, INTERVAL '10' SECOND), id, key ;

Теперь скажем: приложение получает событие

• E1 @ 10: 00: 00
• E2 @ 10: 00: 05
• E3 @ 12: 00: 10

Как видите, E1 и E2 достигаются в течение 5 секунд c и E3 достигаются в 12: 00: 15

• Не могли бы вы помочь мне, когда будут выпущены E1 и E2 для обработки? это будет @ 10: 00: 11? или когда появится E3, а затем запрос оценит окно и выдаст?
• Если это после E3, то есть ли способ убедиться, что запрос выполняется каждые 10 секунд c?

Ценю вашу помощь в этом.

Answer 1

Если вы используете обработку времени события, то окно, которое заканчивается в 10:00:10, будет выпущено, когда водяной знак пройдет 10:00:10. Если водяные знаки выполняются обычным образом с ограниченным порядком, и если нет других событий, то водяной знак не продвигается до тех пор, пока не будет обработан E3.

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

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

Идеальное решение - иметь сообщения поддержки активности, исходящие из того же источника, чтобы вы знайте, что безделье подлинное, а не простои. Если это не удается, см. ProcessingTimeTrailingBoundedOutOfOrdernessTimestampExtractor , чтобы узнать, как использовать таймер для обнаружения бездействия и продвижения водяного знака в зависимости от времени, а не появления новых событий. (Обратите внимание, что этот пример не был обновлен для использования нового интерфейса WatermarkStrategy.)