Воссоздание ошеломляющего окна Kinesis в Кафке - PullRequest
Новая
       4

Воссоздание ошеломляющего окна Kinesis в Кафке

0 голосов
/ 07 мая 2019

AWS Kinesis предлагает реализацию управления потоковыми окнами, которая помогает «анализировать группы данных, поступающих в разное время», разбивать окна .

Такая реализация окна особенно эффективна, поскольку она обеспечиваетокно запускается только тогда, когда первое событие (как определено группировкой событий) получено и заканчивается через определенное время позже, сокращая количество событий, полученных очень скоро друг за другом, и заканчивая в отдельных окнах.

Kinesisкажется хорошим выбором для быстрого и легкого выбора реализации потока, но с целью рассмотрения потенциальной будущей «блокировки» мы пытаемся понять, как мы могли бы воссоздать аналогичную функциональность, при необходимости, используя потоки Kafka.

Потоки Кафки , по-видимому, поддерживают следующие функции управления окнами:

На основании нашего исследования окна сеансов могут быть наиболее близкими к stagger .Однако мы заметили, что окна сеансов все еще могут быть «обновлены», если позднее событие приходит даже после того, как этот сеанс в противном случае считался бы «истекшим / выпущенным», а также что сеансы могут не передаваться до будущих событий «потокового времени»Записаны?

Поэтому я хотел бы спросить, что / если ближайшая реализация окна разбега может быть в Кафке, и какие потенциальные «ошибки» важно знать.

1 Ответ

2 голосов
/ 08 мая 2019

Окна сессий могут быть несколько похожи, однако окна сессий не имеют фиксированного размера.Границы окна определяются параметром «пробел».Если взять пример для документов Amazon, первые два события (назовем их A и B) с интервалом 10 секунд, второе и третье (C) 35 секунд, а третье и четвертое (D) 10 секунд.Если вы укажете промежуток в 10 секунд, вы получите два окна A, B и C, D, которые отличаются от поворотов и отличаются от окон с колебаниями.Если вы укажете промежуток, равный 35 секундам, вы получите одно окно со всеми 4 событиями.

В зависимости от вашего варианта использования, оно все еще может работать с использованием окон сеанса.

Что мы 'однако мы заметили, что окна сеанса все еще могут быть «обновлены», если позднее событие приходит, даже если этот сеанс в противном случае считался бы «истекшим / испущенным»,

Да, это необходимо для обработкиправильная записьЯ не уверен, какова поддержка события-времени в Kinesis - кажется, что их падающие окна совпадают с ROWTIME (это время настенных часов?).Однако, используя suppress(), вы можете получить ровно один результат за сеанс (компенсируя некоторую задержку обработки).Посмотрите этот пост в блоге для получения более подробной информации: https://www.confluent.io/blog/kafka-streams-take-on-watermarks-and-triggers

, а также о том, что сеансы могут не создаваться до тех пор, пока не будут записаны будущие события «потокового времени»?

Это верно,Но это произойдет только в том случае, если новые данные вообще не поступят, что не должно быть в случае приложения обработки потока с непрерывным потоком данных.

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

...