TL;DR
Databricks-Kostenoptimierung beruht auf fünf Gewohnheiten: Wissen, woher die Kosten tatsächlich kommen (der DBU-Satz plus eine separate Cloud-Infrastruktur-Rechnung), Idle-Compute durch Auto-Termination und Timeouts eliminieren, Compute per Right-Sizing richtig dimensionieren – standardmäßig Serverless, klassisches Compute nur für die teuersten Workloads –, Workflows im Hinblick auf Ausführungsfrequenz und inkrementelle Verarbeitung überdenken sowie Storage- und Governance-Einstellungen festschreiben, damit die Einsparungen nicht mit der Zeit verpuffen. Echte Zahlen aus dem Webinar: Ein unüberwachter GPU-Cluster verursachte zusätzliche 4.000 $ auf einer Monatsrechnung von 20.000 $, bevor es jemand bemerkte – und die Reduzierung der Ausführungsfrequenz eines Jobs von 472-mal täglich auf einmal pro Stunde sparte 95 % seiner Kosten, rund 19.000 $ pro Jahr.
Warum Databricks-Kosten so schwer zu kontrollieren sind
Databricks gibt Datenteams ungewöhnlich viel Freiheit. Dieselbe Pipeline lässt sich als interaktiver Cluster, als geplanter Job oder als Serverless-Job ausführen – auf klassischem Compute oder Serverless, mit einem Dutzend verschiedener Node-Typen und Skalierungskonfigurationen dazwischen. Genau diese Flexibilität macht die Kostenkontrolle so schwierig. Mehr Optionen bedeuten mehr Möglichkeiten, etwas falsch zu konfigurieren – und auf der Databricks-Rechnung ist das nicht immer sofort ersichtlich.
Das war der Ausgangspunkt eines kürzlich veranstalteten Webinars mit Ian Whitestone, Mitgründer von SELECT, und Olivier Soucy, einem Databricks-Berater, der jahrelang Datenplattformen von Grund auf aufgebaut hat – unter anderem als Head of Data bei einer Krypto-Börse, wo er eine Databricks-Umgebung von null an entwickelte. Soucy betreibt heute seine eigene Beratung mit Fokus auf Databricks-Kosten und -Performance und stellte in der Session fünf konkrete Strategien vor, um Databricks-Ausgaben in den Griff zu bekommen – jede davon mit echten Zahlen aus Kundenprojekten belegt.
Hier eine Zusammenfassung seiner wichtigsten Punkte.
Verstehen Sie zuerst, wohin das Geld tatsächlich fließt
Bevor Sie irgendetwas optimieren, müssen Sie wissen, wofür Sie eigentlich zahlen – und Databricks macht das schwerer als nötig. Die Kosten setzen sich aus zwei getrennten Posten zusammen: dem von Databricks selbst berechneten DBU-Satz (Databricks Unit) und dem zugrunde liegenden Cloud-Compute, das AWS, Azure oder GCP für die von Databricks bereitgestellten Instanzen in Rechnung stellen.
Der DBU-Satz allein kann in die Irre führen. Soucy rechnete eine einzelne ETL-Pipeline auf drei verschiedene Arten durch: Als interaktiver Cluster kostet sie 55 Cent pro DBU, als Job auf klassischem Compute 30 Cent pro DBU, als Serverless-Job 45 Cent pro DBU. Betrachtet man nur den DBU-Preis, wirkt Serverless wie die teure Option. Klassisches Compute bringt jedoch zusätzlich eine separate Cloud-Infrastruktur-Rechnung mit, die bei Serverless entfällt – das Gesamtbild sieht also oft ganz anders aus, sobald beide Kostenblöcke zusammengerechnet werden.
Die meisten Teams rechnen sie nie zusammen. Auf Whitestones Frage, ob Kunden DBU- und Cloud-Infrastrukturkosten gemeinsam auf Job-Ebene verfolgen, antwortete Soucy unmissverständlich: in der Regel nicht, weil unterschiedliche Teams für die jeweilige Seite zuständig sind. Ein Databricks-Team überwacht Systemtabellen und Workflows; ein Cloud-Team schaut auf die AWS- oder Azure-Rechnung und behandelt Databricks als einen einzigen Posten. Die beiden Datenquellen mit den richtigen Tags zusammenzuführen ist so aufwendig, dass die meisten Organisationen darauf verzichten – selbst wenn sie wissen, wie wichtig es wäre.
Databricks stellt Systemtabellen mit Nutzungs- und Preisdaten bereit, was ausreicht, um ein einigermaßen genaues Kostenmodell für die DBU-Ausgaben aufzubauen. Für klassisches (nicht serverloses) Compute lautet Soucys Faustregel: Die zugrunde liegenden Cloud-Infrastrukturkosten entsprechen ungefähr den DBU-Kosten. Eine DBU-Rechnung von 50.000 $ liegt also oft eher bei 100.000 $, sobald das Cloud-Compute dazukommt. Das ist eine grobe Schätzung und schwankt bei GPU-Workloads stark, aber ein vernünftiger Ausgangspunkt, wenn Sie noch kein besseres Modell haben. Wer tiefer in die Funktionsweise des Databricks-Pricings einsteigen möchte: SELECT hat die drei Stellhebel, auf die es wirklich ankommt, ausführlich beschrieben.
Verschwendung eliminieren, bevor Sie irgendetwas anderes optimieren
Idle-Compute ist, in Soucys Worten, der teuerste Fehler, den ein Team machen kann – denn Sie zahlen für Ressourcen, die während ihrer Laufzeit null Mehrwert liefern. Er nannte zwei Beispiele aus eigenen Kundenprojekten. In einem Fall startete ein neuer Praktikant einen GPU-Cluster ohne Auto-Termination und ohne jegliche Leitplanken. Er lief wochenlang und verursachte zusätzliche 4.000 $ auf einer Monatsrechnung von 20.000 $, bevor es jemand bemerkte. In einem anderen Fall traf ein Job, der in der QA-Umgebung problemlos in rund 20 Minuten durchlief, in der Produktion auf andere Daten – und lief 47 Stunden, bevor ihn jemand stoppte.
Die Abhilfen sind simpel und lohnen sich unabhängig von allem anderen auf dieser Liste:
- Aktivieren Sie Auto-Termination für jeden Cluster und jedes Warehouse. Soucy empfahl als sinnvolle Standardwerte rund 30 Minuten Leerlaufzeit für Cluster und 10 Minuten für Warehouses – wobei der genaue Wert weniger wichtig ist als die Tatsache, überhaupt einen zu setzen.
- Schalten Sie Auto-Scaling ein, damit Compute mit dem tatsächlichen Bedarf wächst und schrumpft, statt rund um die Uhr voll provisioniert zu laufen.
- Setzen Sie Job- und Query-Timeouts. Das Standard-Timeout für SQL-Statements in Databricks beträgt zwei Tage – viel zu lang, da waren sich beide Referenten einig. Whitestone brachte es auf den Punkt: Wenn eine Query länger als einen Tag läuft, sollte sie vermutlich gar nicht mehr laufen, und dieser Standardwert sollte Account-weit gesenkt werden.
- Erzwingen Sie das Ganze per Cluster-Policies. Statt sich darauf zu verlassen, dass Einzelne an Auto-Termination denken, können Cluster-Policies sie auf Account-Ebene verpflichtend machen.
Right-Sizing: Compute passend zum Job dimensionieren
Ist die Verschwendung unter Kontrolle, folgt der nächste typische Fehler: Over-Provisioning – also mehr Compute zuzuweisen, als ein Workload braucht. Soucys Standardempfehlung, die er selbst als etwas kontrovers bezeichnete: standardmäßig Serverless nutzen, sofern es keinen konkreten Grund dagegen gibt.
Er untermauerte das mit einem Beispiel aus der stündlich laufenden ETL-Pipeline eines Kunden. Auf klassischem Compute verbrauchte der Job rund 44 DBUs pro Tag zu 30 Cent pro DBU (etwa 13 $ pro Tag an DBU-Kosten) plus weitere 10 $ pro Tag an Cloud-Infrastruktur – insgesamt knapp 23 $ pro Tag. Auf Serverless verlagert, verbrauchte derselbe Job 38 DBUs zu einem höheren DBU-Satz, aber die Gesamtkosten lagen ähnlich, in diesem Fall sogar leicht darunter – vor allem, weil Serverless die zwei bis vier Minuten Cluster-Startzeit eliminiert, die klassisches Compute bei jedem Lauf kostet. Durch den Wegfall des Startvorgangs sank zudem die Gesamtlaufzeit des Jobs von 20 auf 12 Minuten.
Soucys praktischer Rat: Wer neu bei Databricks ist oder seine Workflows noch nicht getunt hat, sollte überall standardmäßig auf Serverless setzen, dann die fünf bis zehn Workloads identifizieren, die den Großteil der Rechnung verursachen, und nur diese zurück auf klassisches Compute verlagern – dort gibt es mehr Stellhebel im Verhältnis von Kosten und Performance. Alles andere ist den Tuning-Aufwand meist nicht wert. Die Grenze verläuft in der Regel bei der Laufzeit: Jobs, die stundenlang am Stück laufen, profitieren eher von klassischem Compute, wo sich Node-Typ, Autoscaling und Worker-Anzahl direkt feinjustieren lassen.
Für klassisches Compute empfiehlt Soucy, mit der kleinsten verfügbaren Instanzgröße zu starten und erst dann hochzuskalieren, wenn echte Engpässe auftreten – geleitet von Spark-UI-Metriken wie CPU- und Node-Auslastung. Wer zu groß startet, produziert das, was er eine "stille Rechnung" nannte: keine Fehler, keine Ausfälle, nur dauerhaft höhere Kosten als nötig. Außerdem lohnt es sich, den Compute-Typ passend zum Workload zu wählen. Reine SQL-Arbeit gehört auf SQL Warehouses, allgemeine Job-Logik auf Job-Compute, und interaktive bzw. All-Purpose-Cluster sollten tatsächlich interaktiver Arbeit vorbehalten bleiben. Whitestone merkte an, dass dies einer der häufigsten Stolpersteine ist, die SELECT sieht: Läuft ein geplanter Job auf einem interaktiven Cluster statt auf einem dedizierten Job-Cluster, können sich die Databricks-Kosten dieses Jobs fast verdoppeln – ohne jeden Mehrwert.
Den Workflow selbst überdenken
Über die Compute-Dimensionierung hinaus zählen mehrere Änderungen am Pipeline-Design zu den wirkungsvollsten Optimierungen überhaupt.
Die Ausführungsfrequenz zählt mehr, als die meisten Teams annehmen. Nimmt man ein tägliches Update als Basis, kostet ein stündlicher Lauf rund das Fünffache, Near-Realtime-Updates kosten rund das 60-Fache. Soucys Rat: Echtzeit- oder Near-Realtime-Anforderungen aus dem Business ruhig hinterfragen – die meisten Anfragen nach "Echtzeit"-Dashboards bedeuten in Wahrheit nur, dass der Report einen bestimmten Zeitpunkt abbilden soll, nicht einen kontinuierlichen Datenstrom.
Nutzen Sie Views, statt Tabellen zu duplizieren. Für einfache Filter oder Spaltenauswahlen vermeidet eine View anstelle einer neuen physischen Tabelle das Kopieren der Daten und die laufenden Kosten für die Pflege dieser Kopie – ohne echten Nachteil für diejenigen, die darauf zugreifen.
Verarbeiten Sie inkrementell, statt alles neu zu berechnen. Der Auto Loader von Databricks erkennt neue oder geänderte Dateien im Cloud-Storage automatisch; kombiniert mit Structured Streaming verarbeitet eine Pipeline so nur das, was sich geändert hat, statt bei jedem Lauf den kompletten Datensatz. Soucy nannte diesen Ansatz in der Einrichtung komplexer, aber für jeden Workload mit hohem Datenvolumen unverzichtbar.
Analysieren Sie teure Queries im Query-Profil und schreiben Sie sie um. Die Query-Profile-Ansicht von Databricks zeigt, wie Spark eine Transformation tatsächlich ausgeführt hat – inklusive Shuffles und Spills, die leicht übersehen werden. Soucy berichtete, dass das Übergeben dieser Profilinformationen zusammen mit dem zugrunde liegenden Transformationscode an einen KI-Coding-Assistenten in seiner eigenen Arbeit echte, brauchbare Rewrites hervorgebracht hat – eine Aufgabe, die früher tiefe Spark-Expertise erforderte, ist damit deutlich zugänglicher geworden.
Storage nicht übersehen – und dafür sorgen, dass alles Bestand hat
Beim Storage riet Soucy davon ab, Partitionierung und Z-Ordering manuell zu tunen, und empfahl stattdessen Unity-Catalog-Managed-Tables, die Predictive Optimization unterstützen. Predictive Optimization führt Vacuum-, Optimize- und Analyze-Operationen automatisch nach Zeitplan aus: Veraltete Dateien werden bereinigt, kleine Dateien zu größeren kompaktiert und Metadaten aktualisiert, sodass Queries Dateien überspringen können, die sie nicht lesen müssen. Das kostet zwar etwas, aber unterm Strich fällt die Rechnung meist niedriger aus als bei manueller Wartung. Liquid Clustering, das manuelles Z-Ordering weitgehend abgelöst hat, bietet einen ähnlichen Vorteil: Bestehende Daten müssen nicht neu geschrieben werden, wenn sich die Clustering-Spalten ändern sollen.
Ohne Governance hält all das auf Dauer nicht. Soucys Empfehlung: alles als Code verwalten – mit Tools wie Terraform oder Databricks Asset Bundles, ausgerollt per CI/CD –, damit Konfigurationen über Umgebungen hinweg konsistent bleiben und nicht stillschweigend auseinanderdriften. Cluster-Policies sind hier der zentrale Hebel: sinnvolle Standardwerte für die meisten Nutzer setzen, Auto-Termination und Node-Typ-Limits erzwingen und Power-Usern, die wirklich mehr Flexibilität brauchen, einen Weg lassen, diese anzufragen. Cluster-Pools können ebenfalls helfen, indem sie eine Reihe von Instanzen auf Cloud-Provider-Seite warmhalten, sodass Jobs nicht auf den Cluster-Start warten müssen – wobei Sie dem Cloud-Provider diese ungenutzte Kapazität weiterhin bezahlen, auch wenn Databricks sie nicht berechnet.
Soucy wies außerdem auf eine leicht übersehene Kostenkategorie hin: neuere Databricks-Features wie Apps, Model-Serving-Endpoints, Vector Search und Quality Monitors. Er beschrieb, wie er selbst einen Quality Monitor auf einer großen Tabelle falsch konfigurierte, was die Tagesrechnung dieser Tabelle um 50 % erhöhte, bevor er es bemerkte. Whitestone ergänzte, dass KI-bezogene Features generell zu einem wachsenden Posten auf Databricks-Rechnungen werden dürften, und verwies auf den jüngsten Schritt von Databricks, zuvor kostenlose Tools wie Genie kostenpflichtig zu machen. Das Fazit beider: Richten Sie Kosten-Alerts ein, bevor Sie etwas Neues aktivieren – nicht danach.
Der rote Faden
Über alle fünf Strategien hinweg zeigt sich dasselbe Muster: Bei Databricks machen sich Kostenprobleme selten lautstark bemerkbar. Idle-Cluster laufen leise, zu häufig geplante Jobs laufen leise, überdimensioniertes Compute läuft leise – und neue Features werden aktiviert, ohne dass jemand prüft, was sie kosten werden, bis die Rechnung kommt. Keine der Abhilfen hier ist exotisch. Auto-Termination, sinnvolle Timeouts, der passende Compute-Typ für den jeweiligen Workload und Konfiguration als Code decken bei den meisten Teams den Großteil der vermeidbaren Ausgaben ab.
Für Teams, die das lieber automatisch als manuell erledigt haben möchten: SELECT for Databricks macht genau diese Art von Verschwendung direkt sichtbar – fehlende Auto-Termination, zu häufig geplante Jobs (in einem realen Beispiel aus der Session sparte die Reduzierung eines Jobs von 472 Läufen pro Tag auf einmal pro Stunde 95 % seiner Kosten, rund 19.000 $ pro Jahr) sowie Warehouses oder Jobs mit überproportionalem Anteil an den Ausgaben – bis hinunter zur einzelnen Query. Wie das funktioniert, sehen Sie auf select.dev.
FAQ
Was ist der größte Treiber unnötiger Databricks-Kosten? Idle-Compute. Cluster und Warehouses, die ohne Auto-Termination weiterlaufen, oder Jobs, die ohne Timeout hängen bleiben, verursachen Kosten ohne jeden Gegenwert. Dies vor allem anderen auf der Liste zu beheben, zahlt sich in der Regel am schnellsten aus.
Sollte ich auf Databricks standardmäßig Serverless oder klassisches Compute nutzen? Serverless ist für die meisten Workloads ein vernünftiger Standard: Die Cluster-Startzeit entfällt, und die meisten Teams landen ohne manuelles Tuning im richtigen Kostenbereich. Die Ausnahme sind die fünf bis zehn Workloads mit den höchsten Ausgaben – sie profitieren meist von der zusätzlichen Kontrolle, die klassisches Compute über Node-Typ, Autoscaling und Worker-Anzahl bietet.
Was ist der Unterschied zwischen DBU-Kosten und Cloud-Infrastrukturkosten? Der DBU-Satz (Databricks Unit) ist das, was Databricks selbst für Compute berechnet; er variiert je nach Compute-Typ. Bei klassischem Compute kommt zusätzlich eine separate Cloud-Infrastruktur-Rechnung von AWS, Azure oder GCP für die zugrunde liegenden Instanzen hinzu – bei Serverless-Compute entfällt diese. Als grobe Faustregel gilt: Bei klassischem Compute entsprechen die Cloud-Infrastrukturkosten ungefähr den DBU-Kosten.
Wie viel spart Auto-Termination tatsächlich? Das hängt vom Workload ab, aber der Schaden ohne sie kann groß sein. In einem realen Beispiel verursachte ein falsch konfigurierter GPU-Cluster ohne Auto-Termination zusätzliche Kosten von rund 4.000 $ in einem einzigen Monat, bevor es jemand bemerkte.
Wie wirkt sich die Ausführungsfrequenz von Jobs auf die Databricks-Kosten aus? Erheblich. Nimmt man ein tägliches Update als Basis, kostet derselbe Job bei stündlicher Ausführung rund das Fünffache, bei Near-Realtime-Updates rund das 60-Fache. Zu hinterfragen, ob ein Workload wirklich so oft laufen muss, ist oft der wirkungsvollste einzelne Kostenhebel überhaupt.
Stellt Databricks KI-Features wie Genie in Rechnung? Databricks hat begonnen, zuvor kostenlose Tools kostenpflichtig zu machen, darunter Genie, und KI-bezogene Features dürften zu einem wachsenden Posten auf Databricks-Rechnungen werden. Kosten-Alerts einzurichten, bevor neue Features aktiviert werden, ist der beste Schutz vor Überraschungen.