Data Engineering: der unterschätzte Einstieg ins KI-Team

In Stellenanzeigen für KI-Teams steht meistens das Modell im Mittelpunkt. Im Alltag dieser Teams steht es das nicht. Der größere Teil der Arbeit besteht darin, Daten an die Stelle zu bringen, an der ein Modell sie überhaupt lesen kann - in der richtigen Form, zum richtigen Zeitpunkt, mit einer Herkunft, die sich später nachvollziehen lässt. Diese Arbeit heißt Data Engineering. Für Berufseinsteiger ist sie einer der zugänglichsten Wege in ein KI-Team, und sie wird regelmäßig unterschätzt.

Warum ohne diese Arbeit nichts in Produktion geht

Ein Modell in einem Notebook ist ein Ergebnis. Ein Modell in Produktion ist ein Prozess, der jeden Tag ohne Aufsicht laufen muss. Zwischen beidem liegt fast immer dieselbe Lücke: Die Daten, mit denen trainiert wurde, lagen in einer sauber vorbereiteten Datei. Die Daten, die im Betrieb ankommen, kommen aus fünf Systemen, jedes mit eigener Zeitzone, eigenem Format und eigenen Ausfällen.

Wer diese Lücke schließt, entscheidet darüber, ob ein Projekt existiert oder als Demo endet. Das ist kein Nebenschauplatz. In vielen Häusern ist der Grund, warum ein vielversprechendes Modell nie ausgerollt wurde, nicht die Genauigkeit, sondern die Frage, wer die Eingangsdaten jeden Morgen um sechs bereitstellt und was passiert, wenn eine Quelle ausfällt.

Was ein Data Engineer tatsächlich baut

Die Rolle ist konkreter, als der Titel vermuten lässt. Vier Bereiche machen den Großteil der Arbeit aus.

Pipelines. Der Transport von Daten aus Quellsystemen in eine auswertbare Form. Das umfasst das Anzapfen von Datenbanken, Schnittstellen und Dateiablagen, das Umformen und Zusammenführen der Daten und das Schreiben in ein Ziel. Klingt einfach und ist es an einem guten Tag auch. Der Aufwand entsteht durch die schlechten Tage: Ein Feld ändert seinen Typ, ein Export kommt zwei Stunden zu spät, ein Zeichensatz wechselt.

Speicherschichten. Wo liegen Rohdaten, wo aufbereitete Daten, wo die Tabellen, mit denen Fachbereiche arbeiten? Diese Trennung ist keine Formalie. Sie entscheidet darüber, ob man einen Fehler drei Monate später noch zurückverfolgen kann, ohne alles neu laden zu müssen.

Orchestrierung. Was läuft in welcher Reihenfolge, was hängt wovon ab, was passiert bei einem Fehlschlag? Ein Orchestrierungswerkzeug hält diese Abhängigkeiten fest, startet die Schritte, wiederholt fehlgeschlagene Läufe und meldet, wenn etwas hängen bleibt.

Datenqualität. Prüfungen, die vor der Verarbeitung laufen: Sind Pflichtfelder gefüllt, liegen Werte im erwarteten Bereich, ist die Zahl der Zeilen plausibel? Ein Modell beschwert sich nicht über schlechte Daten. Es liefert einfach schlechtere Vorhersagen, und das fällt oft erst Wochen später auf.

Was ein KI-Team anders braucht als ein Data Warehouse

Data Engineering gibt es seit Jahrzehnten, und viele Grundlagen sind dieselben. Drei Unterschiede sind aber deutlich, und sie erklären, warum ein klassisch geprägter Ansatz in einem KI-Team an Grenzen stößt.

Merkmale statt Kennzahlen. Ein Data Warehouse liefert Kennzahlen für Berichte: Umsatz je Region, Stornoquote je Monat. Ein KI-Team braucht Merkmale je Datensatz, oft feingliedriger und in großer Zahl. Und es braucht sie zweimal in identischer Berechnung - einmal historisch für das Training, einmal live für die Vorhersage. Weichen beide Wege voneinander ab, verhält sich das Modell im Betrieb anders als im Test. Das ist einer der häufigsten und am schwersten zu findenden Fehler überhaupt.

Trainingsdaten sind ein Zustand, kein Bericht. Für einen Bericht zählt der heutige Stand. Für ein Training zählt der Stand von damals: Welche Information war zum Zeitpunkt der Entscheidung tatsächlich verfügbar? Wer versehentlich Wissen aus der Zukunft in die Trainingsdaten lässt, bekommt hervorragende Testergebnisse und ein Modell, das im Einsatz versagt. Data Engineering im KI-Umfeld heißt deshalb, Historie sauber zu halten, statt sie zu überschreiben.

Nachvollziehbarkeit. Wenn eine Vorhersage angezweifelt wird, muss sich beantworten lassen, mit welchen Daten und welcher Modellversion sie zustande kam. In regulierten Branchen ist das eine Auflage, überall sonst schlicht Voraussetzung dafür, Fehler zu finden. Diese Spur zu legen, gehört zur Datenseite, nicht zur Modellseite.

Welche Kenntnisse zählen

Die Liste ist kürzer, als viele erwarten, dafür wird sie ernst genommen.

SQL steht an erster Stelle, und zwar nicht auf dem Niveau einfacher Abfragen. Verbünde über mehrere Tabellen, Gruppierungen, Fensterfunktionen und ein Gefühl dafür, warum eine Abfrage langsam ist, gehören dazu. SQL ist die Sprache, in der über Daten gesprochen wird.

Python als zweites Standbein: Dateien einlesen, Daten umformen, Schnittstellen abfragen, kleine Werkzeuge schreiben. Es geht weniger um ausgefeilte Sprachkonstrukte als um lesbaren Code, der auch in einem halben Jahr noch wartbar ist.

Ein Orchestrierungswerkzeug, an dem du zeigen kannst, dass du das Prinzip verstanden hast - Abhängigkeiten als Graph, geplante Läufe, Wiederholungen, Protokolle. Welches Werkzeug du gelernt hast, ist zweitrangig; die Konzepte sind übertragbar.

Grundverständnis Cloud. Objektspeicher, verwaltete Datenbanken, Rechte und Rollen, ungefähre Kosten. Niemand erwartet von einem Praktikanten eine Zertifizierung. Erwartet wird, dass du weißt, warum man Daten nicht einfach auf den eigenen Rechner kopiert.

Dazu kommt Versionsverwaltung als Selbstverständlichkeit. Welche dieser Bausteine du vor einer Bewerbung wirklich mitbringen solltest, ist im Überblick über die fachlichen Voraussetzungen für KI-Praktika einzeln aufgeschlüsselt.

Warum der Einstieg hier leichter gelingt

Auf eine Praktikumsstelle in der Modellierung bewerben sich sehr viele Studierende mit sehr ähnlichen Unterlagen. Auf eine Stelle im Data Engineering bewerben sich deutlich weniger - obwohl es in den meisten Häusern mehr solcher Stellen gibt als Modellierungsstellen. Das Verhältnis von offenen Stellen zu Bewerbern ist damit ein anderes, und das merkt man im Verfahren.

Dazu kommt, dass sich die Eignung besser zeigen lässt. Ob jemand ein Modell sauber auswählt, sieht man erst nach Wochen. Ob jemand eine Pipeline baut, die zweimal hintereinander dasselbe Ergebnis liefert, sieht man am zweiten Tag. Wer ein kleines, aber vollständiges Datenprojekt vorzeigen kann - Quelle, Transformation, geplanter Lauf, Prüfungen, Dokumentation - ist im Gespräch sofort im Vorteil. Wie ein solches Projekt aufgebaut und beschrieben sein sollte, steht ausführlich im Leitfaden für das Portfolio.

Ein dritter Punkt wird selten ausgesprochen: Die Arbeit ist gut abgrenzbar. Ein Team kann einem Neuen eine Datenquelle geben, ohne dass ein Produktivsystem in Gefahr gerät. Genau deshalb werden hier eher Einsteiger genommen.

Was die Rolle langfristig wert ist

Die verbreitete Sorge, man lande auf einem Nebengleis, geht an der Praxis vorbei. Drei Beobachtungen sprechen dagegen.

Erstens kennst du nach zwei Jahren die Datenlandschaft eines Unternehmens besser als fast jeder andere. Das ist eine Position, aus der heraus man gefragt wird, bevor entschieden wird.

Zweitens sind die Übergänge offen. Von der Datenseite führt ein kurzer Weg in den Betrieb von Modellen, wie ihn die Profilseite zum MLOps Engineer beschreibt, ein ebenso kurzer in die Analyse und ein gangbarer in die Modellierung selbst - die Aufgaben auf der anderen Seite sind im Beitrag über den Alltag eines Data Scientist beschrieben. Umgekehrt ist der Weg schwerer: Wer nie Pipelines gebaut hat, holt das später selten nach.

Drittens ist die Nachfrage stabiler. Werkzeuge zur Modellierung werden laufend einfacher. Der Aufwand, Daten aus gewachsenen Systemen verlässlich zusammenzuführen, sinkt dagegen kaum, weil er von der Organisation herrührt und nicht von der Technik.

Wie sich die Rolle im Alltag anfühlt und welche Aufgaben dazugehören, steht auf der Profilseite zum Data Engineer; die verwandten Rollen im Umfeld findest du gebündelt im Berufsfeld Daten und Analytics. Wenn du eher aus der Auswertung kommst, lohnt vorher der Vergleich mit dem Arbeitsalltag im Data Analytics - die beiden Rollen werden in Anzeigen oft vermischt.

So gehst du es an

Such nicht nach dem Wort "KI" in der Anzeige, sondern nach der Aufgabe. Viele Stellen, die für ein KI-Team ausgeschrieben sind, heißen schlicht Werkstudent Datenmanagement oder Praktikum Data Platform. Ein Blick in die ausgeschriebenen Praktika zeigt schnell, wie unterschiedlich dieselbe Tätigkeit benannt wird. Weitere Wege in ein KI-Team sammelt die Kategorie Einstieg.

Kurz gefasst

Data Engineering ist die Arbeit, die darüber entscheidet, ob ein Modell den Weg in den Betrieb findet. Der Einstieg ist realistischer als über die Modellierung, die Fähigkeiten sind übertragbar, und die Kenntnis der Datenlandschaft ist ein Vorsprung, den man in keiner Vorlesung bekommt.