Databricks SQL: BI, Dashboards und Analytics direkt im Lakehouse
Wie Databricks SQL Warehouses, Dashboards und Power BI-Anbindungen vereint, und wann native Lakehouse-BI gegenüber externen Tools sinnvoll ist.
Die Kernaussagen auf einen Blick.
- Databricks SQL verbindet eine SQL-Engine mit eigenen Funktionen für Analyse und Reporting. Dazu gehören SQL-Abfragen, Dashboards, Genie und Benachrichtigungen auf derselben Datenbasis.
- Unternehmen müssen sich nicht grundsätzlich zwischen Databricks SQL und Power BI entscheiden. Entscheidend ist, welche Aufgaben direkt in Databricks stattfinden und für welche weiterhin Power BI oder Tableau genutzt wird.
- Vor dem Rollout sind drei Punkte zu klären: Passende Größe und Art der benötigten Rechenleistung, zentrale Berechtigungen über Unity Catalog und eine verbindliche Stelle, an der jede Kennzahl definiert wird.
- Empfehlenswert ist, Databricks SQL als zentralen SQL-Zugang zu den Daten im Lakehouse zu verwenden, spontane Analysen, Genie und einfache Dashboards direkt in Databricks umzusetzen und Power BI und Tableau dort weiter zu nutzen, wo komplexe Berichte und bestehende BI-Modelle benötigt werden.
Inhaltsverzeichnis
Fünf BI-Wege, fünf Datenkopien
Die Frage nach Databricks SQL entsteht häufig in einer historisch gewachsenen BI-Landschaft. Bestehende Berichte laufen weiterhin auf einem klassischen Cloud Data Warehouse, Power BI greift je nach Bericht auf Snowflake, Synapse oder direkt auf Databricks zu. Fachliche Fragen werden dadurch in verschiedenen Werkzeugen und auf unterschiedlichen Datenständen beantwortet. Zusätzlich wurde Genie für einen ersten KI-Piloten freigeschaltet. Das Ergebnis sind mehrere Datenwege, getrennte Berechtigungen und teilweise unterschiedliche Kennzahlen.
Wir hören in diesen Situationen regelmäßig drei Sätze:
- „Es ist unklar, ob Databricks SQL das bisherige Warehouse ersetzen oder lediglich Power BI mit Daten versorgen soll."
- „Ein Teil der Berichte läuft auf Snowflake, ein anderer auf Databricks. Dadurch entstehen unterschiedliche Ergebnisse."
- „Genie nutzt Databricks SQL, während die bestehenden Berichte auf einer anderen Plattform bleiben. Damit entstehen parallele Strukturen."
Das eigentliche Problem ist die fehlende Entscheidung, welches Werkzeug welche Aufgabe übernimmt. Welche Analysen sollen direkt in Databricks stattfinden und welche weiterhin in Power BI oder Tableau? Ohne diese Abgrenzung kommen mit jeder neuen Anforderung weitere Datenwege hinzu, und Genie, Dashboards und eingebettete Berichte erhöhen dann die technische und organisatorische Komplexität.
Unsere These: Databricks SQL stellt nicht nur Rechenleistung für Power BI bereit, sondern bietet auch eigene Analyse- und Reportingfunktionen. Die zentrale Entscheidung betrifft die Aufgabenteilung zwischen Databricks und den bestehenden BI-Werkzeugen.
Was ist Databricks SQL?
Databricks SQL ist der Bereich der Plattform für SQL-Abfragen, Dashboards und BI-Anwendungen: Eine SQL-Engine, die weitgehend dem bekannten SQL-Standard folgt und durch Photon beschleunigt wird. Ergänzt wird sie durch einen SQL Editor, Dashboards, Genie, Benachrichtigungen und Verbindungen zu externen BI-Werkzeugen. Die dafür benötigte Rechenleistung wird über SQL Warehouses bereitgestellt (Klassen Classic, Pro und Serverless), die Daten liegen in Delta-Tabellen und werden über Unity Catalog verwaltet. Die Databricks-Dokumentation zu Databricks SQL fasst diese Bausteine als SQL-Analysen und Reporting direkt auf dem Lakehouse zusammen. Diese Beschreibung zeigt die technische Grundlage, lässt aber die eigenen BI-Funktionen von Databricks weitgehend außen vor.
Der praktische Nutzen: Databricks SQL ermöglicht ausreichend schnelle Abfragen für viele BI-Anwendungen direkt auf Lakehouse-Daten. Zusätzlich stehen eigene Oberflächen für SQL, Dashboards und Datenfragen bereit. Analysten können Abfragen direkt im SQL Editor erstellen und teilen, Fachanwender können über Genie Fragen in natürlicher Sprache stellen, Power BI kann weiterhin über den offiziellen Connector auf dieselben Daten zugreifen. Alle Zugriffswege können dieselben Tabellen und zentralen Berechtigungen verwenden.
Die klare Abgrenzung: Databricks SQL ersetzt nicht automatisch komplexe Power-BI- oder Tableau-Lösungen. Für umfangreiche DAX-Modelle, speziell gestaltete Berichte und Einbettungen bleiben klassische BI-Werkzeuge häufig besser geeignet. In diesem Fall stellt Databricks die Daten und Rechenleistung bereit, während das BI-Werkzeug die Benutzeroberfläche übernimmt.
Wie die einzelnen Bausteine zusammenspielen und welche Architektur-Entscheidungen vorher fallen, klären wir im Überblick zu Business Intelligence auf Databricks.
Vier Schichten: von der Visualisierung bis zur Governance.
SQL Editor, Dashboards und Genie liegen auf denselben SQL Warehouses und denselben Delta-Tabellen unter Unity Catalog.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Databricks SQL vs klassisches Data Warehouse: Architektur, Storage und Compute
Die SQL-Sprache von Databricks SQL ist nah am ANSI-Standard und damit für Nutzer anderer SQL-Plattformen weitgehend vertraut. SELECT, JOIN, Window Functions, CTEs, MERGE, Time-Travel-Abfragen über Delta-Tabellen, die Syntax folgt dem, was Databricks im SQL Language Reference als ANSI-konform dokumentiert. Bei einer Migration müssen vor allem Datentypen, einzelne Funktionen und Unterschiede im SQL-Dialekt angepasst werden, der grundlegende Aufbau der Abfragen kann meist übernommen werden.
Die wichtigsten Unterschiede liegen bei Speicherung, Rechenleistung, Performance und Berechtigungen:
- Speicherung: Die Daten liegen als Delta-Tabellen im Cloud-Speicher des Unternehmens (S3, ADLS, GCS). Das offene Tabellenformat erleichtert die Nutzung der Daten auch außerhalb einer einzelnen SQL-Engine. Delta ermöglicht verlässliche Änderungen, Zusammenführungen und den Zugriff auf frühere Tabellenstände.
- Trennung von Daten und Compute: Datenhaltung und Rechenleistung werden unabhängig voneinander betrieben. Für unterschiedliche Berichte und Analysen können getrennte Warehouses bei Bedarf gestartet und wieder beendet werden, die zugrunde liegenden Daten bleiben dabei am selben Speicherort.
- Engine: Photon beschleunigt viele SQL-Abfragen durch eine speziell für analytische Verarbeitung entwickelte Engine. Filter, Verknüpfungen und Aggregationen können dadurch deutlich schneller ausgeführt werden, dafür müssen weder Tabellen noch SQL-Abfragen grundlegend geändert werden.
- Berechtigungen: Tabellenrechte, Zeilenfilter und Maskierungen sensibler Spalten werden zentral in Unity Catalog verwaltet. Diese Regeln können für SQL Editor, Genie, Dashboards und Power BI gleichermaßen gelten.
Der zweite Unterschied: Databricks SQL bietet mehr als nur die Ausführung von Abfragen. Bei klassischen Warehouses liegen Reporting und Visualisierung häufig vollständig in externen BI-Werkzeugen. Databricks stellt zusätzlich eigene Funktionen für Abfragen, Dashboards und natürlichsprachliche Datenfragen bereit. Dadurch ist häufig unklar, welche Aufgaben Databricks selbst übernehmen und welche im BI-Werkzeug verbleiben sollen. Richtig eingesetzt können damit jedoch einzelne BI- und Analysewege zusammengeführt werden.
Reicht Photon für schnelle Abfragen?
Für die Abfrageleistung ist vor allem Photon entscheidend: Photon sorgt für Geschwindigkeit, während die SQL-Sprache für viele Nutzer vertraut bleibt. Photon ist Databricks' vektorisierte SQL-Engine, geschrieben in C++, die Daten in größeren Blöcken statt einzeln verarbeitet. Für BI-typische Operationen (Gruppierungen über viele unterschiedliche Werte, Verknüpfungen großer Bewegungsdaten mit Stammdaten, Aggregationen über Window Functions) bringt das deutlich kürzere Laufzeiten bei geeigneten Abfragen gegenüber der klassischen Spark-Ausführung.
Performance-relevant für BI-Workloads sind drei Punkte:
Photon automatisch aktiv
Bei jedem SQL-Warehouse-Start ist Photon bereits eingeschaltet. Bestehende Abfragen laufen ohne Anpassung schneller.
Delta-native Funktionen
Merge und Update auf historisierten Tabellen, Optimierung häufig gefilterter Spalten, Time Travel und vorberechnete Ergebnistabellen.
JSON und verschachtelte Typen
JSON-Pfade, MAP- und STRUCT-Typen sowie der Variant-Typ werden direkt verarbeitet, ohne vorheriges Umbauen in flache Spalten.
Photon löst jedoch nicht jedes Performanceproblem. Das Caching unterscheidet sich deutlich von Snowflake. Databricks SQL kennt einen Disk Cache und einen UI-seitigen Result Cache im SQL Editor. Bei häufig wiederholten Dashboard-Abfragen kann dieser Unterschied Auswirkungen auf Kosten und Dimensionierung haben und sollte deshalb bereits bei der Planung des Warehouses berücksichtigt werden.
Analysefunktionen in Databricks SQL
Bei reinen Performancevergleichen werden die eingebauten Analyse- und Betriebsfunktionen häufig übersehen. Im Workspace findet sich neben den Notebooks der SQL Editor. Im SQL Editor können Analysten Abfragen erstellen, Parameter verwenden, Ergebnisse teilen und einfache Visualisierungen bauen. Ausgeführte Abfragen werden mit Laufzeit und weiteren technischen Informationen protokolliert.
Drei Bausteine machen die Oberfläche für BI-Strecken brauchbar:
Query Profile
Zeigt, welche Schritte einer Abfrage Zeit kosten (Scans, Joins oder fehlender Arbeitsspeicher), ohne Wechsel in Spark-Oberflächen.
Versionierte Abfragen
SQL-Abfragen werden in Git gespeichert, geprüft und automatisiert bereitgestellt. Änderungen bleiben nachvollziehbar und reproduzierbar.
SQL Alerts
Prüfen regelmäßig, ob ein Kennwert einen Grenzwert überschreitet, und benachrichtigen per E-Mail oder Webhook.
Abfragen können außerdem direkt aus externen Anwendungen aufgerufen werden. Dafür ist nicht zwingend ein klassischer Datenbanktreiber notwendig. Das eignet sich beispielsweise für eingebettete Auswertungen, automatische Berichte und interne Datenservices.
Für den Zugriff aus externen Anwendungen, Pipelines oder Orchestrierungs-Tools stehen mehrere Zugriffswege auf dieselbe SQL-Engine bereit:
ODBC und JDBC
Für klassische BI- und Reportingwerkzeuge wie Power BI, Tableau, Looker oder MicroStrategy.
Python-Connector
Der offizielle databricks-sql-python-Connector für Skripte und Anwendungen außerhalb des Workspace.
REST-Schnittstelle
Für Anwendungen und Microservices: ideal für serverlose Anwendungen und eingebettete Analytics.
Orchestrierungs-Tools
Airflow, Prefect und dbt setzen SQL-Statements direkt gegen Databricks SQL Warehouses ab, ohne die Databricks-Oberfläche zu nutzen.
Native BI-Funktionen auf Databricks SQL
Zwei wichtige integrierte Funktionen sind AI/BI Dashboards und Genie. AI/BI Dashboards ermöglichen einfache Berichte direkt in Databricks. Sie bieten Visualisierungen, Filter und Freigaben auf Basis von SQL-Abfragen. Für komplexe DAX-Modelle, große Berichtswelten und aufwendig gestaltete Dashboards bleibt Power BI meist stärker. Einfache Vertriebs-, Betriebs- und Plattformberichte können jedoch direkt in Databricks umgesetzt werden.
Genie übersetzt Fragen in natürlicher Sprache in SQL-Abfragen. Genie arbeitet auf vorher ausgewählten und beschriebenen Tabellen, zeigt das Ergebnis und die generierte Query. Die Qualität hängt stark von der Vorbereitung des jeweiligen Genie Space ab: Benötigt werden verständliche Tabellen, dokumentierte Spalten und geprüfte Beispielfragen. In klar abgegrenzten Fachbereichen (Vertrieb, Marketing, Operations) können Nutzer dadurch einfacher eigene Fragen stellen. Genie erhält zunehmend Aufmerksamkeit, wodurch auch die zugrunde liegende SQL- und Kostenstrategie wichtiger wird.
Dashboards und Genie nutzen dieselben Daten, Berechtigungen und Abfrageprotokolle. Wird Genie ohne klare BI-Architektur eingeführt, entsteht leicht ein zusätzlicher, parallel betriebener Analyseweg.
Classic, Pro und Serverless im Überblick
Ein SQL Warehouse stellt die Rechenleistung für SQL-Abfragen bereit. Es gibt drei Klassen:
Serverless, Pro, Classic: drei Compute-Profile, eine SQL-Semantik.
Photon läuft in allen drei Klassen. Die Automatisierungs- und Performance-Tiefe unterscheidet sich vor allem beim Cold-Start und den zusätzlichen Engine-Funktionen.
Welche Klasse welche Workloads trägt, welche Trade-offs (Bereitstellung, geringere Startzeit gegen höhere Stundenkosten, Compliance-Anforderungen an Compute-Lokation) im Spiel sind und wie das Auto-Stop-Verhalten konkret aussieht, klären wir im Überblick zu SQL Warehouses auf Databricks, dort liegt das Compute-Detail, das für die FinOps- und Sizing-Entscheidung tragend ist.
Für die Engine-Sicht hier reicht ein Punkt: Warehouse-Typ, Größe und Laufzeit bestimmen einen großen Teil der BI-Kosten. Eine Bewertung von Databricks SQL muss deshalb immer auch das geplante Nutzungs- und Kostenprofil der Warehouses berücksichtigen.
Welche BI-Aufgaben wohin gehören
Die wichtigste Entscheidung für die BI-Architektur und der zentrale praktische Nutzen dieser Einordnung. Databricks SQL macht bestehende BI-Werkzeuge nicht automatisch überflüssig. Sie bleiben sinnvoll für komplexe Berichte, etablierte Datenmodelle und eine breite Nutzerbasis: Managementberichte mit umfangreichen Kennzahlen- und Berechnungsmodellen, eingebettete Berichte in Geschäftsanwendungen, exakt gestaltete Druck- und PDF-Berichte, Fachanwender, die bereits mit Power BI oder Tableau arbeiten. Verändert wird vor allem, woher diese Werkzeuge ihre Daten beziehen, und damit die Frage, welche Analysen künftig direkt in Databricks stattfinden können.
Eine pragmatische Aufteilung:
| Workload | Native Databricks-SQL-Oberfläche | Externes BI-Tool (Power BI/Tableau) |
|---|---|---|
| Spontane Analysen durch SQL-erfahrene Nutzer | SQL Editor, AI/BI Dashboards | Externes BI-Tool nur, wenn es organisatorisch bereits etabliert ist oder zusätzliche Funktionen benötigt werden |
| Datenfragen in natürlicher Sprache | Genie auf kuratierten Tabellen | – |
| Managementberichte mit komplexen Kennzahlen und Berechnungen | – | Power BI / Tableau über Connector |
| Berichte innerhalb von Kunden- oder Fachanwendungen | Einfache Datenabfragen und interne Anwendungen | Power BI Embedded / Tableau Embed für komplexe Fälle |
| Automatische Benachrichtigungen bei auffälligen Kennwerten | SQL Alerts | nur bei Anschluss an Geschäftsprozess-Tools |
| Technische und fachliche Datenanalyse durch das Datenteam | SQL Editor, Notebook | – |
| Pixel-perfektes Reporting mit Print/PDF | – | Power BI / Tableau |
| Fragen in natürlicher Sprache und einfache KI-Funktionen | Genie, AI Functions | – |
Das Muster: Spontane Analysen direkt auf Lakehouse-Daten können häufig direkt in Databricks umgesetzt werden. Wo komplexe Kennzahlenmodelle, eingebettete Berichte oder etablierte Nutzerprozesse bestehen, bleiben Power BI oder Tableau meist die passendere Benutzeroberfläche. Der Anschluss läuft in beiden Richtungen über den Databricks-Connector und Unity Catalog.
Wie der Power-BI-Connector konkret funktioniert (DirectQuery vs. Import, Workspace-Berechtigungen, Service-Principal-Setup), klären wir im Überblick zu Power BI mit Databricks. Welche Stärken AI/BI Dashboards für native Auswertungen mitbringt, klären wir im Überblick zu AI/BI Dashboards. Und wo Genie als Text-to-SQL trägt, und wo nicht, klären wir im Überblick zu Genie auf Databricks.
Unity Catalog Governance für Databricks SQL: Permissions, RLS und Column Masks
Unity Catalog sorgt dafür, dass unterschiedliche Zugriffswege dieselben Berechtigungen verwenden. Unity Catalog ist Databricks' zentrale Verwaltung von Catalogs, Schemas und Tabellen mit detaillierten Zugriffsrechten für Gruppen und Nutzer. SQL Editor, Dashboards, Genie und Power BI können auf dieselben zentralen Vorgaben zugreifen.
Die Bausteine, die für BI-Strecken zählen:
Berechtigungen
GRANT SELECT, USE CATALOG und MODIFY auf Datenbereichen, Schemas und Tabellen, vergeben über zentral verwaltete Unternehmensgruppen.
Zeilenfilter
Nutzer sehen nur die für sie vorgesehenen Datensätze: ein regionaler Vertriebsleiter beispielsweise nur seine eigenen Länder.
Spaltenmaskierungen
Schützen sensible Inhalte wie Namen oder Kontodaten pro Nutzergruppe, relevant für personenbezogene Daten in Dashboards.
Beschreibungen und Klassifikationen
Helfen Genie, Daten fachlich richtig einzuordnen und in natürlicher Sprache korrekt zu beantworten.
Der Punkt für die Konsolidierungs-Entscheidung: Bei getrennten Warehouse- und Lakehouse-Strukturen müssen Berechtigungen mehrfach gepflegt werden. Regeln aus einem bestehenden Data Warehouse gelten nicht automatisch in Databricks. Wer Databricks SQL als gemeinsamen Datenzugang verwendet, kann Berechtigungen und Audit stärker bündeln. Das erleichtert Sicherheitsprüfungen, Datenschutzanforderungen und die Freigabe neuer Datenprodukte.
Ist Databricks SQL ein Data-Warehouse-Ersatz?
Ob eine Ablösung sinnvoll ist, hängt von Daten, Workloads und bestehenden Verträgen ab. Databricks SQL ersetzt ein klassisches Warehouse dort, wo Daten ohnehin im Lakehouse landen, BI-Workloads die SQL-Latenz von Photon vertragen und die Governance-Vereinheitlichung der eigentliche Gewinn ist. Databricks SQL ergänzt das Warehouse dort, wo bestehende Modelle, eingebettete Tool-Anbindungen oder vertragliche Bindungen einen vollständigen Wechsel verteuern.
Vier Fragen helfen bei der Bewertung:
Datenfluss
Werden die Daten bereits zentral in Databricks aufbereitet, oder laufen dieselben Daten doppelt in mehrere Plattformen?
Workload
Planbare Reporting- und Analyseabfragen sind einfache Kandidaten. Transaktionsähnliche Abfragen mit Sub-Sekunden-SLA gehören in einen realistischen Lasttest.
Semantik
Kennzahlen, die ausschließlich in Power BI oder Tableau definiert sind, müssen bei einer Ablösung neu aufgebaut werden.
Vertrag und Lizenz
Laufende Verträge und bestehende Lizenzmodelle bestimmen häufig den möglichen Zeitpunkt einer Umstellung.
In vielen Fällen ist ein schrittweises Vorgehen sinnvoll: Neue Berichte und Datenprodukte können direkt auf Databricks aufgebaut werden, vorhandene Berichte werden nach Nutzen, Aufwand und technischer Eignung einzeln geprüft. Ohne klare Zielarchitektur bleiben alte und neue Plattformen dauerhaft parallel bestehen.
Was Databricks SQL nicht übernimmt
Databricks SQL stellt Abfragen, einfache BI-Funktionen und zentrale Datenberechtigungen bereit. Komplexe DAX-Modelle, Hierarchien und Berichtlogik bleiben weiterhin Aufgabe des BI-Teams. Databricks kann nur das zuverlässig bereitstellen, was im Datenmodell eindeutig definiert wurde. Kennzahlen, die nur in Power BI existieren, können von Genie und AI/BI Dashboards nicht automatisch wiederverwendet werden.
Drei Konsequenzen für die Plattform-Entscheidung:
Kennzahl nur einmal definieren
Die Berechnung gehört entweder zentral nach Databricks oder bewusst ins BI-Modell, nie beides parallel, sonst weichen die Ergebnisse mit der Zeit auseinander.
Stammdatenmanagement bleibt separat
Die Pflege von Kunden, Produkten, Schlüsseln und fachlichen Hierarchien löst Databricks SQL nicht. Es liefert nur die Plattform, auf der MDM-Lösungen aufsetzen.
Eine verbindliche Quelle pro Kennzahl
Unterschiedliche Zahlen entstehen nicht durch die SQL-Engine, sondern durch uneinheitliche fachliche Definitionen ohne festgelegte Quelle.
Was kostet Databricks SQL?
Die tatsächlichen Kosten hängen stark vom jeweiligen Nutzungsprofil ab. Databricks berechnet die aktive Rechenleistung über Verbrauchseinheiten, der DBU-Preis variiert nach Compute-Klasse (Classic, Pro, Serverless) und Cloud-Provider. Die Databricks-Pricing-Seite zu SQL Warehouses listet die aktuellen Sätze. Für eine belastbare Kostenschätzung müssen Region, Vertrag, Warehouse-Typ und Nutzung berücksichtigt werden.
Drei Einstellungen beeinflussen die Kosten besonders stark:
Auto-Stop
Voreingestellte Abschaltzeiten sind häufig länger als nötig. Dadurch entstehen Kosten, obwohl keine Abfragen laufen.
Serverless
Höherer Stundenpreis, aber Start in Sekunden statt Minuten und Auto-Termination bis auf eine Minute, bei unregelmäßiger Nutzung oft trotzdem günstiger.
Caching
Wiederholte identische Queries laufen aus dem Cache. Wird der Cache-Effekt nicht berücksichtigt, wird das Warehouse unnötig groß dimensioniert.
Der größte Kosteneffekt entsteht häufig durch eine klare Trennung der Workloads: Weniger doppelte Daten- und Reportingwege, getrennte Warehouses für unterschiedliche Nutzungsarten, Abschaltzeiten, die zum tatsächlichen Nutzungsverhalten passen. Diese Maßnahmen sparen häufig mehr als eine reine Preisverhandlung.
Grenzen von Databricks SQL
Databricks SQL kann viele BI-Workloads abdecken, löst aber nicht jedes Architektur- und Performanceproblem. Eine ehrliche Bewertung des Stacks zeigt fünf Punkte, an denen die Engine an Grenzen läuft:
Caching anders als bei Snowflake
Photon und Disk Cache leisten viel, aber identische Abfragen werden nicht in jedem Fall ohne erneuten Compute beantwortet, relevant für Lasttests und Kostenplanung.
Begrenzte Concurrency pro Warehouse
Sehr viele gleichzeitig aktive Berichtsnutzer benötigen passende Skalierung oder getrennte Warehouses, sonst entstehen Wartezeiten.
Power-BI-Berechnungsmodelle nicht automatisch übernommen
Eine Ablösung oder Vereinheitlichung erfordert fachliche und technische Überarbeitung, keine automatische vollständige Migration.
Genie braucht vorbereitete Daten
Unklare Tabellen, fehlende Beziehungen und uneinheitliche Kennzahlen führen zu unzuverlässigen Antworten.
Compute-Standort bei Serverless
Serverless läuft in einer von Databricks verwalteten Umgebung. Bei strengen Netzwerk- oder Datenresidenzanforderungen muss das vorab geprüft werden.
Die Plattform wird besser: Photon-Erweiterungen, Materialized Views, Predictive I/O auf Pro-Warehouses, Serverless-Verfügbarkeit in mehr Regionen. Die Architektur sollte auf aktuell verfügbaren und vertraglich zugesicherten Funktionen basieren, nicht auf angekündigten Erweiterungen.
Und es bleibt eine Plattformfrage auf Architektur-Ebene, jenseits der reinen Tool-Wahl. Die Einführung ersetzt keine BI-Strategie, keine Kennzahlverantwortung und kein geregeltes Reporting. Es bietet jedoch eine gemeinsame technische Grundlage für SQL, Dashboards, Genie und externe BI-Werkzeuge.
Fazit
Databricks SQL verbindet schnelle SQL-Abfragen mit eigenen Funktionen für Analyse und Reporting.
Photon ermöglicht bei geeigneten Workloads ausreichend schnelle Abfragen für BI, dadurch können viele Berichte direkt auf den Lakehouse-Daten arbeiten. SQL Editor, Dashboards, Genie und Alerts ermöglichen Analysen direkt in Databricks. Databricks SQL ist damit nicht nur eine Datenquelle für externe BI-Werkzeuge. Die wichtigste Entscheidung ist die klare Verteilung der Aufgaben: Spontane Analysen, Genie, einfache Dashboards und Alerts können direkt in Databricks stattfinden. Komplexe Managementberichte, eingebettete Berichte und bestehende semantische Modelle können weiterhin in Power BI oder Tableau bleiben. Berechtigungen sollten unabhängig vom verwendeten Frontend zentral über Unity Catalog geregelt werden, Warehouse-Typ, Größe und Abschaltzeit sollten an den jeweiligen Anwendungsfall angepasst werden.
Empfehlenswert ist folgender Ansatz: Databricks SQL als gemeinsamen SQL-Zugang für Lakehouse-Daten etablieren, spontane Analysen, Genie und einfache AI/BI-Dashboards direkt in Databricks umsetzen, Power BI und Tableau für komplexe Berichte und bestehende Nutzergruppen weiterverwenden, zentrale Kennzahlen und Datenprodukte möglichst einmal verbindlich definieren und über Unity Catalog bereitstellen. So lassen sich doppelte Datenwege und widersprüchliche Kennzahlen schrittweise reduzieren, Kosten und Nutzung werden dadurch besser messbar und steuerbar.
FAQ
Databricks SQL ist die SQL-Strecke der Databricks-Plattform: eine ANSI-SQL-kompatible Engine auf Photon, gekoppelt mit einem Produkt-Frontend aus SQL Editor, AI/BI Dashboards, Genie und Alerts. Compute läuft auf SQL Warehouses (Classic, Pro, Serverless), Daten liegen als Delta-Tabellen unter Unity Catalog. Databricks SQL ist damit Engine plus Produkt und reicht weiter als ein reiner Compute-Layer hinter externen BI-Tools.
