[TASK] Add some introduction.
This commit is contained in:
parent
39ff95967c
commit
aa8ab697bd
|
@ -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]
|
||||
|
|
Loading…
Reference in New Issue