Databricks-Pipelines: Warum KI-Agenten deklarativ arbeiten sollten

KI-Agenten können Databricks-Pipelines erstellen. Ob daraus wartbare und wirtschaftliche Datenverarbeitung entsteht, entscheidet aber nicht allein das verwendete Sprachmodell. Ebenso wichtig ist das Programmiermodell: Schreibt der Agent einzelne Verarbeitungsschritte samt Ablaufsteuerung, oder beschreibt er die gewünschten Datensätze und überlässt die Ausführung der Plattform? Databricks hat beide Ansätze verglichen. Für Unternehmen mit Azure Databricks liefert der Test konkrete Anhaltspunkte, wie sich KI-Unterstützung im Data Engineering kontrolliert einsetzen lässt.

Kurz gesagt: Databricks hat 528 agentengenerierte Pipeline-Implementierungen untersucht und dabei prozedurales PySpark mit Spark Declarative Pipelines verglichen. Der deklarative Ansatz benötigte im Test deutlich weniger Ausführungsressourcen und im Median rund halb so viele Codezeilen, weil strukturelle Fehler früher erkannt und technische Routineaufgaben an Spark abgegeben wurden. Fachlich falsche Ergebnisse verhindert dieser Ansatz allerdings nicht.

Was ist neu an der Untersuchung zu Databricks-Pipelines?

Neu ist der direkte Vergleich beider Programmiermodelle unter denselben Aufgabenbedingungen mit demselben KI-Agenten. Databricks untersuchte 22 Data-Engineering-Aufgaben mit jeweils zwölf unterschiedlichen Eingangsdatensätzen. Daraus entstanden 264 Implementierungen je Ansatz, insgesamt also 528.

Die Aufgaben enthielten Anforderungen an Tabellen, Spalten und Datentypen. Die Eingabedaten umfassten auch problematische Werte, wie sie in betrieblichen Datenbeständen vorkommen. Ein automatisiertes Prüfverfahren bewertete die Ergebnisse, ohne den jeweiligen Implementierungsansatz zu kennen. Nach Fehlern durfte der Agent innerhalb eines festgelegten Limits nachbessern.

Damit geht es nicht um die Ankündigung einer vollständig autonomen Datenfabrik. Der relevante Befund lautet vielmehr: Die Architektur beeinflusst, wie aufwendig Fehler eines KI-Agenten werden. Das ist für deine Entscheidung über Entwicklungsstandards mindestens so wichtig wie die Auswahl des Modells.

Warum lassen sich deklarative Pipelines früher prüfen?

Deklarative Pipelines lassen sich früher prüfen, weil sie Datensätze und deren Abhängigkeiten beschreiben, bevor die eigentliche Datenverarbeitung startet. Spark kann diese Beschreibung auf bestimmte strukturelle Fehler untersuchen.

Bei prozeduralem PySpark legt der Code fest, welche Daten gelesen, transformiert und gespeichert werden und in welcher Reihenfolge dies geschieht. Der Agent muss neben der fachlichen Transformation also auch unterstützende Ablauflogik erzeugen.

Mit Spark Declarative Pipelines, kurz SDP, definiert er dagegen die gewünschten Datensätze und die Abfragen, aus denen sie entstehen. Spark übernimmt die Ausführungsreihenfolge und das Speichern der Ergebnisse.

Was ein Dry Run erkennt – und was nicht

Ein Dry Run prüft die Pipeline-Struktur, ohne die vollständige Verarbeitung auszuführen. Dabei lassen sich beispielsweise folgende Probleme erkennen:

• Eine Transformation verweist auf eine Spalte, die im betreffenden Schema nicht existiert.
• Eine benötigte Tabellenabhängigkeit lässt sich nicht auflösen.
• Die deklarierten Abhängigkeiten oder Konfigurationen sind unzulässig.

Das ist besonders bei mehrstufigen Pipelines hilfreich: Eine falsch benannte Spalte in einem späteren Verarbeitungsschritt muss nicht erst nach vorangegangenen Verarbeitungsschritten auffallen.

Die Grenze bleibt jedoch klar. Wenn ein Agent Netto- und Bruttoumsatz verwechselt, können sämtliche Spaltennamen und Datentypen korrekt sein. Die Pipeline ist dann strukturell gültig, liefert aber eine falsche Kennzahl. Dafür brauchst du fachliche Tests und menschliche Prüfung.

Welche Ergebnisse sind für deine Kostenplanung relevant?

Für deine Kostenplanung sind vor allem die gemessene Ausführungszeit, der Codeumfang und der zusätzliche Tokenbedarf relevant, nicht eine pauschale Einsparungsquote. Die Databricks-Untersuchung zeigt deutliche Unterschiede, liefert aber keine allgemeingültige Kalkulation für deinen Betrieb.

Die wichtigsten Ergebnisse:

• Aufgabenabschluss: Prozedural wurden 255 von 264 Implementierungen abgeschlossen, deklarativ 258 von 264. Beide Ansätze waren damit grundsätzlich leistungsfähig.
• Ausführungsressourcen: Databricks berichtet 596 gegenüber 17 Executor-Sekunden im gemessenen Vergleich, also ungefähr den Faktor 34 zugunsten des deklarativen Ansatzes.
• Codeumfang: Unter den abgeschlossenen Implementierungen lag der Median bei 131 Codezeilen für prozedurales PySpark und 64 für SDP.
• Tokenbedarf: Der deklarative Ansatz benötigte laut Untersuchung etwa das 2,3-Fache an LLM-Tokens, weil mehr Prüfung und Nachbesserung vor der Ausführung stattfanden.

Executor-Sekunden sind aufsummierte Ausführungszeit der Spark-Executors. Sie sind weder unmittelbar die Wartezeit für Anwender noch der Rechnungsbetrag deiner Azure-Umgebung. Aus dem Faktor 34 folgt deshalb nicht, dass jede produktive Pipeline entsprechend schneller oder günstiger wird.

Weniger Code erleichtert die Prüfung

Der geringere Codeumfang ist dennoch ein relevantes Betriebssignal. Wenn Spark Routineaufgaben übernimmt, muss dein Team weniger selbst erzeugte Ablauflogik lesen und warten. Weniger Code garantiert keine Qualität, reduziert aber den Umfang der manuellen Prüfung.

Interessant ist auch die Konsistenz: Im Test verwendeten 19 prozedurale Implementierungen eine lokale Verarbeitung im Speicher statt durchgängig verteilter Spark-Verarbeitung. Bei den deklarativen Implementierungen trat dieses Muster nicht auf. Was mit kleinen Testdaten funktioniert, kann bei größeren Datenmengen zum Betriebsproblem werden.

Was heißt das konkret für den deutschen Mittelstand?

Für mittelständische Unternehmen mit Azure Databricks spricht die Untersuchung dafür, deklarative Entwicklung als bevorzugten Ansatz für geeignete agentengenerierte Pipelines zu prüfen. Ein pauschaler Umbau bestehender PySpark-Verarbeitung lässt sich daraus nicht ableiten.

Ein typischer Prüfpunkt wäre die Zusammenführung von Auftrags-, Liefer- und Rechnungsdaten für das Controlling. Ein Agent kann Transformationen vorschlagen. Welche Stornierungen zählen, wie Teilrechnungen behandelt werden oder welcher Buchungszeitraum gilt, muss jedoch fachlich vorgegeben und überprüft werden.

Die passende Architektur verbindet deshalb Entwicklungsstandards mit Zuständigkeiten, Datenqualität und Betrieb. Genau diese Zusammenhänge solltest du bei der Planung deiner Datenplattform berücksichtigen.

So setzt du einen aussagekräftigen Pilot auf

Für einen begrenzten Test empfiehlt sich folgendes Vorgehen:

1. Eine überschaubare Pipeline auswählen: Nutze einen Prozess mit bekannten Eingabedaten und überprüfbaren Ergebnissen, statt sofort eine geschäftskritische Verarbeitung umzustellen.
2. Fachliche Erwartungen festhalten: Definiere Soll-Ergebnisse, zulässige Abweichungen und Sonderfälle wie fehlende Schlüssel oder verspätete Buchungen.
3. Struktur und Inhalt getrennt prüfen: Kombiniere den Dry Run mit Tests auf fachliche Richtigkeit. Eine bestandene Strukturprüfung ist keine Produktionsfreigabe.
4. Gesamtaufwand messen: Erfasse Tokenverbrauch, Compute-Aufwand, Nacharbeit und Review-Zeit. Prüfe zusätzlich Verhalten und Kosten bei repräsentativen Datenmengen.
5. Berechtigungen und Freigaben begrenzen: Lass Agenten zunächst in einer kontrollierten Entwicklungsumgebung arbeiten. Produktive Änderungen brauchen einen nachvollziehbaren Freigabeweg.

Für personenbezogene oder vertrauliche Daten musst du außerdem festlegen, welche Informationen in Modellanfragen gelangen dürfen. Ein deklaratives Programmiermodell ersetzt weder Zugriffskontrollen noch Datenschutzprüfung. Die Auswahl geeigneter Anwendungsfälle und Kontrollmechanismen gehört deshalb in deine KI-Strategie.

Was das für dich bedeutet

Spark Declarative Pipelines können KI-generiertes Data Engineering besser prüfbar machen: weniger selbst geschriebene Ablauflogik, frühere Erkennung struktureller Fehler und im untersuchten Szenario weniger verschwendete Ausführungsressourcen. Die Verantwortung für fachliche Richtigkeit bleibt bei deinem Unternehmen.

Behandle deklarative Entwicklung deshalb als Architekturentscheidung, nicht als Qualitätsversprechen des KI-Agenten. Ein begrenzter Pilot zeigt, ob der Ansatz zu deinen Daten, Kosten und Betriebsanforderungen passt.

Du möchtest prüfen, welche Pipelines sich dafür eignen? Ailio unterstützt dich als Databricks-Partner bei Architektur, Umsetzung und Betriebsfragen. Sprich mit uns über deine nächsten Schritte in der Databricks Beratung.

Redaktionelle Aufbereitung und Einordnung auf Basis des Beitrags „Built for Agents: The Case for Spark Declarative Pipelines“ im Databricks-Blog.