Во время изучения библиотеки 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? (Если возможно, с некоторыми ссылками на статьи / документы / документацию по этому вопросу)