Event Stream Processing & Complex Event Processing Dirk Bade Die Folien sind angelehnt an eine Präsentation der Orientation in Objects GmbH, 2009 Motivation Business Activity Monitoring Sammlung, Analyse und Präsentation von Echtzeitdaten, die bei der Ausführung von Aktivitäten in Organisationen (+ Kunden und Partner) anfallen. Ziele Überwachen des Status und der Ergebnisse verschiedener Operationen, Prozesse und Transaktionen Schnelle Problemidentifikation, z.b. Erkennen von Überlast Überschreitung von Service-Level-Agreements #2
Motivation Real Time Business Intelligence The process of delivering information about business operations without any latency [Wikipedia 2009] Ohne Latenz? Datenlatenz Analyselatenz Aktionslatenz #3 Motivation Real Time Business Requirements Sehr hohe Anforderungen TPC-C Spitzenreiter: IBM, mit 101.419 Transaktion/Sek. OLTP-Datenbanken in der Praxis: ebay, Amazon 1,000-10,000 TPS International web application 100-1,000 TPS Small internal OLTP 10-100 TPS Sehr hohe Anzahl an Events (>> 100.000) #4
Event-driven Architecture Vier logische Ebenen 1. Event Generator 2. Event Channel 3. Event Processing Engine 4. Downstream event-driven Activity Grundprinzipien Lose Kopplung Asynchroner Nachrichtenaustausch #5 Event-driven Architecture #6
Event-driven Architecture Event Bedeutende Zustandsänderung Quittierung einer Autorisierungsprüfung Antwortzeit der letzten Anfrage Messwert eines Sensors im Haus Aktienpreisänderung Beginn/Ende der Ausführung eines Dienstes #7 Event Processing Simple Event Processing Betrifft Ereignisse, die direkt in Beziehung zu einer bestimmten, messbaren Zustandsänderung stehen, z.b. Temperaturänderung Event Stream Processing Betrifft Ströme primitiver Ereignisse Nicht jedes Ereignis ist von Interesse, sondern der Strom selbst Z.B. Temperaturänderung innerhalb eines Zeitraumes Complex Event Processing Komplexe Muster (z.b. kausale, temporale oder räumliche Beziehungen) in verschiedenen Ereignisströmen erkennen. Z.B. Temperaturoszillation innerhalb eines Zeitraumes nachdem die Heizung eingeschaltet wurde #8
Esper Komponente für ESP & CEP Anwendungen In Java und.net realisiert SQL-ähnliche Event Pattern Language Hoch performant: 500.000 Events/Sek., < 3ms Latenz mit 1000 registrierten Statements auf 2 Ghz. Dual-CPU http://esper.codehaus.org Umfangreiche Dokumentation Viele Beispiele und Abfragemuster #9 Esper Verarbeitungsmodell Kontinuierliche Verarbeitung Datenbank inside-out Anfragen in EQL/EPL Anfragen werden bei EP Runtime registriert Listener registrieren sich für Anfragen Ereignisse fließen durch die Anfragen Push-basierte Listener-Benachrichtigung #10
Esper Big Picture #11 Esper Esper 1x1 (1) String expression = SELECT * FROM Withdrawal ; (2) EPServiceProvider engine = EPServiceProviderManager.getDefaultProvider(); (3) EPStatement stmt = engine.getepadministrator().createeql(expression); (4) stmt.addlistener(new UpdateListener() { public void update(eventbean[] newevents, EventBean oldevents) { /* do something */ } }); (5) engine.getepruntime().sendevent(new Withdrawal(31337)); #12
Esper EQL/EPL Analogie zu SQL Ereignisströme sind Tabellen Ein Ereignis entspricht einem Datensatz Attribute eines Ereignisses entsprechen Datenfeldern [insert into insert_into_def] select select_list from stream_def [as name] [, stream_def [as name]] [where search_conditions] [group by grouping_expression_list] [having grouping_search_conditions] [output output_specification] [order by order_by_expression_list] [limit num_rows] #13 Esper EQL Event-Repräsentation POJO Maps XML EQL-Anfragenlassensichgrobeinteilenin ESP-Anfragen CEP-Anfragen #14
ESP-Anfragen ESP: Abfragen über Einzelne Ereignisse Ereignisse in einem Zeit-Fenster Ereignisse in einem Mengen-Fenster #15 ESP-Anfragen SELECT * FROM Withdrawal #16
ESP-Anfragen SELECT * FROM Withdrawal.win:length(5) #17 ESP-Anfragen SELECT * FROM Withdrawal(amount>=200).win:length(5) #18
ESP-Anfragen SELECT * FROM Withdrawal.win:time(4 sec) #19 CEP-Anfragen CEP: Abfragen über Muster zwischen Ereignissen / Ereignisströmen Verwendeter Begriff pattern select * from pattern [ every s=startevent -> a=abortevent(a.id=s.id) where timer:within(30sec) ] Wiederholungsangabe: every Logische Operatoren: and, or, not Kausaler Operator: -> (followed-by) Guards: timer:within() Observer: timer.interval() oder timer.at() #20
CEP-Anfragen Guards & Observer (A or B) where timer:within(5sec) Ein A oder B in den nächsten 5 Sekunden (every A) where timer:within(10sec) Alle A in den nächsten 10 Sekunden A->timer:interval(10sec) Nach A 10 Sekunden warten every timer:at(5,8:17,*,*,*) Alle 5 Minuten nach der vollen Stunde von 8-17 Uhr #21 Beispiel-Szenario Self-Service Terminal Event-Typen: Checkin, Cancelled,Completed, OutOfOrder, LowPaper, Status select * from pattern [ every a=checkin -> (OutOfOrder(term.id=a.term.id) and not (Cancelled(term.id=a.term.id) or Completed(term.id=a.term.id)) )] select 'terminal 1 is offline' from pattern [every timer:interval(60 sec) -> (timer:interval(65 sec) and not Status(term.id = 'T1'))] insert into CountPerType select type, count(*) as countpertype from BaseTerminalEvent.win:time(10 minutes) group by type output all every 1 minutes #22