[TASK] Generic commit.
This commit is contained in:
parent
d0d3887c1f
commit
48714db495
@ -465,7 +465,7 @@ ACTION
|
|||||||
\paragraph{Sliding Windows und Tumbling Windows}
|
\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 mit Zeiteinheiten wie Sekunden angegeben; selten wird die Größe durch eine 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. 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.
|
Ein \emph{Sliding Window} wird nach erfolgter Auswertung seines Inhalts 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, um das es verschoben wird, gleich sind. Es wird quasi \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.
|
||||||
\todo{GRAFIK: Sliding Window vs Tumbling Window}
|
\todo{GRAFIK: Sliding Window vs Tumbling Window}
|
||||||
|
|
||||||
Da je nach Anforderung einer CEP-Regel ein bestimmtes Ereignisfenster zweckmäßig ist, ist es notwendig, dies in der CEP-Regel festlegen zu können. Dafür werden die Angaben der Fenstergröße (\texttt{WindowSize}) und des Intervalls, in dem das Fenster verschoben wird (\texttt{StepSize}), wie folgt verwendet:
|
Da je nach Anforderung einer CEP-Regel ein bestimmtes Ereignisfenster zweckmäßig ist, ist es notwendig, dies in der CEP-Regel festlegen zu können. Dafür werden die Angaben der Fenstergröße (\texttt{WindowSize}) und des Intervalls, in dem das Fenster verschoben wird (\texttt{StepSize}), wie folgt verwendet:
|
||||||
@ -642,24 +642,33 @@ WHERE {
|
|||||||
\paragraph{Sliding Windows}
|
\paragraph{Sliding Windows}
|
||||||
Um mit der Verarbeitung von Ereignisdatenströmen beginnen zu können, müssen die für die Verarbeitung benötigten RDF-Datenströme in der CEP-Regel angegeben werden. Das Konstrukt \texttt{FROM [NAMED] STREAM <\emph{streamUri}> [\emph{window}]} wird zwischen den Klauseln \texttt{SELECT} und \texttt{WHERE} angegeben und definiert neben der in \texttt{streamUri} zu hinterlegenden URI des zu konsumierenden RDF-Datenstroms auch das an Stelle von \texttt{window} zu definierende Sliding Window, in dem dieser betrachtet werden soll\cite{barbieri:csparql}. Die Angabe des Sliding Windows ist hier zwingend erforderlich, da die kontinuierlich einströmenden Ereignisdaten zur Verarbeitung auf eine endliche Datenmenge reduziert werden müssen. Weiterhin ist die Spezifikation des Sliding Window sinnvoll, da je nach Anforderungen der CEP-Regel Ereignisse aus bestimmten Zeiträumen für die Verarbeitung interessant sind --- je nach Zweck der CEP-Regel können diese Zeiträume sich stark unterscheiden.
|
Um mit der Verarbeitung von Ereignisdatenströmen beginnen zu können, müssen die für die Verarbeitung benötigten RDF-Datenströme in der CEP-Regel angegeben werden. Das Konstrukt \texttt{FROM [NAMED] STREAM <\emph{streamUri}> [\emph{window}]} wird zwischen den Klauseln \texttt{SELECT} und \texttt{WHERE} angegeben und definiert neben der in \texttt{streamUri} zu hinterlegenden URI des zu konsumierenden RDF-Datenstroms auch das an Stelle von \texttt{window} zu definierende Sliding Window, in dem dieser betrachtet werden soll\cite{barbieri:csparql}. Die Angabe des Sliding Windows ist hier zwingend erforderlich, da die kontinuierlich einströmenden Ereignisdaten zur Verarbeitung auf eine endliche Datenmenge reduziert werden müssen. Weiterhin ist die Spezifikation des Sliding Window sinnvoll, da je nach Anforderungen der CEP-Regel Ereignisse aus bestimmten Zeiträumen für die Verarbeitung interessant sind --- je nach Zweck der CEP-Regel können diese Zeiträume sich stark unterscheiden.
|
||||||
|
|
||||||
Um ein Sliding Window zu definieren, wird die folgende Grammatik (entnommen aus \cite{barbieri:csparql}) ab Einstiegspunkt \texttt{window} verwendet:
|
Um ein Sliding Window zu definieren, wird die folgende Grammatik (entnommen aus \cite{barbieri:csparql}) ab dem Einstiegspunkt \texttt{Window} verwendet:
|
||||||
\begin{lstlisting}[mathescape=true]
|
\begin{lstlisting}[mathescape=true]
|
||||||
window $\rightarrow$ LogicalWindow | PhysicalWindow
|
Window $\rightarrow$ 'RANGE' LogicalWindow | 'RANGE' PhysicalWindow
|
||||||
LogicalWindow $\rightarrow$ Number TimeUnit WindowOverlap
|
LogicalWindow $\rightarrow$ Number TimeUnit WindowOverlap
|
||||||
TimeUnit $\rightarrow$ 'MSEC' | 'SEC' | 'MIN' | 'HOUR' | 'DAY'
|
TimeUnit $\rightarrow$ 'MSEC' | 'SEC' | 'MIN' | 'HOUR' | 'DAY'
|
||||||
WindowOverlap $\rightarrow$ 'STEP' Number TimeUnit | 'TUMBLING'
|
WindowOverlap $\rightarrow$ 'STEP' Number TimeUnit | 'TUMBLING'
|
||||||
PhysicalWindow $\rightarrow$ 'TRIPLES' Number
|
PhysicalWindow $\rightarrow$ 'TRIPLES' Number
|
||||||
\end{lstlisting}
|
\end{lstlisting}
|
||||||
|
|
||||||
\todo{EXPLAIN! EXPLAIN!}
|
Mit dieser Grammatik können drei verschiedene Sorten von Sliding Windows definiert werden:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Das reguläre \textbf{Sliding Window} erfasst einen definierten Zeitraum und wird nach jeder Auswertung um seine definierte Schrittgröße weitergeschoben. Die definierte Schrittgröße darf nicht größer als die Größe des Sliding Windows sein. Der Ausdruck
|
||||||
\begin{lstlisting}
|
\begin{lstlisting}
|
||||||
[RANGE 10 MIN STEP 30 SEC]
|
[WindowSize:15min,StepSize:5s]
|
||||||
[RANGE 10 MIN TUMBLING]
|
|
||||||
[RANGE TRIPLES 150]
|
|
||||||
\end{lstlisting}
|
\end{lstlisting}
|
||||||
|
definiert ein Sliding Window, welches Ereignisdaten über einen Zeitraum von 15 Minuten beinhaltet und nach jeder erfolgten Auswertung in 5 Sekunden-Schritten verschoben wird. Übersetzt man diesen Ausdruck mit der obigen Grammatik in einen C-SPARQL-Ausdruck, so erhält man \texttt{[RANGE 15 MIN STEP 5 SEC]}.
|
||||||
|
\item Das \textbf{Tumbling Window} ist ein Sonderfall des Sliding Window, da es nach jeder erfolgten Auswertung um seine eigene Größe verschoben wird. Ein solches Ereignisfenster, welches Ereignisdaten über den Zeitraum einer Stunde fasst und nach jeder erfolgten Auswertung um diese Größe verschoben wird, kann durch den Ausdruck
|
||||||
|
\begin{lstlisting}
|
||||||
|
[WindowSize:1h,StepSize:1h]
|
||||||
|
\end{lstlisting}
|
||||||
|
beschrieben werden. In der Abfragesprache C-SPARQL kann dieses Tumbling Window durch den Ausdruck \texttt{[RANGE 1 HOUR TUMBLING]} definiert werden. Durch das Verschieben des Tumbling Windows um seine eigene Größe kommt es nicht zu Überlappungen zwischen den Fenstern, sodass eine Ereignisinstanz immer nur in einem Tumbling Window und somit auch nur in einer Auswertung vorkommt.
|
||||||
|
\item Das \textbf{Physical Window} nutzt keine Zeiträume zur Festlegung seiner Größe, sondern eine feste Anzahl von Ereignisinstanzen, die es enthalten kann. Da die C-SPARQL-Engine bei dieser Art von Ereignisfenster keine Angabe einer Schrittgröße erlaubt\cite{barbieri:csparql}, um die das Fenster nach jeder Auswertung verschoben wird, wird davon ausgegangen, dass das Fenster immer nur um eine Ereignisinstanz verschoben wird. Der folgende Ausdruck definiert ein Physical Window, welches 150 Ereignisinstanzen erfasst und immer nur um eine Ereignisinstanz verschoben wird:
|
||||||
|
\begin{lstlisting}
|
||||||
|
[WindowSize:150events,StepSize:1event]
|
||||||
|
\end{lstlisting}
|
||||||
|
Übersetzt man diese Definition in die C-SPARQL-Abfragesprache, so erhält man \texttt{[RANGE TRIPLES 150]}.
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
\paragraph{Aggregation von Ereignissen}
|
\paragraph{Aggregation von Ereignissen}
|
||||||
\dots
|
\dots
|
||||||
|
Loading…
Reference in New Issue
Block a user