Reduzierung der Netzwerklast von CEP unter Zuhilfenahmevon

ProjINF - Reduzierung der Netzwerklast von CEP unter
Zuhilfenahme von Datenbanken
Benjamin Braun† , Karsten Schatz‡ , und Vethiga Srikanthan∗
Abstract— Die Bedeutung von Complex Event Processing (CEP) nimmt heutzutage immer weiter zu. Sei es bei der Analyse bzw.
Überwachung von Börsendaten oder bei der Beobachtung von Geschäftsprozessen. Für solche Fälle verwendet man meist stark
verteilte Systeme, da zum Beispiel bei der Überwachung des Weltmarktes Daten aus vielen verschiedenen Quellen weltweit benötigt
werden. In aktuellen CEP-Systemen werden jedoch zumeist alle erzeugten Daten übertragen, um die Verfügbarkeit aller relevanten
Werte zu gewährleisten. Dies kann unter Umständen eine sehr hohe Netzwerklast verursachen. In dieser Arbeit präsentieren wir
einen Ansatz, der die anfallenden Daten in Klassen von hochfrequenten und niederfrequenten Datenströmen einteilt, um mit Hilfe
dieser Einteilung die Netzwerklast zu verringern. Hierbei werden die hochfrequenten, also für die Netzwerklast schlechteren, Datenströme nicht versandt, sondern in einer Datenbank zurückgehalten. Wird das Eintreffen von niederfrequenten Daten detektiert,
werden die relevanten hochfrequenten Daten aus der Datenbank abgefragt. Bei entsprechendem Verhältnis von niederfrequenten zu
hochfrequenten Daten kann dies die Netzwerklast um über 90% vermindern, wie wir auch in einigen Experimenten zeigen.
Index Terms—Complex Event Processing, Verringerung von Netzwerklast.
1 E INFÜHRUNG
Complex Event Processing (kurz CEP) bezeichnet Techniken, Methoden und Werkzeuge, die Ereignisse zeitnah verarbeiten. Dabei werden
sogenannte Events bearbeitet. Es gibt zwei Arten von Events: Einfache Events und komplexe Events. Einfache Events enthalten Werte
von z.B. Sensoren. Werden diese Events vom CEP-System gefiltert,
zusammengefügt und miteinander verglichen, stellen die Ergebnisse
dann komplexe Events dar. Diese komplexen Events können wiederum zu einem komplexen Event weiterverarbeitet werden. Das CEPSystem verarbeitet Eventströme von einer oder mehreren Informationsquellen. Diese Eventströme enthalten zeitlich geordnete Werte, also Events, die sowohl eine fachliche Information, als auch einen Zeitstempel enthalten.
samte CEP-Systems besteht aus einem Netzwerk von mehreren CEPEngines, die miteinander kommunizieren.
Bei ständiger Übertragung der Events ist die Netzwerklast sehr
hoch. Im System werden Events übertragen, die für die Erkennung von
komplexen Events nicht notwendig sind. Es muss eine Lösung gefunden werden, durch die die Last im Netzwerk reduziert werden kann,
ohne relevante Informationen zu verlieren, indem man diese nicht relevanten Events nicht überträgt.
In unserem Anwendungsbeispiel soll die Temperatur das hochfrequente Event und der Niederschlag das niederfrequente Event sein.
Ein Niederschlagswert über 10l/m2 tritt nicht so häufig auf, wie ein
Temperaturwert unter 4 ˚ C. Es entstehen also viele Temperaturwerte,
die nicht relevant für den Schneefall sind, da der Niederschlag nicht
so häufig über 10l/m2 ist. Es müsste also genügen die Temperatur nur
bei einem Niederschlagswert über 10l/m2 auszulesen und auf die Bedingung für ein komplexes Event hin zu prüfen.
Um die Netzwerklast zu reduzieren, müssen wir also einen Weg
finden, bei dem Ereignisse, die häufig auftreten, abgespeichert und bei
Bedarf entnommen werden. Ereignisse, die nicht so häufig auftreten,
sollen kontinuierlich weitergeleitet werden. In unserem Fall sollte der
Temperaturwert nicht verloren gehen, aber auch nicht ständig übertragen werden. Hier führen wir eine Datenbank ein. In dieser Datenbank
werden Temperaturwerte gespeichert. Sie werden also abrufbereit gelagert. Tritt dann ein Niederschlagswert ein, bei dem Schneefall möglich ist, wird die Temperatur aus der Datenbank erfragt. So werden nur
die Events übertragen, die relevant sein könnten.
Im Folgenden klären wir in Sektion 2 (Systemmodell) einige grundlegenden Begriffsbedeutungen und die allgemeine Funktion unseres
Systems. In Sektion 3 geben wir eine genaue Erklärung für unser System wie Datenbank und Trigger genau funktionieren. Zusätzlich erläutern wir auch Hindernisse, die wir dabei entdeckt haben. In Sektion
4 stellen wir unsere Testergebnisse für unser System dar. Hierbei betrachten wir sowohl die Netzwerklast, als auch die Berechnungsdauer
unseres Systems im Vergleich zur Methode ohne Datenbank. In Sektion 5 geben wir noch einen Überblick über verwandte Arbeiten auf
diesem Gebiet und stellen dar, wie die aktuelle Situation aus wissenschaftlicher Sicht ist. In Sektion 6 fassen wir unsere Arbeit zusammen
und geben einen kurzen Ausblick auf Dinge, mit der wir unsere Arbeit
erweitern könnten.
Abbildung 1: Beispiel für CEP
Betrachten wir nun folgende Situation: Der Winterdienst möchte
anhand von Wetterdaten bestimmen, ob Schneegefahr besteht. Dazu
benötigt man die aktuelle Temperatur und die Menge des Niederschlags. Diese Werte werden als einfache Events empfangen. Man
muss jedoch festsetzen, bei welchen Werten Schnee möglich ist. Dazu
verwendet man komplexe Events, die z.B. aussagen, dass der Niederschlag über 10l/m2 und die Temperatur unter 4 ˚ C sein muss.
Um komplexe Events zu berechnen, werden Operatoren verwendet. Ein Operator nimmt einfache Events entgegen und überprüft, ob
die Bedingungen für komplexe Events erfüllt sind. Sind diese Bedingungen erfüllt, so meldet der Operator das Eintreten des komplexen
Events. Um Operatoren zu beschreiben, werden in der Praxis Event
Processing Languages (EPLs) verwendet, die in der Regel ähnlich
zu SQL sind. Operatoren wiederum werden in CEP-Engines ausgeführt. In dieser Arbeit wird als CEP-Engine Esper verwendet. Das ge-
2
†
Benjamin Braun
‡ Karsten
Schatz
∗ Vethiga
Srikanthan
1
S YSTEMMODELL
Das System, das uns vorliegt, ist ein CEP-System. Es ist ein Netzwerk
von Operatoren, welche durch Eventströme verbunden sind. Über diese Eventströme werden Events verschickt. Sowohl der Sender, als auch
Abbildung 2: Systemmodell
der Empfänger sind also Operatoren, die in CEP-Engines ausgeführt
werden. Der Operator, der als Sender fungiert, verschickt die gemessenen oder erzeugten Werte. Der Empfänger erhält die in Events enthaltenen Werte und verarbeitet diese zu neuen, komplexen Events. Leitet
der zweite Operator das Event erneut weiter, funktioniert in diesem
Fall der Operator sowohl als Empfänger, als auch als Sender. Somit haben wir eine Verarbeitungskette. Die Verbindung zwischen allen Sendern und Empfängern ist also unser Netzwerk (Abbildung 2).
Operatoren im System implementieren somit eine Funktion, die den
Eingang auf den Ausgang bildet. Seien e1 und e2 Events, die vom
Sender verschickt werden. Somit führen die Operatoren folgendes aus:
f (e1 , e2 ). Doch bei diesem System ist erkennbar, dass die Last auf den
Eventströmen bei ständiger Übertragung sehr hoch ist.
Unser Ziel ist es, eine Lösung zu finden, durch die bereits nahe dem
Sender Events abgefangen werden und somit eine geringe Netzwerklast zu erreichen. Dazu wird für jeden Eventstrom überprüft, ob eine
kontinuierliche Übertragung notwendig ist, oder ob die Netzwerklast
durch zurückhalten des Stroms effektiv optimiert werden kann.
Abbildung 3: Aufbau unseres Systems
nach der ersten Esper-Instanz die Ansteuerung der Datenbank durchführt. Sobald ein niederfrequentes Event durch die erste CEP-Instanz,
der Esper-Instanz, festgestellt wird, wird eine SQL-Abfrage für die
Datenbank vom Trigger erstellt und durchgeführt. Diese erfragt von
der Datenbank alle für die registrierten komplexen Eventbeschreibungen nötigen Events. Nach Erhalt der Events aus der Datenbank werden
diese in den Eventstrom der zweiten Esper-Instanz eingespeist gefolgt
vom verursachenden Event. Die zweite Esper-Instanz überprüft an den
Events aus dem zweiten Eventstrom, ob die Bedingungen für ein komplexes Event erfüllt sind und teilt dem System, wie bereits erwähnt,
deren Auftreten mit.
Das Netzwerk ist beim verteilten CEP üblicherweise stark ausgelastet und soll mit Hilfe der Datenbank entlastet werden. Die Datenbank
enthält einfache Events, die momentan nicht zur Weiterverarbeitung
benötigt werden. Alle Events werden nach der Reihe, wie sie bei der
Datenbank eintreffen, sortiert. Jedes Event bekommt eine ID und einen
Zeitstempel, die zur Weiterverarbeitung benötigt werden.
3 S YSTEMANSATZ
Um unseren Ansatz zu beschreiben, betrachten wir im Folgenden
einen einzelnen Operator des CEP-Systems. Sei o3 aus Abbildung 2
der betrachtete Operator. Dieser besitzt zwei Eingangsströme, welche
verarbeitet werden. Einer dieser Eingangsströme ist hochfrequent (angenommen o1 ), der andere niederfrequent (o2 ).
Da immer Events beider Ströme gekoppelt und gemeinsam verarbeitet werden, werden nur wenige Events des hochfrequenten Stroms
wirklich verwendet. Deshalb können wir alle Events des hochfrequenten Stroms in einer Datenbank abspeichern und bei Bedarf entnehmen.
Niederfrequente Events werden, wie in Abbildung 3 skizziert, an einen
Trigger übergeben, jedoch nicht in der Datenbank gespeichert. Zuvor
werden diese Events von einer erste CEP-Engine (Engine Instanz 1)
überprüft. An dieser Stelle wäre nicht zwangsläufig eine CEP-Instanz
notwendig um das schlichte Eintreffen von Events zu detektieren, jedoch kann hier eine Vorfilterung durchgeführt werden, um später die
Netzwerklast noch weiter einschränken zu können. Wird nun ein niederfrequentes Event festgestellt, werden sowohl das niederfrequente
als auch das hochfrequente Event aus der Datenbank von einer zweiten CEP-Engine (Engine Instanz 2) überprüft, um festzustellen, ob die
Bedingungen für ein komplexes Event erfüllt sind. Deren Auftreten
wird dann dem System mitgeteilt.
4.1
Datenbank
Die Datenbank ist in diesem Konzept einzig und allein zur Abspeicherung von schnell hintereinander eintreffenden Events ausgelegt. Esper bietet drei unterschiedliche Eventrepräsentationen an. Die am einfachsten umzusetzende dieser drei ist das Java-Objekt. Die Abspeicherung von XML-Events beispielsweise, würde eine XML-Datenbank
erfordern, was nachweislich den Netzwerktraffic in die Höhe treiben würde, da zusätzlich zu den reinen Daten auch noch die XMLBeschreibung übertragen werden müsste.
Es existiert eine ganze Reihe von Java-Bibliotheken, die die Abspeicherung von Objekten in Datenbanken anbieten. Unsere Wahl fiel
auf EclipseLink. Die einzige Restriktion dieser Bibliothek ist die Einschränkung auf weitgehend primitive Datentypen. Events bestehen
fast definitionsgemäß nur aus primitiven Werten bzw. Datentypen, somit ist dies nicht hinderlich. Außerdem muss es sich bei dem übergebenen Objekt um ein JavaBean handeln. Diese spezielle Form eines
Java-Objekts stört Esper nicht in dessen Ausführung, bietet aber für
die weitere Verarbeitung im Trigger noch weitere Vorteile, womit dies
4 S YSTEMIMPLEMETIERUNG
Der in Kapitel 3 vorgestellte Ansatz wurde prototypisch implementiert. Dabei kamen die Esper Korellationsengine als CEP-Engine, und
eine SQL Datenbank zum Einsatz. Dazu wurde ein Trigger erstellt, der
2
auch keine wirkliche Einschränkung darstellt. So wird für jede Art von
schnellem Event eine eigene Tabelle in der Datenbank angelegt. Dies
vereinfacht die spätere Abfrage der Events stark.
Es ist jedoch notwendig, noch zwei weitere Restriktionen einzuführen. Da wir mit der Einspeicherung in der Datenbank quasi die
Einspeisung des Events in Esper modellieren wollen und Esper sich
die Ankunftszeit eines jeden Events merkt, muss jedes Event einen
Zeitstempel besitzen, welcher bei Einspeicherung in die Datenbank
gesetzt wird. So können später Anfragen, die sich auf die Ankunftszeit
beziehen, leicht abgehandelt werden. Des weiteren fordern wir einen
eindeutigen, nach der Ankunftszeit fortlaufenden Schlüssel, also einen
Primary Key. Aufgrund der schnellen Verarbeitungszeiten ist dieser
notwendig, da Events teils so schnell abgespeichert werden, dass sie
denselben Zeitstempel besitzen und dieser somit nicht als Primary Key
dienen kann.
Im folgenden wird nun der Trigger beschrieben, dass Schlüsselelement des Systems.
4.2
Es wäre zwar möglich gewesen deren Funktionalität auf SQLViews abzubilden, jedoch ist das mit EclipseLink eine umständliche
Aufgabe. Es erschien naheliegender, den Where-Clause der Anfrage
zu erweitern bzw. die Anzahl der Ergebnisse einzuschränken, was jedoch zu ganz eigenen Problemen führt. So fordert z.B. die Verwendung von B.win : length(4) nicht die letzten 4 Events für die der
Where-Clause gilt, sondern es schränkt den Sichtbereich prinzipiell
im Vorhinein auf die Anzahl 4 ein.
Die
SQL-Anfrage
hingegen,
bei
der
mittels
order by B.id desc limit 4 die letzten 4 Ergebnisse angezeigt
werden, gibt als Ergebnis nicht die letzten 4 Events aus und überprüft
dann, ob der Where-Clause gilt. Sie überprüft vielmehr zuerst den
Where-Clause und schränkt dann die Anzahl der Ergebnisse auf
die letzten 4 ein. Somit würden beide Varianten unterschiedliche
Ergebnisse produzieren.
Gelöst wird dieses Problem, indem zunächst die maximale Event-Id
aus der spezifischen Datenbank abgefragt wird, um diese dann für den
Where-Clause weiterzuverwenden. Da dieser zuerst überprüft wird,
erhält man nun das gewollte Ergebnis. Das produziert zwar einen
leichten Netzwerk-Overhead, jedoch ist dieser so gut wie vernachlässigbar, da nur die verhältnismäßig sehr kleine Id und die Anfrage
danach übertragen wird.
Die Handhabung von Views, die sich nicht auf die Anzahl der
Events sondern auf die Zeit beziehen, in der sie ankamen, unterscheidet sich davon stark. Da wir fordern, dass jedes Event einen Zeitstempel mit sich führt, kann beispielsweise bei dem View B.win :
time(5 min 3 sec) der Zeitausdruck geparst werden und ein neuer Zeitstempel berechnet werden. Dieser liegt dann die geforderten 5 Minuten und 3 Sekunden vor der Ankunftszeit des auslösenden langsamen
Events und kann nun mit den Zeitstempeln der in der Datenbank befindlichen Events verglichen werden.
Trigger
Der Trigger ist der Hauptbestandteil unseres Konzepts. Er verwaltet
eintreffende Events aus der ersten Esper-Instanz, führt die entsprechenden Datenbankanfragen durch und leitet dann die abgefragten
Events and die zweite Esper-Instanz weiter.
4.2.1
Grundprinzip
Der Listener, der aktiv wird, wenn in der ersten Esper-Instanz ein hereinkommendes Event detektiert wurde, leitet dieses Event komplett an
den Trigger weiter, daraufhin wird dieser aktiv. Es wird überprüft, ob
die zweite Instanz EPL-Statements hält, für welche das hereinkommende Event relevant wäre. Ist dies der Fall, startet das umschreiben der EPL-Statements. Hierbei machen wir uns die Ähnlichkeit der
Esper-EPL zu SQL zunutze und manipulieren die Statements so, dass
das Ergebnis eine äquivalente SQL-Anfrage darstellt. Soll z.b. bei Auftreten eines Events A das letzte Event B detektiert werden und B ausgegeben werden, so wäre der zugehörige EPL-Ausdruck:
4.2.3 Where-Clauses
Nicht nur die Views sondern auch die Where-Clauses fordern hier eine
Bearbeitung. So kann in einer EPL-Anweisung eine Referenz auf ein
langsames Event enthalten sein, dessen Eventklasse nicht in der Datenbank abgespeichert wird. So würde die Datenbank versuchen, mit
ihr unbekannten Daten zu arbeiten, was natürlich unmöglich ist.
Es ist also erforderlich, die vom langsamen Event schon bekannten
Werte in die Anfrage anstatt der zugehörigen Variablen einzusetzen.
Das erfordert eine Erkennung der Aliase die im f rom-Teil des Ausdrucks beschrieben werden. Diese ist recht einfach zu implementieren. Wie schon in Abschnitt 4.2.1 präsentiert wird dann der Platzhalter
(a.timestamp) durch den bekannten Wert ersetzt (’2009 − 09 − 21 14 :
45 : 23’). Die leicht abgeändert Anfrage von dort sei hier nochmal aufgeführt:
select b
from B . s t d : l a s t e v e n t ( ) a s b ,
A. s t d : l a s t e v e n t ( ) as a
where b . b e f o r e ( a )
Die äquivalente MySQL-Anfrage wäre nun (wenn der Timestamp
von A ’2009 − 09 − 21 14 : 45 : 23’ ist):
select b
from B b
where b . timestamp < ’ 2009−09−21 1 4 : 4 5 : 2 3 ’
o r d e r by b . i d d e s c
limit 1
select b
from B . s t d : l a s t e v e n t ( ) a s b ,
A. s t d : l a s t e v e n t ( ) as a
where b . timestamp < a . timestamp
and a . n i e d e r s c h l a g > 5
and b . t e m p e r a t u r e < 4
Befehle der Esper-Intervallalgebra wie b.be f ore(a) sind in unserem Falle redundant, da wir fordern, dass jedes Event ein TimestampFeld besitzt. Kennt man die Eintrittszeit der Events können alle Befehle der Intervallalgebra leicht nachgebildet werden. So kann hier
z.B. where b.be f ore(a) durch where b.timestamp < a.timestamp ersetzt werden.
Im Folgenden soll darauf eingegangen werden, wie wir mit den einzelnen Komponenten des Ausdrucks umgehen, um ihn in eine äquivalenten SQL-Ausdruck umzuwandeln. Zum einen wird auf Window
Views eingegangen. Dies sind bestimmte EPL-Ausdrücke, die die Anzahl der betrachteten Events einschränken können. Zum anderen wird
berichtet, wie man den bereits vorhandenen Where-Clause der EsperEPL in eine SQL-Anfrage übernehmen kann.
4.2.2
Die Where-Clauses können auch, wie der eben gezeigte, nach dem
Einsetzen der bekannten Werte überflüssige Abschnitte erhalten. Beispielsweise könnte unser Verfahren den Ausdruck and 3 > 5 produzieren. Dieser kann augenscheinlich von keinem Event erfüllt werden,
obwohl die komplette Datenbankabfrage zweifelsfrei korrekt ist. Sie
produziert nur zusätzlichen Netzwerktraffic, ohne ein relevantes Resultat zu liefern.
Für solche schon im Vorhinein bei der Erstellung des Ausdrucks erkennbaren Fälle ist die erste Esper-Instanz als Problemlösung vorgesehen. Die Erkennung solcher Fälle muss jedoch anwenderseitig geschehen. Wird hier dieser Problemfall erkannt, kann and a.niederschlag >
5 aus dem Ausdruck gestrichen werden. Jedoch muss dann bei der ersten Instanz der ursprüngliche Erkennungsausdruck select ∗ f rom A zu
Window Views
Zu den Window Views zählen in der Esper-EPL Ausdrücke wie .std :
lastevent(), .win : time() oder .win : length(). Diese lassen sich in zwei
grundlegende Arten einteilen. Zum einen existieren Views, die sich
auf die (Ankunfts-)Zeit von Events beziehen, zum anderen existieren
Views die sich auf deren Anzahl beziehen.
select a
from A a
where a . n i e d e r s c h l a g > 5
3
erweitert werden. Dies filtert zuverlässig irrelevante Events und
spart sowohl Netzwerktraffic als auch Rechenzeit, da der Trigger mit
den so herausgefilterten Events nicht mehr arbeiten muss.
Im nächsten Abschnitt wollen wir nun die Effizienz der soeben beschriebenen Methoden durch Messungen belegen.
Hieraus sieht man nun das mit größer werdender Differenz der Häufigkeit, Esper mit Datenbank eine geringere Netzwerklast hat. Der
Schnittpunkt der Netzwerklasten von Esper mit Datenbank und Esper ohne Datenbank liegt in unserem Experiment bei einem Verhältnis
von einem langsamen Event zu 3 schnellen Events. Das bedeutet, dass
sich die Datenbank erst ab einem Verhältnis von ca. 1:3 lohnt, wie im
nachfolgenden Abbildung 6 ersichtlich wird.
5 E VALUATION
Nun werden wir in Esper unterschiedliche Bedingungen testen. Wir
werden evaluieren, wie man im Durchschnitt die geringste Netzwerklast erreicht, aber auch wie die geringste Rechendauer erreicht werden kann. Zu den Tests wurde als Testmaschine, auf der Esper läuft,
ein Intel Core i7-2600K bei 4,0 GHz mit 16Gb RAM verwendet. Als
Datenbankserver wurde ein Intel Pentium IV Rechner bei 3,0 GHz mit
1GB RAM verwendet.
5.1 Netzwerklast
Zuerst werden wir unser Konzept, also die Netzwerklast von Esper
mit angeschlossener Datenbanken, betrachten. Hierbei gehen wir davon aus, dass immer nur ein Event aus der Datenbank abgefragt wird,
deren Netzwerklast sinkt, wenn das langsamere Event, das nicht in die
Datenbank gespeichert wird, um einiges langsamer ist als das schnelle Event, welches in der Datenbank gespeichert wird. Die Kurve nähert sich immer weiter der 0 an, wie in Abbildung 4 zu sehen ist. Die
zusätzliche Netzwerklast, die durch Verwendung bestimmter Window
Views entsteht ist hierbei schon berücksichtigt.
Abbildung 6: Kombinierter Netzwerktraffic aus Abbildung 4 und 5
Betrachtet man nun die prozentuale Einsparung von Esper mit Datenbank gegenüber Esper ohne Datenbank sieht man, dass ab einem
Verhältnis von 1:3 die prozentuale Einsparung logarithmisch ansteigt.
Esper mit Datenbank spart bei einem Verhältnis von 1:5 die Hälfte der
Netzwerklast und bei einem Verhältnis von 1:10 werden sogar 90% an
Netzwerklast eingespart, wie in Abbildung 7 ersichtlich wird.
Abbildung 4: Unser Ansatz: Netzwerktraffic
Abbildung 7: Unser Ansatz: Einsparung von Netzwerktraffic
Dabei erkennt man, dass Esper mit Datenbank bei der Netzwerklast,
mit zunehmend größerem Verhältnis zwischen schnellen und langsamen Events, konstant besser wird, als Esper ohne Datenbank.
5.2 Berechnungsdauer
Die Berechnungsdauer von Esper ist kürzer wenn keine Datenbank
verwendet wird, da keine zusätzliche Zeit für Datenbankabfragen benötigt wird. Hierzu haben wir Tests durch geführt und die Berechnungsdauer für eine Anzahl von 1-50 Anfragen gemessen. Diese liegen bei Esper ohne Datenbank auf unserem System im Schnitt bei etwa
2, 3ms pro Anfrage, wie aus Abbildung 10 ersichtlich wird.
Die hier zu sehenden Ausreißer können im Zuge der Messtoleranz
und geringen Störungen vernachlässigt werden. Vergleicht man diese
Messungen mit den Ergebnissen der Messung auf unserem System bei
Esper mit Datenbank, sieht man sofort, dass die Variante mit Datenbank immer eine längere Berechnungszeit besitzt, was auf die zusätzliche Zeit für die Abfrage der Datenbank zurückzuführen ist. Aber im
Abbildung 5: Esper: Netzwerktraffic
Wenn mehr als ein Event aus der Datenbank abgefragt wird, verschiebt sich die Kurve pro Event um ca. 60 B/s nach oben. Die Netzwerklast bei Esper ohne Datenbank hingegen nimmt mit größer werdendem Unterschied der Häufigkeit der beiden Eventströme konstant
zu. Was in Abbildung 5 illustriert wird.
4
Abbildung 8: Rechendauer von Esper
Abbildung 10: Verhältnis von abgefragten Events zur Rechendauer
bei einer lokalen Event-Datenbank
Gegensatz zu Esper ohne Datenbank nimmt die Bearbeitungszeit bei
Esper mit Datenbank, bei einer höheren Anzahl von Eventanfragen,
konstant zu, wie in Abbildung 9 gut zu sehen ist.
Abbildung 11: Verhältnis von abgefragten Events zur Rechendauer
Sterne: Unser Ansatz, entfernte Datenbank
Striche: Unser Ansatz, lokale Datenbank
Rauten: Esper ohne Datenbankeinsatz
Abbildung 9: Verhältnis von abgefragten Events zur Rechendauer bei
einer entfernten Event-Datenbank
dazu geeignet, Netzwerklast zu sparen, wenn das Verhältnis von langsamen zu schnellen Events über ca. 1 : 3 liegt.
Obiges Diagramm zeigt nun die Ergebnisse eines Tests, in dem Esper die Events über ein Netzwerk auf einem externen Server abfragt.
Da dies einiges länger dauert als ohne Datenbank, werden wir nun
auch noch einen Testfall betrachten, in dem wir die Datenbank mit der
Engine auf dem gleichen Rechner haben. Auch hier bekommen wir
eine konstant ansteigende Kurve, genau wie beim vorigen Test mit der
Datenbank, wie in Abbildung 10 deutlich zu sehen ist.
Bei der lokalen Datenbank ist die Kurve flacher als bei der entfernten Datenbank, was daran liegt das die Events bei der lokalen Datenbank eine geringere Übertragungsdauer haben als die Events einer entfernten Datenbank. Eine lokale Datenbank ist die schlechteste der möglichen Lösungen, da hier natürlich keinerlei Netzwerklast
durch die Datenbank gespart werden kann. Somit würde nur die Berechnungsdauer erhöht ohne weiteren Nutzen und eine Variante ohne
Datenbank wäre effizienter. Deswegen sollte man die Datenbank natürlich direkt beim Sender installieren. Damit wird keine weitere Netzwerklast benötigt, um die Events in die Datenbank zu speichern.
5.3
6
R ELATED W ORK
Die Wichtigkeit von Complex Event Processing Systemen nimmt ständig zu, somit sind diese auch ein wichtiger Forschungsgegenstand. Insbesondere nimmt hier die Bedeutung von verteilten Systemen zu, sei
es zur Überwachung von Finanzmärkten oder zur schnellen Verarbeitung von Sensordaten. So wird in [5] auf CEP in Unternehmenssystemen eingegangen.
Werden Events von vielen verschiedenen Quellen bezogen, kann es
möglich sein, Erkennungspläne festzulegen, die die Performance des
CEP-Systems erhöhen, auch bezüglich der Netzwerkauslastung. Diese können sich stark von naiven komplexen Events unterscheiden [1].
Um solche Erkennungspläne zu erstellen, können beispielsweise deterministische endliche Automaten als Hilfsmittel herangezogen werden. Ein ähnliches Ziel wird auch in [7] verfolgt, jedoch wird hier nicht
die Verringerung der Netzwerklast als eines der Hauptziele angestrebt.
Vielmehr wird darauf eingegangen, möglichst viele Beschreibungen
komplexer Events gleichzeitig verarbeiten zu können.
Bei beiden vorangegangen Ansätzen werden zwar, ebenso wie bei
unserem, CEP-Queries umgeschrieben, nur wird keine Klassifikation
der unterschiedlichen Events vorgenommen, wie es bei uns der Fall
ist. Ein weiterer Unterschied ist, dass in dieser Arbeit der Prozess des
Umschreibens einem anderen Zweck dient. Wir schreiben um, um eine SQL-Query zu erhalten, mit der man die Events aus der Datenbank auslesen kann. In den beiden Arbeiten werden die EPL-Queries
Wertung
Wenn man nun die drei Methoden vergleicht, erkennt man leicht, dass
die Variante ohne Datenbank in Hinsicht auf die Rechenzeit natürlich
am Effizientesten ist, wie in Abbildung 11 zu sehen ist.
Ab einem bestimmten Verhältnis, in unserem Testfall ca. 1 : 3, verursacht dies mehr Netzwerklast, was es ja zu verhindern gilt. Natürlich
ist Esper mit einer Datenbank langsamer, aber auch effizienter in Hinsicht auf die Netzwerklast. Deswegen ist Esper mit Datenbank bestens
5
in äquivalente EPL-Queries umgeschrieben, um eine bessere Performance zu erzielen.
Die Wichtigkeit der Platzierung von Operatoren wie unserer Datenbank in Netzwerken wird in [6] untersucht. Es wird eine Erweiterung
für eine Netzwerkschicht präsentiert, die die Platzierung der Operatoren eigenständig regeln kann. Wichtig für diese Arbeit ist jedoch nur
die Methodik, nach der dies geschieht.
Mit der Übertragung von Dateien im Allgemeinen (in unserem
Fall sind dies natürlich Events) beschäftigt sich [3]. Hierbei wird
nicht nur auf das titelgebende Publish/Subscribe eingegangen, welches einen wichtigen Mechanismus für CEP-Systeme darstellt, sondern auch auf Techniken wie Remote Procedure Calls oder Message
Queuing. Nichtsdestotrotz waren bei unserem Ansatz andere Kommunikationswege vonnöten, um das angestrebte Ziel zu erreichen.
Relevant für diese Arbeit waren natürlich auch die Dokumentationen der verwendeten Software bzw. Bibliotheken. In [2] wird eine
komplette Beschreibung der Funktionsweise von Esper und der EsperEPL vorgenommen. Auch wird eine Einführung in Complex Event
Processing präsentiert. Die Beschreibung von EclipseLink und der
Technik der Abspeicherung von Objekten in Datenbanken wird in [4]
getätigt.
7
tems. In Data Engineering, 2006. ICDE ’06. Proceedings of the 22nd
International Conference on, page 49, april 2006.
[7] N. P. Schultz-Møller, M. Migliavacca, and P. Pietzuch. Distributed
complex event processing with query rewriting. In Proceedings of the
Third ACM International Conference on Distributed Event-Based Systems,
DEBS ’09, pages 4:1–4:12, New York, NY, USA, 2009. ACM.
Z USAMMENFASSUNG
Um die Netzwerklast zu reduzieren führen wie eine Datenbank ein.
Darin werden häufig auftretende Events abgespeichert und bei auftreten noch niederfrequente Events abgerufen. Dieses System kann
mit zwei Esper-Instanzen erstellt werden. Hierzu entnimmt die erste Esper-Instanz ein niederfrequentes Event und leitet diese an die
zweite Instanz weiter, wenn die Bedingungen für ein komplexes Event
erfüllt sind. Anschließend werden die letzten hochfrequenten Events
ebenfalls aus der Datenbank an die zweite Esper-Instanz weitergeleitet. Diese Methode ist bei einem Verhältnis von niederfrequenten zu
hochfrequenten Events von 1 : 3 in der Netzwerklast besser als bei Esper ohne Datenbank. Dabei hat Esper mit Datenbank zwar eine längere
Rechenzeit, spart jedoch signifikant viel Netzwerklast ein.
Man kann noch weitere wenige Verbesserungen einführen, um Esper mit Datenbank noch effizienter zu machen. Zum Beispiel könnte
man einen Eventpuffer bzw. einen Eventcache hinzufügen, damit die
Events, die bereits abgefragt wurden, nicht noch ein weiteres mal abgefragt werden. Man könnte auch die gesamten Informationen aus der
Datenbank auf mehrere Datenbanken verteilen oder mehrere Datenbanken unterstützen, dass jeder Event-Sender eine eigene Datenbank
besitzt. Damit würde sich sowohl die Zugriffszeit als auch der Netwerktraffic noch weiter verringern.
ACKNOWLEDGMENTS
Zuletzt möchten wir uns noch bei unseren Betreuern, Björn Schilling
und Beate Ottenwälder für die stetige Beratung und ihre schier endlos
erscheinende Geduld bedanken.
L ITERATUR
[1] M. Akdere, U. Çetintemel, and N. Tatbul. Plan-based complex event detection across distributed sources. Proc. VLDB Endow., 1(1):66–77, Aug.
2008.
[2] EsperTech.
Esper Reference Documentation Version 4.5.0.
http://http://esper.codehaus.org/esper-4.5.0/doc/
reference/en/pdf/esper_reference.pdf, 2011.
[Online;
accessed 15-April-2012].
[3] P. T. Eugster, P. A. Felber, R. Guerraoui, and A.-M. Kermarrec. The many faces of publish/subscribe. ACM Comput. Surv., 35(2):114–131, June
2003.
[4] E. Foundation.
EclipseLink Documentation.
http://wiki.
eclipse.org/EclipseLink/Documentation_Center, 2012.
[Online; accessed 15-April-2012].
[5] D. C. Luckham. The Power of Events: An Introduction to Complex Event
Processing in Distributed Enterprise Systems. Addison-Wesley Longman
Publishing Co., Inc., Boston, MA, USA, 2001.
[6] P. Pietzuch, J. Ledlie, J. Shneidman, M. Roussopoulos, M. Welsh, and
M. Seltzer. Network-aware operator placement for stream-processing sys-
6