Wir stellen uns vor: Es wird ein System entwickelt, das für bestimmte, lokal definierte Anforderungen ausgelegt ist. Das System etabliert sich und läuft stabil und zuverlässig. Dann soll die lokale Beschränkung des Systems aufgehoben werden – es soll international verfügbar sein.
An dieser Stelle beginnen die Herausforderungen. Denn die international zugrundeliegenden Daten und -strukturen passen nicht mehr in ein lokal definiertes Schema – Einheiten, Adressumfänge und weitere Datenformate sind schließlich je nach Land unterschiedlich. Gemeinhin wird dann das System selbst für unterschiedliche Zielmärkte geklont, angepasst und unabhängig von dem Ursprungssystem weiterentwickelt.
Diese Trennung der Einzelsysteme, wodurch auch die Daten wiederum durch dicke Silowände voneinander abgetrennt sind, führt zu weiteren Herausforderungen. Jedes Einzelsystem muss in der Lage sein, die Diversität der globalen Marktanforderungen individuell umzusetzen. Globale Analysen in Echtzeit sind hierbei nur durch enorme Aufwände realisierbar.
Unser zweites TechSnack Online-Meetup widmete sich deshalb der Fragestellung: Wie könnte eine Softwarearchitektur aussehen, die solch eine Diversität und die daraus resultierenden Einzelsysteme vereinheitlicht sowie granulare Anpassungen bezogen auf lokale und auch globale Anforderungen zulässt?
Zu diesem Thema hatte unser Experte Hendrik Höing seine Masterarbeit erstellte und präsentierte die Ergebnisse zusammen mit seinem Betreuer Holger Tiemeyer im Livestream, moderiert von unserer Kollegin Jana Ullmann.
Wie kann also ein moderner Ansatz für eine einheitliche Softwarearchitektur die Praxisherausforderung des Datenmanagements in lokalen, globalen sowie komplexen Organisationen lösen und dabei die Aufwände einer Änderung minimieren? Lesen Sie hier mehr darüber:
Anstelle einer klassischen Herangehensweise, ein Schema für die Daten zu definieren und darum herum das System auszugestalten, haben wir Datenströme in den Fokus der Betrachtung gestellt. Eine Kernherausforderung besteht in vielen Fällen darin, einem definierten Schema gerecht zu werden; sich also auch bei Datenströmen Gedanken darüber zu machen, in welchem Format oder welcher Ausprägung Daten gestreamed werden sollen. Hierin sehen wir auch die resultierenden Aufwände von Anpassungen im oben beschriebenen Szenario des Ausrollens des Systems im internationalen Kontext.
Eine Verlagerung der Aufbereitung der Daten zum Zeitpunkt des Abrufens scheint daher eine gute Möglichkeit zu sein, um Transformationen oder Schema-Anpassungen zu umgehen oder zu vermeiden.
Hierdurch rückt ein Ziel in den Fokus, das von klassischen Ansätzen des Datenmanagements abweicht. Dies zieht neue Anforderungen an die Softwarearchitektur nach sich.
Für eine datengetriebene Softwarearchitektur braucht es also zunächst einen unvoreingenommenen Blick. Technisch gesehen muss sie zudem folgenden Anforderungen erfüllen:
- Hohe Flexibilität und Anpassbarkeit
- Datenverarbeitung in Echtzeit
- Globaler Datenzugriff bei gleichzeitiger Lokalisierbarkeit
- Generische und skalierbare Architektureigenschaften
- Hohe Performanz bzw. geringe Latenzzeiten
Um diese Anforderungen umzusetzen, bedarf es einer frischen Herangehensweise bei der Planung: Die initiale Idee rund um Streaming-Daten bestand darin, diese im Rohformat – sozusagen schemalos – zu versenden und für Analysezwecke eben auch im Rohformat aufzubewahren. Erst zum Zeitpunkt der Datenabfrage werden diese für ein entsprechendes Zielsystem aufbereitet.
In Kombination mit verschiedenen, aktuellen Technologien hat Hendrik Höing einen Use Case für die Automobilbranche entworfen, der sich auch generisch auf andere Industriezweige übertragen lässt.
Das Anwendungsbeispiel verfolgt die Zielsetzung, Sensordaten verschiedener Pkw in einen Data Lake zu streamen, der in der Lage ist, unstrukturierte, semi-strukturierte oder auch strukturierte Daten zu verwalten. In solch einem Data Lake lassen sich bezogen auf verschiedene Anwendungsfälle aus der Automobilbranche analysieren, zum Beispiel Wartungszustände und weitere Informationen über das Automobil.
Auch in entgegengesetzter Richtung ist ein Datenfluss beabsichtigt: In Echtzeit – auf Basis von Analysen – erzeugte Informationen und Warnungen sollen vom System aus an die Pkw zurückgesendet werden.
Als Streamingtechnologie kommt für diese Anwendungsfälle Apache Kafka zum Einsatz. Die Streaming-Plattform unterstützt die oben genannte Anforderungen, sodass sich diese umgehend umsetzen lassen.
Abbildung 1: Datenstreaming mit Apache Kafka (Grafik: Hendrik Höing)
In Abbildung 1 werden aus den Pkw heraus Daten über Apache Kafka gestreamed, um sie zu analysieren beziehungsweise zu filtern. Anschließend streamed die Plattform entweder wieder Daten zurück in das Auto – zum Beispiel Wartungshinweise oder Warnmeldungen – oder leitet sie in einen Data Lake weiter. Dieser nimmt die Daten zunächst in ihrem Rohformat auf. Sie können dort bereinigt, gefiltert, aggregiert, analysiert und persistiert werden. Optional lassen sie sich zudem in ein traditionelles Data Warehouse weiterleiten, um sie dort zu speichern oder weiter zu verarbeiten.
Eine Herausforderung ist der Metadatenkatalog, über den die in einem Data Lake enthaltenen Daten auffindbar sind. In Kombination mit einem Suchindex wie zum Beispiel Elasticsearch, der die Daten des Metadatenkataloges indiziert, können die Daten selbst in effizienter Weise mit vielen Möglichkeiten gefunden werden.
Auf einem nachgelagerten Dashboard können aus dem Data Lake heraus die Daten angezeigt werden. Da Dashboards in ihren regionalen Ausprägungen die Daten in bestimmten Formaten benötigen und darstellen, ist die Schnittstelle zur Datenabfrage mit GraphQL entwickelt. Diese ermöglich es, über eine Query-Language exakt diejenigen Daten aus dem Suchindex zu erfragen, die in einem bestimmten Anwendungsfall oder einer lokalen Ausprägung benötigt werden.
Zur Abfrage globaler Analyseergebnisse wird eine oben beschriebene, lokale Ausprägung als sogenanntes „Datenprodukt“ in die Systemlandschaft integriert. Der Begriff eines Datenproduktes entstammt der Data Mesh-Bewegung und impliziert eine schichtenübergreifende Sichtweise auf Daten. In unserem Beispiel besitzen die Datenprodukte definierte Schnittstellen und Endpunkte. Zum einen sind es Streaming-Schnittstellen, über die regionale Daten in weitere, globale Analyse- und Filtereinheiten geleitet werden können.
Zum anderen können über die regional verfügbaren GraphQL-Endpunkte Einzeldaten aus den jeweiligen Regionsausprägungen erfragt werden.
Somit setzt sich die Gesamtarchitektur aus regionalen Datenanalysen zusammen, die nach globalen Standards gefiltert werden können.
Abbildung 2: Globale Zielarchitektur für den vorgestellten Use Case (Grafik: Hendrik Höing)
Abbildung 2 zeigt zwei Datenprodukte mit ihren Schnittstellen sowie erweiterte Möglichkeiten einer globalen, einheitlichen Analyse.
Der Technologie-Stack dieser datenzentrierten Softwarearchitektur ist bereits hinreichend etabliert und erprobt, sodass sie sich in einem professionellen Umfang bereits heute einsetzen lässt.
Auch die Anbindung von Legacy-Systemen an die dargestellte Streaming-Plattform mit den Data Lakes ist möglich, da auch vorstrukturierte oder strukturierte Daten in solch einem Data Lake aufgenommen werden können.
Sie wollen noch tiefer in das Thema datenzentrierte Softwarearchitekturen einsteigen? Dann sehen Sie sich die Präsentation in gesamter Länge auf unserem YouTube-Kanal an. Auch die Ausgabe 01-2021 zum Thema DevOps finden Sie dort zum Nachsehen.
Nehmen Sie auch an dem nächsten spannenden Vortrag im Rahmen unseres TechSnack Online-Meetups teil: Merken Sie sich den Termin am 29. September ab 17:30 Uhr schon einmal vor.
Last but not least freuen wir uns sehr, dass Hendriks Abschlussarbeit mit der Bestnote bewertet wurde und er ab August als Consultant bei AUSY Technologies in Stuttgart startet. Herzlichen Glückwunsch!