- Da AI das Schreiben von Code und die Erstellung von Pipelines automatisiert, verlagert sich der Kern des Data Engineering von der bloßen Datenbewegung hin zum Umgang mit Bedeutung (meaning)
- Die bestehende ETL(Extract, Transform, Load)-Struktur kann die Bedeutung von Daten nicht bewahren; als neues Framework zu ihrem Ersatz gewinnt ECL(Extract, Contextualize, Link) an Bedeutung
- ECL strukturiert nach der Datenextraktion Bedeutung durch Kontextualisierung (Contextualize) und Verknüpfung (Link) und baut eine bedeutungszentrierte Pipeline auf, in der AI und menschliches Urteilsvermögen zusammenwirken
- Data Contract, Contextualize-Pipeline und Context Store sind die zentralen Bausteine, um Zuverlässigkeit und semantische Konsistenz der Daten zu erhalten
- Künftig müssen sich Data Engineers von reinen Pipeline-Bauern zu „Context Architects“, also Architekten der Datenbedeutung, weiterentwickeln
Grenzen des ETL-Zeitalters und der Wandel
- ETL(Extract, Transform, Load) war eine Struktur für die Datenbewegung zwischen Systemen in der Vergangenheit und diente dazu, Formatinkonsistenzen und Siloprobleme zu lösen
- Die Transform-Phase hatte jedoch den Nachteil, dass Business-Regeln im Code verborgen waren und schwer zu verwalten blieben; bei Definitionsänderungen musste die gesamte Pipeline angepasst werden
- Da AI die Codegenerierung automatisiert, sind einfache Transformationsaufgaben kein Differenzierungsmerkmal mehr
- Das Wesen des Data Engineering wird neu definiert: nicht Daten bewegen, sondern mit Bedeutung arbeiten
ECL — Extract, Contextualize, Link
- Extract bleibt weiterhin erforderlich und verlangt architektonische Entscheidungen zu Datenzuverlässigkeit, Latenz, Volumen und Ausfallmodi
- Contextualize ist der Prozess, Daten Bedeutung zu verleihen; AI übernimmt Felddefinitionen, Entitätsklassifizierung und Beziehungsinferenz, der Mensch validiert dies
- Beispiel: Die Definition von „revenue“ unterscheidet sich je nach Abteilung, oder die Bedeutung von null-Werten variiert je nach System
- Link verbindet Entitäten aus unterschiedlichen Systemen und macht Bedeutung transportierbar
- Durch die Verknüpfung von Kundendatensätzen, Nutzerdaten und Event-Logs wird kontextuelle Konsistenz sichergestellt
Early Binding — ausführbare Datenverträge
- Early Binding bedeutet, Bedeutung bereits zum Zeitpunkt der Datenerzeugung explizit festzulegen, umgesetzt über Data Contracts
- Ein Vertrag definiert Schema, Qualitätserwartungen, Eigentümerschaft und die Bedeutung einzelner Felder
- Er darf nicht nur Dokumentation sein, sondern muss als ausführbare Einschränkung (Executable Constraint) mit definierten Fehlerzeitpunkten funktionieren
- Dazu gehören automatisierte Prüfungen wie Pipeline-Fehler bei Schemaänderungen oder Benachrichtigungen bei Qualitätsverstößen
- In AI-Umgebungen wird Vertragsmehrdeutigkeit zu großflächigen Fehlern verstärkt, daher sind klare Verträge unverzichtbar
Grenzen von Early Binding
- In der Medallion-Architektur (Bronze–Silver–Gold) geht beim Weiterreichen der Daten schrittweise Bedeutung verloren
- Die Gold-Schicht ist ein auf bestimmte Fragestellungen optimiertes Ergebnis und kann die ursprüngliche Bedeutung verfälschen
- Early Binding allein kann die schrittweise Erosion von Bedeutung nicht verhindern
- Als Ergänzung wird daher eine Contextualize-Pipeline benötigt
Late Binding — agentenbasierte Contextualize-Pipeline
- Late Binding verschiebt die Anwendung von Business-Regeln auf den Zeitpunkt der Abfrage, erforderte aber bislang dennoch vorab definierte Begriffsbestimmungen
- Der neue Ansatz lässt die Definitionen selbst durch eine dedizierte Pipeline dynamisch erzeugen und validieren
- Ereignisbasierte Trigger sorgen für automatische Ausführung bei neuen Datensätzen oder Schemaänderungen
- AI-Agenten analysieren Datenstruktur, Samples, Statistiken und Lineage, um Bedeutung zu erschließen
- LLM-as-Judge genehmigt hochzuverlässige Schlussfolgerungen automatisch, unsichere Punkte werden von Domänenexperten geprüft
- Validierte Ergebnisse werden im Context Store gespeichert und dienen anschließend als bedeutungsbasierter Referenzpunkt für sämtliche AI- und Query-Prozesse
Kriterien für die Wahl zwischen Early und Late Binding
- Daten, die innerhalb der Organisation kontrollierbar sind, eignen sich für Early Binding
- Vertragsverhandlungen und Durchsetzung sind möglich, explizite Bedeutungsdefinitionen bleiben erhalten
- Für externe Daten oder nicht kontrollierbare Quellen ist Late Binding über eine Contextualize-Pipeline erforderlich
- Schemaänderungen und Bedeutungsinferenz müssen automatisiert werden
- Das entscheidende Kriterium ist nicht die organisatorische Position, sondern das Vorhandensein von Verantwortlichkeit (accountability)
- Gibt es Verantwortlichkeit, passt Early Binding; fehlt sie, ist Contextualize angemessen
- Durch wiederholte Validierung kann entdeckte Bedeutung zu einem formalen Vertrag erhoben werden
Context Propagation — eine Relay-Struktur statt einer Pipeline
- Bedeutung (Context) bewegt sich nicht entlang der Datenpipeline selbst, sondern wird parallel über Metadaten und Lineage weitergegeben
- Early Binding versieht die Quelle mit Vertragsmetadaten, und Lineage-Tools übertragen sie durch die Bronze–Silver–Gold-Stufen
- Die Contextualize-Pipeline liest diese Lineage, leitet daraus Bedeutung ab und speichert validierte Ergebnisse im Context Store
- Git-Analogie: Daten sind die committeten Dateien, Lineage ist das
git log, der Context Store ist die Versionshistorie der Bedeutung
Context Store — eine neue Engineering-Oberfläche
- Der Context Store ist ein Speicher für Business-Definitionen und liegt nicht als Wiki-Dokument, sondern in Form validierter Version-Artefakte vor
- Konflikte bei der Definition von „revenue“ werden über einen vertrauensbasierten Prozess gelöst
- Er ist ein zentraler Punkt der Datenzuverlässigkeit, an dem sich semantisch verfälschte Daten erkennen und korrigieren lassen
- Um die Zuverlässigkeit von durch AI erzeugten und konsumierten Daten sicherzustellen, sind Verwaltung des Context Store und das Design von Validierungs-Workflows entscheidend
- Eigentümerschaft innerhalb der Organisation, Konfliktabstimmung und Verfahren zur Bedeutungsbeförderung befinden sich noch in der Experimentierphase
Der neue Data Engineer — Context Architect
- Der Data Engineer der Zukunft übernimmt die Gestaltung der Architektur von Bedeutung
- Entwurf von Verträgen, Aufbau von Lineage-Infrastruktur sowie Verwaltung von Contextualize-Pipelines und Context Store
- Entscheidung darüber, wann Bedeutung explizit definiert und wann sie entdeckt werden soll
- Über die technische Rolle hinaus agiert er als Koordinator, der organisationsübergreifendes Bedeutungsverständnis und Verantwortungsstrukturen gestaltet
- Daher ist die Bezeichnung „Context Architect“ passender als „Data Engineer“
Offene Frontier
- ECL ist keine abgeschlossene Methodik, sondern eine Richtung, und die zugehörigen Tools sowie Governance-Modelle entwickeln sich noch
- Organisationen, die Verträge als ausführbare Infrastruktur behandeln und Lineage sowie Context Store als zentrale Engineering-Assets verwalten, dürften in den kommenden zehn Jahren den Standard des Data Engineering definieren
- Auch im AI-Zeitalter bleiben „Architektur und Trade-offs“ der Bereich, den Menschen verantworten müssen;
seine konkrete Form zeichnet sich nun in ECL und dem Context Architect ab
1 Kommentare
Es scheint, als beschleunige sich der Wandel von einer Rolle, die der eines klassischen Technikers ähnelte, hin zu einem Domänenexperten noch weiter.