Корреляция событий Flink и ретроспективный анализ

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

  1. Логика корреляции событий состоит из статических правил, основанных на типе события, поступающего во входной поток. В течение последних X минут коррелируйте события разных типов событий и выводите данные о событиях, которые имеют бизнес-ценность, на основе этих правил. Например, за последнюю 1 минуту проверьте, не превышает ли цена события типа A на торговой площадке A1 <20 000, а цена события типа B на торговой площадке M2 менее 30 000, затем добавьте данные события A в выходной поток, иначе добавьте данные события Б.
  2. Для событий, представляющих интерес / ценность для бизнеса, рассчитайте разницу в цене за последние X минут. Например, если при публикации применяются все правила, мы решаем, что событие A представляет интерес для последнего 1-минутного окна, перед добавлением данных о событии в выходной поток мы также хотим вычислить разницу в цене события A за последние 10 минут.

Чтобы реализовать эти варианты использования, я оценивал применение ключа по входному потоку по идентификатору типа продукта во входных данных. Это даст мне данные о нескольких типах событий для этого продукта для разных торговых площадок, а затем с использованием скользящего временного окна события периода ретроспективного анализа, скажем, последних 10 минут со скользящим окном в 1 минуту и ​​применения ProcessWindowFunction для написания логики корреляции для данных за последние 1 минуту и использование других 9 минут данных для ретроспективного анализа и расчета разницы в ценах на интересующие события.

Я не совсем уверен, что это лучший способ их реализации. Любые советы / рекомендации будут очень признательны!


person ekjot    schedule 17.03.2021    source источник


Ответы (1)


В целом я бы сказал, что у вас есть следующие варианты:

  • Используйте раздвижные окна, как вы предложили.
  • Используйте KeyedProcessFunction. Этот API нижнего уровня предлагает больший контроль и может привести к более оптимизированному решению. Иногда это также проще, поэтому, если вы обнаружите, что оконный API мешает вам, подумайте об этом.
  • Используйте Flink SQL и / или API таблиц. Возможно, вам будет проще выразить и поддерживать правила, если они написаны на SQL. Возможно, MATCH_RECOGNIZE актуален .
person David Anderson    schedule 18.03.2021
comment
Спасибо за помощь, Дэвид! есть дополнительный вопрос. Хотя этот подход со скользящим окном работает нормально, я думал о том, чтобы выделить логику ретроспективного анализа в отдельное приложение KDA, чтобы повысить модульность. Таким образом, входной поток (поток I) поступает в два приложения Flink (Flink A: вычисление корреляции в 1-минутном окне и интересующее событие вывода в потоке A, Flink B: вводится как поток I, а поток A вычисляет разницу в ценах с использованием функции connect и KeyedCoProcessFunction и генерирует вывод в потоке B. Хотел понять, будет ли у этого подхода недостатки по сравнению с выполнением всего в 1 приложении Flink / KDA. - person ekjot; 04.04.2021
comment
Самый большой недостаток, о котором я могу думать, - это добавленная задержка (которая может быть не такой уж значительной). - person David Anderson; 05.04.2021