header_picture

Projekt

-

Du möchtest gerne mehr über unser Projekt erfahren? Gerne!
Auf dieser Seite beschreiben wir unser Projekt, dazu gehört was uns dazu motiviert hat dieses Projekt zu machen, wie unsere Architektur aufgebaut ist und wie die einzelnen Komponenten funktionieren.

Motivation

Datenmenge
Abbildung 1: Datenmenge

In den letzten Jahren konnte ein signifikanter Anstieg von maritimen Daten und Datenquellen beobachtet werden. Allein im Jahr 2000 wurden mehr Daten im maritimen Bereich gesammelt als in den 100 Jahren davor. Die Bereiche, in denen die Daten erhoben werden, sind dabei sehr unterschiedlicher Natur. Zu den Datenquellen gehören beispielsweise Thermographen zur Ermittlung der Wassertemperatur oder sogenannte Drifter, um die Strömungsgeschwindigkeiten zu ermitteln, aber auch Daten aus autonomen Fahrzeugen.
All diese verschiedenen Daten finden ihre Anwendung in der maritimen Forschung. Unser Projekt MIRAPLA legt dabei das Hauptaugenmerk auf die Anwendung von Künstlicher Intelligenz auf diese heterogenen Daten. Auf der Basis der vorhandenen Daten können beispielsweise illegale Fischerboote erkannt werden. Zudem besteht das Potenzial Schiffe zu erkennen, bevor diese in Naturschutzgebiete eindringen. Die Daten können auch für die Erhöhung der Verkehrseffizienz genutzt werden, denn auf der Basis von Strömungsgeschwindigkeiten oder Wellengänge könnten effizientere Routen bestimmt werden.

Problemstellung

Im vorherigen Abschnitt wurde angesprochen, dass es im maritimen Bereich viele verschiedene Datenquellen gibt, die sehr unterschiedliche Daten bereitstellen. Nicht alle Datenquellen sind jedoch öffentlich zugänglich. Zudem gibt es einige Hürden zu meistern, damit die verschiedenen Datenquellen gemeinsam genutzt werden können. Da jede Datenquelle unterschiedliche Daten beinhaltet, müssen die Daten zusammengeführt werden, um einen höheren Informationsgewinn zu erhalten.
Des Weiteren besteht auch eine Ungewissheit über die Entstehung der Daten und wie hoch die Eignung der Daten für das eigene Projekt ist. Zusätzlich kann mangelndes Vertrauen zwischen den Eigentümern der Daten und den potenziellen Nutzern dazu führen, dass Daten nicht für wissenschaftliche Projekte genutzt werden können. Letztlich werden wissenschaftliche Vorhaben im maritimen Bereich dadurch erschwert, dass es wenige Bibliotheken für die Aufbereitung von Daten mithilfe von künstlicher Intelligenz gibt, die auf die maritimen Daten zugeschnitten sind.

Ziele

Das Ziel dieser Projektgruppe ist es, die in der Problemstellung genannten Hürden zu überwältigen. Entwickelt werden soll vor diesem Hintergrund eine Plattform mit welcher verschiedene Typen von Datenquellen dezentral angebunden werden können. Dazu gehört auch das Zusammenfügen der Daten aus den unterschiedlichen Datenquellen.
Am Ende des Projekts soll somit eine modulare Plattform zur Anbindung dezentraler Datenquellen für KI-Projekte in einem wissenschaftlichen Rahmen entstehen. Dazu kommen verschiedene ergänzende sowie unterstützende Ziele, um den Funktionsumfang von MIRAPLA zu erweitern:

  • Ein Datenprovider, welcher Daten auf der Plattform zur Verfügung stellt, behält die Kontrolle darüber, welche Nutzer auf seine Datenbestände zugreifen dürfen und welche nicht.
  • Um den wissenschaftlichen Aspekt zu unterstützen, wird eine Dokumentation der Datenverarbeitungsschritte implementiert. Diese Nachvollziehbarkeit soll es ermöglichen dritten die gleichen Ergebnisse aus den Daten zu generieren.
  • Für die wissenschaftliche Anwendung in KI-Projekten werden Funktionen zur Datenaufbereitung zur Verfügung gestellt, diese umfassen beispielsweise eine Migration auf einen einheitlichen Datentyp über mehrere Datenquellen hinweg oder eine Bereinigung von fehlerhaften Daten.

Architektur

grobkonzept
Abbildung 2: Grobkonzept

Bei der MIRAPlattform handelt es sich um eine modular aufgebaute Plattform, die aus insgesamt vier verschiedenen Layern besteht. Jeder dieser Layer repräsentiert dabei einen spezifischen Aufgabenbereich. Bei den vier Layern der MIRAPlattform handelt es sich um den Konnektor-Layer, den Plattform-Layer, den Data-Processing-Layer und den Data-Distribution-Layer. Des Weiteren stellt MIRAPLA zum einen eine Bibliothek zur Verfügung, welche verschiedene Funktionen zur Verfügung stellt, um den Zugriff auf die Plattform zu verwirklichen und zum anderen ein User-Interface, welches dem Nutzer ermöglichen soll, die verschiedenen verfügbaren Datenquellen einzusehen.
Jeder der genannten Layer wird im Folgenden genauer vorgestellt. Dazu gehört beispielsweise, wie der jeweilige Layer aufgebaut ist und welche Aufgabenbereiche dieser repräsentiert.

Konnektor-Layer (External)

connector_layer
Abbildung 2: Konnektor-Layer

Der Konnektor-Layer dient als dazu die externen Datenquellen an die Plattform anzubinden. Da es verschiedene Typen von Datenquellen gibt, beispielsweise CSV-Dateien, REST-Schnittstellen oder verschiedene Datenbanken, stellt der Konnektor-Layer für jede angebundene Datenquelle einen Konnektor bereit. Der passende Konnektor muss lediglich mit den passenden Verbindungsinformationen gefüllt werden. Jede Datenquelle hat einen eigenen Konnektor.
Die angebundenen Datenquellen und auch die Konnektoren werden durch die Eigentümer der Daten verwaltet und bereitgestellt. Aus diesem Grund werden die Konnektoren in der Architektur von der Plattform abgegrenzt. Der Unterschied vom Konnektor-Layer zu den übrigen Layern ist, dass dieser ausgelagert von der üblichen Plattform ist.
Aufgrund der Problematik, dass jede Datenquelle eine andere Anfragesprache hat (bspw. SQL bei Datenbanken) wird eine mächtige Anfragesprache benötigt. MIRAPLA nutzt intern als Anfragesprache GraphQL. Vorteilhaft ist, dass die GraphQL-Anfragen in die entsprechenden nativen Anfragesprachen konvertiert werden und dadurch Anfragen vom Nutzer für jede Datenquelle auf die gleiche Art und Weise formuliert werden können. Die vom Nutzer gestellten GraphQL-Anfragen werden durch die gesamte Plattform gereicht.

Plattform-Layer

plattform_layer
Abbildung 3: Plattform Layer

Der Plattform-Layer befindet sich vor dem Konnektor-Layer und speichert unter anderem die Metainformationen der Datenquellen in einer Datenbank. Zu den gespeicherten Metainformationen gehört unter anderem der Name der Datenquelle eine Beschreibung und das Schema der Daten. Wenn eine Anfrage an die Plattform gestellt wird, dann findet zunächst eine Prüfung dieser statt. Nur valide Anfragen werden anschließend an den Konnektor-Layer weitergereicht. Zusätzlich können Informationen über alle vorhandenen Datenquellen bei dem Plattform-Layer angefragt werden.

Data-Processing-Layer

data_processing_layer
Abbildung 4: Data-Processing-Layer

Nachdem sich der Nutzer für eine Datenquelle entschieden hat, kann dieser nun auf die Daten zugreifen. An dieser Stelle kommt der Data-Processing-Layer ins Spiel. Innerhalb des Data-Processing-Layers werden die Daten aus den Datenquellen in einem sogenannten `Topic` innerhalb eines `Kafka-Clusters` geschrieben. Zusätzlich wird die Dokumentation der Datenverarbeitungsschritte durch die Data-Processing-Layer gespeichert.
Ein Nutzer der MIRAPlattform könnte beispielsweise die aktuellen Wetterdaten aus einer bestimmten Datenquelle anfragen. Besteht innerhalb des Kafka-Clusters bereits ein Topic mit den abgefragten Datenbestand, so werden die Daten an den Data-Scientist weitergegeben. Sollte kein Topic zur Verfügung stehen, wird die Anfrage an den entsprechenden Konnektor über den Konnektor-Layer weitergeleitet und ein neues Topic mit den Daten angelegt.
Jeder der durchgeführten Schritte, wie z. B. das Anfragen von Daten, das Zusammenfügen von verschiedenen Daten oder das Bereinigen von Daten wird im Rahmen einer Dokumentation abgespeichert. Als Basis dient dazu das `Open Provenance Model`. Das Open Provenance Model verbindet das Eingangs-Topic (Entität) durch Funktionen (Aktionen) wie die Datenbereinigung mit dem daraus entstehenden Ausgangs-Topic (Entität). Zusätzlich werden noch weitere Metainformationen über die Vorgänge abgespeichert. Bei diesen Informationen handelt es sich z. B. um den Bearbeiter oder den Zeitpunkt des Verarbeitungsschrittes.

Data-Distribution-Layer

data_distribution_layer
Abbildung 5: Data-Distribution-Layer

Als Concierge (Portier) der Plattform fungiert der Data-Distribution-Layer. Dieser ist die erste Instanz der Plattform und stellt die Verbindung zwischen der Plattform und dem Nutzer her. Jegliche Anfragen an die Plattform starten im Data-Distribution-Layer.
In diesem Layer befindet sich auch die Zugriffsverwaltung. MIRAPLA als wissenschaftliche Plattform ermöglicht nur registrierten Nutzern einen Zugriff auf die unterschiedlichen Datenquellen. Eingesetzt wird die Technologie Keycloak, um die Identitäten und Zugriffe zu verwalten. Im Rahmen der Authentifizierung und Autorisierung bei Keycloak wird jedem Nutzer ein Zugriffstoken zugeteilt. Nur mithilfe des Zugriffstokens können weitere Anfragen an die Plattform gestellt werden.
Zum Data-Distribution-Layer gehört des Weiteren die Bibliothek, welche in die Entwicklungsumgebung eingebunden wird. Diese Bibliothek stellt dem Nutzer verschiedene Funktionen zur Verfügung. Zu diesen Funktionen gehören beispielweise:

  • Das Authentifizieren bei Keycloak über ein PopUp-Fenster oder direkt über den Nutzernamen und Passwort.
  • Das Erstellen eines Producer zum Schreiben von Daten in ein Topic.
  • Das Erstellen eines Consumers zum Auslesen von Daten aus einem Topic.
  • Das Abfragen der Dokumentation zu einem Topic.
  • Das Erstellen von Bearbeitungsschritten für die Dokumentation.
  • Das Stellen von Anfragen.

Die Bibliothek wurde in Java geschrieben.
Die Bibliothek der MIRAPlattform wurde in Java geschrieben. Letzlich gehört auch das User Interface als Anbindung für den Nutzer zum Data-Distribution Layer. Das User Interface ermöglicht die Suche nach passenden Datenquellen auf Basis von Stichpunkten. Ebenfalls kann der Nutzer verschiedene Informationen über sein Profil einsehen und die Zugriffsrechte seines Zugriffstokens einsehen.

Schnittstellen

Aufgrund der Umsetzung einer modularen Architektur, müssen die einzelnen Layern auch untereinander Kommunizieren können. Dazu besitzt jeder einzelne Layer seine eigene REST-Schnittstelle. Die REST-Schnittstellen wurden mittels OpenAPI/Swagger realisiert und dienen ebenso für die Kommunikation zwischen den Layern als auch für die Kommunikation zu der Bibliothek oder dem User Interface.

Projekt Überblick

Gesamte Commits

Insgesamt getätigte Commits

Letzter Commit

Datum des letztens Commits

Anzahl Branches

Aktuell existierende Branches
200

Offene PullRequests

Aktuell offene PullRequests
0