2012 wurde der Beruf Data Scientist von der Harvard Business Review zum erstrebenswertesten Beruf des 21. Jahrhunderts gekürt. Damals, in den Anfängen der Data Science, war das sicherlich auch richtig. Seither hat sich der Arbeitsmarkt, zumindest was die Tätigkeitsbeschreibung angeht, tatsächlich noch mal verändert.
Zum einen hat das viel mit der Ausdifferenzierung der Data-Science-Profile zu tun. Bis vor einigen Jahren musste jeder Data Scientist viele Bereiche abdecken, die heute als Spezialisierungen abgespalten sind – der Data Engineer ist eine davon. Zum anderen sind mit zunehmendem Reifegrad der Data-Science-Anwendungen auch neue Aufgaben hinzugekommen, die vorher vielleicht eher im Plattform- oder Betriebsteam der IT-Abteilung angesiedelt waren. Eine einzelne Person kann die ganze Breite nicht länger abdecken, jedenfalls nicht in der notwendigen Tiefe, die hochkomplexe Systeme erfordern.
Das bedeutet auch, dass die heutigen Mitarbeitenden im Data Engineering eine breitere Fülle von Aufgaben haben und gleichzeitig viel tiefer in die jeweilige Materie einsteigen können. Beides gleichzeitig geht nicht. Aber auch im Data Engineering haben sich klare Karrierepfade und Unterdisziplinen herausgebildet. Es bieten sich für jedes Interessenprofil Gelegenheiten, sich fachlich weiterzuentwickeln.
Reise Richtung Data Engineering
Im Rahmen der Data Journey, der Herangehensweise bei der Alexander Thamm GmbH [at], für die der Autor arbeitet, schließen sich die Aufgaben des Data Engineering konzeptionell an die Arbeiten der Kolleginnen und Kollegen in der Data Science an. Da stehen dann normalerweise Aufgaben an, die erarbeiteten Konzepte und Prototypen aus dem Data-Science-Labor als Pilot-Implementierung auf eine Plattform zu heben. Oftmals heißt das, die Artefakte aus lokalen Jupyter Notebooks oder JupyterLab-Instanzen neu zu verpacken, zum Beispiel durch Containerisierung, um sie dann auf wesentlich größerer Infrastruktur zum Einsatz zu bringen.
Im Vergleich zum Prototyp, den wir als Basis für die Entwicklung der Pilot-Implementierung benutzen, werden dann normalerweise auch externe Datenquellen direkt angebunden, anstatt beispielhafte Datensätze in Excel-Dateien zu verwenden. Im nächsten Schritt wird darauf wieder konzeptionell gearbeitet. Als Data Engineer muss man in der Lage sein, einen Skalierungsplan für den Hochlauf einer bislang nur begrenzt einsetzbaren Anwendung zu entwickeln.
In solchen Plänen wird dann betrachtet, welche Parameter sich im Produktivbetrieb im Vergleich zum Prototyp oder der Pilot-Implementierung am meisten ändern. Ein großer Faktor sind meist die Volumen der Datenflüsse. Für einen Prototypen kann, je nach Anwendungsfall, eine Datei mit einigen Hundert Millionen Datensätzen schon eine sehr große Basis für die Entwicklung sein. Zu beobachten sind dann oft Szenarien, in denen die externe Datenquelle ein Vielfaches dieser Menge jeden Tag schon im Pilotbetrieb liefert – meist in Kombination mit der Erwartung, dass noch mehrere vergleichbare Datenquellen an das produktive System anzubinden sind, um die notwendige Skalierung zu erzielen, die dann tatsächlich Mehrwert erzeugt. Letztlich ist immer ein Datenprodukt das Ziel. Dazu gehört dann neben einer belastbaren Infrastruktur gleichermaßen auch die technische Überwachung der Prozesse.
Das Monitoring erhebt grundlegende Metriken über das System, die zum Beispiel die Auslastung oder die Art der Nutzung beschreiben. Dazu kommt dann auch immer noch eine Protokollierung aller Vorgänge in einem Logging-System, damit man im Nachhinein auditieren kann, wer das System benutzt hat, wofür es eingesetzt wurde und wie gut die Leistung war. Bei komplexeren Systemen, die aus vielen Einzelkomponenten bestehen, wird dann meist noch eine zusätzliche Tracing-Schicht eingerichtet. Das Funktionsprinzip ist ähnlich wie beim Logging, allerdings werden Systemanfragen vom Frontend Schritt für Schritt durch alle Teile des Systems verfolgt, bis sie vom Backend beantwortet und dann zurück ans Frontend gesendet werden. So dokumentiert man, wie sich jede Einzelkomponente verhält, und kann man gegebenenfalls schlecht dimensionierte Engstellen finden.
Gerade für datengetriebene Anwendungen, wie im Bereich des maschinellen Lernens, ist diese technische Überwachung noch wichtiger als bei traditioneller Software. In klassischen Anwendungen ist in jeder Datenlage klar, was zu tun ist. Im Zweifelsfall kann die Anwendung einen Fehler ausgeben, aber solange die Entwickler keinen Fehler gemacht haben, trifft die Anwendung auch immer die richtigen Entscheidungen. In der Welt der künstlichen Intelligenz ist das anders. Hier sind die Daten immer auch Teil des Algorithmus. Zumindest in dem Sinne, dass KI-Modelle mit Beispieldaten trainiert werden.
Das Verhalten eines Modells wird gewissermaßen für die zu erwartende Realität justiert. Treten dann andere Daten als erwartet auf, stimmen auch die Entscheidungen nicht mehr. Ein Bilderkennungssystem zur Unterscheidung von Hunden und Katzen wird Fotos von Pferden nicht erkennen und fälschlicherweise in eine seiner beiden bekannten Kategorien pressen. Solche Schieflagen automatisiert zu erkennen und im besten Fall sogar automatisiert durch Nachjustierung der Modelle mittels maschinellen Lernens zu beheben, ist eine wichtige Aufgabe beim Betrieb einer Datenplattform.
Fünf Profile zum Data-Engineering– getriebenem Unternehmen
Bei einer solchen Vielfalt an Aufgaben bilden sich früher oder später Spezialisierungen heraus. Bei [at] haben wir etwa fünf dieser Profile entdeckt und fördern diese auch gezielt durch Schulungen und entsprechende Industriezertifizierungen. Zunächst einmal gibt es den Bereich des Cloud und Plattform Engineering. Diese Kolleginnen und Kollegen treffen die Entscheidung, wie genau eine Plattform gebaut werden sollte. Je nach Art der Plattform – Data Warehouse, Data Lake, Big-Data-Analytics-Plattform, MLOps-Plattform – und der zu verwendenden Cloud-Infrastruktur kommen hier sehr unterschiedliche Technologien zum Einsatz. Auch die Entscheidung, ob eine Plattform aus Einzelkomponenten gebaut (ein Stack) oder durch eine Produktfamilie (eine Suite) abgebildet werden sollte, ist zu klären.
Normalerweise befindet man sich mit einer neuen Datenplattform nicht "auf der grünen Wiese" sondern muss sich in eine bestehende Systemlandschaft integrieren. Hier kommt das Profil des Enterprise Architect zum Tragen. Zunächst muss sichergestellt werden, dass die neue Plattform und alle ihre Datenquellen über das Netzwerk erreichbar sind. Zusätzlich müssen diese Zugänge dann abgesichert sein. Dazu gehört die Anbindung an ein Single-Sign-on-System und die Umsetzung eines Rollen- und Rechtekonzepts.
Sobald die Daten verfügbar sind, kann ein Data Engineer mit der Arbeit beginnen. Je nach eingesetzter Technologie wird in einem ETL- (Extract, Transform, Load) oder einem ELT-Rahmen (Extract, Load, Transform) gearbeitet. Es müssen immer Pipelines gebaut werden, welche die Daten in die Plattform laden, sie dort konsolidieren, aggregieren und in einer geeigneten Form wieder zur Verfügung stellen. Das eingesetzte Datenmodell kann hier entscheidend sein. Bei dieser konzeptionellen Vorarbeit müssen Data Engineers entscheiden, ob es zum Beispiel bei einem einfachen Sternschema bleibt oder ob doch ein komplexeres Datenmodell zu verwenden ist, welches sich „Uneingeweihten“ nicht mehr auf einen Blick in Gänze erschließt.
Sobald die Daten dann in geeigneter Menge und Qualität zur Verfügung stehen, können Machine Learning Engineers die Plattform um KI-Anwendungen mithilfe von Funktionen aus dem maschinellen Lernen erweitern. Hier geht es im Gegensatz zur Entwicklung geeigneter Modelle eher darum, ein bereits erarbeitetes Konzept in einer Produktionsumgebung zu skalieren.
Diese Arbeiten werden oft von unseren internen Software Engineers unterstützt. Der Schwerpunkt unserer Arbeit liegt zwar nicht in der Applikationsentwicklung, aber wir bearbeiten viele Fragestellungen rund um Daten, die sich nur durch spezialisierte Software beantworten lassen. Auch sind oft neue Programmschnittstellen zu bauen, damit sich die Daten aus der Plattform direkt in anderen Systemen verwenden lassen. Letzten Endes wollen wir mit unseren Daten immer Geschichten erzählen. Ein echter Mehrwert wird nur dann generiert, wenn auf Basis der Analysen Entscheidungen getroffen werden können. Dabei sind unsere Data Visualisation Engineers im Fokus. Diese Spezialistinnen und Spezialisten erstellen grafische Oberflächen, ob als Dashboard oder als Weboberfläche, um die Daten möglichst eindeutig und eingängig zu präsentieren. Es wird Wert daraufgelegt, Missverständnisse möglichst zu vermeiden.
Fazit
Anhand dieser einfachen Beispiele wird deutlich, wie sich neben dem klassischen Software Engineer eine Reihe von spezialisierten Rollen entwickelt hat, welche Unternehmen auf ihrem Weg in die Digitalisierung unterstützen. Während gerade kleinere Unternehmen, welche sich vielleicht noch ganz am Anfang ihrer Reise befinden, weiterhin auf "Allrounder" setzen, von denen Kompetenz in allen Bereichen erwartet wird, haben viele Firmen mit einem höheren Reifegrad bereits verstanden, dass jede der hier vorgestellten Rollen ihre eigene Nische ausfüllt und in komplexeren Umgebungen nicht mehr durch andere Rollen ersetzt werden kann.
