Databricks und Power BI verbinden: Vier Entscheidungen für stabiles Reporting
Die Kernaussagen auf einen Blick.
- Damit Power BI auf Databricks zuverlässig läuft, müssen vier Entscheidungen sauber getroffen werden: Connector, Zugriffsmodus, SQL Warehouse und der Ort der Kennzahlenlogik.
- Der offizielle Databricks-Connector unterstützt die zentrale Anmeldung über Microsoft Entra ID und kann Unity-Catalog-Berechtigungen bis in Power BI weiterreichen; eine allgemeine ODBC-Verbindung kann das meist nur eingeschränkt.
- DirectQuery passt zu großen oder häufig aktualisierten Datenbeständen, Import ist oft schneller und günstiger, wenn ein geplanter Refresh ausreicht; Composite-Modelle verbinden schnelle importierte Kennzahlen mit aktuellen Detaildaten.
- Empfehlenswert ist: Den offiziellen Connector mit zentraler Anmeldung verwenden, den Zugriffsmodus je Bericht auswählen, planbare Reporting-Lasten auf einem Pro Warehouse betreiben und jede Kennzahl genau an einer Stelle verbindlich definieren.
Inhaltsverzeichnis
Power BI auf Databricks kann teuer und langsam werden
Ein Power-BI-Dashboard öffnet sich langsam und reagiert auch beim Filtern nur verzögert. Gleichzeitig steigen die Kosten des SQL Warehouses stärker als geplant. Zusätzlich zeigt Power BI für eine wichtige Kennzahl einen anderen Wert als Databricks SQL. Die Ursache kann im Warehouse, im Verbindungsmodus oder in einer anders definierten Kennzahl liegen.
Solche Probleme entstehen häufig, wenn die Anbindung schrittweise gewachsen ist, aber nie bewusst geplant wurde. Die erste Verbindung wurde im Rahmen eines Piloten eingerichtet und später unverändert übernommen, die Zugangsdaten wurden direkt im Power-BI-Dataset hinterlegt, Import oder DirectQuery wurden einmal ausgewählt, aber später nicht mehr anhand der tatsächlichen Nutzung überprüft. Mit Microsoft Fabric und Direct Lake kommt zudem eine weitere Architekturvariante hinzu, die neu bewertet werden muss. Die Verbindung wurde als technische Einrichtung behandelt, nicht als dauerhafte Architekturentscheidung.
Welche Verbindung sollte für produktive Power-BI-Berichte der Standard sein, und welche Vorteile bietet der offizielle Databricks-Connector gegenüber einer allgemeinen ODBC-Verbindung? Wann sind Import, DirectQuery oder ein gemischtes Modell sinnvoll? Welches SQL Warehouse liefert genug Leistung, ohne im Leerlauf unnötig Kosten zu erzeugen? Wo sollten Kennzahlen definiert werden: direkt im Power-BI-Modell oder zentral in Databricks, damit auch andere Anwendungen dieselbe Berechnung nutzen können?
Eine verlässliche Verbindung zwischen Power BI und Databricks beruht auf vier aufeinander abgestimmten Entscheidungen: Connector-Wahl, Verbindungs-Modus, Warehouse-Typ und Semantik-Aufteilung. Wer diese Entscheidungen bewusst trifft, kann Antwortzeiten, Kosten und Berechtigungen deutlich besser steuern, auch Datenzugriffe und Schutzregeln lassen sich bis in den Bericht durchgängig anwenden. Ohne klare Standards entstehen immer wieder dieselben Diskussionen über größere Warehouses, widersprüchliche Kennzahlen und provisorische Anmeldelösungen.
Die vier wichtigsten Entscheidungen
Die Anbindung umfasst den ganzen Weg von der Databricks-Tabelle bis zum Power-BI-Bericht. Dabei geht es um Anmeldung, Abfragen, Datenübertragung und Kennzahlenlogik. Vier Entscheidungen bestimmen, ob dieser Weg schnell, sicher und wartbar bleibt.
| Entscheidung | Frage | Auswirkung |
|---|---|---|
| Verbindung | Offizieller Databricks-Connector oder ODBC/JDBC | Leistung, zentrale Anmeldung und Übernahme von Datenberechtigungen |
| Art des Datenzugriffs | Daten importieren, live abfragen oder beide Ansätze kombinieren | Antwortzeit, Aktualität und Databricks-Kosten |
| SQL-Warehouse-Variante | Pro, Serverless, Classic | Kosten, Startzeit und verfügbare Funktionen |
| Ort der Kennzahlberechnung | Kennzahlen im Power-BI-Modell oder zentral in Databricks definieren | einheitliche Kennzahlen und weniger Pflegeaufwand |
Databricks SQL Warehouses stellen die Rechenleistung für die Abfragen bereit. Zusätzliche Optimierungen können Abfragen beschleunigen und unnötiges Lesen großer Datenmengen vermeiden. In Power BI werden Tabellen, Beziehungen und Kennzahlen für die Berichte aufgebaut. Der Connector überträgt die Abfragen und bestimmt, mit welcher Identität Power BI auf Databricks zugreift. Die Databricks-Doku zu Power BI führt die Connector-Mechanik und die Verbindungs-Optionen im Überblick.
Wie die Engine darunter funktioniert und welche Last sie trägt, ordnen wir im Überblick zu Databricks SQL ein. Wo die Anbindung in der gesamten BI-Strecke sitzt, zeigen wir im Überblick 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.
Welcher Connector für Power BI?
Der Connector ist die technische Verbindung zwischen Power BI und dem Databricks SQL Warehouse. Dafür gibt es drei Wege.
Offizieller Databricks-Connector
Standard für neue produktive Berichte. Gibt Filter und Berechnungen an Databricks weiter, unterstützt zentrale Anmeldung mit dem Microsoft-Unternehmenskonto und reicht nutzerabhängige Datenrechte bis nach Power BI durch.
ODBC- oder JDBC-Treiber
Funktioniert, gibt aber nicht alle Verarbeitungsschritte zuverlässig an Databricks weiter. Unity-Catalog-Berechtigungen können verloren gehen, zentrale Anmeldung ist aufwendiger. Sollte eine begründete Ausnahme bleiben.
Drittanbieter-Connectoren
Sinnvoll bei besonderen Anforderungen wie eigenen Caches oder speziellen Echtzeitverbindungen. Für die meisten Berichte bleibt der offizielle Connector die einfachere Wahl.
Die Unterschiede werden im Betrieb sichtbar:
| Eigenschaft | Native-Connector | ODBC/JDBC |
|---|---|---|
| Abfragen werden weitgehend in Databricks ausgeführt | vollständig | eingeschränkt |
| Übernahme nutzerabhängiger Datenfilter | über OAuth | nicht garantiert |
| Anmeldung mit dem bestehenden Unternehmenskonto | nativ | Workaround |
| Aggregations-Tabellen / Composite | unterstützt | begrenzt |
| Aktualisierung gemeinsam mit Power BI | ja | manuell |
| Typischer Use Case | Default für Power BI | Spezial-Werkzeuge, Legacy |
Der offizielle Connector sollte für alle neuen produktiven Berichte verwendet werden. ODBC bleibt auf begründete technische Ausnahmen beschränkt.
Wie greift Power BI sicher auf Databricks zu?
Die Anmeldung entscheidet, mit welchen Rechten Power BI auf Databricks zugreift. Davon hängen sichtbare Daten, Row-Level Security und Auditierbarkeit ab. Drei Pfade sind möglich.
OAuth über Microsoft Entra ID als Standard. Anmeldung mit dem bestehenden Microsoft-Unternehmenskonto. Databricks erkennt, welcher Nutzer den Bericht öffnet; dadurch gelten die Berechtigungen dieses Nutzers oder seiner Gruppe, Row-Level Security und Column Masks können dadurch auch im Power-BI-Bericht wirken. Im Power BI Service muss dafür eine passende Cloud-Verbindung eingerichtet werden. Die Databricks-Doku zur Power-BI-SSO-Integration zeigt die Konfiguration im Detail.
OAuth über Microsoft Entra ID
Standard-Pfad. Databricks erkennt den angemeldeten Power-BI-Nutzer, RLS und Column Masks aus Unity Catalog wirken direkt im Bericht.
Service Principal
Technisches Konto für geplante Dataset-Aktualisierungen ohne angemeldeten Nutzer. Sollte nur die für den Refresh wirklich nötigen Rechte erhalten.
Personal Access Token (PAT)
Persönlicher Zugangsschlüssel im Dataset. Databricks erkennt den tatsächlichen Berichtsnutzer nicht mehr, keine dauerhafte Lösung für produktive Berichte.
Geteiltes Personal-Access-Token
Ein Token als gemeinsame Anmeldung für alle Berichtsnutzer. Alle sehen dieselben Daten, Zeilenfilter und Column Masks aus Unity Catalog laufen ins Leere.
Zu weitreichendes Refresh-Konto
Ein technisches Konto darf mehr lesen, als der Bericht braucht. Bei einer Kompromittierung ist der Schadensradius entsprechend groß.
Manuelle Token-Pflege
Wer welches Token wann erneuert hat, lässt sich im Auditfall nicht sauber rekonstruieren.
Import, DirectQuery oder Composite?
Der Modus entscheidet, ob Power BI Daten vorlädt oder bei jeder Interaktion neu aus Databricks abfragt. In der Praxis sind vier Modi relevant.
Import. Power BI lädt die Daten zu festgelegten Zeiten in den internen VertiPaq-Speicher. Filter und Visualisierungen reagieren danach sehr schnell, weil nicht jede Interaktion eine Databricks-Abfrage auslöst. Die Aktualität ist auf das Refresh-Intervall beschränkt, Databricks wird vor allem während des Refreshs belastet. Das ist meist der Standard für überschaubare Datenmengen ohne echte Live-Anforderung.
DirectQuery. Jeder Filter, Klick oder Seitenwechsel kann eine neue Abfrage an Databricks senden. Die Antwortzeit hängt an Warehouse, Modell und Query, dafür sehen Nutzer sehr aktuelle Daten. Die Databricks-Kosten entstehen während der Nutzung laufend. Sinnvoll ist DirectQuery für sehr große oder häufig aktualisierte Daten und operative Berichte. Die Microsoft-Learn-Doku zu DirectQuery auf Databricks listet Eigenschaften und Grenzen im Detail.
Composite Model. Hybrid aus Import und DirectQuery: aggregierte Tabellen liegen lokal in Power BI, die Faktentabelle bleibt live in Databricks. Power BI beantwortet die meisten Visualisierungen aus dem lokalen Speicher und fragt Databricks nur bei Detailanalysen ab. Für große Modelle mit Standardansichten und wenigen Drilldowns ist das oft der bessere Ansatz.
Live Connection. Verbindung gegen ein vorhandenes semantisches Modell im Power-BI-Service. Für die direkte Anbindung an Databricks selten relevant; taucht nur auf, wo ein Tabular-Modell zwischen Power BI und Databricks liegt.
Auswirkungen pro Modus auf einen Blick:
| Modus | Latenz pro Interaktion | Aktualität | DBU-Wirkung | Typischer Use Case |
|---|---|---|---|---|
| Import | sehr niedrig (In-Memory) | Refresh-Intervall | Burst pro Refresh | stabile Aggregat-Modelle, moderates Volumen |
| DirectQuery | Warehouse-abhängig | live | kontinuierlich | volatile Daten, große Volumen, Audit-Anforderung |
| Composite | gemischt | gemischt | mittel | große Modelle mit Drilldown-Bedarf |
| Live Connection | Modell-abhängig | Modell-abhängig | je nach Hintergrund-Modell | gegen vorhandenes Tabular-Modell |
Eine einfache Faustregel hilft bei der Auswahl:
Import wählen, wenn
- Die Datenmenge überschaubar ist und ein geplanter Refresh ausreicht
- Filter und Visualisierungen ohne Live-Anforderung schnell reagieren sollen
- Databricks nur während des Refreshs belastet werden soll, nicht laufend
DirectQuery oder Composite wählen, wenn
- Die Daten sehr groß sind oder häufig aktualisiert werden und Nutzer aktuelle Werte sehen müssen
- Ein Composite-Modell aggregierte Kennzahlen lokal hält und nur Detailanalysen live gegen Databricks abfragt
- Operative Berichte jederzeit den aktuellen Datenstand zeigen müssen
Neue Berichte sollten zunächst im Import-Modus starten, wenn Aktualität und Datenmenge das zulassen. DirectQuery oder Composite sollten erst eingesetzt werden, wenn ein konkreter Bedarf besteht.
Welches Databricks SQL Warehouse passt zu Power BI?
Der Warehouse-Typ beeinflusst Kosten, Startzeit und Performance. Drei Compute-Typen stehen zur Wahl.
Pro läuft in der Kundenumgebung, hat Photon und Predictive IO als Standardausstattung, Startzeit von mehreren Minuten, mittlerer Stundenpreis. Geeignet für planbare Reporting-Last: Geplante Aktualisierungen zu festen Zeiten, DirectQuery mit relativ gleichmäßiger Nutzung während des Tages. Photon beschleunigt viele Abfragen, und das Warehouse passt gut zu wiederkehrender Last.
Serverless wird von Databricks betrieben, hat Photon und Predictive IO ebenfalls aktiv, Start-Latenz unter zehn Sekunden, höchster Stundenpreis. Geeignet für unregelmäßige Nutzung und schnelle Starts: Berichte, die nur gelegentlich genutzt werden, KI-Features wie Genie und AI/BI-Dashboards, Entwicklung und Tests, bei denen das Warehouse schnell verfügbar sein soll.
Classic läuft in der Kundenumgebung mit klassischer Konfiguration, Photon optional, niedrigster Stundenpreis, mehrere Minuten Start-Latenz. Für Power BI ist Classic meist nur bei besonderen technischen, regulatorischen oder regionalen Anforderungen sinnvoll.
Serverless, Pro, Classic: drei Compute-Profile für Power BI.
Serverless startet in Sekunden und passt zu sporadischer Reporting-Last und KI-Features. Pro bedient planbare Import-Refreshs und gleichmäßige DirectQuery-Last. Classic bleibt die Ausnahme für Sonderfälle ohne Serverless-Verfügbarkeit.
Drei Einstellungen helfen bei der Kostenkontrolle:
Auto-Stop passend zur Nutzung
Pro für Reporting: 15–30 Minuten. Serverless für sporadische Last: 5–10 Minuten. Sehr lange Leerlaufzeiten verursachen meist unnötige Kosten.
Erst Cluster-Skalierung prüfen
Bei vielen parallelen Abfragen zunächst zusätzliche Cluster statt sofort ein größeres Warehouse wählen. Häufig günstiger als eine dauerhafte Vergrößerung.
Getrennte Warehouses pro Lastprofil
Ein Warehouse für nächtliche Import-Refreshs und tagsüber DirectQuery-Last braucht widersprüchliche Einstellungen. Getrennte Warehouses lassen sich besser dimensionieren und auswerten.
Die Compute-Wahl klären wir im Überblick zu SQL Warehouses tiefer. Als Standard passt Power-BI-Reporting häufig auf ein Pro Warehouse mit Photon, unregelmäßige Self-Service- und KI-Last eher auf Serverless.
Sternschema statt Wide Table
Die technische Verbindung zu Databricks ist nur die Grundlage. Wie schnell und konsistent Berichte sind, entscheidet auch das Datenmodell in Power BI. Drei Modellierungs-Entscheidungen wirken besonders stark.
Sternschema statt Wide Table
Power BI ist für klar getrennte Fakten- und Dimensionstabellen optimiert. Eine breite Lakehouse-Tabelle funktioniert im Import zunächst, DAX-Maße und Cardinality-Erkennung der VertiPaq-Engine arbeiten aber dagegen. Mit wachsender Datenmenge wird das Modell langsamer.
Dimensionstabellen bewusst behandeln
In einem Composite-Modell liegen Dimensionstabellen im Import, die große Faktentabelle bleibt per DirectQuery live. Filter reagieren schnell aus dem Power-BI-Speicher, Fakten kommen bei Bedarf aus Databricks.
Granularität an den Fragen ausrichten
Sehr feine Granularität führt zu massiven Importen oder langen DirectQuery-Antwortzeiten. Bei täglicher oder wöchentlicher Standardauswertung sollte die Lakehouse-Schicht passende Aggregations-Views bereitstellen.
Wie verbessert man die Power-BI-Performance?
Mehr Performance entsteht nicht immer durch ein größeres Warehouse.
Query Folding
Power BI sollte Filter und Verarbeitungsschritte an Databricks weitergeben. Komplexe eigene Power-Query-Schritte können das verhindern. Dann lädt Power BI deutlich mehr Daten als nötig.
Aggregations-Tabellen
Voraggregierte Tabellen, die das Power-BI-Modell als Aggregations-Quelle registriert. Die meisten Visualisierungen laufen dann aus der kleinen Tabelle, nur Detailfragen greifen auf die große zu.
Result-Cache und Photon
Wiederholte identische Abfragen nutzen bereits berechnete Ergebnisse, Photon beschleunigt die übrigen größeren SQL-Abfragen. Beide Hebel wirken zusammen.
Materialized Views als Lakehouse-Cache
Wiederkehrende Aggregationen in Databricks vorberechnen, inkrementeller Refresh hält sie aktuell. Wirkungsvoll für Top-N-Auswertungen und Dashboard-Tiles im DirectQuery-Modus.
Visual- und Seiten-Design
Power BI sendet meist eine Abfrage pro Visual. Weniger Visuals pro Seite, kombinierte Karten und die Option „Apply slicers later“ senken die Last direkt im Bericht.
Query History als Diagnose
Die Query History im Databricks-SQL-Editor zeigt die langsamsten Abfragen pro Warehouse: macht sichtbar, ob Modell, Power-Query-Schritt oder View bremst, bevor das Warehouse vergrößert wird.
Bevor das Warehouse vergrößert wird, sollte geprüft werden, ob Power BI die Verarbeitung tatsächlich an Databricks überträgt, ob vorberechnete Kennzahlen verwendet werden können und ob wiederholte Abfragen aus dem Cache beantwortet werden. Erst danach sollte eine größere Warehouse-Stufe geprüft werden.
Wo gehören Measures hin?
Für jede Kennzahl sollte klar sein, wo ihre verbindliche Berechnung liegt: in DAX-Measures im Power-BI-Modell oder in einer Lakehouse-Semantik-Schicht in Databricks SQL (Views, Materialized Views, SQL-Funktionen). Beide Varianten sind möglich, haben aber unterschiedliche Stärken.
Measures in Power BI definieren, wenn
- Der Bericht überwiegend reine Power-BI-Nutzung hat, ohne andere BI-Werkzeuge
- Zeitvergleiche, dynamische Filter oder komplexe Berichtsauswertungen im Vordergrund stehen
- Die Berechnung im Import-Modus sehr schnell ausgeführt werden soll
Measures in Databricks SQL definieren, wenn
- Mehrere Werkzeuge wie Power BI, Genie oder AI/BI-Dashboards dieselbe Berechnung nutzen sollen
- Eine zentral verbindliche Kennzahl wichtiger ist als komplexe DAX-Zeitlogik
- Konsistenz über Berichte und Tools hinweg Priorität hat
DAX-Optimierung im Power-BI-Modell. Wenn Measures in DAX bleiben, beeinflusst ihre Qualität auch die Performance und Last. Variablen (VAR) statt mehrfacher Filter-Wiederholungen, Measures statt berechneter Spalten und das bewusste Vermeiden teurer Context-Transitions reduzieren die Zahl der Engine-Iterationen messbar. Der Performance Analyzer in Power BI Desktop zeigt pro Visual, welche DAX-Berechnung wie lange braucht, und macht die teuerste Stelle im Modell sichtbar.
Drei Fehler führen häufig zu unterschiedlichen Kennzahlen:
Kennzahl parallel gepflegt
Eine Kennzahl in Power BI und Databricks gleichzeitig pflegen. Dadurch entstehen mit der Zeit unterschiedliche Ergebnisse.
Zeitlogik unnötig in SQL nachgebaut
Komplexe Power-BI-Zeitlogik in SQL-Views erzeugt Wartungsaufwand, den DAX in Minuten löst.
Views ohne Versionierung geändert
Zentrale Views verändern, ohne Änderungen nachvollziehbar zu versionieren und zu testen.
Jede Kennzahl sollte genau eine verbindliche Berechnung besitzen. Kennzahlen, die ausschließlich in Power BI verwendet werden und komplexe Zeitlogik benötigen, können sinnvoll in DAX bleiben. Kennzahlen für mehrere BI- und KI-Werkzeuge sollten möglichst zentral in Databricks bereitgestellt werden. Für jede Kennzahl sollte eine der beiden Varianten verbindlich festgelegt werden.
RLS, Column Masks und Audit
Unity Catalog verwaltet, welche Nutzer welche Tabellen, Zeilen und sensiblen Spalten sehen dürfen. Mit offiziellem Connector und zentraler Anmeldung erkennt Databricks den jeweiligen Power-BI-Nutzer. Drei Dinge funktionieren dann sauber.
Audit-Details liefern die System Tables: Databricks protokolliert dort, welcher Nutzer über Power BI auf welche Daten zugegriffen hat.
Row-Level Security wird weitergegeben
Zeilenfilter sorgen dafür, dass Nutzer nur die für sie freigegebenen Datensätze sehen. Die Regel muss nicht zusätzlich in jedem Power-BI-Modell gepflegt werden.
Column Masks werden weitergegeben
Sensible Inhalte werden abhängig von der Berechtigung verborgen oder unkenntlich gemacht. Berechtigte Nutzer sehen den tatsächlichen Wert, andere nur eine geschützte Darstellung.
Audit über System Tables
Databricks protokolliert, welcher Nutzer über Power BI auf welche Daten zugegriffen hat, Grundlage für regelmäßige Sicherheits- und Compliance-Prüfungen.
Damit das funktioniert, müssen drei Bedingungen erfüllt sein:
Zentrale Anmeldung statt persönlicher Tokens
Bei einem gemeinsamen Token erkennt Databricks die einzelnen Berichtsnutzer nicht. RLS und Column Masks laufen dann ins Leere.
Datenrechte über zentral verwaltete Gruppen
Berechtigungen auf Microsoft-Entra-Gruppen statt auf einzelne Nutzer reduzieren den Pflegeaufwand.
Klare Workspace-Zuordnung
Pro produktivem BI-Workspace gehört eine klare Zuordnung zum Databricks-Workspace mit den passenden freigegebenen Catalogs und Datenbereichen.
Die Hub-Brücke zum Überblick zu Unity Catalog zeigt, wie das Governance-Modell unter der Anbindung sitzt. Ohne sauberes Berechtigungsmodell verbessert der Connector allein weder Sicherheit noch Auditierbarkeit.
Was kostet Power BI auf Databricks?
Die Kosten hängen vor allem von zwei Faktoren ab: wie viele Abfragen Power BI an Databricks sendet, und wie lange das Warehouse läuft und wie stark es skaliert.
Import-Modus
Ein geplanter Refresh erzeugt kurzzeitig mehrere größere Abfragen. Bei einem nächtlichen Refresh läuft das Warehouse 5–30 Minuten und schaltet danach ab. Kosten sind dadurch meist gut planbar.
DirectQuery
Jede Nutzung des Berichts kann neue Compute-Kosten verursachen. Ohne Aggregationen und Kostenkontrolle kann DirectQuery deutlich teurer werden als ein vergleichbarer Import-Bericht.
Composite
Die Kosten hängen davon ab, wie häufig Nutzer von importierten Kennzahlen auf live abgefragte Detaildaten wechseln.
Drei Hebel helfen bei der Kostenkontrolle:
- Aggregations-Tabellen für DirectQuery-Modelle. Vorberechnete Kennzahlen können die Zahl großer DirectQuery-Abfragen deutlich verringern.
- Auto-Stop bewusst einstellen. Pro mit 15–20 Minuten, Serverless mit 5–10 Minuten. Das Warehouse nach einer passenden kurzen Leerlaufzeit abschalten, sonst verursacht es auch ohne Nutzung weiter Kosten.
- Kostenstelle, Team und Anwendungsfall konsequent taggen. Pflicht-Tags cost_center, team, workload, env werden über Cluster-Policies vererbt und landen in system.billing.usage. Ohne diese Angaben lässt sich nicht erkennen, welcher Bericht oder Fachbereich die Kosten verursacht hat.
Wir vertiefen die Compute-Mechanik im Überblick zu SQL Warehouses. Bei hohen Power-BI-Kosten sollten zuerst Zugriffsmodus, Abfragehäufigkeit und vorberechnete Kennzahlen geprüft werden. Ein größeres Warehouse ist meist nicht der erste sinnvolle Schritt.
Direct Lake oder Databricks SQL?
Microsoft Fabric bietet mit Direct Lake einen anderen Weg für Power-BI-Berichte. Power BI greift dabei direkt auf Daten in OneLake zu. Dieser Ansatz läuft ohne Databricks SQL Warehouse.
| Eigenschaft | Power BI gegen Databricks SQL | Direct Lake auf Fabric Onelake |
|---|---|---|
| Speicherort der Daten | Delta Lake unter Databricks Unity Catalog | Onelake (Delta + Parquet) |
| Rechenleistung für die Berichte | Databricks SQL Warehouse | Fabric-Capacity |
| Berechtigungen und Datenverwaltung | Unity Catalog (RLS, Column Masks) | Fabric-eigene Governance |
| BI-Plattform | Power BI | Power BI |
| Benötigte Plattform | Databricks-Workspace plus Power BI | Fabric-Lizenz plus Onelake-Storage |
Drei Kriterien helfen bei der Entscheidung:
- Wenn Databricks bereits die zentrale Daten- und Governance-Plattform ist, bleibt Databricks SQL meist der passende Power-BI-Zugang.
- Wenn Daten und Governance vollständig in Microsoft Fabric liegen, sollte Direct Lake geprüft werden.
- Wer Databricks und Fabric parallel nutzt, muss festlegen, welche Plattform langfristig Datenhaltung, Governance und Compute verantwortet.
Direct Lake ist nicht nur ein anderer Verbindungsmodus, sondern Teil des Fabric-Plattformmodells. Im Vergleichs-Frame gehört sie als Alternative aufgeführt; im Architektur-Frame als eigene Entscheidung.
Was die Power-BI-Anbindung nicht löst
Die Verbindung stellt Daten für Power BI bereit. Sie beantwortet nicht, ob einzelne Berichte besser direkt in Databricks gebaut werden sollten, und ersetzt keine saubere Datenmodellierung.
Mehr dazu im Überblick zu AI/BI-Dashboards und im Überblick zu Genie.
AI/BI-Dashboards bleiben eine Alternative
Databricks-eigene Dashboards laufen direkt auf einem SQL-Warehouse-Endpoint. Für Nutzer, die ohnehin in Databricks arbeiten und einfache operative Berichte brauchen, oft einfacher als eine zusätzliche Power-BI-Strecke.
Genie ersetzt keine festen Berichte
Genie beantwortet Ad-hoc-Fragen in natürlicher Sprache, Power BI bleibt stark für feste Berichte. Beide verursachen Abfragen auf SQL Warehouses.
Datenmodell bleibt entscheidend
Zu viele Spalten, ungeeignete Tabellenverknüpfungen und fehlende Vorberechnungen führen auch mit einem schnellen Warehouse zu langen Antwortzeiten, unabhängig vom Connector.
Die Anbindung ist nur die Verbindung zwischen Databricks SQL und Power BI. Was die Engine bedient und was darunter im Speicher liegt, klären andere Schichten.
Power-BI-Berichte auf Databricks SQL migrieren: Sechs Schritte
Viele Power-BI-Anbindungen an Databricks entstehen im Rahmen einer Migration: ein klassisches Data Warehouse (Synapse, klassisches Azure SQL, ein lokales SQL-Server-Modell) wird durch Databricks SQL ersetzt; Power BI bleibt als Reporting-Werkzeug bestehen. Ein schrittweises Vorgehen reduziert Risiken und Abweichungen bei Kennzahlen.
Datasets, Berichte und Abhängigkeiten erfassen
Welche Datasets liegen im Power-BI-Service, welche Berichte hängen daran, welche Tabellen werden gezogen, welche DAX-Measures sind definiert? Datenmenge, Aktualisierungsrhythmus und benötigte Aktualität sind die Grundlage für Modus und Warehouse.
Berichte nach Nutzung und Anforderungen gruppieren
Nach Volumen, Aktualität und Nutzung gruppieren. Drei Klassen reichen meist: regelmäßig aktualisierte Standardberichte, Berichte mit sehr aktuellen Daten, Datenmodelle für eigenständige Fachbereichs-Analysen.
Mit einer überschaubaren Gruppe beginnen
Begrenzte Datenmenge und klar benannte Nutzergruppe bekommen die neue Anbindung: offizieller Connector, zentrale Anmeldung, Pro Warehouse und zunächst Import. Kennzahlen werden mit den alten Werten verglichen, bevor weitere Berichte umgestellt werden.
Kennzahlen mit dem bisherigen System vergleichen
Pro Kennzahl ein Vergleich gegen den alten Warehouse-Pfad. Abweichungen entstehen meist bei Zeitzonenbehandlung, leeren Werten oder der Reihenfolge von Berechnungen und Gruppierungen: vor der fachlichen Abnahme klären.
Weitere Berichte gruppenweise umstellen
Sobald die Pilotgruppe stabil läuft, wandern die nächsten Klassen über. Große und live abgefragte Modelle bekommen vorberechnete Kennzahlen, Genie und AI/BI erhalten getrennte Serverless Warehouses.
Bisherige Datenverbindung kontrolliert abschalten
Das bisherige Warehouse läuft so lange parallel, bis alle Klassen migriert sind. Bei großen Berichtsumgebungen kann ein längerer Parallelbetrieb nötig sein, während dieser Zeit entstehen zeitweise Kosten in beiden Plattformen.
Die Dauer hängt stark von Zahl, Komplexität und fachlicher Bedeutung der Berichte ab. Das größte Risiko sind unterschiedliche Kennzahlen zwischen alter und neuer Lösung. Ein früh aufgesetzter Kennzahl-Vergleich fängt die Differenzen, bevor die Abweichungen in Management- oder Fachbereichsberichten sichtbar werden.
Grenzen der Power-BI-Integration mit Databricks
Die vier Entscheidungen sind wichtig, lösen aber nicht alle Reporting-Probleme.
Ersetzt keine Datenmodellierung
Eine sehr große Faktentabelle, die nicht für Reporting vorbereitet ist, kann auch auf einem sehr großen Warehouse langsam bleiben. Besseres Tabellenlayout und vorberechnete Ergebnisse bringen mehr als zusätzlicher Compute.
Power-BI-Modell muss sauber sein
Ein einfaches, klar strukturiertes Datenmodell und sauber gepflegte Berechnungen sind eigene Optimierungs-Hebel. Viele komplexe, voneinander abhängige DAX-Berechnungen werden auch durch mehr Databricks-Compute nicht schnell.
Regelt keine Power-BI-Governance
Umgebungen, Veröffentlichungsprozesse, Verantwortliche und die Pflege veralteter Berichte sind eine eigene Schicht. Die Anbindung übergibt nur die Identität an Databricks.
Verhindert nicht automatisch Kosten
Auto-Stop, Auto-Scale-Limit, Tagging und Aggregations-Tabellen sind die Hebel. Abschaltzeiten, Skalierungsgrenzen und Nutzung müssen regelmäßig überprüft werden.
Nicht in jeder Cloud und Region gleich
Serverless ist nicht in allen Cloud-Regionen ausgerollt, OAuth-SSO über Microsoft Entra ID hat je nach Cloud-Plattform und Region unterschiedlichen Funktionsumfang.
Die Verbindung ist nur ein Teil der gesamten BI-Architektur. Ihr Nutzen entsteht erst zusammen mit gutem Datenmodell, klaren Berechtigungen und geregeltem Betrieb.
Sobald Berichte operative Entscheidungen beeinflussen, sollte die Anbindung standardisiert und regelmäßig überprüft werden: Verbindliche Standards, Kostenmerkmale, automatisierte Kennzahlvergleiche und regelmäßige Reviews sollten gemeinsam aufgebaut werden und machen Leistung, Kosten und Berechtigungen nachvollziehbar.
Fazit
Damit Power BI auf Databricks zuverlässig läuft, müssen vier Entscheidungen sauber getroffen werden: Connector, Zugriffsmodus, SQL Warehouse und der Ort der Kennzahlenlogik.
Eine klare Power-BI-Strategie wird spätestens dann wichtig, sobald mehrere produktive Berichte auf Databricks zugreifen und wenn Kosten, Kennzahlen und Datenberechtigungen regelmäßig überprüft werden müssen. Connector, Zugriffsmodus, Warehouse und Kennzahlmodell bestimmen gemeinsam Antwortzeiten, Kosten und Berechtigungen.
Besonders relevant ist ein klares Zielbild bei:
- Der Ablösung eines bisherigen Data Warehouses durch Databricks SQL
- Großen DirectQuery-Berichten mit steigenden Databricks-Kosten
- Berichten, bei denen nutzerabhängige Datenfilter und Maskierungen nachweisbar sein müssen
- Datenplattformen, deren Kennzahlen von Power BI, Genie, AI/BI und weiteren Werkzeugen genutzt werden
Für einen einzelnen kleinen Bericht reicht häufig der offizielle Connector, zentrale Anmeldung, Import-Modus und ein passend dimensioniertes Warehouse. Ein umfangreiches Betriebsmodell wird erst mit wachsender Zahl von Berichten, Nutzern und Datenmengen notwendig.
Ein guter Standard ist: Verwendet den offiziellen Databricks-Connector mit zentraler Anmeldung als Standard. Entscheidet je Bericht anhand von Datenmenge, Aktualität und Nutzung zwischen Import, DirectQuery und Composite: Import für überschaubare Datenmengen und planbare Aktualisierungen, DirectQuery oder Composite für sehr große und häufig aktualisierte Datenbestände, möglichst mit vorberechneten Kennzahlen. Nutzt ein Pro Warehouse für regelmäßige, planbare Reporting-Last und ein getrenntes Serverless Warehouse für Genie, AI/BI und unregelmäßige Self-Service-Abfragen. Legt für jede Kennzahl genau eine verbindliche Berechnung fest, entweder in Power BI oder zentral in Databricks. Zentrale Berechtigungen, sauberes Tagging und automatisierte Kennzahlvergleiche sollten von Beginn an dazugehören.
FAQ
Power BI verbindet sich über einen Connector gegen einen Databricks-SQL-Warehouse-Endpoint. Empfohlen ist der offizielle Databricks-Connector mit OAuth über Microsoft Entra ID; er unterstützt Query Folding, SSO und die Weitergabe von Unity-Catalog-Berechtigungen. ODBC oder JDBC sind möglich, nutzen aber nicht alle Integrationen. Vier Entscheidungen prägen die Anbindung: Connector, Verbindungs-Modus, Warehouse-Typ und Semantik-Aufteilung.
