KI SpotlightNewsDatabricks: Deklarative Spark-Pipelines seien für KI-Agenten sicherer und billiger
Der Hersteller legt einen eigenen Benchmark vor und verweist auf einen Agenten-Anteil von über 70 Prozent bei SDP-Pipelines. Zahlen, Aufgaben und Modelle fehlen, Snowflake bewirbt mit Dynamic Tables einen konkurrierenden Ansatz.
Mit KI erstelltInhalt
◆ Fakten auf einen Blick
- Databricks gibt an, über 70 % der SDP-Pipelines würden inzwischen von KI-Agenten erstellt.
- Laut Databricks sind deklarative Pipelines vor dem Lauf auf strukturelle Fehler prüfbar, prozedurale nur durch Ausführen.
- Spark Declarative Pipelines ist ein deklaratives Framework für Batch- und Streaming-Pipelines auf Spark, mit Python und SQL.
- Laut Databricks ist SDP seit Apache Spark 4.1 eine native Spark-Fähigkeit.
- Databricks hat SDP ursprünglich als Delta Live Tables entwickelt und auf dem Data + AI Summit 2025 an Apache Spark beigetragen.
Databricks: Deklarative Pipelines sind für KI-Agenten sicherer, billiger und schlanker
Databricks hat einen Benchmark veröffentlicht. Er vergleicht deklarative Spark-Pipelines (Spark Declarative Pipelines, SDP) mit prozeduralen. Laut Unternehmen bearbeitete derselbe Agent dieselben Aufgaben mit beiden Programmiermodellen. Das Fazit des Herstellers: Deklarativ sei „safer, cheaper, and leaner“.
Als Begründung nennt Databricks einen Anteil. Agenten erstellen inzwischen über 70 Prozent der SDP-Pipelines auf der Plattform. Daraus leitet das Unternehmen zwei Anforderungen ab. Jeder Versuch eines Agenten kostet Rechenzeit und Geld, Iterationen müssen also günstig sein. Außerdem wird das Code-Review zur wichtigsten Kontrollstelle. Der Code soll deshalb knapp sein, sich lesen lassen und vor allem stimmen.
Beide Angaben stammen vom Hersteller und beziehen sich auf sein eigenes Produkt. Was Databricks unter „von Agenten erstellt“ versteht, welchen Zeitraum und welche Stichprobe die 70 Prozent abdecken, geht aus dem vorliegenden Text nicht hervor.
Strukturfehler fallen vor dem Lauf auf, stille erst im falschen Ergebnis
Databricks unterscheidet zwei Fehlerarten. Strukturelle Fehler, etwa eine nicht aufgelöste Spaltenreferenz, eine Tabelle, die es noch nicht gibt, oder eine unzulässige Konfigurationsänderung, lassen sich laut Databricks schon beim Lesen der Pipeline finden. Stille Fehler treten dagegen erst zutage, wenn der Lauf endet und das Ergebnis falsch ist.
Der Unterschied liegt im Modell. Eine deklarative Pipeline beschreibt die gewünschten Datensätze, Spark entscheidet über den Weg. Deshalb lässt sie sich vorab auf strukturelle Fehler prüfen. Eine prozedurale Pipeline schreibt Schritt für Schritt vor, wie Daten entstehen. Ob sie funktioniert, zeigt erst die Ausführung.
Zahlen, Aufgaben, Modelle und Metriken des Benchmarks enthält das vorliegende Material nicht.
SDP ist keine Neuheit. Laut Databricks gehört es seit Spark 4.1 zu den nativen Fähigkeiten von Spark. Ursprünglich entwickelte das Unternehmen es als Delta Live Tables und brachte es auf dem Data + AI Summit 2025 in das Apache-Spark-Projekt ein. Unterstützt werden Python und SQL.
Ohne offengelegten Benchmark bleibt die Aussage unbestätigt, Snowflake setzt auf einen anderen Weg
Um die Behauptung zu prüfen, bräuchte es Benchmark-Code, Aufgabenset, Agent beziehungsweise Modell und Rohergebnisse. Eine unabhängige Replikation steht aus. Bis dahin bleibt „sicherer, billiger, schlanker“ eine Herstellerbehauptung.
Databricks ordnet SDP im Rahmen von Lakeflow als offenes Framework für Datenteams und KI-Agenten ein. Zum Portfolio gehört mit Genie Code auch ein agentisches Produkt für die Pipeline-Erstellung. Die dazu genannten Kennzahlen zu Lakeflow, 85 Prozent schnellere Entwicklung und 50 Prozent weniger Kosten, nennen weder Quelle noch Bezug. Auch eine Methodik fehlt.
Snowflake wirbt mit Dynamic Tables für einen konkurrierenden deklarativen SQL-Ansatz. Pipelines lassen sich dort mit dem Agenten CoCo aus natürlicher Sprache erstellen. Ob einer der beiden Ansätze für Agenten überlegen ist, lassen die vorliegenden Quellen offen.
