[TASK] Generic commit.
This commit is contained in:
parent
fce55510a9
commit
8c54076788
|
@ -381,11 +381,27 @@ Wie in Listing~\ref{lst:sample_sparql_construct} gezeigt, können einfache Opera
|
|||
Von Transaktionen im Handel über Messereignisse von Sensoren bis hin zu Benutzerinteraktionen auf Webseiten entstehen täglich eine Vielzahl von Ereignisdaten, die für einen begrenzten Zeitraum einen Teil der echten Welt abbilden. Um aus diesen großen Datenmengen durch Erkennung von Mustern oder durch Aggregation von Daten schnellstmöglich höherwertige Informationen gewinnen zu können, ist Complex Event Processing (CEP) das Mittel der Wahl. Wie der Begriff CEP bereits andeutet, geht es dabei um die Verarbeitung von komplexen Ereignissen. Im folgenden Abschnitt wird hierfür ein kurzer Einstieg in die Grundlagen von CEP gegeben. Für eine detailreiche Erläuterung und die beispielhafte Anwendung der CEP-Engine \enquote{Esper} sei auf \cite{hsh:cep} verwiesen.
|
||||
|
||||
\paragraph{CEP-Engine}
|
||||
Um Complex Event Processing durchführen zu können, wird eine CEP-Engine benötigt. Eine CEP-Engine ist eine Software, welche Ereignisdatenströme konsumiert und durch die Auswertung benutzerdefinierter CEP-Regeln verarbeitet. Aufgrund der großen Datenvolumen, die eine CEP-Engine verarbeiten muss, werden Ereignisse nur für die Dauer der Verarbeitung im Speicher gehalten\footnote{Dieser Parameter hängt meist von der Größe der verwendeten Sliding Windows ab.} und nicht persistiert.
|
||||
Um Complex Event Processing durchführen zu können, wird eine CEP-Engine benötigt. Eine CEP-Engine ist eine Software, welche Ereignisdatenströme konsumiert und diese durch die Auswertung benutzerdefinierter CEP-Regeln verarbeitet. Aufgrund der großen Datenvolumen, die eine CEP-Engine verarbeiten muss, werden Ereignisse nur für die Dauer der Verarbeitung im Speicher gehalten\footnote{Dieser Parameter hängt meist von der Größe der verwendeten Sliding Windows ab.} und nicht persistiert.
|
||||
|
||||
\paragraph{CEP-Regeln}
|
||||
Eine CEP Regel besteht aus zwei Teilen: Der erste Teil definiert Bedingungen, die nach bestimmten Mustern in einem Ereignisdatenstrom suchen sollen. Der zweite Teil definiert eine Reihe von Aktionen, die ausgeführt werden sollen, sobald die Bedingungen der Regel eintreffen. Passen Ereignisse aus dem Datenstrom auf die Bedingungen, so matcht die Regel. Die in der Regel definierten Aktionen werden dann ausgeführt --- die Regel feuert\cite{hsh:cep}.
|
||||
Um eine effiziente Ereignisverarbeitung durchführen zu können, beziehen sich CEP-Regeln immer nur auf Inhalte von Sliding- oder Tumbling Windows, da somit nur eine endliche, überschaubare Menge von Daten ausgewertet werden muss.
|
||||
Zur Erläuterung von CEP-Regeln und der Vereinfachung des Übergangs zu C-SPARQL wird für CEP-Regeln eine abstrakte Sprache eingeführt, anhand derer die einzelnen Konstrukte von CEP-Regeln erläutert werden sollen.
|
||||
Eine CEP-Regel besteht aus zwei Teilen: Zuerst definiert der \texttt{CONDITION}-Teil Ereignismuster, die in dem Ereignisdatenstrom gesucht werden sollen, sowie spezifische Bedingungen, die für auf das Muster passende Ereignisse erfüllt sein müssen.
|
||||
\begin{lstlisting}[mathescape=true,label={},caption={}]
|
||||
CONDITION (Ereignismuster)
|
||||
... weitere Bedingungen ...
|
||||
\end{lstlisting}
|
||||
Sind alle Bedingungen im \texttt{CONDITION}-Teil erfüllt, so \enquote{matcht} die Regel\cite{hsh:cep}. Im darauffolgenden \texttt{ACTION}-Teil wird eine Reihe von Aktionen definiert, die ausgeführt werden sollen, sobald die Bedingungen der Regel eintreffen. Da die Daten der Ereignisse, auf die der \texttt{CONDITION}-Teil gepasst hat, für die weitere Verarbeitung von Interesse ist, stehen sie im \texttt{ACTION}-Teil zur Verfügung.
|
||||
\begin{lstlisting}[mathescape=true,label={},caption={}]
|
||||
ACTION
|
||||
... auszulösende Aktionen ...
|
||||
\end{lstlisting}
|
||||
Matcht eine Regel, so werden die in ihr definierten Aktionen ausgeführt --- die Regel feuert\cite{hsh:cep}. Zusammengefasst sieht eine CEP-Regel wie folgt aus:
|
||||
\begin{lstlisting}[mathescape=true,label={lst:abstract_cep_rule_one},caption={Grundgerüst einer CEP-Regel}]
|
||||
CONDITION (Ereignismuster)
|
||||
... weitere Bedingungen ...
|
||||
ACTION
|
||||
... auszulösende Aktionen ...
|
||||
\end{lstlisting}
|
||||
|
||||
\paragraph{Ereignisse}
|
||||
Ein Ereignis trägt neben inhaltlichen Informationen über den Vorgang durch den es ausgelöst wurde auch eine eindeutige ID sowie einen Zeitstempel mit sich. Während der Zeitstempel den Zeitpunkt der Ereignisauslösung angibt, dient die ID zur eindeutigen Abgrenzung von anderen Ereignisssen, die vom selben Ereignistyp sind oder zum selben Zeitpunkt entstanden sind. Da es bedingt durch Übertragunglatenz und weitere technische Randbedingungen möglich ist, dass die Ereignisdaten zeitverzögert bei der CEP-Engine ankommen, wird der Zeitstempel ebenfalls benötigt, um die zeitlichen Beziehungen zwischen den Ereignissen zu erhalten.
|
||||
|
@ -397,14 +413,30 @@ Dafür treten diese primitiven Ereignisse häufig mit einer sehr hohen Frequenz
|
|||
Natürlich können nicht nur externe Komponenten als Quelle von Ereignissen dienen. Viele CEP-Engines unterstützen die Erzeugung von Ereignisdaten und deren Injektion in die eigene Ereignisverarbeitung. So können durch CEP-Regeln gewonnene Erkenntnisse direkt Einfluss auf die weitere Verarbeitung nehmen, indem sie als neue Ereignisse in die Verarbeitung aufgenommen werden.
|
||||
|
||||
\paragraph{Sliding Windows und Tumbling Windows}
|
||||
Um die großen Mengen von Ereignisdaten aus einem Datenstrom effizient verarbeiten zu können, werden sie in einem Fenster fester Größe betrachtet. Die Größe eines solchen Fensters wird häufig in Sekunden angegeben; sehr selten wird die Größe durch eine maximale Anzahl von Ereignissen angegeben, die das Fenster enthalten kann.
|
||||
Um die großen Mengen von Ereignisdaten aus einem Datenstrom effizient verarbeiten zu können, werden sie in einem Fenster fester Größe betrachtet. Die Größe eines solchen Fensters wird häufig mit Zeiteinheiten wie Sekunden angegeben; selten wird die Größe durch eine Anzahl von Ereignissen angegeben, die das Fenster enthalten kann.
|
||||
|
||||
Ein \emph{Sliding Window} wird in regelmäßigen Intervallen um eine festgelegten Größe verschoben, um aktuellere Ereignisse zu betrachten, wobei die älteren Ereignisse zugunsten der neuen Ereignisse aus dem Fenster herausfallen. Ein \emph{Tumbling Window} hingegen wird nicht verschoben sondern \enquote{umgeklappt}, sodass alle zuvor in ihm enthaltenen Ereignisse herausfallen und aktuellere Ereignisse in das nun leere Fenster gefüttert werden.
|
||||
|
||||
Nur die Ereignisse, die in diesen Ereignisfenstern enthalten sind, werden somit von CEP-Regeln ausgewertet.
|
||||
Ein \emph{Sliding Window} wird in regelmäßigen Intervallen um eine festgelegten Größe verschoben um aktuellere Ereignisse zu betrachten, wobei die älteren Ereignisse zugunsten der neuen Ereignisse aus dem Fenster herausfallen. Die Ergebnisse von CEP-Regeln verändern sich somit nach jedem Verschieben des Ereignisfensters. Das \emph{Tumbling Window} ist ein Sonderfall des Sliding Window, bei dem die Fenstergröße und das Intervall, in dem es verschoben wird, gleich sind. Es wird daher \enquote{umgeklappt}, sodass alle zuvor in ihm enthaltenen Ereignisse herausfallen und aktuellere Ereignisse in das nun leere Fenster gefüttert werden. Da somit ein Ereignis nur einmal in einem Tumbling Window Platz findet, kann es auch nur ein einziges Mal Einfluss auf die Auswertung nehmen. Somit eignen sich Tumbling Windows beispielsweise dazu, die Anzahl von PKW zu erfassen, die einen Messpunkt auf einer Fahrbahn passiert haben.
|
||||
|
||||
\todo{GRAFIK: Sliding Window vs Tumbling Window}
|
||||
|
||||
Da je nach Anforderung einer CEP-Regel ein bestimmtes Ereignisfenster benötigt wird, ist es notwendig, dieses innerhalb der CEP-Regel festlegen zu können. Dafür werden die Angaben der Fenstergröße und die des Verschiebeintervalls, beziehungsweise die Ereigniskapazität des Fensters angegeben:
|
||||
\begin{lstlisting}[mathescape=true,label={},caption={}]
|
||||
[Window:15min,SlideInterval:10s]
|
||||
\end{lstlisting}
|
||||
oder
|
||||
\begin{lstlisting}[mathescape=true,label={},caption={}]
|
||||
[Window:150events,SlideInterval:10events]
|
||||
\end{lstlisting}
|
||||
|
||||
Diese Angabe wird am \texttt{CONDITION}-Teil der CEP-Regel platziert, sodass eine CEP-Regel nun wie folgt aussieht:
|
||||
\begin{lstlisting}[mathescape=true,label={lst:abstract_cep_rule_two},caption={CEP-Regel mit Angabe zu Ereignisfenster}]
|
||||
CONDITION (Ereignismuster)[Window:foo,SlideInterval:bar]
|
||||
... weitere Bedingungen ...
|
||||
ACTION
|
||||
... auszulösende Aktionen ...
|
||||
\end{lstlisting}
|
||||
|
||||
|
||||
\paragraph{Mustererkennung}
|
||||
\todo{Mehr! Mustererkennung!}
|
||||
Komplexere Sachverhalte kann man häufig über ihre Ereignismuster erkennen. Hierbei spielen die Ereignissequenzen und die zeitlichen Beziehungen zwischen Ereignissen eine Rolle. Um ein \enquote{bedeutungsvolles Ereignismuster} zu erkennen, wird eine CEP-Regel definiert, die dieses Muster beschreibt.
|
||||
|
|
Loading…
Reference in New Issue