Databricks SQL Warehouses: Typen, Sizing und BI-Workloads
Welche Databricks SQL Warehouses zu Power BI, Genie und nativer BI passen – Serverless, Pro oder Classic, und wie Sizing und Auto-Stop Kosten steuern.
Die Kernaussagen auf einen Blick.
- Databricks bietet drei SQL-Warehouse-Typen für unterschiedliche BI- und Analyse-Workloads: Classic für Sonderfälle mit besonderen technischen oder regionalen Anforderungen, Pro für planbare Reporting-Lasten, Serverless für spontane Abfragen, viele Nutzer und Funktionen wie Genie oder AI/BI-Dashboards.
- Der passende Warehouse-Typ sollte je Workload gewählt werden. Diese Entscheidung beeinflusst die Kosten oft stärker als die reine Warehouse-Größe. Wichtige Einstellungen sind automatische Abschaltung, Skalierungsgrenzen, Tags und verbindliche Vorgaben.
- Ohne einheitliche Tags, Größenlimits und Auto-Stop entstehen schnell zu viele teure Warehouses. Die Kosten lassen sich dann nur schwer Teams und Anwendungen zuordnen. Zusätzliche Genie- und AI/BI-Warehouses können die Kosten deutlich erhöhen, wenn sie nicht getrennt geplant werden.
- Sinnvoll sind drei klar getrennte Warehouse-Klassen für spontane Analysen, regelmäßiges Reporting und KI-Funktionen, von Beginn an mit Kostenstellen, Größenlimits und automatischer Abschaltung.
Inhaltsverzeichnis
Ein SQL Warehouse reicht selten für alles
Die Databricks-SQL-Kosten steigen, und mehrere Warehouses bleiben über Nacht aktiv, obwohl niemand sie nutzt. Es ist unklar, welches Team welches Warehouse verwendet und welche Kosten dabei entstehen. Für einen Genie-Piloten wurde zusätzlich ein Serverless Warehouse eingerichtet; seitdem gibt es einen weiteren Kostenblock, dessen Kosten im Management-Review schwer erklärbar sind. Power BI sendet täglich viele kleine Abfragen an dasselbe Warehouse, und als erste Reaktion soll das Warehouse größer gemacht werden. Oft ist aber gar nicht klar, ob die Warehouse-Größe wirklich das Problem ist.
So entsteht mit der Zeit eine Warehouse-Landschaft ohne klares Konzept. Ein ursprünglich eingerichtetes Classic Warehouse wird einfach weiterverwendet, für Power BI kam später ein Pro Warehouse hinzu, mit Genie wurde zusätzlich Serverless eingeführt, und welcher Typ für welchen Workload gedacht ist, wurde nie verbindlich entschieden. Im Kostenreview müssen diese Fragen dann nachträglich geklärt werden.
Welcher Warehouse-Typ passt zu Reporting, Self-Service und KI-Funktionen? Welche zusätzlichen Kosten entstehen durch Genie und AI/BI-Dashboards? Werden langsame Power-BI-Berichte durch ein größeres Warehouse wirklich schneller? Wie lassen sich Kosten Teams und Anwendungen zuordnen und gleichzeitig begrenzen?
Die Wahl des Warehouse-Typs ist eine technische und wirtschaftliche Entscheidung. Die drei Varianten eignen sich für unterschiedliche Nutzungs- und Abfragemuster, und entscheidend sind Nutzungsfrequenz, gewünschte Antwortzeit und benötigte Funktionen.
Was ist ein Databricks SQL Warehouse?
Ein SQL Warehouse stellt die Rechenleistung für SQL-Abfragen, Dashboards und BI-Tools bereit. Alle Varianten nutzen grundsätzlich dieselbe SQL-Engine. Sie unterscheiden sich vor allem bei Bereitstellung, Startzeit, Funktionen und Kosten. Power BI, Tableau und andere Werkzeuge verbinden sich direkt mit einem Warehouse. Das Warehouse führt die Abfragen aus und liefert die Ergebnisse zurück. Auch Genie und AI/BI-Dashboards laufen über SQL Warehouses. Der Warehouse-Typ bestimmt unter anderem Startzeit, Skalierung, Kosten und verfügbare Funktionen.
Es gibt drei zentrale Warehouse-Typen. Classic läuft in der eigenen Cloud-Umgebung und bietet die meisten technischen Einstellmöglichkeiten: Teams haben mehr Kontrolle über Instanzgrößen und Compute-Einstellungen, Spark und Photon kann bei Bedarf zusätzlich aktiviert werden. Der Start dauert meist mehrere Minuten. Der Preis pro aktiver Stunde ist in der Regel am niedrigsten. Pro läuft ebenfalls in der eigenen Cloud-Umgebung. Photon und automatische Optimierungen sind bereits aktiv. Zusätzliche Optimierungen für SQL-Abfragen sind aktiv, preislich liegt Pro meist zwischen Classic und Serverless. Serverless: Bei Serverless betreibt Databricks die zugrunde liegende Infrastruktur. Das Warehouse startet meist innerhalb weniger Sekunden, Photon und Predictive IO sind ebenfalls aktiv. Der Preis pro laufender Stunde ist am höchsten. Vor dem Einsatz sollte geprüft werden, ob Serverless in der jeweiligen Region verfügbar ist. Die Microsoft-Learn-Übersicht zu SQL Warehouses listet die Typen und ihre Mechanik mit denselben drei Varianten; auf AWS und GCP gilt dieselbe Logik.
Die Engine selbst ist eine andere Geschichte: Wir ordnen sie im Überblick zu Databricks SQL ein und zeigen dort, wie der Engine-Layer über die Warehouses bedient wird. Wie diese Compute-Wahl in die übergeordnete Datenarchitektur passt, klären wir im Pillar zu Business Intelligence auf Databricks.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Classic, Pro und Serverless SQL Warehouse im Vergleich
Die Namen wirken zunächst wie reine Preisstufen. Tatsächlich unterscheiden sie sich vor allem bei Betrieb, Startzeit, Funktionen und passendem Nutzungsmuster.
| Eigenschaft | Classic | Pro | Serverless |
|---|---|---|---|
| Wo die Rechenleistung läuft | Im eigenen Cloud-Netzwerk | Im eigenen Cloud-Netzwerk | In Databricks-betriebener Infrastruktur |
| Typische Startzeit | ca. 3–5 min | ca. 3–5 min | unter 10 sek |
| Photon | optional | aktiv | aktiv |
| Automatische Optimierung gelesener Datenmengen | nicht | aktiv | aktiv |
| Unterstützung moderner verwalteter Funktionen | begrenzt | begrenzt | voll |
| Unterstützung für Genie und AI/BI | nicht | teilweise | Pflicht |
| Preis während der aktiven Laufzeit | niedrig | mittel | hoch |
| Risiko von Leerlaufkosten | hoch (langes Auto-Stop nötig) | hoch | klein (Auto-Stop greift schnell) |
| Typische Use Cases | Sonderfälle mit besonderen technischen Anforderungen | Regelmäßig laufende Berichte mit planbarer Nutzung | Spontane Abfragen, viele Nutzer und KI-Funktionen |
Dahinter stehen drei unterschiedliche Betriebsmodelle. Classic ist die älteste und am stärksten konfigurierbare Variante, im eigenen VPC betrieben; Instanzen und technische Einstellungen können detailliert festgelegt werden. Pro ergänzt Classic um aktivierte SQL-Optimierungen: Photon und Predictive IO sind als Standardausstattung hinterlegt, Abfragen werden stärker automatisch optimiert, bei regelmäßigen Reporting-Workloads können dadurch Laufzeiten sinken. Bei Serverless übernimmt Databricks Bereitstellung, Start und Skalierung; der Startvorgang fällt von Minuten auf Sekunden, die benötigte Kapazität wird im Hintergrund von Databricks vorgehalten, der Stundenpreis liegt höher.
Der höhere Stundenpreis bedeutet nicht automatisch, dass Serverless insgesamt teurer ist. Entscheidend ist, ob der Workload dazu passt. Ein Classic Warehouse kann wegen langer Start- und Abschaltzeiten deutlich länger aktiv bleiben als tatsächlich benötigt, ein Serverless Warehouse kann nur für die tatsächlich benötigten Minuten laufen und anschließend schnell wieder herunterfahren.
Welches Warehouse für Reporting, Self-Service, Genie und AI/BI?
Drei Fragen helfen bei der Auswahl. Ist die Nutzung dauerhaft hoch oder nur zu bestimmten Zeiten? Müssen Abfragen sofort starten oder sind einige Minuten Startzeit akzeptabel? Werden Genie, AI/BI-Dashboards oder bestimmte verwaltete Funktionen benötigt?
| Workload | Last-Profil | Empfehlung | Warum |
|---|---|---|---|
| Spontane SQL-Abfragen und Analysen | Unregelmäßige Nutzung mit langen Pausen | Serverless | Sehr kurze Startzeit, Auto-Stop greift schnell, wenig Kosten zwischen einzelnen Abfragen |
| Regelmäßige Power-BI-Datenaktualisierung | Hohe Last zu festen Aktualisierungszeiten | Pro | Gute Unterstützung für größere, planbare SQL-Abfragen, planbare Kapazität reicht aus |
| Power BI mit direkter Abfrage bei jeder Nutzerinteraktion | Viele parallele Abfragen während der Arbeitszeit | Serverless | Start-Latenz fällt weg, hohe Query-Frequenz wird ohne lange Startzeit verfügbar bedient |
| Genie und AI/BI-Dashboards | unregelmäßige Last, gebunden an KI-Funktionen | Serverless | Pflicht-Compute für Genie und AI/BI-Funktionen |
| Kleinere SQL-basierte Datenaufbereitungen | Ausführung zu festen Zeiten | Classic oder Pro | gezielte Konfiguration möglich, Auto-Stop konservativ |
| Sonderanforderungen an Netzwerk, Region oder Konfiguration | gegeben | Classic | volle technische Kontrolle, Spot-Instances möglich |
Als einfache Orientierung gilt: Bei vielen kurzen, unregelmäßigen Abfragen ist Serverless häufig wirtschaftlicher. Bei planbarer Reporting-Last ist Pro häufig die bessere Wahl. Classic bleibt sinnvoll, wenn besondere technische Einstellungen oder eine nicht unterstützte Region dies erfordern.
Problematisch wird es, wenn sehr unterschiedliche Workloads dasselbe Warehouse nutzen. Ein Warehouse, das nachts große Refreshs und tagsüber spontane Nutzerfragen bedienen soll, hat widersprüchliche Anforderungen. Es bleibt tagsüber häufig unnötig lange aktiv und ist gleichzeitig für große nächtliche Abfragen möglicherweise zu klein. Getrennte Warehouses sind in solchen Fällen meist einfacher zu steuern und auszuwerten.
SQL Warehouse Sizing: Größe oder Auto-Scaling?
Ein Warehouse kann auf zwei Arten mehr Leistung liefern: Der einzelne Cluster kann größer gewählt werden, oder mehrere Cluster können parallel Abfragen verarbeiten. Die Size geht von 2X-Small bis 4X-Large; eine größere Stufe erhöht Rechenleistung und Kosten deutlich. Zusätzliche Cluster helfen vor allem, wenn viele Abfragen gleichzeitig eintreffen: Sie werden hinzugefügt, wenn sich Abfragen in der Warteschlange sammeln, und wieder zurückgefahren, sobald die Last sinkt.
| Hebel | Verhalten | Wann eingesetzt |
|---|---|---|
| Größe des einzelnen Clusters | vertikal: mehr Rechenleistung und Speicher für einzelne große Abfragen | wenn eine einzelne Abfrage zu groß oder langsam ist |
| Anzahl paralleler Cluster (Auto-Scale) | horizontal: Verteilung vieler gleichzeitiger Abfragen | wenn viele Nutzer oder BI-Visualisierungen gleichzeitig zugreifen |
Ein häufiger Fehler: Bei vielen parallelen Power-BI-Abfragen wird oft zuerst die Warehouse-Größe erhöht, obwohl zusätzliche Cluster sinnvoller wären. In solchen Fällen kann eine begrenzte automatische Skalierung günstiger und wirksamer sein. Bei einer einzelnen großen Abfrage bringen zusätzliche Cluster dagegen wenig, da eine einzelne Abfrage nicht automatisch auf mehrere Warehouse-Cluster verteilt wird; hier sollte eher die Größe des einzelnen Clusters geprüft werden. Die Databricks-Doku zu Sizing und Scaling führt die Verteilungs-Logik im Detail.
In der Auslegung der BI-Strecke: Für viele parallele Nutzer sind oft mehrere kleinere Cluster sinnvoller. Für wenige große Abfragen ist häufig ein größerer einzelner Cluster sinnvoller. Beide Lastprofile auf demselben Warehouse zu mischen, kann Kosten erhöhen, ohne die Antwortzeiten zuverlässig zu verbessern.
SQL Warehouse Auto-Stop: Leerlaufkosten vermeiden
Ein aktives Warehouse verursacht auch dann Kosten, wenn gerade keine Abfrage ausgeführt wird. Auto-Stop ist deshalb eine der wichtigsten Kosteneinstellungen. Damit wird festgelegt, wie schnell ein ungenutztes Warehouse beendet wird. Die Standardwerte passen häufig nicht zum echten Nutzungsverhalten.
Drei Auto-Stop-Profile haben sich bewährt:
Spontane Analysen auf Serverless: nach wenigen Minuten Leerlauf abschalten. Da Serverless schnell wieder startet, ist eine kurze Abschaltzeit meist unproblematisch. Ein Idle-Timeout von 5 Minuten verursacht beim nächsten Klick meist wenig zusätzliche Wartezeit und reduziert die Kosten zwischen einzelnen Nutzeranfragen deutlich.
Regelmäßiges Power-BI-Reporting auf Pro: Auto-Stop an den Refresh-Rhythmus anpassen. Bei sehr kurzen Aktualisierungsintervallen lohnt sich ein dauerhaft aktives Warehouse eher. Bei längeren Pausen sollte es dagegen automatisch herunterfahren.
SQL-basierte Jobs: kurz nach Abschluss automatisch abschalten. Sobald der Job durch ist, fährt der Endpoint herunter; der nächste Lauf startet mit wenigen Minuten Startverzögerung später.
Drei Fehler treiben die DBU-Kosten schnell hoch:
- Sehr lange Auto-Stop-Zeiten bei unregelmäßiger Nutzung. Das Warehouse verursacht während längerer Pausen weiterhin Kosten.
- Dauerhaft aktives Serverless Warehouse ohne echte Dauerlast. Der höhere Serverless-Preis fällt dann rund um die Uhr an.
- Das Warehouse sofort vergrößern, ohne die Ursache zu prüfen. Jede größere Stufe erhöht die laufenden Kosten deutlich; häufig liegen langsame Antworten eher an Parallelität, Abfragen oder Datenmodell.
Die Kostenlogik lässt sich einfach zusammenfassen. Die Kosten pro Stunde hängen von Warehouse-Typ und Größe ab. Wie lange das Warehouse läuft und wie stark es skaliert, wird durch Abschaltung und Skalierung bestimmt. An beiden Hebeln zu drehen, bringt mehr als jede einzelne Sizing-Entscheidung.
SQL Warehouse Performance: Photon, Predictive IO und Result Cache
Drei Funktionen beeinflussen die Laufzeit vieler Abfragen deutlich.
Photon ist bei Pro und Serverless bereits aktiv und kann bei Classic zugeschaltet werden. Was die vectorized Engine dahinter ausmacht, definiert der Glossareintrag zu Photon. Besonders größere SQL-Abfragen mit Filtern, Joins und Aggregationen profitieren häufig; bei sehr kleinen oder sehr individuellen Abfragen ist der Nutzen meist geringer.
Predictive IO ist auf Pro und Serverless aktiv. Databricks versucht automatisch, nur die benötigten Datenbereiche zu lesen, unnötige Daten werden möglichst nicht verarbeitet. Das kann besonders bei Änderungen und gezielten Zugriffen auf große Tabellen helfen. Die Predictive-IO-Doku erklärt die Mechanik im Detail.
Result Cache. Der Result Cache wirkt auf Warehouse-Ebene. Wiederholte identische Abfragen können ein bereits berechnetes Ergebnis verwenden, die zugrunde liegenden Tabellen müssen dann nicht erneut vollständig verarbeitet werden. Wiederholte Dashboard-Abfragen können dadurch deutlich weniger Compute verbrauchen.
Zusammen reduzieren diese Funktionen den Druck, ein Warehouse sofort größer zu dimensionieren. Bevor ein Warehouse vergrößert wird, sollte geprüft werden, ob Optimierungen greifen und die Abfragen sinnvoll aufgebaut sind.
Serverless SQL Warehouses für Genie und AI/BI-Dashboards
Mit Genie können Fachanwender Datenfragen in natürlicher Sprache stellen; AI/BI-Dashboards nutzen ähnliche Plattformfunktionen. Für den vollständigen Funktionsumfang wird meist ein Serverless Warehouse benötigt. Das hat zwei Gründe.
Erstens braucht das Feature kurze Antwortzeiten. Bei Fragen in natürlicher Sprache erwarten Nutzer schnelle Antworten. Die kurze Startzeit von Serverless passt deshalb gut zu diesem Nutzungsmuster. Zweitens steht ein Teil der benötigten Funktionen nur auf Serverless vollständig zur Verfügung.
Die FinOps-Folge: Mit Genie entsteht ein zusätzlicher Serverless-Kostenblock. Wie hoch er ausfällt, hängt von Zahl und Häufigkeit der Nutzerfragen ab. Ein Genie-Rollout ohne eigenes Warehouse, saubere Tags und kurze Auto-Stop-Zeit ist schwer steuerbar. Drei Empfehlungen helfen beim Rollout:
- Eigene Serverless Warehouses für größere Fachbereiche oder klar getrennte Genie-Anwendungen, damit Kosten eindeutig zugeordnet werden können.
- Kurze Auto-Stop-Zeiten zwischen Nutzeranfragen, damit Pausen zwischen Fragen nicht abgerechnet werden.
- Feste Grenzen für Auto-Scaling, damit ein unerwartet stark genutzter Genie Space die Kosten nicht unbegrenzt steigen lässt.
Wir ordnen die Genie- und AI/BI-Workloads im Überblick zu Genie und im Überblick zu AI/BI-Dashboards ein; dort findet ihr die Details, wie die Compute-Anforderung im Detail zur Engine-Wahl zurückspielt.
Power BI auf Databricks SQL Warehouses: Import, DirectQuery und getrennte Warehouses
Power BI verursacht in vielen Unternehmen einen großen Teil der Databricks-SQL-Last. Entscheidend ist, ob Power BI Daten importiert oder live abfragt.
Import-Modus. Im Import-Modus lädt Power BI die Daten zu festgelegten Zeiten neu. Das Warehouse verarbeitet während des Refreshs mehrere größere Abfragen, danach wird es bis zum nächsten Refresh kaum genutzt. Für dieses planbare Lastprofil passt häufig Pro: Photon und Predictive IO beschleunigen die Aggregate, nach der Aktualisierung kann das Warehouse automatisch herunterfahren.
DirectQuery und Live-Connect. Bei DirectQuery kann fast jeder Filter und Klick eine neue Abfrage auslösen. Bei vielen Visualisierungen und Nutzern entsteht schnell eine hohe Zahl paralleler Abfragen. Serverless mit begrenztem Auto-Scaling ist dafür häufig besser geeignet: keine längere Wartezeit beim Start, zusätzliche Cluster können viele gleichzeitige Abfragen auffangen, wiederholte Abfragen können teilweise aus dem Cache beantwortet werden.
Eine klare Entscheidung vorab erspart spätere Sizing-Diskussionen. Import-Refreshs und DirectQuery sollten bei größerer Nutzung nicht über dasselbe Warehouse laufen; getrennte Warehouses lassen sich besser dimensionieren und kostenmäßig zuordnen. Wir vertiefen den Connector-Aspekt im Überblick zur Power-BI-Integration.
Wie steuert man Databricks SQL Warehouse Kosten?
Sobald mehrere Teams eigene Warehouses erstellen können, braucht es klare Regeln. Zwei Maßnahmen sind besonders wichtig.
Cluster-Policies für SQL Warehouses. Verbindliche Vorgaben legen fest, welche Varianten und Größen genutzt werden dürfen, welche maximale Größe erlaubt ist, wie weit Auto-Scaling gehen darf und wie schnell es sich bei Nichtnutzung abschaltet. Die Databricks-Doku zu SQL-Warehouse-Cluster-Policies zeigt die Felder und Beispielprofile. Für viele Unternehmen reichen drei Standardprofile:
- Spontane Analysen: Kleines Serverless Warehouse mit kurzer Abschaltzeit und begrenzter Skalierung.
- Regelmäßiges Reporting: Pro Warehouse mit moderater Größe und ausreichend Kapazität für parallele Berichte.
- Genie und AI/BI: Nur für Workloads vorgesehen, die diese Funktionen tatsächlich benötigen.
Einheitliche Tags für Kosten und Verantwortung. Pflichtangaben sollten zentral vorgegeben werden, statt sie bei jedem Warehouse manuell zu pflegen. Sinnvolle Pflichtangaben sind Kostenstelle, Team, Anwendung und Umgebung. Diese Informationen können anschließend in den Verbrauchsdaten ausgewertet werden und machen Kosten nachvollziehbar und zuordenbar. Damit lassen sich die täglichen Kosten jedes Warehouses separat auswerten.
Ohne Vorgaben entstehen schnell zu viele und zu große Warehouses. Ohne Tags bleibt unklar, welche Teams und Anwendungen die Kosten verursachen. Beides zusammen ist der Mindeststandard, an dem sich eine FinOps-Sicht für Warehouses überhaupt aufbauen lässt.
Was ein anderer Warehouse-Typ nicht löst
Das Warehouse stellt Compute bereit, es löst aber keine Probleme bei Berechtigungen, Datenmodell oder Abfragen.
- Die SQL-Engine selbst. Wie die SQL-Engine Anfragen plant, welche Optimierungen sie kennt und welche Sprach-Features sie unterstützt, klären wir im Überblick zu Databricks SQL. Die unterstützte SQL-Sprache bleibt grundsätzlich gleich.
- Die Governance über Unity Catalog. Welche Nutzer auf welche Daten zugreifen dürfen, wird unabhängig vom Warehouse in Unity Catalog festgelegt. Das regelt Unity Catalog. Ein schnelles Warehouse mit zu breiten Berechtigungen bleibt ein Sicherheitsproblem.
- Das Datenmodell und die Speicher-Schicht. Langsame Berichte entstehen häufig durch ungeeignete Tabellen, fehlende Vorberechnungen oder schlechte Abfragen. Ein größeres Warehouse kann das Problem kurzfristig verdecken, aber nicht dauerhaft lösen. Das Serverless-Modell als Dach ordnet, wo Compute-Layer und Engine ineinandergreifen.
Der Warehouse-Typ ist nur ein Teil der gesamten BI-Architektur. Seine Wirkung hängt davon ab, wie Datenmodell, Governance und Abfragen aufgebaut sind.
SQL-Warehouse-Landschaft konsolidieren: Sechs Schritte
In vielen Unternehmen wurden Warehouses über die Zeit für einzelne Projekte angelegt. Eine Bereinigung gelingt am besten in klaren Schritten.
Schritt 1: Alle vorhandenen Warehouses und ihre Kosten erfassen. Über die System Tables (system.billing.usage und system.compute.warehouses) eine Liste aller Warehouses ziehen, dabei tägliche Kosten, tatsächliche Nutzung und Leerlaufzeiten auswerten. Diese Liste ist die Grundlage für weitere Entscheidungen.
Schritt 2: Jedes Warehouse einem Hauptanwendungsfall zuordnen. Pro Warehouse die dominanten Workload-Familien benennen: zum Beispiel spontane Analysen, Berichtsläufe, direkte BI-Abfragen, KI-Funktionen oder SQL-Jobs. Wenn keine klare Zuordnung möglich ist, ist das Warehouse wahrscheinlich für mehrere unterschiedliche Lastprofile genutzt worden und sollte auf eine Trennung geprüft werden.
Schritt 3: Spontan genutzte Warehouses zuerst auf Serverless prüfen. Häufig besonders hohes Potenzial durch kurze Abschaltzeiten: kurze Abfragen, viele Idle-Phasen, hoher Idle-DBU-Anteil. Ein dauerhaft laufendes Classic Warehouse für Self-Service wird durch einen Serverless-Endpoint mit 5-Minuten-Auto-Stop ersetzt; die Kosten können deutlich sinken, müssen aber am tatsächlichen Nutzungsprofil gemessen werden.
Schritt 4: Planbare Berichtsläufe auf Pro prüfen. Power-BI-Import-Lasten können auf Pro Warehouses laufen mit Auto-Stop nach Abschluss der Datenaktualisierung. Photon und Predictive IO sind aktiv, die Aggregate werden schneller, die benötigte Warehouse-Größe kann dadurch geringer ausfallen.
Schritt 5: Genie und AI/BI auf getrennten Serverless Warehouses betreiben. KI-Features bekommen einen separaten Serverless-Endpoint mit klarem Tagging und Auto-Stop unter 5 Minuten. Die DBU-Position ist damit von Beginn an separat messbar und einem Verantwortlichen zuordenbar.
Schritt 6: Verbindliche Standardprofile einführen. Die drei Policy-Klassen (Self-Service, Reporting, KI) werden für neue Warehouses verbindlich vorgegeben. Bestehende Warehouses werden schrittweise auf die neuen Profile überführt.
Der Aufwand hängt stark von Zahl, Nutzung und Abhängigkeiten der Warehouses ab. Erste Kosteneffekte sind oft schon im nächsten Abrechnungszeitraum sichtbar. Änderungen sollten nachvollziehbar und in klaren Schritten erfolgen, damit ihre Wirkung messbar bleibt.
Grenzen von Databricks SQL Warehouses
Der Warehouse-Typ beeinflusst die Kosten stark. Für effizienten Betrieb reicht die Typwahl allein aber nicht aus.
Ein Warehouse ersetzt keine Datenmodellierung. Ein Bericht, der unnötig viele Spalten oder sehr große Datenmengen lädt, kann auch auf einem großen Warehouse langsam bleiben. Ein besseres Tabellenlayout und vorberechnete Ergebnisse können mehr bewirken als zusätzlicher Compute.
Der Warehouse-Typ legt keine Datenberechtigungen fest. Ein Serverless Warehouse ohne saubere Unity-Catalog-Berechtigungen bleibt ein Risiko, das nicht durch Compute-Einstellungen gelöst wird. Zugriffsrechte und Verantwortlichkeiten sollten vor dem Rollout feststehen.
Nicht jeder Warehouse-Typ ist in jeder Region verfügbar. Serverless ist nicht in allen Cloud-Regionen ausgerollt. Fehlt Serverless, müssen Classic oder Pro verwendet werden und einige KI-Funktionen können eingeschränkt sein. Die Verfügbarkeit gehört vor jeder Architektur-Entscheidung in einer neuen Region geprüft.
Auch Serverless verhindert hohe Kosten nicht automatisch, wenn Auto-Stop und Auto-Scaling falsch eingestellt sind. Databricks stellt die notwendigen Einstellungen bereit. Sie müssen jedoch verbindlich eingerichtet und regelmäßig überprüft werden.
Ein anderes Warehouse behebt kein schlecht aufgebautes Power-BI-Modell. Sehr komplexe Berichte, unnötig viele Visualisierungen und ineffiziente Berechnungen erzeugen Last, gegen die kein Compute-Hebel ankommt. Zuerst sollten Datenmodell, Abfragen und Bericht geprüft werden. Erst danach folgt die Compute-Größe.
Die Warehouse-Wahl ist nur ein Hebel in der BI-Architektur. Sie wirkt erst richtig, wenn Datenmodell, Governance und Betrieb ebenfalls sauber aufgebaut sind.
Sobald operative Maßnahmen daran hängen, gehört die Compute-Auslegung in einen reproduzierbaren Prozess: Verbindliche Vorgaben, Kostenmerkmale, regelmäßige Auswertungen und feste Reviews sollten gemeinsam aufgebaut werden und machen Verbrauch und Verantwortlichkeiten nachvollziehbar.
Fazit
Eine klare Warehouse-Strategie wird spätestens dann wichtig, wenn mehrere BI-Anwendungen und Teams Databricks SQL nutzen und die Compute-Kosten regelmäßig bewertet werden müssen. Die Wahl des passenden Warehouse-Typs beeinflusst Kosten und Antwortzeiten erheblich, oft stärker als die reine Wahl einer größeren oder kleineren Warehouse-Stufe; sie bestimmt Startzeit, Leerlaufkosten und den verfügbaren Funktionsumfang.
Besonders relevant ist eine solche Strategie bei:
- mehreren historisch gewachsenen Warehouses ohne klare Zuordnung
- Power BI DirectQuery mit vielen gleichzeitigen Nutzern
- Der Einführung von Genie und AI/BI neben bestehenden Reporting-Warehouses
- Warehouses für spontane Analysen, die auch ohne Nutzung dauerhaft laufen
Bei wenigen Nutzern und einem klaren Anwendungsfall kann zunächst ein einzelnes Warehouse ausreichen; mehrere Standardprofile werden erst sinnvoll, wenn Nutzung und Zahl der Teams wachsen. Einheitliche Tags, Größenlimits und Auto-Stop sollten trotzdem von Beginn an gesetzt werden.
Ein sinnvoller Standard ist: Nutzt für spontane Analysen ein kleines Serverless Warehouse mit kurzer automatischer Abschaltung, nutzt für planbare Power-BI-Berichte ein Pro Warehouse mit begrenzter automatischer Skalierung, betreibt Genie und AI/BI getrennt auf Serverless und ordnet Kosten eindeutig Fachbereichen zu und definiert früh Standardprofile und Pflichtangaben für Kostenstelle, Team, Anwendung und Umgebung. Classic sollte vor allem dort bleiben, wo besondere technische oder regionale Anforderungen es notwendig machen.
Lasst uns über den nächsten Schritt sprechen
Ob eure Warehouse-Landschaft zur BI-Strecke passt oder die DBU-Rechnung still auseinanderläuft, lässt sich oft schon in einem ersten Databricks Operations Review gut einordnen.
- welche eurer Endpoints die richtige Compute-Variante haben und welche aufgetrennt werden sollten
- welche Policies, Tags und Auto-Stop-Profile zu eurer BI-Strecke passen
- welcher Konsolidierungs-Pfad euch in 6–12 Wochen zu einer prüfbaren DBU-Rechnung führt
FAQ
Ein SQL Warehouse ist der Compute-Endpoint, der Databricks-SQL-Abfragen ausführt. Die SQL-Engine ist überall dieselbe; der Compute-Layer dahinter kommt in drei Varianten: Classic im Kunden-VPC mit voller Konfiguration, Pro mit Photon und Predictive IO als Standardausstattung, Serverless im Databricks-Backend mit Sub-10-Sekunden-Start. BI-Tools und KI-Features verbinden sich gegen einen Warehouse-Endpoint und übergeben SQL.
