Eine neue Umsatzfrage, eine alte Pipeline und ein riskanter Umbau: Ananth Packkildurai beschreibt in seinem Essay „The Self-Organizing Data Stack“, warum Data Engineers häufig lieber SQL kopieren, als bestehende Abhängigkeiten anzufassen. Seine Beispiele sind ein Architekturentwurf, kein Bericht über ein bereits eingesetztes autonomes System. Die zentrale Frage lautet, wie eine Engine den Datenbestand umbauen könnte, während Menschen weiterhin die fachlichen Definitionen bestimmen.
An dieser Stelle setzt der Essay „The Self-Organizing Data Stack“ an. Er sortiert die Arbeitsteilung im Data Engineering neu. Seine Beobachtung: Wer eine neue Frage hat, baut lieber neu, als Bestehendes anzufassen. Über Hunderte von Engineers und einige Jahre ergibt diese Überlebensstrategie einen Zustand, den Packkildurai hochentropischen Wildwuchs nennt. Ein Dutzend Versionen von customer_spend, tausende Modelle, die keiner mehr anfassen will, Petabytes an Zombie-Tabellen, die niemand löscht.
Warum aus einer Kopie ein Datenfriedhof wird
Der Essay beschreibt zwei Jobs, die heute auf denselben Schultern liegen. Der erste ist Datenmodellierung: entscheiden, welche Tabellen es geben soll, welches Korn sie haben, welche Definitionen gelten. Der zweite ist Handarbeit an der Orchestrierungsengine: Zeitpläne, Abhängigkeiten, Retries, Backfills. Zusammen ist das mehr, als eine Person sauber tragen kann. Bei jeder neuen Anforderung wird beides erneut fällig.
KI hat diesen Zustand nicht entschärft, sondern beschleunigt. Coding-Agenten erzeugen eine neue Pipeline in Minuten. Den Umbau einer bestehenden haben sie nicht billiger gemacht. Packkildurai nennt das asymmetrisches Risiko: Die Kosten der Erzeugung fallen gegen null, die Kosten der Reparatur bleiben hoch. Jeder Agent, der lokal für einen einzelnen Prompt optimiert, vergrößert das globale Chaos. Aus vielen kleinen, für sich plausiblen Entscheidungen wird ein Data-Warehouse-Sprawl, den niemand mehr überblickt.
Der Essay benennt die Ursache nüchtern. Man hat den Wildwuchs toleriert, weil Datenmodellierung eine menschliche Tätigkeit für menschliche Konsumenten war. Stern-Schemata und konforme Dimensionen existieren nicht, weil die Datenbank sie braucht, sondern weil ein Analyst sich im Warehouse zurechtfinden muss. Lesbarkeit war der Zweck des Modells. Wenn ein KI-Agent die Daten konsumiert und eine Antwort produziert, muss das physische Modell nicht mehr wie eine Museumsvitrine aussehen.
Was ein Datenprodukt von einem Glühwürmchen unterscheidet
Für die Analogie hilft ein Blick in die Physik. In „Sync“ fragt Steven Strogatz, wie Ordnung ohne Dirigenten entsteht: wie tausende Glühwürmchen an einem Flussufer nahezu gleichzeitig blinken, wie einzelne Herzzellen sich zu einem ruhigen Rhythmus synchronisieren. Das Muster ist nicht von außen verordnet. Es entsteht aus lokalen Regeln und ständiger Rückkopplung. Einzelne Teile sind fragil, das Ganze bleibt organisiert.
Für Data Engineering heißt das: Wenn der menschliche Choreograf wegfällt, muss sich ändern, was ein Datenasset ist. In einem selbstorganisierenden Data Stack ist ein Asset keine physische Tabelle im Storage, sondern ein logisches Datenprodukt mit stabiler Identität. Es erklärt seine Bedeutung, sein Korn und seine Zusagen gegenüber jedem Konsumenten stromabwärts. Es startet keine eigenen Hintergrundprozesse und trifft keine eigenen Entscheidungen. Es deklariert seine Grenzen.
Der architektonische Schnitt liegt hier. Die Identität bleibt beim Asset, die physische Umsetzung gehört der Engine. Der Datenvertrag hängt am Asset. Die Maschinerie dahinter darf sich ändern, ohne dass ein Konsument seine Integration neu schreibt. Erst diese Trennung erlaubt es, ein Warehouse kontinuierlich umzuverdrahten, statt es alle paar Jahre von Hand neu zu bauen. Datenverträge können den Sprawl so nicht nur dokumentieren, sondern reduzieren.
Fünf Regelkreise für den Graphen
Die Orchestrierungsengine führt in diesem Entwurf den Abhängigkeitsgraphen. Packkildurai beschreibt fünf Regelkreise. Synthesize baut die physischen Tabellen und Transformationen, die eine neue Anfrage braucht. Consolidate erkennt überlappende Spezifikationen und schlägt Teilen, Aufteilen oder Zusammenführen vor. Verify and Repair prüft jede Graphänderung gegen die Verträge stromabwärts, bevor sie ausgerollt wird. Coordinate aktiviert versionierte Änderungen atomar, damit keine aktive Zusage bricht. Escalate legt einem menschlichen Owner eine konkrete Frage mit Belegen und Abwägungen vor, wenn semantische Mehrdeutigkeit den Fortschritt blockiert.
Der Prüfkreis soll in diesem Entwurf die Korrektheit der Umbauten absichern. Der Essay führt ein Beispiel an, das viele Wochenenden ruiniert hat: historische Identitätsaufspaltung. Die Kundenidentität führt Kontozusammenlegungen mit, und die freigegebene Attributionsregel verwendet die Zuordnung, die beim Kauf galt. Wer nur über account_id joint, zählt bei jedem Konto mit zwei historischen Zuordnungen jeden Einkauf doppelt. Schema-Check, Null-Check und Eindeutigkeit nach Aggregation laufen trotzdem grün durch. Jede klassische Qualitätsanzeige steht auf Grün und lügt.
Ein selbstorganisierender Stack prüft deshalb gegen semantische Invarianten, nicht nur gegen Syntax. Ein Abgleich mit der freigegebenen Einkaufsdefinition legt den doppelt gezählten Umsatz offen und führt zurück auf die vorgeschlagene Tagesabhängigkeit. Die Engine korrigiert den Join auf Gültigkeitsintervalle, lässt die Prüfung erneut laufen und vergleicht alte und neue Implementierung auf identischen Snapshots. Ein Sprachmodell, das Berechnung und Test selbst schreibt, kann die eigenen Annahmen nicht zertifizieren. Die Freigabe bleibt deterministischen Prüfern vorbehalten.
Eine Anfrage ohne Tabellen, Joins und Cronjobs
Im zweiten Teil beschreibt Packkildurai den Alltag dieses Entwurfs. Eine Vertriebsanwendung braucht den Kundenumsatz der letzten 30 Tage. Ob ein Mensch die Anfrage tippt oder ein Agent sie über eine Schnittstelle schickt, spielt keine Rolle. Die Anfrage nennt nur Ergebnis und Zusage. Eine Zeile pro Kunde, Umsatz über die letzten 30 vollständigen Kalendertage in UTC, freigegebene Definitionen für Einkaufsbetrag und Kundenidentität, Kunden ohne qualifizierende Käufe eingeschlossen, neue Quelldaten sichtbar innerhalb von fünf Minuten. Keine Tabelle, kein Join-Schlüssel, kein Zeitplan.
Damit die Engine diese Absicht interpretieren kann, ohne zu raten, braucht sie eine semantische Schicht: autoritative Quellen, Entitätsschlüssel, Einheiten, freigegebene Berechnungen und zeitliche Regeln. Packkildurai nennt sie die tragende Wand des Designs. Das System darf aus einem plausiblen Spaltennamen keine Geschäftsdefinition machen. Fehlt Bedeutung, wird eine offene Frage eskaliert, statt in SQL zu raten. Aus der semantischen Schicht kompiliert der Planer eine formale Spezifikation und leitet die Tests gleich mit ab: eine Zeile pro Kunde erzwingt Eindeutigkeit, der Einschluss von Kunden ohne Umsatz verlangt einen äußeren Join gegen das Kundenregister, der freigegebene Einkaufsbetrag liefert Abgleichsregeln gegen das Rohjournal.
Ein Monat später fragt ein Support-Team denselben Wert über 90 volle UTC-Tage. Heute legt ein Coding-Copilot eine zweite Pipeline über dieselben Rohkäufe. Im selbstorganisierenden Stack schaut der Planer an den physischen Tabellen vorbei auf die Spezifikationen darunter. Er erkennt dieselbe DNA: gleiche Umsatzdefinition, gleiche Identitätsregeln und gleiche Tagesgrenzen in UTC. Ohne dass jemand eine Tastatur berührt, entsteht ein gemeinsames Tagesaggregat mit 90 Tagen Historie. Die Quellhistorie wird geprüft, Zugriffsrichtlinien werden kontrolliert, das Rollup wird nachgeladen, das 90-Tage-Asset darauf gebaut und das bestehende 30-Tage-Asset still auf die neue Zwischenstufe umgehängt.
Konsolidierung ist eine Kostenfrage
Der Essay bleibt an dieser Stelle uneitel. Konsolidierung ist kein blindes Gebot. Eine andere Währungspolitik, eine andere Kundendefinition, ein anderer Zugriffsumfang oder ein abweichender Finanzkalender verlangen eine eigene Umsetzung. Ähnliche Spaltennamen und passende Beispielzeilen beweisen keine Gleichwertigkeit. Das können nur formale Definitionen. Wer aus Namensgleichheit auf Identität schließt, baut den nächsten stillen Fehler.
Auch gültige gemeinsame Nutzung hat ihren Preis. Eine geteilte Abhängigkeit vergrößert den Wirkungsradius eines Ausfalls. Ein schweres Zwischenaggregat alle fünf Minuten zu aktualisieren, um einen einzigen Echtzeit-Konsumenten zu bedienen, kann teurer sein als zwei getrennte Pipelines. Deshalb verhält sich der Planer wie ein gedämpftes Regelungssystem. Er misst Rechenkosten, verlangt eine Mindestersparnis, bevor er umbaut, und begrenzt, wie oft ein Asset refaktoriert werden darf. Findet er echte Duplikate, führt er ihre physische Umsetzung hinter beiden bestehenden Schnittstellen zusammen, bis die abhängigen Systeme migriert sind.
Das verschiebt, was Plattformteams feiern. Nicht Tabellenzahlen, nicht Pipeline-Durchsatz, sondern erfüllte Konsumentenverträge zu optimalen Kosten. Manchmal ist die beste Antwort auf eine neue Anfrage: gar nichts bauen.
Was das konkret bedeutet
Teile dieser Vision existieren bereits, nur nicht in Kombination. Kubernetes hat den Abgleich zwischen Soll- und Ist-Zustand populär gemacht. Asset-orientierte Orchestrierer haben den Blick von Aufgabenplänen auf Datenassets verschoben. Dynamische Tabellen und materialisierte Views automatisieren inkrementelle Aktualisierungen. Was diesen Werkzeugen fehlt, ist die Autorschaft des Graphen selbst: Sie bleibt beim Menschen. Der selbstorganisierende Stack verschiebt diese Aufgabe in die Laufzeit.
Damit das sicher funktioniert, hält die Engine zwei versionierte Ansichten auseinander: den gewünschten Zustand, also Ergebnisse und SLAs, auf die Konsumenten sich verpflichtet haben, und den beobachteten Zustand, also Implementierungen, Lineage, Wasserstände und Gesundheit. Öffnet eine neue Anfrage, eine fehlgeschlagene Prüfung oder eine abgelaufene Zusage eine Lücke zwischen beiden, schlägt die Engine eine Änderung am Graphen vor. Ein Sprachmodell darf beim Parsen der Absicht helfen und SQL-Entwürfe liefern. Seine Zuversicht autorisiert nichts. Entwürfe laufen durch deterministische Planer, Typprüfungen, Zugriffsschranken, Kostenkontrollen und unabhängige Verifikation.
Die Zeitplanung ergibt sich aus den Entscheidungen selbst: Tagesaggregate laufen, wenn Quellwasserstände vorrücken; Fenster-Views rollen um Mitternacht UTC weiter. Das dreht den klassischen Pipeline-DAG um. Er ist nicht länger die dauerhafte Quelle der Wahrheit, sondern ein Wegwerfartefakt für eine einzelne Änderung. Was bleibt, sind Assets, Zusagen und Entscheidungen. Autonomie ohne Verifikation wäre nur automatisierter Wildwuchs mit besserem Marketing.
Das ist weniger ein Produktversprechen als eine Verschiebung der Zuständigkeit. Menschen behalten die Bedeutung: Definitionen, Richtlinien, Urteile, die das System respektieren muss. Die Maschine übernimmt das Verdrahten. Für Data Engineering heißt das: Es zählt nicht, wie schnell jemand eine neue Tabelle baut, sondern wie sauber eine Engine dynamische Datenabhängigkeiten auflösen kann, ohne bestehende Datenverträge zu brechen. Wer heute ein Warehouse voller Kopien verwaltet, muss morgen nicht alles umbauen. Es hilft aber, die eigenen Assets als logische Datenprodukte mit stabiler Identität zu denken. Das funktioniert auch ohne KI-Agenten.
Quelle: dataengineeringweekly.com
