Databricks SQL Warehouses: Typen, Sizing und BI-Workloads
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.
Classic, Pro, Serverless: drei Compute-Profile im direkten Vergleich.
Startzeit, Feature-Umfang und Preis pro DBU unterscheiden sich deutlich zwischen den drei Klassen. Die volle Sizing- und Kostenlogik dazu folgt im nächsten Abschnitt.
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.
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.
Cluster-Größe erhöhen, wenn
- Eine einzelne Abfrage zu groß oder zu langsam ist
- Mehr Rechenleistung oder Speicher für eine komplexe Query nötig ist
- Die Last überwiegend aus wenigen, aber großen Abfragen besteht
Auto-Scaling (mehr Cluster) nutzen, wenn
- Viele Nutzer oder BI-Visualisierungen gleichzeitig zugreifen
- Sich Abfragen in der Warteschlange sammeln
- Parallele Power-BI-Abfragen die Last treiben, nicht einzelne große Queries
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.
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:
Serverless: kurzer Timeout
Nach wenigen Minuten Leerlauf abschalten. Serverless startet schnell wieder: ein Idle-Timeout von 5 Minuten kostet beim nächsten Klick kaum zusätzliche Wartezeit.
Pro-Reporting: an Refresh-Rhythmus koppeln
Bei sehr kurzen Aktualisierungsintervallen lohnt sich ein dauerhaft aktives Warehouse eher. Bei längeren Pausen sollte es automatisch herunterfahren.
SQL-Jobs: sofort nach Abschluss stoppen
Der Endpoint fährt direkt nach Jobende herunter, der nächste Lauf startet mit wenigen Minuten Verzögerung neu.
Drei Fehler treiben die DBU-Kosten schnell hoch:
Sehr lange Auto-Stop-Zeiten
Bei unregelmäßiger Nutzung verursacht das Warehouse während längerer Pausen weiterhin Kosten.
Dauerhaft aktives Serverless ohne Dauerlast
Der höhere Serverless-Preis fällt dann rund um die Uhr an, obwohl keine echte Dauerlast vorliegt.
Warehouse sofort vergrößern
Ohne Ursachenprüfung erhöht jede größere Stufe 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.
Photon, Predictive IO und Result Cache
Drei Funktionen beeinflussen die Laufzeit vieler Abfragen deutlich.
Der Photon-Überblick zeigt, welche Workloads über die vectorized Engine echte Verkürzung erzielen und welche keinen Effekt sehen. Die Predictive-IO-Doku erklärt die Mechanik im Detail.
Photon
Bei Pro und Serverless aktiv, bei Classic zuschaltbar. Größere SQL-Abfragen mit Filtern, Joins und Aggregationen profitieren am stärksten; bei sehr kleinen oder individuellen Abfragen ist der Nutzen geringer.
Predictive IO
Aktiv auf Pro und Serverless. Liest automatisch nur die benötigten Datenbereiche, hilft besonders bei Änderungen und gezielten Zugriffen auf große Tabellen.
Result Cache
Wirkt auf Warehouse-Ebene. Wiederholte identische Abfragen nutzen ein bereits berechnetes Ergebnis; wiederholte Dashboard-Abfragen verbrauchen dadurch deutlich weniger Compute.
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 Warehouses pro Fachbereich
Größere Fachbereiche oder klar getrennte Genie-Anwendungen bekommen eigene Serverless-Endpoints, damit Kosten eindeutig zugeordnet werden können.
Kurze Auto-Stop-Zeiten
Kurze Abschaltzeiten zwischen Nutzeranfragen sorgen dafür, dass Pausen zwischen Fragen nicht abgerechnet werden.
Feste Grenzen für Auto-Scaling
Feste Skalierungsgrenzen verhindern, dass ein unerwartet stark genutzter Genie Space die Kosten 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.
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: Pro Warehouse
- Power BI lädt Daten zu festgelegten Zeiten neu
- Wenige größere Refresh-Abfragen statt vieler kleiner Anfragen
- Warehouse kann nach der Aktualisierung automatisch herunterfahren
- Photon und Predictive IO beschleunigen die Aggregate
DirectQuery / Live-Connect: Serverless Warehouse
- Fast jeder Filter und Klick löst eine neue Abfrage aus
- Viele Visualisierungen und Nutzer erzeugen viele parallele Abfragen
- Keine Wartezeit durch Cold-Start beim Start nötig
- Zusätzliche Cluster fangen parallele Last über Auto-Scaling auf
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.
Sechs Schritte
In vielen Unternehmen wurden Warehouses über die Zeit für einzelne Projekte angelegt. Eine Bereinigung gelingt am besten in klaren Schritten. Grundlage ist eine Liste aller Warehouses aus den System Tables (system.billing.usage und system.compute.warehouses).
Alle vorhandenen Warehouses und ihre Kosten erfassen
Aus den System Tables eine Liste aller Warehouses ziehen, dabei tägliche Kosten, tatsächliche Nutzung und Leerlaufzeiten auswerten. Diese Liste ist die Grundlage für weitere Entscheidungen.
Jedes Warehouse einem Hauptanwendungsfall zuordnen
Pro Warehouse die dominanten Workload-Familien benennen: spontane Analysen, Berichtsläufe, direkte BI-Abfragen, KI-Funktionen oder SQL-Jobs. Ist keine klare Zuordnung möglich, wird das Warehouse wahrscheinlich für mehrere Lastprofile genutzt und sollte auf eine Trennung geprüft werden.
Spontan genutzte Warehouses zuerst auf Serverless prüfen
Besonders hohes Potenzial durch kurze Abschaltzeiten bei kurzen Abfragen, vielen Idle-Phasen und hohem 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.
Planbare Berichtsläufe auf Pro prüfen
Power-BI-Import-Lasten laufen auf Pro Warehouses 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.
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.
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.
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 bewirken oft mehr als zusätzlicher Compute.
Keine Datenberechtigungen
Der Warehouse-Typ legt keine Zugriffsrechte fest. Ein Serverless Warehouse ohne saubere Unity-Catalog-Berechtigungen bleibt ein Risiko, das Compute-Einstellungen nicht lösen.
Nicht überall verfügbar
Serverless ist nicht in jeder Cloud-Region ausgerollt. Fehlt Serverless, müssen Classic oder Pro verwendet werden, und einige KI-Funktionen können eingeschränkt sein.
Kein Kostenschutz ohne Konfiguration
Auch Serverless verhindert hohe Kosten nicht automatisch, wenn Auto-Stop und Auto-Scaling falsch eingestellt sind. Die Einstellungen müssen verbindlich eingerichtet und regelmäßig überprüft werden.
Kein Fix für ein schlechtes Power-BI-Modell
Sehr komplexe Berichte, unnötig viele Visualisierungen und ineffiziente Berechnungen erzeugen Last, gegen die kein Compute-Hebel ankommt. Zuerst gehören Datenmodell, Abfragen und Bericht geprüft, erst danach 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.
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.
