[TASK] Generic commit.
This commit is contained in:
parent
0daf6b381c
commit
a103fc0045
|
|
@ -156,10 +156,11 @@ Hannover, den \today \hfill Unterschrift
|
|||
Diese Arbeit beschäftigt sich mit \enquote{Complex Event Processing} (CEP), also der Verarbeitung komplexer Ereignisse auf Ereignisdatenströmen mit Integration von Hintergrundwissen, und der praktischen Nutzung der CEP-Engine C-SPARQL.
|
||||
|
||||
Nach einem kurzen Einstieg in das Thema CEP soll der Leser einen Einblick in die Features von aktuellen CEP-Engines erhalten und am Beispiel der Engine C-SPARQL\footnote{Mehr Informationen zu C-SPARQL und Download unter \url{http://streamreasoning.org/resources/c-sparql}} die Verarbeitung von Ereignisströmen im RDF-Format in Kombination mit Hintergrundwissen im Detail kennenlernen.
|
||||
An einem Beispielszenario soll dann der Praxiseinsatz von C-SPARQL erklärt werden, in dem einige der vorgestellten Funktionen Anwendung finden. Im Abschluss wird ein kurzer Ausblick auf die technischen Möglichkeiten des \enquote{Reasoning} gegeben - eine Technik, die es erlaubt auf den vorhandenen und eingehenden Daten logische Operationen und Schlussfolgerungen durchzuführen um daraus neues Wissen abzuleiten.
|
||||
An einem Beispielszenario soll dann der Praxiseinsatz von C-SPARQL erklärt werden, in dem einige der vorgestellten Funktionen Anwendung finden. Im Abschluss wird ein kurzer Ausblick auf die technischen Möglichkeiten des \enquote{Reasoning} gegeben --- eine Technik, die es erlaubt auf den vorhandenen und eingehenden Daten logische Operationen und Schlussfolgerungen durchzuführen um daraus neues Wissen abzuleiten.
|
||||
|
||||
\todo{Dem Dokument anpassen; Soll groben Ausblick auf Inhalte geben.}
|
||||
|
||||
|
||||
\section{Motivation}
|
||||
|
||||
\begin{draft}
|
||||
|
|
@ -180,13 +181,14 @@ Bei RDBMS gibt es je nach Anwendung unterschiedlichste Datenbankschemen, die Str
|
|||
Für die Verknüpfung von Daten aus verschiedenen RDBMS miteinander wird es hier sehr schwierig, da beispielsweise klassisches SQL keine Unterstützung für Queries über mehrere Datenbankserver unterstützt.
|
||||
\end{draft}
|
||||
|
||||
|
||||
\section{Einführung in Complex Event Processing}
|
||||
|
||||
Im folgenden Abschnitt wird ein kurzer Einstieg in das Konzept von Complex Event Processing (CEP) gegeben. Eine detailreiche Erläuterung von CEP und die beispielhafte Anwendung der CEP-Engine \enquote{Esper} wird in \cite{hsh:cep} beschrieben.
|
||||
|
||||
Wie der Begriff \enquote{Complex Event Processing} schon andeutet, geht es bei CEP um die Verarbeitung von komplexen Ereignissen - konkret: Die Erkennung und Erfassung von komplexen Ereignissen aus Datenströmen von primitiven Ereignissen. Von Messereignissen aus mit Sensoren ausgestatteten Geräten über Transaktionen im Handel bis hin zu Benutzerinteraktionen auf Webseiten entstehen täglich unzählig viele Ereignisse, die abhängig von ihrem Kontext für einen bestimmten Zeitraum ein Stück der echten Welt korrekt abbilden.
|
||||
Wie der Begriff \enquote{Complex Event Processing} schon andeutet, geht es bei CEP um die Verarbeitung von komplexen Ereignissen --- konkret: Die Erkennung und Erfassung von komplexen Ereignissen aus Datenströmen von primitiven Ereignissen. Von Messereignissen aus mit Sensoren ausgestatteten Geräten über Transaktionen im Handel bis hin zu Benutzerinteraktionen auf Webseiten entstehen täglich unzählig viele Ereignisse, die abhängig von ihrem Kontext für einen bestimmten Zeitraum ein Stück der echten Welt korrekt abbilden.
|
||||
|
||||
Die Informationen dieser Ereignisse stellen nur einen momentanen Zustand dar; sie sind für sich alleine betrachtet Kontext- und somit Bedeutungslos. Betrachtet man beispielsweise ein Ereignis \enquote{Die gemessene Temperatur beträgt 42°C.}, so ist zunächst nicht einmal zu erkennen, was es mit dieser Temperatur auf sich hat. Hier kommt das \emph{Hintergrundwissen} (auch Domänenwissen) ins Spiel, welches uns in diesem Fall verraten kann, dass die Quelle dieses Ereignisses ein Sensor in einem PKW ist und am Motorblock befestigt ist. Dieses Wissen beinhaltet auch weitere Angaben zum konkreten Modell des PKW - unter anderem auch dessen zulässige Höchstgeschwindigkeit und die für den Motor zugelassenen Temperaturbereiche. Dies ermöglicht eine weiterführende Interpretation des Ereignisses; allerdings werden noch weitere Informationen benötigt, um ein eindeutiges Bild zu erhalten. Kombiniert man dieses Ereignis mit den Meldungen des im PKW installierten Geschwindigkeitssensors, so kann man herausfinden, ob die gemessene Motortemperatur für den aktuellen Betriebszustand des PKW innerhalb der im Hintergrundwissen für die über das spezifische PKW-Modell hinterlegten Grenzwerten liegt.
|
||||
Die Informationen dieser Ereignisse stellen nur einen momentanen Zustand dar; sie sind für sich alleine betrachtet Kontext- und somit Bedeutungslos. Betrachtet man beispielsweise ein Ereignis \enquote{Die gemessene Temperatur beträgt 42°C.}, so ist zunächst nicht einmal zu erkennen, was es mit dieser Temperatur auf sich hat. Hier kommt das \emph{Hintergrundwissen} (auch Domänenwissen) ins Spiel, welches uns in diesem Fall verraten kann, dass die Quelle dieses Ereignisses ein Sensor in einem PKW ist und am Motorblock befestigt ist. Dieses Wissen beinhaltet auch weitere Angaben zum konkreten Modell des PKW --- unter anderem auch dessen zulässige Höchstgeschwindigkeit und die für den Motor zugelassenen Temperaturbereiche. Dies ermöglicht eine weiterführende Interpretation des Ereignisses; allerdings werden noch weitere Informationen benötigt, um ein eindeutiges Bild zu erhalten. Kombiniert man dieses Ereignis mit den Meldungen des im PKW installierten Geschwindigkeitssensors, so kann man herausfinden, ob die gemessene Motortemperatur für den aktuellen Betriebszustand des PKW innerhalb der im Hintergrundwissen für die über das spezifische PKW-Modell hinterlegten Grenzwerten liegt.
|
||||
|
||||
Ein weiterer, wichtiger Faktor ist der Zeitraum in dem gewisse Ereignisse auftreten. Um dies näher zu erläutern, betrachten wir den gegebenen Ereignisstrom aus Listing~\ref{lst:sample_eventstream}.
|
||||
\begin{lstlisting}[caption={Exemplarischer Ereignisstrom: Motortemperatur eines PKW},label={lst:sample_eventstream}]
|
||||
|
|
@ -201,6 +203,7 @@ Ein weiterer Kernaspekt von CEP ist die Mustererkennung in Ereignissen. Aus best
|
|||
|
||||
Insgesamt liegt die Herausforderung von CEP darin, in kürzester Zeit große Datenströme von Ereignissen mit Hintergrundwissen anzureichern, diese zu höherwertigen Ereignissen zu kombinieren und bestimmte Muster zu finden, sowie die Ergebnisse mit möglichst geringer Verzögerung in Echtzeit ausgeben zu können oder Reaktionen einzuleiten.
|
||||
|
||||
|
||||
\section{Complex Event Processing auf RDF-Datenströmen}
|
||||
|
||||
\begin{draft}
|
||||
|
|
@ -247,13 +250,17 @@ WHERE {
|
|||
}
|
||||
\end{lstlisting}
|
||||
|
||||
|
||||
\chapter{Gegenüberstellung existierender CEP-Engines}
|
||||
|
||||
Es gibt bereits einige Technologien um Ereignisströme zu verarbeiten.
|
||||
Im Folgenden stelle ich nun ein paar bekannte Systeme kurz vor.
|
||||
|
||||
|
||||
\section{Anforderungen an CEP-Engines}
|
||||
|
||||
Öhm \dots wie sieht dieser Part eigentlich aus? Habe ich wirklich Anforderungen? Immerhin wird es irgendwo Grenzen geben, was für Anforderungen ich stellen kann.
|
||||
|
||||
Wichtig wären gegebenenfalls diese Kriterien:
|
||||
|
||||
\begin{itemize}
|
||||
|
|
@ -262,7 +269,7 @@ Wichtig wären gegebenenfalls diese Kriterien:
|
|||
\item Konstruktion neuer Ereignisse
|
||||
\item Sliding/Tumbling Windows
|
||||
\item Mustererkennung (Abfolge, Präsenz/Absenz von Ereignissen [zeitlicher Abstand])
|
||||
\item \enquote{COMPUTE EVERY} - Neuberechnung in festen Intervallen
|
||||
\item \enquote{COMPUTE EVERY} (Neuberechnung in festen Intervallen)
|
||||
\item Ausführen von benutzerdefiniertem Code
|
||||
\item Integration von Hintergrundwissen [aus weiteren Quellen]
|
||||
\item Aggregationsfunktionen über mehrere Ereignisse (Sum, Avg, ...)
|
||||
|
|
@ -272,79 +279,103 @@ Wichtig wären gegebenenfalls diese Kriterien:
|
|||
|
||||
\section{Etalis/EP-SPARQL}
|
||||
|
||||
\dots
|
||||
|
||||
|
||||
\section{CQELS}
|
||||
|
||||
\dots
|
||||
|
||||
|
||||
\section{Esper}
|
||||
|
||||
Ein Ansatz mit einer eigenen Abfragesprache.
|
||||
Hintergrundwissen etwas fummelig, aber theoretisch möglich. Nur halt nicht in der selben Abfragesprache.
|
||||
|
||||
|
||||
\section{C-SPARQL}
|
||||
|
||||
Verarbeitet Ströme im RDF-Format. Kann Hintergrundwissen im RDF-Format einbeziehen. Wurde in Java implementiert \dots
|
||||
Es gibt einen W3C-Standard für die Sprache C-SPARQL.
|
||||
Diese Engine werde ich nachher genauer vorstellen und benutzen.
|
||||
|
||||
|
||||
\subsection{Bekannte Probleme}
|
||||
|
||||
Die Timestamp-Funktion der C-SPARQL-Engine (Version 0.9.6) gibt für Tripel die Literale enthalten keinen Timestamp zurück. Dadurch ist es nicht direkt möglich, solche Tripel zeitlich einzuordnen. Es ist allerdings möglich, dieses Problem durch Erweiterung oder Umstrukturierung der Ereignistripel zu umgehen.
|
||||
|
||||
|
||||
\chapter{Die C-SPARQL-Engine im Detail}
|
||||
|
||||
So, hier kommt dann das, was man so zu C-SPARQL erzählen kann.
|
||||
Dieser Bereich bekommt noch genug Sections für die Features von C-SPARQL.
|
||||
\begin{itemize}
|
||||
\item Woher kommt sie, wie sieht die Entwicklung zur Zeit aus?
|
||||
\item Eckdaten über Implementierung
|
||||
\item Warum wurde gerade diese Engine gewählt?
|
||||
\item Fähigkeiten und Funktionen?
|
||||
\end{itemize}
|
||||
|
||||
\todo {Teilbereiche überdenken und füllen}
|
||||
|
||||
\chapter{Die C-SPARQL-Engine im Einsatz}
|
||||
|
||||
Hier wird jetzt mal wirklich C-SPARQL verwendet.
|
||||
\begin{itemize}
|
||||
\item RDF-Datenströme
|
||||
\item Beispielszenario
|
||||
\item Umsetzung mit C-SPARQL
|
||||
\item Nötiger Code für das Grundsetup der Engine, Generatoren und co
|
||||
\item Konkreter Blick auf die CSPARQL-Queries
|
||||
\item Ergebnisse der Abfragen
|
||||
\end{itemize}
|
||||
|
||||
\section{RDF-Datenströme}
|
||||
|
||||
Spannender ist es, wenn man dann ein Haufen RDF-Tripel reingedrückt bekommt.
|
||||
Die sehen anders aus, sind aber auch toll.
|
||||
Schemenhaft könnten die ja so aussehen:
|
||||
|
||||
Wir können uns diese Datenströme angucken und beispielsweise auf bestimmte Dinge achten.
|
||||
Aber irgendwie ist das nicht so toll, weil unsere Abfragen recht spezifisch sein müssen.
|
||||
Wäre es nicht toll, wenn wir bestimmte Dinge bereits vorher irgendwie da integrieren könnten?
|
||||
|
||||
\section{Beispielszenario}
|
||||
|
||||
Ich hab noch keine richtig tolle Idee, aber das kommt noch.
|
||||
|
||||
\section{Umsetzung mit C-SPARQL}
|
||||
|
||||
Jetzt kommt ein kurzer Schwank dazu, wie die Umsetzung gedacht ist.
|
||||
|
||||
\subsection{Nötiger Code für das Setup}
|
||||
|
||||
Zunächst wird ein Datenstrom benötigt; dafür wäre ein kleiner Generator nicht verkehrt.
|
||||
|
||||
\subsection{Abfrage des Datenstroms mit C-SPARQL}
|
||||
|
||||
Und jetzt werden Listener und Abfragen gebaut, um aus diesem Strom Informationen zu extrahieren oder neue, höherwertige Ereignisse zu konstruieren.
|
||||
|
||||
\section{Bewertung/Ergebnis}
|
||||
|
||||
\enquote{Und? Wie war's?}
|
||||
\begin{itemize}
|
||||
\item Konnten die gestellten Anforderungen erfüllt werden?
|
||||
\item Was konnte erreicht werden?
|
||||
\item Was konnte nicht erreicht werden?
|
||||
\item Gab es Schwierigkeiten?
|
||||
\item Wie hoch war der Aufwand?
|
||||
\item Wie steht es um die Qualität der Ergebnisse?
|
||||
\item Eventuell ein Blick auf die Performance?
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\chapter{Fazit}
|
||||
|
||||
Die Engine macht sich hoffentlich ganz gut.
|
||||
\begin{itemize}
|
||||
\item Bewertung der Ergebnisse im Abgleich mit den Anforderungen und dem Aufwand?
|
||||
\item Ist es für die Anforderungen (und mehr) praxistauglich?
|
||||
\item Oder gibt es zur Zeit bessere Alternativen?
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\chapter{Ausblick}
|
||||
|
||||
Vielleicht geht das mit dem Reasoning später ja noch besser - aktueller Stand ist noch limitiert, aber es wird fleißig daran geforscht. \dots
|
||||
\begin{itemize}
|
||||
\item Kann man mit der Engine in Zukunft noch mehr schaffen?
|
||||
\item Wie steht es um Reasoning?
|
||||
\end{itemize}
|
||||
|
||||
% Kurzer Test
|
||||
\cite{hsh:cep}[Einstieg]
|
||||
\cite{hsh:integrating}[erste Quelle]
|
||||
\cite{barbieri:reasoning}[zweite Quelle]
|
||||
\cite{barbieri:querying}[dritte Quelle]
|
||||
Vielleicht geht das mit dem Reasoning später ja noch besser --- aktueller Stand ist noch limitiert, aber es wird fleißig daran geforscht \dots
|
||||
|
||||
\chapter*{Dummy-Kapitel für Tests}
|
||||
|
||||
\textcolor{red}{Dieses Kapitel fliegt am Ende natürlich raus.}
|
||||
|
||||
Sil-ben ge-trenn-t mit ei-nem Strich
|
||||
|
||||
C--SPARQL (Zwei Striche ergeben einen Bindestrich)
|
||||
|
||||
Und dann --- neben vielen anderen Zeichen --- gibt es mit drei Strichen den Gedankenstrich.
|
||||
|
||||
\begin{itemize}
|
||||
\item \cite{hsh:cep}[Einstieg]
|
||||
\item \cite{hsh:integrating}[erste Quelle]
|
||||
\item \cite{barbieri:reasoning}[zweite Quelle]
|
||||
\item \cite{barbieri:querying}[dritte Quelle]
|
||||
\end{itemize}
|
||||
|
||||
% Referenz auf Bibtex mit Kommentar
|
||||
% \cite{robbins:gawk}[Siehe ab S.95]
|
||||
|
|
|
|||
Loading…
Reference in New Issue