TL;DR
Die Quick Wins bei der Databricks-Kostenoptimierung (Auto-Termination, Timeouts, Autoscaling, Right-Sizing der Compute) bringen die beste Rendite, die Sie je erzielen werden: Sie senken die Rechnung oft um 20 bis 40 % und sind in Minuten umgesetzt. Darüber hinaus sind meist weitere 20 bis 40 % drin – allerdings zum Preis von Tagen oder Wochen Aufwand, und das lohnt sich nur bei den Workloads, bei denen die Rechnung aufgeht. In diesem Guide geht es um diese zweite Stufe: wie Sie die Jobs finden, die den Aufwand wert sind, und wie Sie sie weniger Arbeit verrichten lassen, bevor Sie entscheiden, welche Compute Sie dafür einsetzen.
Einleitung
Die meisten Ratschläge zu Databricks-Kosten hören bei der Konfiguration auf. Auto-Termination setzen, Timeouts ergänzen, Autoscaling aktivieren, keine überdimensionierten Cluster mehr. Dieser Rat ist richtig, und Sie sollten all das zuerst umsetzen, denn es ist tatsächlich die Arbeit mit dem höchsten Return. Je nach Ausgangslage holen diese Quick Wins häufig 20 bis 40 % der Rechnung zurück, und die meisten davon dauern Minuten. Niemand sollte sie überspringen, und dieser Beitrag behauptet keineswegs, sie wären klein.
Der Punkt ist: Sie haben eine Obergrenze. Sobald die Idle-Cluster weg sind, die Timeouts gesetzt und die Compute richtig dimensioniert ist, haben Sie eine große einmalige Ersparnis eingefahren – und die Kurve flacht ab. Die Workloads selbst verrichten noch genauso viel Arbeit wie zuvor. Die nächsten 20 bis 40 % zu holen bedeutet, zu verändern, was die Jobs tatsächlich tun: eine Pipeline, die jede Nacht ihre gesamte Historie neu verarbeitet, eine Query, die hundertmal mehr Daten scannt, als sie zurückliefert, ein "Echtzeit"-Dashboard, das niemand öfter als einmal am Tag öffnet. Nichts davon wird günstiger, wenn Sie den Cluster neu dimensionieren. Günstiger wird es, wenn Sie die Arbeit neu konzipieren – und das kostet Tage oder Wochen statt Minuten. Außerdem zahlt es sich nur bei manchen Workloads aus, weshalb der erste echte Schritt darin besteht, herauszufinden, bei welchen. Genau um diese zweite Stufe geht es in diesem Guide.
Warum bleiben die meisten Databricks-Kosteninitiativen nach den Quick Wins stecken?
Der erste Anlauf bei Databricks-Kosten zielt fast immer auf dieselbe Handvoll Stellschrauben – aus gutem Grund. Es sind die Maßnahmen mit dem höchsten Return bei geringstem Aufwand, und wer sie auslässt, lässt die Rechnung eskalieren. Falls Sie sie noch nicht umgesetzt haben, fangen Sie dort an: Unser Beitrag Databricks Pricing Explained führt im Detail durch Auto-Termination, Timeouts und Job Compute versus All-Purpose. Betrachten Sie jenen Beitrag als Voraussetzung – und diesen hier als den nächsten Schritt.
Das Problem, wenn man dort aufhört: Jede dieser Stellschrauben ist eine einmalige Korrektur. Auto-Termination verhindert, dass Sie für Idle-Cluster zahlen – aber sobald die Leerlaufzeit bei null liegt, gibt es nichts mehr zu holen. Eine Pipeline von einem All-Purpose-Cluster mit 0,55 $ pro DBU auf Jobs Classic mit 0,30 $ pro DBU umzuziehen, senkt die Rate dieses Jobs um rund 45 % – aber diesen Wechsel können Sie nur einmal machen. Das sind große, schnelle Erfolge, häufig ein Fünftel bis zwei Fünftel der Rechnung, und dann sind sie vorbei. Die Kurve flacht ab, und die Rechnung pendelt sich auf einer neuen, niedrigeren Baseline ein, die sich nicht mehr bewegt.
Diese Baseline wird davon bestimmt, wie viel Arbeit Ihre Jobs verrichten – und genau diese Variable rühren die Quick Wins nie an. Eine tägliche Pipeline, die eine Tabelle mit einer Milliarde Zeilen komplett neu schreibt, ist auch auf dem günstigsten korrekt dimensionierten Jobs-Cluster teuer. Die nächste Stufe der Einsparungen steckt im Workload selbst: weniger Daten verarbeiten, seltener laufen, Ergebnisse einmal berechnen statt immer wieder. Das ist schwieriger als ein Konfigurations-Toggle, dauert Tage oder Wochen statt Minuten und zahlt sich nicht überall aus. Bei einer günstigen oder selten laufenden Pipeline kostet die Engineering-Zeit mehr, als sie einspart. Genau deshalb ist der nächste Schritt nicht, mit dem Optimieren loszulegen, sondern herauszufinden, welche Workloads sich überhaupt zu optimieren lohnen.
Wie finden Sie die Workloads, die sich zu optimieren lohnen?
Bevor Sie irgendetwas optimieren, finden Sie heraus, was tatsächlich teuer ist. Das ist wichtiger, als es klingt, denn das Bauchgefühl der Engineers und die Rechnung zeigen selten auf dasselbe. Die Pipeline, die Sie nervt, ist oft günstig. Die, an die niemand denkt, läuft dreimal täglich auf einem großen Cluster und dominiert still und leise die Rechnung.
Der schnellste Weg, Ihre Ausgaben zu ranken, sind die Billing-System-Tables. Joinen Sie system.billing.usage (jede verbrauchte DBU) mit system.billing.list_prices (dem effektiven Preis pro SKU), um Mengen in Dollar zu verwandeln, und ergänzen Sie dann system.lakeflow.jobs, um einen lesbaren Job-Namen anzuhängen, damit das Ranking tatsächlich handlungsrelevant wird:
WITH price AS ( SELECT sku_name, pricing.effective_list.default AS price_effective FROM system.billing.list_prices WHERE price_end_time IS NULL),usage AS ( SELECT * FROM system.billing.usage WHERE usage.billing_origin_product = 'JOBS'Code erweitern
Das rankt Ihre Jobs nach Tageskosten inklusive Namen und beantwortet damit die einzige Frage, die in dieser Phase zählt: Welche konkreten Jobs treiben die Rechnung? Der Join auf system.lakeflow.jobs ist übrigens der Grund, warum sich Tagging lohnt. Tags senken für sich genommen nie eine Rechnung, aber sie ermöglichen es, dieses Ergebnis nach Team, Umgebung oder Projekt zu gruppieren, statt in Job-IDs und Namen zu versinken, die sich über die Zeit verändern.
Der Grund, vor dem Handeln zu ranken: Optimierung hat selbst einen Preis, und es ist leicht, mehr Engineering-Zeit auszugeben, als man einspart. Eine Pipeline umzuschreiben, die 1 % Ihrer Rechnung ausmacht, ist eine befriedigende Übung, die auf der Rechnung nie sichtbar wird – und die investierten Stunden übersteigen die Ersparnis meist auf Jahre hinaus. Sortieren Sie nach Kosten, schauen Sie sich die teuersten Workloads an und ignorieren Sie den Long Tail, bis die teuren erledigt sind. Optimieren Sie die Ausreißer, nicht alles.
Wer die eigenen Ausgaben pro Workload ranken will, muss diese Queries schreiben und pflegen – und die Dashboards aktuell halten, während Jobs umbenannt werden und Pipelines sich weiterentwickeln. SELECT übernimmt diese Zuordnung automatisch und zeigt Ihre teuersten Workloads, ungenutzte Compute und unpassende Compute-Typen, ganz ohne manuelles Query-Bauen. Sehen Sie, was SELECT in Ihrer Umgebung findet.
Warum schlägt die Optimierung des Jobs das Resizing des Clusters?
Dieser Abschnitt ist der, für den sich der ganze Beitrag lohnt. Wenn ein Job langsam oder teuer ist, ist der instinktive Fix ein größerer Cluster – es ist eine einzige Einstellung, und meistens funktioniert sie. Es ist aber auch der teuerste verfügbare Fix, und er lässt die eigentliche Verschwendung bestehen. Ein Job, der mehr Daten scannt als nötig, unnötig shuffelt oder bereits verarbeitete Historie erneut verarbeitet, verbrennt bei jeder Cluster-Größe überflüssige Compute. Wer hochskaliert, zahlt diesen Preis nur schneller.
Um es konkret zu machen: Ein Kunde von mir betrieb eine IoT-Daten-Pipeline, deren Laufzeit wir um rund 85 % und deren Kosten wir um 75 % senkten – etwa 10.000 $ pro Jahr – auf derselben Umgebung. Die Compute war von Anfang an nicht schlecht dimensioniert, nicht optimal, aber auch nicht eklatant daneben. Ein Resizing hätte die Rechnung um einstellige Prozentwerte bewegt. Die Einsparungen kamen vollständig daraus, zu ändern, was die Pipeline tat: inkrementelles Laden der Bronze- und Silver-Layer statt kompletter Neuverarbeitung, Verschieben eines teuren Fact-Table-Joins hinter die tägliche Aggregation, nachdem diese die Datenmenge verkleinert hatte, Umschreiben der aufwendigsten Transformation und Bereitstellung über Views statt Datenduplikation in neue Tabellen. Jede dieser Maßnahmen entspricht einem der Hebel unten. Keine einzelne war allein ausschlaggebend – und Compute-Sizing stand nicht auf der Liste.
Query-Profil lesen, dann den teuren Teil neu konzipieren
Databricks stellt für jede Ausführung ein detailliertes Query-Profil bereit, das zeigt, wohin die Zeit in jeder Phase des Plans geflossen ist. Aus der Query-Historie oder direkt aus einem Job oder einer SQL-Query können Sie das Profil öffnen und den vollständigen Execution Plan als JSON herunterladen. Dieses JSON ist der Input für den wirkungsvollsten und am wenigsten bekannten Trick im modernen Data-Engineering-Workflow: Geben Sie es einem LLM.
Ein LLM ist sehr gut darin, ein Query-Profil zu lesen und zu sagen, wo die Kosten liegen: welche Stage gespillt hat, welcher Join explodiert ist, wo ein Shuffle auf weit mehr Partitionen lief, als die Daten rechtfertigten. Bei einem echten Job identifizierte eines als Engpass eine SQL-Transformation, die einen vollständigen Datumskalender aufbaute (eine Zeile pro Entität pro Tag, über rund vierzehn Jahre Historie) und ihn anschließend wieder zusammenfaltete – und dabei zig Millionen Zwischenzeilen produzierte, um ein Ergebnis zu berechnen, das nur einen winzigen Bruchteil davon brauchte. Es blieb nicht bei der Diagnose. Es schlug einen ersten Rewrite in PySpark vor, mit einem eventbasierten Interval-Sweep-Ansatz, der den Kalender nie materialisiert, und wurde von da an zu einem echten Mitstreiter bei der Lösung. Ich wies auf einen Edge Case hin, den die erste Version nicht abdeckte, es arbeitete einen Fix ein, wir hielten den Fall als Unit-Test fest – und diesen Zyklus wiederholten wir zwei bis drei Tage lang, bis die Ergebnisse durchgängig korrekt waren. Der tägliche Job ging von rund zwei Stunden auf zehn Minuten herunter – eine Reduktion von Laufzeit und DBU-Kosten um grob den Faktor 15.
Der Punkt ist die Arbeitsteilung – und sie lautet nicht "KI findet Probleme, der Mensch macht die eigentliche Arbeit". Das Modell fand den Engpass, schlug den Algorithmus vor und schrieb den Großteil des Codes. Mein Job war das Steuern: die übersehenen Fälle erkennen, entscheiden, wann die Lösung tatsächlich korrekt ist, und die Iteration mit Tests ehrlich halten. Das ist eine wirklich andere und leistungsfähigere Nutzung, als nur eine Fehlermeldung hineinzukopieren. Wenn Sie im Databricks-Workspace arbeiten, erledigt Genie das gut; sitzen Sie in Ihrer IDE, funktioniert der dort bereits integrierte Assistent genauso gut. Das Tool ist weniger wichtig als die Gewohnheit, das Profil zu lesen und den teuren Teil neu zu bauen, statt zum größeren Cluster zu greifen.
Inkrementell verarbeiten statt die ganze Tabelle zu überschreiben
Der komplette Overwrite ist das einfachste Pipeline-Muster, und für kleine oder mittelgroße Tabellen ist er oft die richtige Wahl. Die Komplexität inkrementeller Verarbeitung lohnt sich nicht immer. Aber bei hohen Datenvolumina – gerade bei Transaktionsdaten, Telemetrie oder Zeitreihen – wird es mit jedem Wachstum der Tabelle teurer und schwerer zu rechtfertigen, die gesamte Tabelle bei jedem Lauf neu zu verarbeiten.
Die inkrementelle Alternative: neue Datensätze bei unveränderlichen Daten anhängen, geänderte Datensätze bei aktualisierten Daten mergen – und dieses Muster durch so viele Layer Ihrer Medallion-Architektur wie möglich durchziehen. Erst wenn Daten auf etwas Kleines herunteraggregiert sind, wird ein kompletter Overwrite wieder vertretbar. Spark Structured Streaming ist hier das praktische Werkzeug: gepaart mit Auto Loader für File-Ingestion oder beim nativen Lesen aus einer Delta-Tabelle verwaltet es Checkpoints automatisch, sodass jeder Lauf nur das verarbeitet, was seit dem letzten angekommen ist. Der größte Gewinn für die meisten Teams ist nicht kontinuierliche Echtzeit-Verarbeitung, sondern das zuverlässige inkrementelle Batch-Muster, das Streaming einfach macht: neue Daten verarbeiten, ohne Bestehendes erneut zu scannen.
Hinterfragen Sie die "Echtzeit"-Anforderung, bevor Sie sie akzeptieren
"Wir brauchen Daten nahezu in Echtzeit" ist eine der teuersten Anforderungen, die ein Datenteam ohne Rückfrage akzeptieren kann – und sie stimmt nur sehr selten. Stakeholder brauchen fast nie einen kontinuierlichen Strom frischer Daten. Sie brauchen eine ausreichend aktuelle Sicht in dem Moment, in dem sie tatsächlich hinschauen – und das ist etwas völlig anderes und deutlich Günstigeres. Bevor Sie für Echtzeit bauen, finden Sie heraus, wie oft das Dashboard wirklich geöffnet und der Report wirklich gelesen wird. Stündliche, tägliche, selbst wöchentliche Aktualisierungen reichen weit öfter aus, als die ursprüngliche Anfrage vermuten lässt.
Der Kostenunterschied ist nicht marginal. Nehmen Sie eine beispielhafte Pipeline und halten Sie die Arbeit konstant, während Sie nur den Takt ändern: Kontinuierlich betrieben kostet sie vielleicht 58 Einheiten; stündlich fällt dieselbe Arbeit auf rund 5 Einheiten; dreimal täglich liegen Sie nahe 1 Einheit. Das ist keine Rundungsdifferenz – es ist grob Faktor 12 von kontinuierlich zu stündlich, und von dort geht es noch einmal deutlich weiter nach unten.
Der praktische Schritt: Bauen Sie jede Pipeline mit Structured Streaming, unabhängig von der anfänglich geforderten Frequenz, denn Streaming macht den Wechsel zwischen geplantem Batch und kontinuierlichem Betrieb trivial. Starten Sie dann mit der niedrigsten Frequenz, die den tatsächlichen Geschäftsbedarf erfüllt, und erhöhen Sie sie nur, wenn es echte Belege dafür gibt, dass mehr Aktualität nötig ist. Die Möglichkeit zum Hochskalieren ist da, wenn Sie sie brauchen; die Ersparnis durch das nicht vorzeitige Hochskalieren kommt sofort an.
Views statt Tabellen bauen
Nicht jede Tabelle muss physisch Daten halten. Ein großer Teil der Tabellen in einer typischen Databricks-Umgebung existiert nicht wegen komplexer Transformationen, sondern um Daten in anderer Form bereitzustellen: ein anderes Schema, ein Filter, eine Teilmenge der Spalten, andere Zugriffsrechte. In diesen Fällen bringt das physische Kopieren der Daten Speicherkosten, Compute-Kosten und Pipeline-Komplexität ohne echten Nutzen.
Dafür ist eine View das richtige Werkzeug. Sie ist eine virtuelle Schicht, definiert durch eine Query – nichts wird kopiert oder gespeichert, und bei einer einfachen Spaltenauswahl oder einem Filter ist das Leseerlebnis von einer Tabelle nicht zu unterscheiden. Reservieren Sie physische Tabellen für die Ergebnisse wirklich teurer Transformationen, bei denen das Materialisieren spürbare Neuberechnung einspart. Für alles andere hält eine View den Speicher schlank und die Pipelines einfacher. Für eine tiefere Behandlung dieser Workflow-Muster arbeitet unser kostenloses E-Book zur Kostenoptimierung sie mit dem Diagnose-Flowchart durch, mit dem wir entscheiden, welcher Hebel bei welchem Workload greift.
Wie wählen Sie die richtige Compute, sobald der Job effizient ist?
Beachten Sie die Reihenfolge. Die Compute-Auswahl kommt nach der Workload-Optimierung, nicht davor – und genau diese Reihenfolge ist das gesamte Argument dieses Beitrags. Compute auf einen ineffizienten Job zuzuschneiden, zementiert die Verschwendung nur in der gewählten Größenordnung. Sobald der Job die richtige Menge Arbeit verrichtet, wird die Compute-Entscheidung einfacher und das Risiko kleiner.
Der Standard sollte Serverless sein – durchgängig, für Jobs, Notebooks und SQL. Das kann sich falsch anfühlen, denn Serverless hat eine höhere DBU-Rate: Auf Azure Premium liegt Jobs Serverless bei 0,45 $ pro DBU gegenüber 0,30 $ für Jobs Classic, interaktives Serverless bei 0,95 $ gegenüber 0,55 $ für klassisches All-Purpose. Aber die DBU-Rate ist nur die halbe Geschichte, und genau diesen Teil übersehen Teams beim Vergleich am häufigsten. Bei klassischer Compute ist die DBU-Gebühr nicht die ganze Rechnung. Sie zahlen zusätzlich separat an Ihren Cloud-Provider für die darunterliegenden VMs – eine Zahl, die sich vorab wirklich schwer schätzen lässt. Serverless bündelt die Infrastruktur in die DBU-Rate: Der Preis, den Sie sehen, ist der Preis, den Sie zahlen.
Diese Bündelung kippt den naiven Vergleich öfter, als man erwarten würde. Die stündliche ETL-Pipeline eines Kunden ist ein sauberes Beispiel. Auf Job Classic mit 0,30 $ pro DBU verbrauchte sie rund 44 DBU am Tag – etwa 13 $ in DBUs plus weitere 10 $ an Cloud-VM-Kosten, insgesamt rund 23 $ pro Tag. Die Serverless-Variante desselben Workloads nutzte weniger DBUs (rund 38, weil sie enger an der tatsächlichen Arbeit skalierte) bei 0,45 $ pro DBU – etwa 18 $ pro Tag, ganz ohne separate Cloud-Rechnung. Die Option mit der höheren nominellen Rate war die günstigere, sobald die VM-Kosten mitgezählt wurden – und sie erforderte dafür null Tuning.
Es gibt noch einen zweiten Kostenblock, der auf keiner der beiden Rechnungen auftaucht: die Engineering-Zeit, um einen klassischen Cluster richtig zu dimensionieren und zu tunen (Instance-Typ, Memory-to-Core-Verhältnis, Autoscaling-Verhalten – und all das erneut, sobald sich der Workload weiterentwickelt). Für die meisten Workloads kostet diese Zeit mehr als jeder DBU-Aufpreis. Ein Tag Tuning, um 10 % bei einer überschaubaren Pipeline zu sparen, kann ein Jahr bis zum Break-even brauchen. Serverless beseitigt zudem eine ganze Klasse operativer Probleme: kein Cluster-Startup, kein Versionsmanagement, keine vergessenen Idle-Cluster.
Die ehrliche Einordnung: Serverless ist für eine einzelne Pipeline isoliert betrachtet selten die absolut günstigste Option, aber für die meisten Pipelines kommt es mit null Tuning-Aufwand auf 80 bis 90 % heran. Über Ihr gesamtes Portfolio hinweg gewinnt das bei der Total Cost of Ownership, denn die große Mehrheit Ihrer Pipelines wird einigermaßen effizient, ohne dass Sie eine Minute investieren. Dann nutzen Sie Ihr Kosten-Ranking, um die Handvoll hochfrequenter, teurer Jobs mit vorhersehbarem Laufverhalten zu finden – die lohnen den Umzug auf klassische Compute und das manuelle Tuning, Cloud-VM-Rechnung inklusive. Optimieren Sie die Ausreißer, stellen Sie alles andere standardmäßig auf Serverless.
Wenn Sie klassische Compute konfigurieren, starten Sie mit der kleinsten Ressource, die funktioniert, und skalieren Sie auf Basis von Belegen. Überdimensionierung ist der Normalzustand der meisten Databricks-Deployments, weil Konfigurationen vom Kollegen kopiert, aus einem alten Projekt geerbt oder beim Vorschlag der UI belassen werden. Wählen Sie die kleinste SQL-Warehouse-Größe und gehen Sie erst hoch, wenn die Query-Zeiten inakzeptabel werden; bei Clustern starten Sie mit einem General-Purpose-Node-Typ und lassen per Autoscaling von einem auf zwei oder vier Worker skalieren. Doppelt so große Compute führt Jobs nicht doppelt so schnell aus – kostet aber zuverlässig doppelt so viel.
Wie verhindern Sie, dass die Kosten wieder nach oben driften?
Einzeloptimierung ist ein Startpunkt, kein Dauerzustand. Teams wachsen, Workloads vervielfachen sich, neue Engineers kommen mit eigenen Gewohnheiten – und die Kosten driften wieder nach oben, wenn nichts sie unten hält. Diese Rolle übernimmt eine Governance-Ebene, und sie macht aus einer einmaligen Aufräumaktion eine dauerhafte Baseline.
Der zuverlässigste Einzelschritt: Compute darf nicht mehr ad hoc erstellt werden. Wenn Engineers ihre eigenen Cluster provisionieren, werden die entscheidenden Einstellungen (Auto-Termination, Skalierungslimits, Instance-Typen, Tags) inkonsistent oder gar nicht gesetzt, und jede sorgfältige Optimierung anderswo versickert. Definieren Sie Cluster und Warehouses als Infrastructure as Code, deployen Sie sie über CI/CD und lassen Sie Engineers aus einem vorab freigegebenen Set wählen, statt eigene zu bauen. Für Power-User, die wirklich eigene Compute brauchen, sind Cluster-Policies der Mittelweg: Eine Policy kann Auto-Termination erzwingen, Cluster-Größen deckeln und Instance-Typen einschränken – und lässt innerhalb dieser Grenzen trotzdem Spielraum. Die kosteneffiziente Wahl wird zur einzig verfügbaren Wahl. Mehr dazu, warum dieses Problem aus unserer Sicht dediziertes Tooling verdient, lesen Sie unter warum wir SELECT für Databricks gebaut haben.
Prävention fängt nicht alles ab, kombinieren Sie sie also mit Alerting. Databricks bietet eine native Budgets-Funktion in der Account-Konsole für Ausgaben-Schwellenwerte – ein guter Startpunkt. Das sensiblere Signal ist aber statistisch, kein fixes Limit: Messen Sie die Standardabweichung der täglichen oder wöchentlichen Kosten pro Workload und alarmieren Sie bei Abweichungen vom Normalbereich. Ein fixer Schwellenwert löst erst aus, wenn die Ausgaben bereits eine harte Grenze überschritten haben. Wer auf Drift achtet, erkennt ein Problem an dem Tag, an dem ein Job aus dem Ruder läuft – nicht am Ende des Abrechnungszyklus, wenn der Schaden angerichtet ist. Diese taggleiche Transparenz ist der Unterschied zwischen einer kleinen Korrektur und einer hässlichen Rechnung.
Databricks-Kostenoptimierung ist kein einmaliges Projekt. Die Plattform entwickelt sich weiter, Teams ergänzen Workloads, und die Baseline, die Sie mühsam gesenkt haben, driftet ohne kontinuierliche Transparenz wieder nach oben. SELECT gibt Datenplattform-Teams diese Transparenz an einem Ort: Ausgaben pro Workload ranken, Drift erkennen, sobald sie beginnt, und Einsparungen aufdecken, die sich über die Zeit summieren. Buchen Sie eine Demo und sehen Sie, was SELECT in Ihrer Umgebung aufdeckt.
FAQ
Wie lassen sich Databricks-Kosten am schnellsten senken?
Zwei Konfigurationsänderungen holen mit dem geringsten Aufwand das meiste Geld zurück: Setzen Sie Auto-Termination auf jedem Cluster und SQL Warehouse, damit ungenutzte Ressourcen nicht weiter abgerechnet werden, und verschieben Sie geplante Pipelines von All-Purpose-Compute auf Jobs Compute. Auf Azure Premium senkt das einen Job von 0,55 $ pro DBU auf 0,30 $ – rund 45 % weniger auf die Rate dieses Workloads. Beides sind Änderungen für einen Nachmittag. Der ehrliche Vorbehalt: Keine davon berührt eine schlecht konzipierte Pipeline. Verarbeitet ein Job jede Nacht seine gesamte Historie neu oder scannt weit mehr Daten, als er zurückliefert, bleibt er auch auf dem günstigsten korrekt dimensionierten Cluster teuer. Die schnellen Erfolge setzen eine niedrigere Baseline; sie weiter zu senken heißt, die Arbeit neu zu konzipieren.
Ist Serverless günstiger als klassische Compute?
Nicht pro DBU und nicht immer in Summe – ein klares Ja oder Nein gibt es also nicht. Serverless hat eine höhere Rate (auf Azure Premium 0,45 $ pro DBU für Jobs Serverless gegenüber 0,30 $ für Jobs Classic), bündelt aber die Infrastruktur, die Sie sonst separat bezahlen und selbst tunen würden. Für die meisten Workloads wiegt die gesparte Engineering-Zeit den DBU-Aufpreis auf, weshalb Serverless ein guter Standard ist. Die Falle dabei: Serverless skaliert so geschmeidig, dass sich Kostensteigerungen besser verstecken als auf klassischer Compute. Zwei Läufe können dieselbe reale Laufzeit haben und dabei sehr unterschiedliche DBU-Mengen verbrauchen, weil Serverless für den schwereren Lauf still hochskaliert hat. Die Dauer wirkt konstant, während sich die Rechnung verdoppelt. Überwachen Sie den DBU-Verbrauch, nicht nur die Ausführungszeit.
Erhöht Unity Catalog meine Databricks-Rechnung?
Unity Catalog selbst ist kein separat bepreistes Produkt, aber seine Aktivierung verändert Ihre Kostenstruktur auf eine Weise, die Sie vor der Migration verstehen sollten. Predictive Optimization, das OPTIMIZE und VACUUM automatisch auf Unity-Catalog-Managed-Tables ausführt, verbraucht DBUs (es finanziert sich in der Regel durch Query-Einsparungen selbst, ist aber ein realer Posten). Governance-Funktionen, die Wartung verwalteter Tabellen und die Serverless-Compute, auf der mehrere Katalog-Operationen laufen, tauchen alle irgendwo auf. Wie Unity Catalog die Kosten beeinflusst, behandeln wir in einem eigenen Guide; die Kurzfassung: Governance lohnt sich, ist aber nicht gratis, und Sie sollten wissen, wo sie auf der Rechnung landet, bevor Sie sie einschalten.