В чем разница между Flink Core и Flink CEP в отношении их возможностей? - PullRequest
0 голосов
/ 05 марта 2020

Во время изучения библиотеки Flink CEP за последние несколько дней у меня сложилось впечатление, что она не добавляет каких-либо новых фундаментальных функций к стандартным возможностям Flink. Похоже, что единственная цель Flink CEP - сделать обработку событий проще с четкой семантикой и интуитивно понятной структурой кода. Например, Flink CEP представляет только 5 семантику пропуска совпадений событий. Хотя этой семантики может быть достаточно для большого числа случаев, она может не решить конкретные c проблемы, что заставляет нас вернуться к обычному Flink.

Тестовый пример - это следующий шаблон:

Emmit a alert(represented by 'a') for each non-overlapping pair of numbers in a stream

Представлено шаблоном:

Pattern.begin[EventType]("pair",skipStrategy).where(new AlwaysTrueFunction()).times(2)

Итак, для ввода типа (числа, вводимые слева направо в потоке) 1 1 1 1 1 ожидаемый результат будет a a, но ни одна из 5 стратегий пропуска совпадений не даст правильного результата:

No-skip: a a a a
Skip-to-next: a a a a
Skip-past-last-event: a a a a
Skip-to-first[1]: a a a a
Skip-to-last[1]: a a a a

Хотя эти стратегии не могут генерировать желаемый шаблон, его можно легко сделать, используя RichFunction со счетчиком ValueState, чтобы определить, когда следует выдавать новое предупреждение, преобразуя входной поток в поток событий.

Таким образом, я был бы признателен за некоторое понимание этих вопросов:

  • Почему была создана библиотека CEP, если Flink кажется более полным?

  • Шаблон, созданный с помощью CEP, более эффективен (с большей пропускной способностью / другими показателями c), чем шаблон, созданный с помощью стандартных операторов DataStream Flink? (Если возможно, с некоторыми ссылками на статьи / документы / документацию по этому вопросу)

1 Ответ

0 голосов
/ 05 марта 2020

и спасибо за игру с Flink CEP.

Flink CEP - это библиотека поверх Flink. Таким образом, он не добавляет никаких функциональных возможностей, которые не могут быть реализованы с использованием Vanilla Flink (ProcessFunctions, et c). Фактически, под капотом он реализован как специальный оператор, который проверяет элементы, которые соответствуют указанному шаблону c, и большая часть его функциональных возможностей может быть даже реализована как ProcessFunction (с большим количеством инструментов вокруг).

Тем не менее, Flink CEP может не добавлять функциональность, которая не может быть реализована с помощью Vanilla Flink, НО она добавляет выразительность, которая облегчает реализацию некоторых вариантов использования. То же самое относится и к другим API, например, Windowing API во Flink, который вы можете реализовать с помощью ProcessFunctions (с большим количеством инструментов).

Теперь, когда дело доходит до эффективности, ответ таков: это зависит". Ручное создание функции специального процесса с учетом вашего варианта использования и всеми возможными оптимизациями для вашей рабочей нагрузки может быть более эффективным, чем FlinkCEP, поскольку последняя представляет собой библиотеку общего назначения. Если у вас есть опыт и время, то оптимальным решением всегда будет внедрение PoC с использованием обоих (CEP и Vanilla Flink) и выбор наиболее эффективного для вашего случая.

...