SQL Warehouses (Databricks)

Ein SQL Warehouse ist eine von Databricks bereitgestellte Rechenumgebung (Compute-Cluster), die speziell für Auswertungen mit SQL (der Abfragesprache für Datenbanken) und für Business-Intelligence-Werkzeuge (BI, Reporting- und Dashboard-Software) auf dem Lakehouse (Databricks-Datenplattform) ausgelegt ist. Sie bündelt die schnelle Photon-Abfrage-Engine, feste Größenstufen (T-Shirt-Größen von 2X-Small bis 4X-Large) und einen automatischen Start bei Bedarf, sodass Reporting-Tools und interaktive Datenabfragen ohne den Aufbau eines allgemeinen Databricks-Clusters laufen.

Was SQL Warehouses sind und wie sie funktionieren

Ein SQL Warehouse stellt eine eigene Rechenumgebung für SQL-Abfragen bereit. Sie bedient einerseits die Databricks-eigene SQL-Oberfläche im Browser, andererseits externe Programme, die per SQL auf Daten zugreifen (SQL-Clients). Über die Standard-Datenbankschnittstellen JDBC (Java Database Connectivity) und ODBC (Open Database Connectivity) binden Reporting-Werkzeuge wie Power BI, Tableau oder Looker das Warehouse als Datenquelle an; in der Databricks-Oberfläche laufen ad hoc gestellte Abfragen, Dashboards und Warnmeldungen gegen dieselbe Rechenumgebung. Der Zugriff auf Tabellen und Sichten läuft über den zentralen Berechtigungsdienst Unity Catalog, sodass Zugriffsrechte, Zeilen- und Spalten-Sicherheit sowie die Herkunftsverfolgung (Lineage, also der Nachweis, aus welchen Quellen Daten stammen) einheitlich zu anderen Databricks-Auswertungen gelten.

Zu den Kernbestandteilen zählen die Photon-Engine als vektorisierte Ausführungsschicht, T-Shirt-Größen von 2X-Small bis 4X-Large für die Cluster-Größe, ein Auto-Stop bei Leerlauf sowie ein Multi-Cluster-Load-Balancing, das bei steigender Nutzerzahl zusätzliche Cluster startet und wieder abbaut. Query-Historie und Query-Profil geben Einblick in Laufzeiten, Wartezeiten und Ausführungspläne der einzelnen Abfragen.

SQL Warehouses existieren, weil allgemeine Databricks-Cluster (All-Purpose Compute) für Notebook-Interaktion und gemischte Sprachen gebaut sind. BI-typische Anforderungen wie viele parallele Sessions, kurze Startzeiten, stabile Latenz bei kleinen Abfragen und planbare Kosten pro Dashboard verlangen ein anderes Compute-Profil. SQL Warehouses sind dafür vorkonfiguriert und werden von Databricks als eigenständiger Compute-Typ behandelt, mit eigener DBU-Rate und eigenen Bedienoberflächen.

Databricks unterscheidet drei Klassen von SQL Warehouses. Classic SQL Warehouses laufen als VMs im Cloud-Konto des Kunden; Databricks steuert die Software, die Cloud-Infrastruktur wird separat abgerechnet. Pro SQL Warehouses erweitern den Funktionsumfang um Predictive I/O, Geospatial-Funktionen und Query-Föderation. Serverless SQL Warehouses stellen das Compute aus einem von Databricks verwalteten Pool bereit, starten in wenigen Sekunden, skalieren bis auf null herunter und enthalten die Infrastrukturkosten in der DBU-Rate.

Abgrenzung zu verwandten Compute-Typen und Konzepten

Das SQL Warehouse ist ein spezialisiertes Compute in Databricks und wird häufig mit benachbarten Konzepten verwechselt. Die folgende Übersicht zeigt die Unterschiede.

Zwischen All-Purpose Compute und SQL Warehouse liegt der wichtigste Unterschied im Nutzungsprofil. All-Purpose-Cluster tragen gemischte Entwicklungsarbeit; SQL Warehouses sind auf viele parallele SQL-Sessions mit kurzer Latenz optimiert und erzwingen Photon. Jobs Compute unterscheidet sich davon nochmal, weil es an einen konkreten Job gebunden ist und nach dessen Ende endet, während ein SQL Warehouse wartet und beim nächsten Query wieder Abfragen entgegennimmt.

Der Begriff Data Warehouse beschreibt eine Zielarchitektur aus modellierten Fakten- und Dimensionsdaten, Governance und einem Zugriffs-Layer für Analyse. Ein SQL Warehouse liefert das Compute für diese Architektur auf dem Lakehouse, ersetzt aber weder Datenmodell noch Governance. Snowflakes Virtual Warehouse ist architektonisch das nächstgelegene Analog; der Unterschied liegt im Speicher-Layer (Delta Lake und Unity Catalog gegenüber Snowflake-Storage), in der Engine (Photon gegenüber der Snowflake-Engine) und im Abrechnungsmodell (DBU gegenüber Snowflake-Credits).

Innerhalb der SQL Warehouses grenzt sich Serverless vom Classic-Modell durch die Verantwortung für die Infrastruktur ab. Classic-Warehouses starten VMs im Cloud-Konto des Kunden und brauchen Minuten bis zur Verfügbarkeit; Netzwerk und Compute-Policies bleiben unter Kundenkontrolle. Serverless-Warehouses starten in Sekunden aus dem Databricks-Pool und skalieren bis auf null herunter, wodurch Warmhalte-Kosten entfallen; die Infrastruktur liegt bei Databricks.

Typischer Einsatz

Ein Analyse-Team betreibt Power-BI-Dashboards im DirectQuery-Modus gegen ein Serverless SQL Warehouse der Größe 2X-Small mit Auto-Stop nach zehn Minuten Leerlauf und einem Multi-Cluster-Bereich von eins bis vier. Öffnen Nutzer morgens die Berichte, startet das Warehouse innerhalb weniger Sekunden; steigt die Anzahl paralleler Anfragen, aktiviert Databricks zusätzliche Cluster im Hintergrund. Nach Feierabend fährt das Warehouse automatisch herunter, es entstehen nur Kosten für die tatsächliche Laufzeit.

Ein alternatives Setup führt Ad-hoc-Analysen und ETL-Prüfabfragen über Databricks SQL auf einem Classic Pro SQL Warehouse der Größe Medium aus, das im Cloud-Konto des Kunden bleibt. Netzwerkanforderungen wie Private Link, kontrollierter Egress oder eigene Compliance-Policies lassen sich in diesem Modell direkt am Cloud-Konto durchsetzen; im Gegenzug fallen längere Startzeiten und getrennte Infrastruktur-Kosten an.