Complex Event Processing

Complex Event Processing (CEP) erkennt vorher festgelegte Muster in laufenden Ereignisströmen (kontinuierlich eintreffende Einzelmeldungen wie Klicks, Zahlungen oder Sensorwerte). Mehrere zeitlich geordnete Einzelereignisse werden zu einem zusammengesetzten Ereignis verdichtet, sobald eine vorher beschriebene Bedingung greift, etwa eine bestimmte Reihenfolge, ein Zeitfenster, eine Häufigkeit oder das Ausbleiben einer erwarteten Folgemeldung. CEP ist ein spezialisierter Zweig der Stream-Verarbeitung (kontinuierliche Datenverarbeitung im Fluss statt in Batches) und dient typischerweise der schnellen Reaktion auf mustergetriebene Situationen wie Betrug, Ausfälle oder Schwellenverletzungen.

Was ist Complex Event Processing?

Auf einem oder mehreren Ereignisströmen laufen Muster-Definitionen (Patterns, also Regelvorlagen), die einzelne Ereignisse zueinander in Beziehung setzen. Erfüllt eine Ereignisfolge das Muster (etwa „drei fehlgeschlagene Logins innerhalb von 30 Sekunden, gefolgt von einem erfolgreichen Login von einer neuen IP"), erzeugt die CEP-Engine (das verarbeitende System) ein zusammengesetztes Ereignis (Complex Event), das eine Alarmmeldung, eine automatische Aktion oder eine nachgelagerte Weiterverarbeitung auslöst.

Die Kern-Operatoren einer CEP-Engine umfassen Sequenz (A gefolgt von B), Konjunktion (A und B im selben Zeitfenster), Disjunktion (A oder B), Negation (A ohne folgendes B innerhalb eines Zeitraums), Wiederholung (A n-mal) und Zeitfenster-Varianten (Sliding, Tumbling, Session). Teilübereinstimmungen werden im State-Store gehalten, bis das Muster vollständig erfüllt, durch ein negatives Ereignis widerlegt oder durch Timeout verworfen ist.

Der Begriff entstand Anfang der 2000er als eigene Disziplin (David Luckham prägte ihn im Rahmen des Rapide-Projekts an der Stanford University) und wurde zunächst in spezialisierten Engines umgesetzt: [Esper](https://esper.espertech.com/) mit der Event Processing Language (EPL), TIBCO StreamBase und BusinessEvents, Oracle CEP sowie Progress Apama. Heute ist CEP-Funktionalität überwiegend als Bibliothek oder Sub-System in generischen Stream-Verarbeitungs-Engines integriert, etwa als [FlinkCEP](https://nightlies.apache.org/flink/flink-docs-stable/docs/libs/cep/) in Apache Flink oder über den SQL-Standard-Operator MATCH_RECOGNIZE (ISO/IEC 9075-2:2016 Row Pattern Recognition), den unter anderem Flink SQL und Oracle unterstützen.

Architektonisch sitzt die CEP-Komponente im Verarbeitungslayer zwischen einem Message-Broker (Apache Kafka, Amazon Kinesis, Azure Event Hubs) und dem Reaktionslayer (Alerting, Trigger, downstream Topic). Muster-Definitionen werden deklarativ formuliert, entweder in einer Pattern-DSL, in EPL oder über SQL-Erweiterungen. Die typische Latenzklasse liegt im Milli- bis Sekundenbereich und hängt vor allem von der Länge der beobachteten Zeitfenster und den State-Zugriffskosten ab.

Abgrenzung: Stream Processing, Structured Streaming und Rule Engines

CEP wird häufig mit benachbarten Konzepten verwechselt. Die folgende Tabelle klärt die drei zentralen Verwechslungen.

Jede CEP-Verarbeitung ist Stream Processing, nicht jede Stream-Verarbeitung ist CEP.

Beispiel: Betrugserkennung auf Zahlungsströmen

Zahlungs-Ereignisse einer Banking-Plattform laufen über ein Kafka-Topic ein. Eine CEP-Engine wie Flink CEP hält eine Muster-Definition vor: „innerhalb von 60 Sekunden mehr als drei Transaktionen von derselben Karte an geografisch weit entfernten Terminals". Sobald eine passende Sequenz auftritt, emittiert die Engine ein Complex Event SuspectedFraud, das einen Sperrprozess triggert und in einen Alert-Topic geschrieben wird.

Weitere verbreitete Einsatzfelder sind die Erkennung von Netzwerkangriffen über Login-Sequenzen, die Störungserkennung in Industrie-4.0-Umgebungen anhand von Sensor-Mustern über mehrere Maschinen, Handelssystem-Trigger auf Marktkonstellationen sowie Prozess-Compliance mit Prüfung auf fehlende Freigabe-Ereignisse innerhalb definierter Zeitfenster.