Kontinuierliche Kontrolle

Inhaltsverzeichnis

Unternehmen werten ihre Prozesse nahezu ausschließlich auf der Basis von Informationen aus einem Data Warehouse aus. Die Analyse erfolgt offline nach Prozessende, dann, wenn „das Kind bereits in den Brunnen gefallen“ ist. Wer dynamische Vorgänge bereits zur Laufzeit überwachen und anpassen wollte, benutzte meist selbst gestrickte Skripte, die den Nachteil haben, unflexibel und nicht standardisiert zu sein. Wegen der zunehmenden Dynamik heutiger Prozesse floss in den letzten Jahren viel Forschungsgeld in eine Querschnittstechnik mit dem Namen Complex Event Processing (CEP). Erste Produkte aus dieser Ecke verrichten bereits erfolgreich ihren Dienst in industriellen Projekten [2, 3].

Ein CEP-System bietet eine standardisierte Softwareinfrastruktur zum kontinuierlichen Kontrollieren und Steuern zeitkritischer Prozesse in Echtzeit. Mögliche Einsatzgebiete sind insbesondere der elektronische Handel, die Logistik, die Netzwerküberwachung sowie das Energiemanagement. Beispielsweise könnte man Betrugsversuche mit Kreditkarten erkennen, Serviceverträge überwachen oder verschiedene Aktivitäten im Netzwerk auswerten. Für die effektive Prozesskontrolle müssen entsprechende Anwendungen in der Lage sein, eine große Menge einströmender Daten bezüglich fachlicher und zeitlicher Kriterien fortwährend zu analysieren. Datenbankgestützte Applikationen können das nicht. Aufgrund der vielfältigen Einsatzszenarien und der ersten vielversprechenden Erfolge von CEP-Systemen prognostizieren Analysten dieser Technik ein großes Marktpotenzial. Einige glauben sogar, dass sie die Informationslandschaft ebenso umkrempeln wird wie seinerzeit die relationalen Datenbanksysteme (DBMS).

CEP-Systeme beruhen jedoch auf einem fundamental anderen Paradigma – sie konkurrieren also nicht mit den DBMS. Letztere sind primär darauf ausgelegt, auf persistenten Datenbeständen vom Benutzer einmalig gestellte Anfragen zu beantworten. CEP stellt diesen Ansatz auf den Kopf. Ähnlich wie bei RSS-Feeds abonniert die CEP-Anwendung Datenströme bei einer oder mehreren unabhängigen Informationsquellen. Die Datenströme bestehen aus einer potenziell unendlichen Folge zeitlich geordneter Elemente beziehungsweise einfacher Events, die neben den fachlichen Informationen über einen Zeitstempel verfügen. Ein Beispiel für einen Datenstrom sind die Nachrichten, die zwischen Applikationen auf einem Enterprise Service Bus ausgetauscht werden und beispielsweise per Zeitstempel bekanntgeben, wann der Sender die Nachricht erzeugt hat (Abbildung 1) [1].

CEP: Immer im Dienst

Hauptaufgabe eines CEP-Systems ist die ständige Extraktion von Informationen aus heterogenen Datenströmen. Es filtert Events, aggregiert sie und korreliert sie mit Ereignissen aus anderen Strömen. Die Ergebnisse bezeichnet man als komplexe Events, womit der Name „Complex Event Processing“ erklärt wäre. CEP setzt dabei nicht auf traditionelle Datenbanktechnik, sondern auf neuartige Algorithmen, die im Hauptspeicher ablaufen und inkrementell die eintreffenden Elemente verarbeiten. Der Endbenutzer formuliert die notwendigen Schritte in Form „kontinuierlicher“ Anfragen.

In diesem Punkt unterscheiden sich die Systeme der verschiedenen Anbieter maßgeblich. Einige führen eine eigene Event-Sprache ein, andere erweitern die standardisierte Datenbankanfragesprache SQL. Unabhängig davon gilt, dass eine Anfrage in einem CEP-System nicht einmalig ausgewertet wird, sondern so lange im System bleibt, bis der Benutzer sie explizit entfernt. Das CEP-Programm wertet registrierte Anfragen permanent aus und leitet die Ergebnisse automatisch weiter. Die Events fließen somit durch ein Netz von kontinuierlichen Anfragen, bis sie mittels eines Adapters die externen Anwendungsprogramme (auch als Datensenken bezeichnet) erreichen, die sich für die Anfrage angemeldet haben. Die Senken können aufgrund der eintreffenden Events weitere Aktionen auslösen, beispielsweise in einer Kreditapplikation einen Prozess anstoßen, der aufgrund des komplexen Events „ungewöhnliche Transaktion“ die Karte sperrt.

Der Weg in den Markt

Bei der Entwicklung von CEP-Anwendungen gibt es regel- sowie SQL-basierte Ansätze. Der Fokus dieses Artikels liegt auf den Letzteren, auf die sich auch die Forschung in den letzten Jahren konzentrierte. Im Kern geht es darum, ein um zeitliche Konstrukte erweitertes SQL zur Verfügung zu stellen, das als Continuous Query Language (CQL) bezeichnet wird. Aus einigen Projekten, etwa der Stanford University sowie der Universität in Marburg, entstanden inzwischen kommerzielle CEP-Anbieter. Gegenüber regelbasierten Systemen bieten SQL-Anwendungen neben einer standardisierten Benutzerschnittstelle Vorteile bei der Performance, die sich aus der Adaption von bewährten DBMS-Techniken wie Anfrageoptimierung ergeben.

Auf dem Zeitstrom

Als Beispiel soll hier ein einfaches Online-Auktionssystem mit drei Datenströmen dienen, die denen des im Forschungsumfeld bekannten NEXMark-Benchmark entsprechen (siehe iX-Link):

Bid: itemID, bidderID, bid_price 
 OpenAuction: id, itemID, sellerID, start_price
 Closed Auction: id, itemID, bid
 

Anders als in einer Datenbankrelation ist „Zeit“ ein implizites Attribut der Datenströme. Ihr Wert wird von der Applikationssoftware gesetzt, durch die Eingabeadapter angepasst und ist nicht mehr veränderbar. Die folgenden (bewusst einfach gehaltenen) Anfragen könnten in einem Auktionsszenario interessant sein:

• Melde die Gebote zu dem Artikel mit itemID = 42.
• Melde die Auktionen, die innerhalb einer Stunde geschlossen wurden.
• Melde jede Minute die Anzahl der Gebote innerhalb der letzten 15 Minuten für den Artikel mit itemID = 42.
• Melde die Artikel, bei dem in zwei aufeinanderfolgenden Geboten das zweite Gebot deutlich über dem ersten Gebot liegt.

Das Beispiel geht davon aus, dass die Datenquellen an einen CEP-Server angebunden sind und ein CQL-Client zur Verfügung steht (Abbildung 2). Über den Client formuliert der Anwender seine Anfragen und registriert sie beim Server. Anschließend kann er entsprechende Senken auf den Anfragen an- oder abmelden. Die folgenden Anfragen sind im CQL-Dialekt des CEP-Anbieters RTM Realtime Monitoring verfasst, der weitgehend SQL2003-kompatibel ist:

SELECT Bid.* FROM Bid WHERE itemID = 42;
 

Das Statement unterscheidet sich nicht von einer gewöhnlichen Datenbankanfrage, nur dass hier die FROM-Klausel einen Datenstrom und keine Relation anspricht. Und die Ergebnisse werden wiederum in Form eines Stroms von Events zur Verfügung gestellt.

Wesentlich komplizierter ist die zweite Anfrage, denn es kommt eine Verknüpfung (Join) zwischen den Datenströmen OpenAuction und ClosedAuction ins Spiel. Ein Join zwischen potenziell unendlichen Datenströmen ist zwar nicht möglich, es lässt sich jedoch der Umstand ausnutzen, dass der Benutzer sich nur für das Ergebnis interessiert, bei dem die beiden Events in den beteiligten Datenströmen zeitlich nah beieinanderliegen. Diese Eigenschaft kann der Entwickler durch ein sogenanntes gleitendes Zeitfenster spezifizieren (umgesetzt mit dem WINDOW-Konstrukt), dass er jedoch in der FROM-Klausel an den Datenstrom OpenAuction anhängt. Die Anfrage lautet jetzt:

SELECT OpenAuction.*
 FROM OpenAuction WINDOW (RANGE 1 HOURS) O, Closed Auction C
 WHERE O.itemID = C.itemID;

Das Fenster weist dem Event O aus OpenAuction eine Lebensdauer von einer Stunde zu. O wird mit Event C aus ClosedAuction verknüpft, wenn der Zeitstempel von C innerhalb der Lebensdauer von O liegt und zusätzlich die Join-Bedingung erfüllt ist.

Anzahl der Ergebnisse begrenzen

Beim dritten Statement handelt es sich um eine Aggregatanfrage, die, ähnlich wie beim Join, das Aggregat über ein gleitendes Fenster von 15 Minuten berechnet und jede Minute ein Ergebnis ausgeben soll. Die Anfrage formuliert man wie in SQL, reichert sie jedoch mit dem SLIDE-Konstrukt an, damit das Resultat tatsächlich nur einmal pro Minute ausgegeben wird. Ohne diese Einschränkung würde bei jeder Änderung des Aggregats (also beim Eintreffen eines neuen Events) ein neues Ergebnis entstehen, was zu einer riesigen Menge von Ergebnissen führen kann und zudem wesentlich aufwendiger zu berechnen ist. In CQL sieht die Anfrage so aus:

SELECT COUNT(*) 
 FROM Bid WINDOW (RANGE 15 MINUTES SLIDE 1 MINUTE)
 WHERE itemID = 42;

Mit einer kleinen Erweiterung berechnet der Entwickler für alle Artikel das jeweilige Aggregat. Hierzu setzt er statt der WHERE- eine GROUP-BY-Klausel mit dem Attribut itemId ein.

Die nächste Anfrage unterscheidet sich von den bisherigen, da sie nach Mustern in einem Datenstrom sucht. Muster werden typischerweise über reguläre Ausdrücke beschrieben. CQL bietet die Funktion über eine Pattern-Klausel an.

SELECT old_price
 FROM (SELECT Bid.* FROM Bid WHERE itemID = 42) AS Filter
 MATCHING (MATCHING (
 MEASURES old_price INTEGER
 PATTERN 'ab'
 DEFINE a DO old_price = Filter.bid_price
 b AS old_price*1.1 < Filter.bid_price
 );

Das Statement bestimmt zunächst in einer Unteranfrage alle Gebote für den Artikel mit itemId = 42. Die anschließende MATCHING-Klausel sucht nach Paaren von aufeinanderfolgenden Geboten, bei denen das zweite um mehr als zehn Prozent über dem ursprünglichen liegt. Man beachte, dass das System die im MEASURES-Konstrukt definierten Zustände zwischenspeichern und bei der Mustersuche wiederverwenden kann. Die Erweiterung, die CQL erst in den letzten Jahren erhielt, bietet Funktionen, die zuvor den regelbasierten CEP-Systemen vorbehalten waren.

Die bisherigen Ausführungen zeigen, dass es grundsätzlich einfach ist, die gewünschte Geschäftslogik mit CQL-Anfragen einzurichten. Die Sprache bietet weitere vielfältige Möglichkeiten. Wahrscheinlich wird die leicht unterschiedliche Syntax und Semantik der verschiedenen CQL-Dialekte später in einem Standard zusammengeführt werden.

Der Zeitbegriff ist das A und O in CEP-Systemen, da der Zeitstempel jedes Stromelements bei nahezu allen Anfragen relevant ist. Oft scheitern Projekte, weil ihnen ein falsches Verständnis von Zeit zugrunde liegt, und leider (populäre) CEP-Systeme existieren, die nicht Anwendungszeit per Default unterstützen, sondern Systemzeit.

Realität ist zeitabhängig

Von Systemzeit spricht man, wenn die Elemente einer Datenquelle beim Eintreffen in das CEP-System ihren Zeitstempel erhalten. Anwendungszeit wird, wie der Name schon sagt, durch die Anwendung gesetzt und ist somit für den Benutzer klar definiert und interpretierbar. Systemzeit und Anwendungszeit sind zwei Zeitdimensionen, die zu verschiedenen Anfrageergebnissen führen. Jedoch lässt sich bei der Verwendung von Applikationszeit sicherstellen, dass bei einer gleichen Eingabe tatsächlich dieselbe Ausgabe erzeugt wird. Diese Eigenschaft ist – Stichwort Revisionssicherheit – in nahezu allen CEP-Anwendungen essenziell. Und das kann die Systemzeit nicht leisten.

Veranschaulichen lässt sich die Sache anhand des Join aus Anfrage zwei: Da die Events C und O mit der gleichen itemID bezüglich Systemzeit genau eine Stunde auseinanderliegen, entsteht ein Join-Ergebnis. Würde aufgrund von Netzwerklatenzen das Element C nur eine Sekunde später eintreffen, hätte dies zur Folge, dass kein Resultat zustande kommt. Der Einsatz von CEP-Systemen, die lediglich Systemzeit kennen, ist deshalb nicht zu empfehlen. Ein solches Produkt ist zum Beispiel das frei verfügbare Esper, das sich durch Nachimplementierung von Anwendungszeit jedoch aus der Affäre ziehen könnte. Allerdings wäre dieser Akt alles andere als einfach.

Diverse Quellen bilden den Strom

Eine weitere Anforderung an CEP-Systeme stellt die flexible Datenintegration dar. Informationen müssen sich aus verschiedenen Quellen einspeisen und Ergebnisse anwendungsspezifisch aufbereiten lassen. Zu diesem Zweck stellen die Anbieter typischerweise Adapter für gängige Datenquellen und -senken zur Verfügung, zum Beispiel für JDBC/ODBC, JMS, Webservices, Sockets, SNMP und Excel. Insbesondere die unkomplizierte Interaktion mit Datenbanken und Data Warehouses ist wichtig, da die kontinuierlich verarbeiteten Daten oftmals mit gespeichertem Kontextwissen angereichert werden müssen. Neben den Adaptern sind aus Sicht des Fachanwenders Management Cockpits interessant, in denen er die Ergebnisse der Anfragen in Echtzeit betrachten kann. Ein künftiges Thema dürfte der Einbezug mobiler Endgeräte sein.

Welche Möglichkeiten zur Erkennung komplexer Events bestehen und ob sich die entsprechenden Geschäftsprozesse einfach abbilden lassen, sind ebenfalls berechtigte Fragen. Wie bereits erwähnt, ist die Validität und Reproduzierbarkeit der Ergebnisse unerlässlich. SQL-basierte Ansätze bieten auch deswegen Vorteile, weil Entwickler mit SQL-Kenntnissen ohne großen Aufwand CEP-Anwendungen erstellen können. Das System muss darüber hinaus in der Lage sein, neue Geschäftsprozesse und Datenquellen im laufenden Betrieb einzubinden.

Um die stetig anwachsenden Datenmengen in Echtzeit zu verarbeiten, muss ein CEP-System schnell und skalierbar sein. Das im Hauptspeicher stattfindende Verarbeiten der Datenströme sollte daher Multi-Threading unterstützen, um moderne Multi-Core-CPUs möglichst effizient auszunutzen. Für CEP-Anwendungen auf SQL-Basis ist die automatische Optimierung von CQL-Anfragen ein weiterer wichtiger Faktor. Ein Anfrageoptimierer erkennt beispielsweise identische Teile von CQL-Anfragen und berechnet sie nur einmal (Subquery Sharing). Aus Skalierungsgründen sollte das CEP-System Anfragen über mehrere Server verteilt ausführen können. Die Anbieter geben in der Regel die Verarbeitungskapazität mit mehreren Hunderttausend Events pro Sekunde auf modernen Rechnerplattformen an.

Hochverfügbarkeit ist für ein CEP-System ebenfalls essenziell. Denn da die Daten nur flüchtig im Hauptspeicher vorliegen, hätte ein Systemausfall fatale Folgen. In diesem Kontext sind Recovery-Funktionen ebenfalls vonnöten. Das System muss beim Wiederanlauf die Verbindung zu den Datenquellen automatisch wiederherstellen und die zuletzt gelaufenen Anfragen selbsttätig neu starten. Idealerweise werden die während des Ausfalls einlaufenden Daten in einem persistenten Speicher zwischengelagert, damit keine Ergebnisse verloren gehen.

CEP-Anwendungen müssen hohe Lasten verkraften. Um die Stabilität des Systems zu gewährleisten, benötigt man ein zusätzliches Monitoring. Zu seinen Aufgaben gehört es etwa, Lastspitzen frühzeitig zu erkennen, ressourcenfressende Anfragen zu identifizieren und die aktuelle Auslastung zu berechnen. Selbstverständlich müssen sich CEP-Systeme in eine gegebene IT-Landschaft integrieren lassen und mit gegebenen Anwendungen interagieren können.

Goldene Zeiten für CEP

Analystenhäuser wie Forrester und Gartner sehen CEP auf dem Weg vom Nischenmarkt in den Mainstream. Als Indikator gilt, dass alle großen Hersteller inzwischen mitmischen. Neben dem Pionier TIBCO haben auch Oracle, IBM und Microsoft erste CEP-Funktionen im Angebot. Aufkäufe von spezialisierten kleineren Anbietern wurden ebenfalls schon vermeldet. IBM verleibte sich beispielsweise AptSoft ein, und Informatica übernahm Agent Logic.

Neben den Generalisten haben sich etliche Spezialisten etabliert. Bei einigen handelt es sich um Ausgründungen aus dem universitären Umfeld. Dazu zählen StreamBase, Aleri/Coral8, RTM Realtime Monitoring und Progress Software (Apama). Die Wurzeln der drei zuerst aufgeführten gehen zurück auf die oben genannten Forschungsprojekte. Im Bereich Open Source ist EsperTech bis dato allein, wobei das Unternehmen verschiedene Lizenzmodelle anbietet. Beim Funktionsumfang der einzelnen Produkte ergibt sich kein einheitliches Bild, da sich bisher keine Standards entwickelt haben. Einige Protagonisten offerieren erste vorkonfigurierte CEP-Anwendungen vorwiegend für den Finanzsektor [3].

Der CEP-Markt ist den Kinderschuhen entwachsen, die Zahl entsprechender Projekte dürfte weltweit mindestens im mittleren dreistelligen Bereich liegen. Die meisten davon laufen in nordamerikanischen Finanzanwendungen. Hierzulande und im übrigen Europa hat CEP noch nicht den gleichen Stellenwert erlangt. Ein Problem der Technik liegt in ihrer weitgehenden Unbekanntheit sowie dem Mangel an Experten für das Fachgebiet. Unstrittig dürfte jedoch sein, das CEP mehr ist als eine Modeerscheinung und das Potenzial zur Querschnittstechnologie mitbringt.

Dr. Bernhard Seeger

ist Professor am Fachbereich Mathematik und Informatik der Philipps-Universität in Marburg sowie Gründungsmitglied der RTM Realtime Monitoring GmbH. Er ist Keynote-Sprecher auf der CEPconf, die vom 23.-24. Februar in München stattfindet.

Literatur

Mehr Infos

iX-TRACT

• Mit Complex Event Processing (CEP) lassen sich Datenströme in Echtzeit kontinuierlich auswerten und beeinflussen.
• Anfragen via SQL beziehen sich immer auf einen bestimmten Zustand der Datenbank. Mit der Continuous Query Language (CQL) kann der Entwickler Anfragen auf Datenströme unter Berücksichtigung einer Zeitdimension formulieren.
• Analysten sagen CEP eine goldene Zukunft voraus und erwarten, dass diese Technik die Informationswelt tiefgreifend verändern wird.

[1] Alexander Schatten, Josef Schiefer; IT-Architekturen; Ungeplante Wege; Ereignisbasierte Systeme verbessern SOA

[2] K.M. Chandy, W.R. Schulte; Event Processing: Designing IT Systems for Agile Companies; Osborne, 2009

[3] N. Levitt; Complex-Event Processing Poised for Growth. Computer, Volume 42, No. 4, 2009

[4] T. Greiner, C. Heinz; Business Activity Monitoring mit Stream Mining am Fallbeispiel TeamBank AG. HMD-Praxis der Wirtschaftsinformatik, 2009

www.ix.de/ix1002131 (jd)