Schnell wurden wir uns einig, dass wir den für beiden Seiten neuen Weg gemeinsam gehen wollten.

Die Themenwahl verlief im konstruktiven Austausch. Big Data ist in gewisser Weise in der IT-Branche ja das Gebot der Stunde. Daher war ich gleich angetan, als sich aus der Ideensammlung der Teilbereich „Stream Processing“ herauskristallisierte. Die Herausforderung, mit großen Datenmengen zu jonglieren, reizte mich vom ersten Moment an. Ich durfte mich auch sehr glücklich schätzen, mit Christoph Schmidt-Casdorff einen der erfahrensten Software-Architekten der IKS an meine Seite gestellt zu bekommen. Gemeinsam mit Prof. Dr. Schildgen, den ich ebenfalls mit dem Themen-Vorschlag begeistern konnte, entwickelten wir dann einen Ansatz, der direkten Praxisbezug hat.

"Was hat Schifffahrt mit Big Data zu tun?"

Die IKS sorgte für den Kontakt zu einem großen Kunden aus dem Logistikbereich, welcher als Ideengeber mit an Bord geholt wurde. An Bord ist in diesem Fall sogar ziemlich direkt zu nehmen. Logistik heißt nämlich auch Schifffahrt und genau in diesem Umfeld habe ich mich rund ein halbes Jahr lang beschäftigt. Nun wirst du dich sicherlich fragen, was die Schifffahrt mit Big Data oder Datenstromverarbeitung zu tun haben wird. Ganz einfach: Auch Schiffe erzeugen heute Big Data! Seit der Jahrtausendwende sind die meisten Schiffe mit einem speziellen Funksystem ausgestattet. Das sendet alle paar Minuten oder sogar Sekunden aktuelle Infos wie die GPS-Position oder die Geschwindigkeit. Solche Daten mit örtlichem Bezug werden auch als Geodaten bezeichnet. Ursprünglich wurde das Funksystem eingeführt, um Kollisionen zu vermeiden und die Seefahrt sicherer zu machen. Weil man sich diese „AIS“-Nachrichten heute aber auch über das Internet besorgen kann, sind den Anwendungsmöglichkeiten keine Grenzen gesetzt. Dazu zählen auch Fragen wie „Wann ist mein Schiff am Zielhafen?“ oder „Ist der Zielhafen überfüllt und muss ich mit Verspätungen rechnen?“. Fragen, die auch für Logistikunternehmen relevant sind.

So hatten wir also schon mal eine grobe Richtung: Ich sollte mich intensiv mit der Datenstromverarbeitung beschäftigen. Die Daten, die verarbeitet werden, stammen von den Schiffen. Durch deren Analyse wollte ich aber nicht nur das ein oder andere interessante Szenario beantworten. Stattdessen sollte die Masterarbeit zeigen, wie sich die eingesetzten Datenstromsysteme dazu eigenen, mit Geodaten zu arbeiten. Doch schießen wir vielleicht mit der Kanone auf Spatzen? Gibt es Fälle, wo herkömmliche Ansätze wie relationale Datenbanken auch ausreichend sein können? Auch diese Fragen sollten behandelt werden. Denn Ziel einer wissenschaftlichen Arbeit ist es auch, seine Entscheidungen sauber zu begründen und auch den Blick auf Alternativen zu werfen.

Die Schritte des Datenbezuges über verschiedene Zwischentopics und Transformationen bis hin zu einem zentralen Zieltopic als Ausgangspunkt für eine weitere Datenstromverarbeitung (Quelle: eigene Abbildung)

Aller Anfang ist schwer

Gar nicht so einfach, sich in ein abgeschlossenes und rundes Thema einzufinden. Aber es braucht ein konkretes Ziel vor Augen, auf das man in den folgenden 6 Monaten hinarbeiten kann.

Nachdem der Schritt der Themenfindung endlich geschafft war, konnte ich mich ins Getümmel stürzen. Ein Getümmel voller neuen Technologien und Arbeitsweisen. Ich habe viele Hobbies. Die Boot- oder Schifffahrt gehörte jedoch bislang noch nicht dazu. Also hieß es für mich: ins Thema einlesen. Erstmal muss schließlich ich die Daten verstehen, um sie dann später mit den verschiedenen Systemen analysieren lassen zu können. Gleichzeitig verlangte die Einarbeitung in die Datenstromverarbeitung von mir, dass ich meine bisherigen Denkmuster und Arbeitsweisen über Bord werfe! Bis dato war ich gewohnt, die Daten irgendwo zwischen zu speichern und diese dann häppchenweise zu verarbeiten. „Map-Reduce“ mit Apache Hadoop ist dafür ein typisches Beispiel. Bei einem Datenstrom ist es jedoch so, dass die Informationen nicht erst abgelegt werden, sondern sofort bei ihrem Auftreten verarbeitet werden. Der Vorteil dabei liegt auf der Hand: Schnellere Verwertung heißt schnelleres Reagieren. Stell dir vor, eine von vielen teuren Maschinen in einem Industriebetrieb gibt verdächtige Protokollmeldungen aus. Sie wird möglicherweise zu heiß. Wir werten diese Daten aber erst Stunden später aus, als es schon zu spät ist. Eine Überwachung aller Protokolle aller Maschinen in nahezu Echtzeit – mittels Datenstromverarbeitung – hätte uns dies erspart.

Doch mit welchen Tools sollten wir unsere Werkzeugkiste füllen?

Wir einigten uns auf die zwei Big Data-Frameworks Apache Kafka und Spark. Kafka ist sehr bekannt als Nachrichten(puffer)system, Spark als skalierbares Cluster Verarbeitungsframework. Beide sind für alle Arten von Daten gemacht und unterstützen mittlerweile Datenströme, es gibt aber keine spezielle Geodaten-Funktionen. Der Alternativansatz mit einer relationalen Datenbank sollte mit der sehr schnellen In-Memory-Datenbank „Exasol“ umgesetzt werden. Diese Datenbank hat sogar bereits einige Funktionen für Geodaten integriert. Ich kannte alle drei Systeme bis dahin noch nicht. So stand ich vor den Fragen: „Wie bekomme ich die ganzen Plattformen zum Laufen? Wie können sie untereinander kommunizieren?“ Fragen, zu denen ich Antworten finden musste, bevor es an das eigentliche Thema der Masterarbeit ging. Es beruhigte mich ungemein, dass ich mit Christoph einen sehr kompetenten Ansprechpartner an der Seite hatte.