Budgets und Alerts für Cloud-Data-Warehouse-Kosten einrichten

Jedes Analytics-Team kennt das: Am Monatsende kommt die Rechnung und ein einziges SQL-Warehouse hat das Budget gesprengt – vielleicht, weil eine Compute-Ressource über Nacht lief, oder weil eine Ad-hoc-Ressource automatisch hochskaliert wurde, um während einer Quartalsprüfung 80 Tableau-Nutzer zu bedienen. Die Kosten sind real, aber der Frust sitzt tiefer: Niemand wusste Bescheid, bis es zu spät war.

Proaktives Kostenmanagement stellt dieses Modell auf den Kopf. Statt nachträglicher, mühsamer Rechnungsanalyse setzen Sie Leitplanken, bevor auch nur ein Cent ausgegeben wird – Budgets werden an Warehouses, Teams oder BI-Workloads gekoppelt. Warnmeldungen, die bei von Ihnen gewählten Schwellenwerten ausgelöst werden, und Dashboards, die Nutzungstrends in Echtzeit aufzeigen – all das auf der Databricks Data & AI Platform. Wenn Sie sich gerade mitten in der Migration von einem On-Premises-System oder einem anderen Cloud Data Warehouse befinden, ist jetzt der richtige Zeitpunkt, um diese Governance einzuführen.

Warum scheitert reaktives Kostenmanagement?

Data-Warehousing-Workloads bringen ganz eigene Kostenherausforderungen mit sich. SQL-Warehouses bedienen interaktive, vom Menschen gesteuerte Workloads (BI-Dashboards, Ad-hoc-Analysen, eingebettete Analysen), bei denen die Nachfrage unvorhersehbar und sprunghaft ist. Ein einziges All-Hands-Meeting der Geschäftsführung, das 200 gleichzeitige Dashboard-Aktualisierungen auslöst, kann die Kosten in wenigen Minuten in die Höhe treiben. Die meisten Unternehmen beginnen ihre FinOps-Reise auf dieselbe Weise: Jemand lädt die CSV-Datei mit den Nutzungsdaten des letzten Monats herunter, öffnet eine Pivot-Tabelle und fängt an, Fragen zu stellen. Dieser Ansatz scheitert aus vier Gründen:

• Sie sehen nicht, wer die Kosten verursacht. Die Nutzung wird auf Plattformebene zusammengefasst, nicht auf Ebene des Teams oder der Abfrage, die sie verursacht hat. So kann niemand für ein bestimmtes Budget verantwortlich gemacht werden.
• Niemand übernimmt die Verantwortung für ein Budget. Ohne Ausgabenziele, die an ein Warehouse oder Team gebunden sind, spürt der Analyst, der SELECT * auf einer 2 TB großen Tabelle ausführt, die Kosten nie. Das Plattform-Team trägt sie stillschweigend.
• Sie erfahren es erst zu spät. Bis die Excel-Berichte des letzten Monats die Budgetüberschreitung aufzeigen, ist sie bereits zwei Abrechnungszyklen alt und die Entscheidung, die dazu geführt hat, ist nicht mehr nachvollziehbar.
• Manuelle Prüfungen sind nicht skalierbar. Fünf Warehouses lassen sich vielleicht noch monatlich per Pivot-Tabelle überprüfen. Sobald es jedoch Dutzende sind, wird die Unterstützung von Hunderten von Analysten über Tableau, Power BI und Looker hinweg unüberschaubar.

Proaktives Kostenmanagement – Zuordnung, Budgets, Warnmeldungen, Dashboards und Optimierung – löst alle fünf Probleme.

Starten Sie mit Serverless: die erste Kostenentscheidung.

Bevor Sie Budgets einrichten, wählen Sie den richtigen Warehouse-Typ. Serverless SQL-Warehouses sind die von Databricks empfohlene Option für die meisten Workloads. Sie starten in Sekundenschnelle, skalieren sofort nach Beendigung der Abfragen herunter und überlassen das Zuweisen von Compute-Ressourcen dem Intelligent Workload Management. So zahlen Sie nur für die tatsächliche Ausführung von Abfragen, nicht für Leerlaufzeiten.

Wenn Sie von einem Legacy-Cloud-Data-Warehouse migrieren, ist dies eine große Umstellung. Die meisten Altsysteme berechnen Kosten für dauerhaft aktive Compute-Ressourcen oder erfordern manuelle Skalierungsentscheidungen. Serverless eliminiert diese gesamte Kategorie von Kostenfehlern.

Lumen Technologies hat dies aus erster Hand erfahren: Die Migration zweier wichtiger Telekommunikationssysteme von einem On-Premises Data Warehouse zu Serverless SQL reduzierte die Compute-Kosten um 30–40 % und steigerte die Abfragegeschwindigkeit um 90 %. Das System skaliert nun automatisch, um alle 10 Minuten etwa 7 GB zu verarbeiten, wobei Serverless die "Dauerbetrieb-Steuer" eliminiert, die normalerweise mit sprunghaften Echtzeit-Workloads verbunden ist.

Die fünf Säulen des proaktiven Kostenmanagements

Das Framework besteht aus fünf Säulen. Die ersten vier machen Ihre Ausgaben sichtbar, die fünfte senkt sie tatsächlich:

• Kostenzuordnung. Versehen Sie alles mit Tags, damit Sie wissen, wer wie viel für welches Warehouse ausgegeben hat.
• Budgets. Definieren Sie monatliche Ausgabenziele auf Konto-, Workspace- oder Team-Ebene.
• Warnmeldungen. Lassen Sie sich benachrichtigen, sobald die Ausgaben einen Schwellenwert erreichen oder überschreiten.
• Dashboards. Visualisieren Sie Warehouse-Trends und machen Sie Kosten zu einer betrieblichen Kennzahl erster Klasse.
• Optimierungen. Senken Sie von vornherein die Kosten für die Arbeit.

Säule 1: Kostenzuordnung auf zwei Ebenen

Man kann nur verwalten, was man auch zuordnen kann. Bei Warehouses bedeutet das zwei Ebenen: das Warehouse selbst und die einzelne Abfrage. Die eine Ebene zeigt Ihnen, welches Warehouse das Geld ausgegeben hat, die andere, wer darin es war.

Ebene 1: Tagging des Warehouses

SQL-Warehouses unterstützen benutzerdefinierte Tags als Schlüssel-Wert-Paare (key:value), die an system.billing.usage weitergegeben werden. So wird jede verbrauchte DBU mit einem Team, Projekt oder einer Kostenstelle verknüpft. Das Tagging funktioniert bei jedem Warehouse-Typ gleich – Classic, Pro und Serverless werden alle auf Warehouse-Ebene getaggt, sodass Sie ein Muster lernen und überall anwenden können.

Legen Sie Tags in der UI unter SQL Warehouses > Ihr Warehouse > Edit > Tags fest, oder erstellen Sie das Warehouse über die REST-API:

Tagging über die REST-API

Wenden Sie mindestens drei Dimensionen an: Team (wem es gehört), Kostenstelle (wer bezahlt) und Anwendungsfall (BI-Bereitstellung, Ad-hoc, geplante Aktualisierung).

Aktuell gibt es keine native Richtlinie, die Warehouse-Tags erzwingt, sodass jeder ein Warehouse ohne Tags erstellen kann. Integrieren Sie die Durchsetzung stattdessen in Ihren Bereitstellungsprozess – erstellen Sie Warehouses mit Terraform, Declarative Automation Bundles oder der REST-API mit Tags in der Definition, und behandeln Sie die UI als Ausnahme. Die Abfrage zur Zuordnungslücke weiter unten in diesem Beitrag erfasst alles, was durchschlüpft.

Ebene 2: Tagging der Abfrage

Warehouse-Tags verraten Ihnen, dass ein Warehouse im letzten Monat 4.000 $ gekostet hat. Sie verraten Ihnen jedoch nicht, dass 60 % davon auf ein einziges Power BI-Dashboard entfallen, das alle 15 Minuten aktualisiert wird. Diese Lücke ist wichtig, da Warehouses gemeinsam genutzt werden – ein einziges BI-Warehouse bedient Dutzende von Dashboards, mehrere dbt-Modelle und einen kontinuierlichen Strom von Ad-hoc-Abfragen.

Abfrage-Tags (Public Preview) schließen diese Lücke, indem sie einzelnen SQL-Anweisungen geschäftlichen Kontext hinzufügen:

Die Tags landen in der Spalte query_tags von system.query.history (Public Preview), zusammen mit executed_by und statement_id, sodass Sie die Ausgaben nach Dashboard, Modell oder Kostenstelle statt nach Warehouse gruppieren können. Einige Tools übernehmen dies für Sie: Ab dbt-databricks 1.11.0 werden Modellabfragen automatisch mit dem dbt-Modellnamen getaggt, und Power BI übergibt Workspace- und Dataset-IDs über den ADBC-Treiber.

Zwei Einschränkungen: Abfrage-Tags gelten nur für SQL-Warehouse-Abfragen. Da sie im Abfrageverlauf und nicht in den Abrechnungsdaten gespeichert sind, müssen Sie beide selbst zusammenführen, um die Kosten pro Abfrage zu ermitteln.

Bevor Sie SQL schreiben, prüfen Sie die Seite „Kosten“ im Governance Hub (Beta) – eine Ansicht auf Kontoebene für Ausgaben, Kostentreiber, Budgets und Tagging-Abdeckung sowie der schnellste Weg, um zu sehen, wie viel Ihrer Nutzung überhaupt zugeordnet werden kann. Ein Kontoadministrator kann dies auf der Seite „Vorschauen“ der Kontokonsole aktivieren.

Säule 2: Budgets in der Kontokonsole festlegen

Ein Budget erstellen

Gehen Sie in der Kontokonsole zu Nutzung > Budgets, klicken Sie auf Budget hinzufügen und konfigurieren Sie:

• Name: Aussagekräftig (z. B. „Analytics SQL Warehouses, monatlich“)
• Betrag: Monatliches Ziel in USD
• Bereich: Filtern nach Workspaces und/oder Tags (z. B. Team:Analytics)
• E-Mail-Benachrichtigungen: Empfänger, die benachrichtigt werden, wenn die Ausgaben den Budgetbetrag erreichen

Beispiele für Budgetkonfigurationen

Das wichtigste Muster sind gestaffelte Budgets: Budgets auf Teamebene für die Eigenverantwortung sowie ein kontoweites Budget als Sicherheitsnetz, das alles auffängt, was durchrutscht. 

Denken Sie daran, dass Budgets ein Überwachungsmechanismus sind und keine feste Obergrenze. Sie stoppen weder die Nutzung noch verhindern sie Gebühren, sodass Ihre Rechnung den Betrag dennoch überschreiten kann. Das Ziel ist Sensibilisierung und schnelles Reagieren, nicht Abschaltungen, die ein Produktions-Dashboard mitten in der Aktualisierung beschädigen könnten.

GetYourGuide hat dies direkt getestet: Die Konsolidierung aller Looker-Workloads auf SQL Serverless senkte die BI-Bereitstellungskosten um ca. 20 % und beschleunigte Abfragen um 35 %, obwohl das Team erwartet hatte, dass Classic-Cluster günstiger sein würden. Die Wahl des Warehouse-Typs ist eine Budgetentscheidung, die es wert ist, neu validiert zu werden, und keine einmalige Angelegenheit.

Ihre Burn-Rate verstehen

Klicken Sie auf ein beliebiges Budget, um die aktuellen Ausgaben im Vergleich zum Ziel, das verbleibende Budget und eine tägliche Visualisierung der Burn-Rate anzuzeigen. Für das Data Warehousing ist dieses Diagramm besonders aufschlussreich:

• Linearer täglicher Verbrauch bedeutet stabile BI-Bereitstellungskosten.
• Sägezahnmuster mit Spitzen am Montag/Freitag deutet auf Ad-hoc-Analysen hin, die sich um die Arbeitstage konzentrieren.
• Ein plötzlicher Anstieg Mitte des Monats bedeutet, dass ein neues Dashboard ohne Kostenprüfung bereitgestellt wurde.
• Ein allmählicher Aufwärtstrend bedeutet, dass die organische Akzeptanz Ihre Budgetannahmen übersteigt.

Säule 3: Warnmeldungen, das Nervensystem der Cost Governance

Budgets zeigen Ihnen, wo Sie stehen. Warnmeldungen sagen Ihnen, wann Sie handeln müssen.

E-Mail-Warnmeldungen für Budgets

Wenn Sie ein Budget erstellen, fügen Sie E-Mail-Empfänger hinzu, die benachrichtigt werden, wenn die Ausgaben den Budgetbetrag überschreiten. Es ist keinerlei Code erforderlich.

Erstellen Sie für schwellenwertbasierte Warnmeldungen Databricks SQL-Warnmeldungen, die `system.billing.usage` direkt abfragen. Hier sind die wichtigsten Muster:

Warnmeldung, wenn die täglichen SQL-Warehouse-Ausgaben einen Schwellenwert überschreiten

Prognose-Warnmeldung: Die prognostizierten Ausgaben am Monatsende werden das Budget überschreiten

Dies ist das Muster, von dem Teams am meisten profitieren. Anstatt erst nach der Überschreitung zu warnen, prognostiziert es die Ausgaben am Monatsende und schlägt an, bevor diese Prognose Ihr Budget überschreitet – so haben Sie noch Zeit zu handeln:

Planen Sie dies alle vier Stunden und leiten Sie es an Slack oder per E-Mail weiter. So haben Teams Tage Zeit zu reagieren (ein Warehouse anzupassen, eine teure Abfrage zu optimieren, einen Batch zu verschieben), bevor das Budget überschritten wird.

Versteckte Kosten durch Aktualisierungen von Materialized Views erkennen

Die Kosten für die Aktualisierung von Materialized Views werden von Teams am häufigsten übersehen, da sie als serverlose Pipeline-Nutzung und nicht als Warehouse-Nutzung abgerechnet werden. Eine Sicht, die so eingestellt ist, dass sie alle 15 Minuten mit einer Quelle aktualisiert wird, die sich nur zweimal täglich ändert, verursacht unnötige Kosten ohne Nutzen. Passen Sie den Aktualisierungszeitplan an die tatsächliche Häufigkeit der Datenänderungen an und überwachen Sie die Pipeline-Ausgaben direkt:

Säule 4: Dashboards und kontinuierliche Überwachung

Warnmeldungen sind punktuelle Auslöser. Dashboards bieten kontinuierlichen Kontext. Databricks stellt vorgefertigte Nutzungs-Dashboards bereit, die Konto-Admins in jeden Unity Catalog-aktivierten Workspace importieren können. Diese decken Ausgabentrends, Top-N-Analysen, Tag-Filterung und Drilldowns pro Warehouse ab. Für ein benutzerdefiniertes Monitoring sind zwei Abfragen besonders nützlich:

SQL-Warehouse-Kosten nach Team

Nicht zugeordnete SQL-Nutzung (Zuordnungslücke)

Nicht getaggte SQL-Nutzung ist Ihre Zuordnungslücke – Warehouse-Ausgaben, die keinem Team zugeordnet werden können. Reduzieren Sie diese auf null.

Raiffeisen Bank International hat eine eigene Plattform zur Kostenüberwachung und -prognose direkt auf Basis von Databricks-Systemtabellen aufgebaut – mit Transparenz pro Warehouse, pro Benutzer und pro Workload. Der Nutzen war ebenso kultureller wie technischer Natur: 3–4-mal schnellere Workloads und, was noch wichtiger ist: Wenn Teams ihre eigenen Ausgaben sehen und diese erklären müssen, ändert sich das Verhalten ganz ohne Vorschriften.

Säule 5: Optimierung – die Säule, die die Rechnung tatsächlich verändert

In den ersten vier Säulen geht es darum, Ihre Ausgaben sichtbar zu machen. In dieser Säule geht es darum, sie zu senken – und das ist der Schritt, den die meisten Teams überspringen. Beginnen Sie mit den zwei Änderungen, die gleichzeitig die Kosten senken und die Leistung verbessern.

Aktivieren Sie die prädiktive Optimierung für von Unity Catalog verwaltete Tabellen. Databricks führt OPTIMIZE, VACUUM und ANALYZE basierend auf den tatsächlichen Abfragen der einzelnen Tabellen für Sie aus, und mit CLUSTER BY AUTO werden die Clustering-Schlüssel angepasst, wenn sich die Abfragemuster ändern. Weniger gescannte Daten bedeuten schnellere Abfragen und weniger DBUs, ohne dass ein Wartungsplan eingehalten werden muss. Für Konten, die am oder nach dem 11. November 2024 erstellt wurden, ist dies standardmäßig aktiviert und wird bis 2026 auch für ältere Konten eingeführt.

Nutzen Sie standardmäßig Serverless-Warehouses wegen der zuvor beschriebenen Vorteile beim Starten und im Leerlauf – für die meisten Teams macht dies den Großteil der Einsparungen aus, und das ganz ohne laufenden Aufwand.

Darüber hinaus lohnt es sich, einige Einstellungen anzupassen:

• Verkürzen Sie das automatische Beenden (Auto-Stop). Pro und Classic stoppen standardmäßig nach 45 Minuten Leerlauf; Serverless stoppt standardmäßig nach 10 Minuten, und Sie können diesen Wert in der UI auf 5 oder über die API auf 1 Minute senken. Jede Minute Leerlauf auf einem BI-Warehouse, nachdem das letzte Dashboard geschlossen wurde, ist reine Verschwendung.
• Legen Sie ein Anweisungstimeout fest (Beta – aktivieren Sie die Vorschauversion und legen Sie es dann pro Warehouse über die API fest). Eine einzelne ausufernde Abfrage sollte nicht das Rechenbudget eines ganzen Wochenendes verschlingen; halten Sie das Limit bei BI-Warehouses kurz und bei ETL länger.
• Legen Sie ein Standard-Warehouse fest (Admin-Einstellungen > Compute), damit ein kurzer Blick auf zehn Zeilen nicht gleich einen Cluster in ETL-Größe startet, und beginnen Sie mit Small oder Medium, anstatt zu überdimensionieren.
• Skalieren Sie gezielt hoch oder breit. Hochskalieren (Scaling up – größere Instanzen, jetzt bis zu 5X-Large in der Public Preview) beschleunigt eine einzelne schwere Abfrage; Breitenskalierung (Scaling out – eine höhere maximale Cluster-Anzahl) bedient mehr gleichzeitige Benutzer. Hier die falsche Wahl zu treffen, ist ein häufiger und teurer Fehler.

Die Datenschicht ist ebenfalls wichtig: OPTIMIZE, VACUUM und Liquid Clustering reduzieren jeweils die für eine Abfrage erforderliche Rechenleistung, was sich bei Tausenden von BI-Abfragen pro Tag summiert.

Letztendlich sind die meisten Kostenprobleme eigentlich Abfrageprobleme. Ein fehlender Join-Schlüssel oder ein SELECT * auf eine breite Tabelle kostet gleich viel, egal wie das Warehouse konfiguriert ist – und die Zuordnung aus Säule 1 zeigt Ihnen, welche Abfragen und Dashboards Sie korrigieren müssen.

Wichtige Erkenntnisse

1. Verankern Sie Serverless und Zuordnung vom ersten Tag an in der Plattform. Nutzen Sie standardmäßig SQL Serverless-Warehouses für sofortigen Start, automatische Skalierung und keine Kosten im Leerlauf, und setzen Sie von Anfang an benutzerdefinierte Tags durch, denn nicht zugeordnete Nutzung ist unsichtbar, und unsichtbare Nutzung nimmt immer zu.

2. Planen Sie Budgets und Warnungen proaktiv auf mehreren Ebenen. Kombinieren Sie Budgets pro Team für die Eigenverantwortung mit einem kontoweiten Budget für Anomalien. Richten Sie Warnmeldungen basierend auf dem Verlauf (Pace) und nicht nur auf Schwellenwerten ein, damit Sie rechtzeitig von einer Überschreitung erfahren und reagieren können, bevor das Limit überschritten ist.

3. Machen Sie Ausgaben sichtbar und etablieren Sie ein Kostenbewusstsein.  Die nachhaltigsten Einsparungen entstehen durch Transparenz, nicht durch Einschränkungen. Platzieren Sie Kosten-Dashboards also dort, wo die Teams arbeiten. Wie RBI feststellte: Wenn Teams ihre eigenen Ausgaben sehen können, ändert sich das Verhalten ganz ohne Vorschriften.

Erste Schritte

Dies ist Ihr schnellster Weg für den Einstieg, um Ihre Rechnungen im Griff zu behalten, bevor die Kosten explodieren:

• Erstellen Sie Ihr erstes Budget in der Kontokonsole. 
• Ordnen Sie die Nutzung zu, indem Sie Ihr SQL-Warehouse und Ihre Abfragen taggen
• Überwachen Sie Kosten mit Systemtabellen, fragen Sie system.billing.usage ab, um warehouse-spezifische Erkenntnisse zu erhalten
• Größenanpassung und Skalierungsverhalten von SQL-Warehouses, verstehen Sie IWM und die Funktionsweise von Serverless
• Best Practices zur Kostenoptimierung, Warehouse-Größenanpassung, Photon und Delta Lake-Optimierung
• Vom Chaos zur Kontrolle: Eine Reise zur Kostenreife mit Databricks, das Crawl-Walk-Run-Framework für die FinOps-Reife

Sind Sie bereit, die Kontrolle über Ihre Cloud-Data-Warehouse-Kosten zu übernehmen? Richten Sie ein kostenloses Databricks-Testkonto ein, erstellen Sie Ihr erstes SQL Serverless-Warehouse und konfigurieren Sie ein Budget mit E-Mail-Warnmeldungen in der Kontokonsole. Das dauert nur fünf Minuten und kostet nichts.

Für einen tieferen Einblick in die Kostentransparenz lesen Sie die Dokumentation zu Abrechnungs-Systemtabellen und importieren Sie das vorgefertigte Nutzungs-Dashboard, um Ihre Ausgaben vom ersten Tag an zu überwachen.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag