Masterarbeit mit der IKS Teil 2

Ankunftszeitprognose: Wann wird das Schiff an seinem Ziel ankommen?
Zwar enthalten die AIS-Nachrichten bereits eine geschätzte Ankunftszeit (ETA), diese wird jedoch händisch eingegeben und ist oft fehlerbehaftet. Daher soll anhand aktueller Parameter ermittelt werden, wann das Schiff an seinen Bestimmungsort sein wird. Bei dieser Fragestellung ist eine Echtzeit-Aktualisierung zwar schön, aber nicht zwingend notwendig. Die geschätzte Ankunftszeit ist beispielsweise für fast alle wichtig, die an einer Logistikkette beteiligt sind. Denn wer möchte schon auf seine Lieferung warten und dabei nicht wissen, wie lange die Verzögerung ist?

Alle drei Fragestellungen wurden mit den beiden Verarbeitungssystemen Apache Kafka und Apache Spark bearbeitet. Für die Anwendungsfälle mit nicht zwingender Echtzeitanforderung wurde die relationale, aber sehr schnelle Datenbank Exasol verwendet. Diese In-Memory-Datenbank ist sehr schnell. Zur Durchführung der Anwendungsfälle erstellte ich eine „Datenverarbeitungspipeline“. Pipeline deswegen, weil die Daten von links nach rechts fließen und verschiedene Schritte durchlaufen. In meinem Fall traf das zwar nicht ganz zu, weil zum Teil Daten wieder zurückflossen. Dennoch fand ich dieses Bild der Pipeline sehr hilfreich für das Verständnis.

Am liebsten hätte ich sofort damit begonnen, die erstellten Anwendungsszenarien zu bearbeiten. Doch ganz so schnell ging es nicht. Die gründliche Vorbereitung war und ist das A und O. Zur Datenvorbereitung zählten mehrere Schritte.

Der erste Schritt

bestand darin, die AIS-Schiffsnachrichten zu besorgen. Dafür zapfte ich nicht nur eine Quelle an, sondern nutzte mehrere Anbieter. So waren die Technologien ebenso unterschiedlich wie die Datenformate. Das überraschte nicht, denn dies ist eine typische Herausforderung von „Big Data“. Mit sogenannten „Feedern“, kleine Kafka-Producer-Anwendungen, wurden die Nachrichten dann in das Kafka-System geladen und in „Topics“ gespeichert. Darunter versteht man so etwas wie ein Postfach. In diese Postfächer schreiben sogenannte Kafka-Producer und aus den Postfächern lesen Consumer. Mit dem Laden der Nachrichten ins Kafka-System ist es aber noch lange nicht getan.

Die Antennenposition, die Referenzpunkte und deren Beziehung 

Die Erde ist ja bekanntlich keine Scheibe

Bis die Daten verwendet werden können, müssen sie noch vereinheitlicht, angereichert und von fehlerhaften oder unbrauchbaren Nachrichten befreit werden. Schlussendlich landeten die Nachrichten in einem einheitlichen Format (GeoJSON) in einem Topic. Dieses Topic stellte den Ausgangspunkt für alle weiteren Analyseschritte dar. Alle Vorbereitungsschritte wurden ausschließlich mit Kafka und der integrierten Streaming-Bibliothek KStreams vorgenommen. Diese Bibliothek eignet sich für diese Art der Datentransformation sehr gut, da sie direkt in Kafka integriert ist. Das ermöglicht es aus Topics zu lesen, die Nachrichten zu bearbeiten (transformieren) und danach wieder in ein Topic einzuspeisen. Um die Schiffsnachrichten besser zu verstehen, habe ich zusätzlich ein kleines Werkzeug zur Visualisierung gebastelt. Damit konnte ich die Strecken der Schiffe auf einer Karte einzeichnen und so die Funkabdeckung prüfen. Zu erfahren, welche Besonderheiten der Umgang mit Geodaten mit sich bringt, war eine weitere Herausforderung für mich. Die Erde ist ja bekanntlich keine Scheibe, deswegen sind Entfernungsberechnungen und die Arbeit mit Koordinaten gar nicht so leicht. Festzuhalten ist auf jeden Fall, dass der wichtige Schritt der Datenvorbereitung nicht auf die leichte Schulter zu nehmen ist. Der Aufwand lohnt sich aber definitiv!

Nach den ausführlichen Vorbereitung hieß es endlich: „Ablegen“ zur Umsetzung der Anwendungsfälle!

Indem ich die Probleme mit den verschiedenen Systemen anging, konnte ich zeigen, wie sich die Programme und Frameworks für diese spezielle Geodaten eignen. Zunächst musste ich aber die Szenarien in mathematischen bzw. geometrische Fragestellungen „übersetzen“. Logistikschiffe sind zum Teil um die 200 Meter lang. Somit wäre es zu ungenau gewesen, die Schiffspositionen lediglich als „Punkte“ darzustellen. Vielmehr sollte das Schiff als geometrische Figur wie ein Rechteck abgebildet werden. Da in der Schiffsnachricht Informationen über die Position der GPS-Ende enthalten sind, konnte ich unter Anwendung der Mathematik die Koordinaten der Eckpunkte bestimmen. Dadurch war es beispielsweise leicht zu prüfen, ob ein Schiff in Form eines Polygons innerhalb eines Kreises liegt, der die Überwachungszone darstellt. Etwas komplizierter waren die zwei anderen Anwendungsfälle. Um die Ankunftszeit vorherzusagen, setzte ich die Distanz der aktuellen Schiffsposition zum Zielort in das Verhältnis mit dem Durchschnitt der letzten X Geschwindigkeiten. Die Information, wann das Schiff am Ziel ist, muss nicht zwingend in Echtzeit geliefert werden. Diesen Anwendungsfall musste ich vereinfachen, so auch die Kollisionswarnung. Das ist aber insofern kein Problem, da die Szenarien ja eher Mittel zum Zweck der Evaluation waren. Damit ich prüfen konnte, ob sich zwei Schiffe gefährlich nahe kommen, schätzte ich die zukünftige Fahrstrecke der Schiffe, wenn sie ihren aktuellen Kurs und Geschwindigkeit beibehalten. Aus den zwei Strecken konnte ich dann den Schnittpunkt berechnen, wie in der Schulmathematik. Sind die Zeitpunkte, an denen die Schiffe den Schnittpunkt erreichen werden, zu nah beisammen, wird eine Alarmnachricht ausgegeben.

Visualisierung der Prüfung, ob ein Schiff, dargestellt als POINT innerhalb (within)einer durch ein POLYGON festgelegten Zone liegt.

Apache Kafka ideal für Datenstrom-Neulinge

Mit allen Systemen konnte ich die Anwendungsfälle umsetzen. Der Aufwand und das Vorgehen hierfür unterschied sich von System zu System stark. Da Apache Kafka und Spark keine Funktionalitäten für Geodaten boten, mussten stattdessen Geodaten-Bibliotheken als Hilfsmittel herangezogen werden. Apache Sedona und die Exasol-Datenbank verfügen hingegen selbst über viele Geodaten-Funktionalitäten. Weil die Exasol-Datenbank durch ihre In-Memory-Technologie sehr schnell ist, kann sie durchaus als Alternative zu den Streaming-Plattformen angesehen werden. Dies gilt dann, wenn die Echtzeit-Anforderungen nicht zu streng sind. Möchte man mit nachträgliche Analysen wissen, wann zum Beispiel wie viele Schiffe innerhalb einer Zone lagen, eignet sich die relationale Datenbank nach wie vor. Apache Kafka konnte vor allem damit punkten, dass es einerseits ein etabliertes Nachrichtensystem ist, mit KStreams zugleich aber auch eine Datenstrom-Bibliothek beinhaltet. Das ist vor allem für Datenstrom-Neulinge wie ich es war sehr praktisch, weil man zunächst nur mit einem System schon viel mit Datenströmen experimentieren kann. Benötigt man viele verschiedene Geodaten-Funktionen und muss man mit mehreren Geodaten-Formaten hantieren, empfiehlt sich auf jeden Fall ein Blick auf spezielle Big-Geodaten-Verarbeitungssysteme. Diese gibt es so gut wie nur für Apache Spark, jedoch nicht für Apache Kafka. Dazu zählt auch Apache Sedona als Erweiterung für Apache Spark, das früher als „Geospark“ bekannt war. Damit war das direkte Einlesen der Nachrichten als GeoJSON möglich und die Probleme ließen sich mit deutlich weniger Codezeilen mit viel Ähnlichkeiten zu SQL lösen. Allerdings hatte ich anfangs etwas mit Kompatibilitätsproblem zu kämpfen.

Kurz gesagt: Es gibt keinen klaren „Gewinner“, der bei der Geodaten-Verarbeitung das Mittel der Wahl ist. Es kann sogar sinnvoll sein, mehrere Systeme zu kombinieren.

Wie kam es eigentlich zur Zusammenarbeit mit IKS und wie wurde das Thema der Masterarbeit festgelegt? Darum geht es in

Masterarbeit mit der IKS Teil 1

Ein Resümee über die Zusammenarbeit und auch äußeren Umstände zieht Mario in

Masterarbeit mit der IKS Teil 3