[TASK] Add some introduction.

This commit is contained in:
Jan Philipp Timme 2016-05-03 17:05:04 +02:00
parent 39ff95967c
commit aa8ab697bd
2 changed files with 72 additions and 103 deletions

View File

@ -148,26 +148,24 @@ Hannover, den \today \hfill Unterschrift
\chapter{Einleitung}
\todo
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.
Diese Arbeit beschäftigt sich mit der Verarbeitung von komplexen Ereignissen (CEP) auf RDF-Datenströmen mit C-SPARQL.
\chapter{Einführung in Complex Event Processing}
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 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 Features Anwendung finden. Im Abschluss wird ein kurzer Ausblick auf die technischen Möglichkeiten des Reasoning gegeben - eine Technik, die es erlaubt auf den vorhandenen und eingehenden Daten logische Schlussfolgerungen und Operationen durchzuführen um neues Wissen zu erhalten.
\todo
Was ist CEP und warum sollte man es verwenden wollen?
\section{Einführung in Complex Event Processing}
Generell sollen Muster von primitiven Events erkannt und zu komplexen Events zusammengefasst werden. (Niedrige Abstraktion \textrightarrow~ Höhere Abstraktion). Dann sollen daraus tolle Erkenntnisse gewonnen werden.
Im folgenden Abschnitt wird ein kurzer Überblick über Complex Event Processing (CEP) gegeben. Eine detailreiche Erläuterung von CEP und die Anwendung der Engine Esper in einem Beispielszenario wird in \cite{hsh:cep} beschrieben.
Ereignisse stellen einen konkreten momentanen Zustand dar, aber sind für sich alleine betrachtet kontextlos; die daraus resultierende Bedeutung fehlt. Weiterhin sind diese Informationen oft nur für einen begrenzten Zeitraum gültig.
Die Erkennung von Mustern in den Ereignissen ist interessant.
Wir verarbeiten Ereignisströme und versuchen aus dem großen Rauschen bestimmte Ereignismuster zu erkennen.
Und wir wollen kurz-, mittel- oder langfristig bestimmte Werte beobachten und sicherstellen, dass sie innerhalb eines spezifizierten Wertebereichs bleiben.
Es ist eine tolle Herangehensweise, um aus großen Datenströmen wesentliche Informationen zu extrahieren - noch bevor ein Mensch diese Daten zu Gesicht bekommt.
\section{Ereignisquellen}
\todo
Ereignisse treten überall auf, wenn man sich darauf einlässt.
Welche Ereignisse kann man sich denn so vorstellen?
@ -185,8 +183,6 @@ Diese hier:
\section{Ereignisse als Informationsträger}
\todo
Alles, was irgendwo passiert liefert Informationen über den Zustand unserer Umgebung.
Jede aktuell gemeldete Information ist ein Ereignis. Eine gerade gemessene Temperatur, eine Fehlermeldung einer Werkzeugmaschine oder das Auslösen eines Rauchmelders sind Ereignisse, die einen aktuellen Zustand unserer Welt repräsentieren.
@ -207,62 +203,53 @@ Ein Ereignis kann beispielsweise so strukturiert sein:
\section{Ereignisströme als Datenquelle}
\todo
Ja, Ereignisse treten öfters in Rudeln auf. Wenn viele Ereignisse aneinandergereiht werden, spricht man von einem Ereignisstrom.
Anbieter von Daten können anstatt aktueller Messwerte als einzelnes Ereignis natürlich gleich Ereignisströme liefern. Das ist technisch sicherlich auch ganz praktisch, weil Verzicht auf Polling und so Sachen.
\chapter{Gegenüberstellung existierender CEP-Engines}
\todo
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}
Wichtig wären gegebenenfalls diese Kriterien:
\paragraph{Integration von Hintergrundwissen}
Ereignisse kommen ohne Kontext, daher ist es nötig, sie in einen Kontext zu bringen, um etwas mit dem Ereignis anfangen zu können.
Um nun den passenden Kontext herzustellen, muss dieses Ereignis also mit weiteren Daten verknüpft werden.
Das können andere Ereignisse oder Daten sein, die uns schon bekannt sind - Hintergrundwissen.
\paragraph{(Performance)}
Auch, wenn einige tausend Ereignisse über einen Datenstrom in der Minute eintreffen muss die Software dennoch sehr zeitnah (im Idealfall sofort) Ergebnisse liefern.
(Das hier wird später ein Grund sein, weshalb Reasoning nur sehr begrenzt auf Datenströmen stattfinden kann oder aber sehr teuer ist.)
\begin{itemize}
\item Verarbeitung von mehreren Ereignisströmen
\item Kombination von Ereignissen \enquote{Join}
\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 Ausführen von benutzerdefiniertem Code
\item Integration von Hintergrundwissen [aus weiteren Quellen]
\item Aggregationsfunktionen über mehrere Ereignisse (Sum, Avg, ...)
\item Vergleichsoperatoren für Selektionskriterien
\item Bonuspunkte: Reasoning (Logikoperationen und Schlussfolgerungen)
\end{itemize}
\section{Etalis/EP-SPARQL?}
\todo
Kenne ich noch nicht.
\section{CQELS?}
\todo
Kenne ich noch nicht.
\section{Esper}
\todo
Ein Ansatz mit einer eigenen Abfragesprache.
Hintergrundwissen etwas fummelig, aber theoretisch möglich. Nur halt nicht in der selben Abfragesprache.
\section{C-SPARQL}
\todo
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.
\chapter{Die C-SPARQL-Engine im Detail}
\todo
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.
@ -276,14 +263,10 @@ Dieser Bereich bekommt noch genug Sections für die Features von C-SPARQL.
\chapter{Die C-SPARQL-Engine im Einsatz}
\todo
Hier wird jetzt mal wirklich C-SPARQL verwendet.
\section{RDF-Datenströme}
\todo
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:
@ -294,48 +277,34 @@ Wäre es nicht toll, wenn wir bestimmte Dinge bereits vorher irgendwie da integr
\section{Beispielszenario}
\todo
Ich hab noch keine richtig tolle Idee, aber das kommt noch.
\section{Umsetzung mit C-SPARQL}
\todo
Jetzt kommt ein kurzer Schwank dazu, wie die Umsetzung gedacht ist.
\subsection{Nötiger Code für das Setup}
\todo
Zunächst wird ein Datenstrom benötigt; dafür wäre ein kleiner Generator nicht verkehrt.
\subsection{Abfrage des Datenstroms mit C-SPARQL}
\todo
Und jetzt werden Listener und Abfragen gebaut, um aus diesem Strom Informationen zu extrahieren oder neue, höherwertige Ereignisse zu konstruieren.
\section{Bewertung/Ergebnis}
\todo
\enquote{Und? Wie war's?}
\chapter{Fazit}
\todo
Die Engine macht sich hoffentlich ganz gut.
\chapter{Ausblick}
\todo
Vielleicht geht das mit dem Reasoning später ja noch besser - aktueller Stand ist noch limitiert, aber es wird fleißig daran geforscht. \dots
% Kurzer Test
\cite{hsh:cep}[Einführung]
\cite{hsh:cep}[Einstieg]
\cite{hsh:integrating}[erste Quelle]
\cite{barbieri:reasoning}[zweite Quelle]
\cite{barbieri:querying}[dritte Quelle]