Power BI Integration Databricks: Definition, Aufbau

Power BI Integration bezeichnet die technische Anbindung zwischen Microsoft Power BI und Databricks: Berichte in Power BI greifen über einen mitgelieferten Databricks-Connector (Verbindungsbaustein) auf Tabellen in Databricks zu, so dass Databricks als gemeinsame Datenbasis dient und Power BI die Berichts- und Visualisierungsschicht bleibt.

Was ist die Power BI Integration?

Der Begriff meint kein eigenes Produkt, sondern den Sammelnamen für alle Wege, mit denen Power BI Daten aus Databricks liest. Zwei Anwendungen sind gemeint: Power BI Desktop (die Windows-Anwendung, in der Berichte gebaut werden) und der Power BI Service (die Cloud-Oberfläche, in der Berichte geteilt und geplant aktualisiert werden). Beide sprechen über denselben Verbindungsbaustein mit Databricks.

Zentral ist der offizielle Databricks-Connector. Er ist in Power BI ab Werk eingebaut und im Verbindungsdialog „Daten abrufen" auswählbar. Der Connector meldet den Nutzer über sein Microsoft-Unternehmenskonto (Entra ID, das frühere Azure Active Directory) an Databricks an und leitet Abfragen an ein SQL Warehouse (den Rechen-Endpunkt für SQL-Abfragen in Databricks) weiter. Weil die Anmeldung mit dem echten Nutzer erfolgt, wirken die Berechtigungen aus Unity Catalog (der zentralen Berechtigungs- und Katalogschicht in Databricks) bis in den Bericht durch. Ein Vertriebsleiter sieht dadurch im selben Bericht nur die eigenen Regionen, obwohl die Faktentabelle die Daten aller Regionen enthält.

Auf der Power-BI-Seite entscheidet ein Betriebsmodus, ob eine Kopie der Daten in Power BI vorgehalten oder jede Frage live an Databricks geschickt wird. Der Import Mode lädt Tabellen komprimiert in die interne VertiPaq-Engine von Power BI; das Warehouse wird nur beim geplanten Refresh belastet und der Bericht antwortet aus dem lokalen Speicher. Der DirectQuery-Modus speichert nichts vor: Jede Filter- und Klick-Interaktion wird zur Laufzeit in eine SQL-Abfrage übersetzt und an das SQL Warehouse geschickt. Ein Bericht kann beide Modi in einem sogenannten Composite Model kombinieren, meist mit kleinen Dimensionen im Import und großen Faktentabellen im DirectQuery.

Aus dem Databricks-Workspace heraus existiert zusätzlich das Publish-to-Power-BI-Feature: Im Kontextmenü einer Tabelle im Unity Catalog kann eine Verbindung samt vorbereitetem Power-BI-Dataset direkt an den Power BI Service übergeben werden. Databricks legt das Dataset an, verbindet es mit einem passenden SQL Warehouse und stellt die Berechtigungen. Der Weg ersetzt keine architekturelle Modus-Entscheidung, senkt aber die Einstiegshürde für erste Berichte auf neu bereitgestellten Tabellen.

Der Begriff existiert, weil in vielen Unternehmen zwei Entscheidungen unabhängig voneinander getroffen wurden: Power BI ist als BI-Frontend gesetzt (Lizenzen im Microsoft-365-Vertrag, geschulte Analysten, bestehende Berichts-Landschaft), und Databricks wird als analytische Datenplattform aufgebaut oder aus einem klassischen Data Warehouse übernommen. Die Integration ist der Weg, beides zu koppeln, ohne die Analyse-Ergebnisse in ein zweites Backend zu kopieren.

Abgrenzung zu Genie, AI/BI Dashboards, Excel-Integration, ODBC/JDBC und Tableau

Die Power BI Integration wird in Diskussionen häufig mit anderen BI-Zugängen zu Databricks vermischt: mit der nativen Databricks-Frontend-Familie, mit einfachen Ad-hoc-Wegen über Excel, mit der treiberbasierten Direktverbindung und mit der strukturell ähnlichen Anbindung von Tableau. Die Trennung verläuft entlang zweier Achsen: welche Rolle Power BI spielt (Frontend oder gar nicht anwesend) und wie die Verbindung technisch abgewickelt wird.

Begriff	Rolle	Kernunterschied
Genie / AI/BI Dashboards	Databricks-eigenes Frontend	Genie ist ein natürlichsprachlicher Analyse-Assistent, AI/BI Dashboards die native Reporting-Oberfläche im Databricks-Workspace. Beide arbeiten ohne Power BI und ohne den Databricks-Connector. Sie stehen als Alternative neben der Power BI Integration.
Excel-Integration	Ad-hoc-Client	Excel greift über den ODBC-Treiber oder eine Kopie aus Power BI auf Databricks zu. Üblich für einmalige Auswertungen, aber kein Publish-Weg für geteilte Berichte und mit eingeschränktem Berechtigungsdurchgriff. Excel bleibt eine Einzelplatz-Anwendung.
ODBC/JDBC-Direktverbindung	Treiberschicht	ODBC und JDBC sind Datenbank-Treiber-Standards und die technische Basis, auf der der offizielle Power-BI-Connector selbst aufsetzt. Wer im Dialog stattdessen „ODBC-Datenquelle" wählt, umgeht die Connector-Logik: Query-Folding (das Übersetzen von Power-Query-Schritten in SQL) ist unvollständig, Unity-Catalog-Zeilenfilter greifen nicht durchgängig, die Anmeldung ist meist auf technische Konten reduziert.
Tableau-Integration	Konkurrenz-Frontend	Tableau hat einen eigenen Databricks-Connector mit vergleichbarer Mechanik (Live-Verbindung entspricht DirectQuery, Extract entspricht Import). Die Power BI Integration bezeichnet spezifisch die Microsoft-Power-BI-Anbindung; die Tableau-Anbindung ist strukturell ähnlich, technisch aber ein separater Connector mit eigenen Optionen.

Am folgenreichsten ist die Trennung zwischen der Power BI Integration und den Databricks-eigenen BI-Werkzeugen. Beide beantworten die Frage „wie kommen Berichte an Databricks-Daten", tun das aber anders: Power BI bleibt das Frontend und arbeitet mit einem eigenen Semantik-Modell, DAX-Kennzahlen und Berichts-Layout; AI/BI Dashboards und Genie leben im Databricks-Workspace und nutzen dessen Semantik-Layer direkt. Welche Variante trägt, hängt an bestehenden Lizenzen, Team-Kompetenzen und der geplanten Rollen-Aufteilung zwischen Analytics-Engineering und Fachbereich.

Beispiel: Databricks-Migration bei bestehender Power-BI-Landschaft

Ein mittelständisches Handelsunternehmen betreibt sein BI-Reporting seit Jahren in Power BI: Vertriebs-Dashboards, Filial-Reports, Controlling-Cockpits, verteilt über den Power BI Service, konsumiert von rund 200 Nutzern. Die dahinterliegende Datenplattform wird von einem klassischen Data Warehouse auf Databricks migriert; Delta-Tabellen im Gold-Layer ersetzen die alten OLAP-Cubes. Statt die Berichts-Landschaft ebenfalls auszutauschen, wird Power BI als Frontend behalten.

Die Umsetzung nutzt vier Bausteine der Integration. In Databricks wird ein Pro-SQL-Warehouse bi-powerbi-prod bereitgestellt, mit Photon (der vektorisierten Query-Engine) aktiv und Auto-Stop nach 15 Minuten Inaktivität. In Power BI Desktop wählen Analysten den offiziellen Databricks-Connector und melden sich mit ihrem Microsoft-Unternehmenskonto an; die Berechtigungen aus dem Unity Catalog wirken damit direkt im Bericht, ohne dass eigene Rollen-Modelle in Power BI gepflegt werden. Für die Vertriebs-Dashboards werden Dimensionen (Artikel, Filiale, Kalender) im Import Mode geladen, die 800-Millionen-Zeilen-Umsatz-Faktentabelle läuft im DirectQuery-Modus gegen das Warehouse (Composite Model). Berichte werden anschließend in den Power BI Service publiziert; Unity-Catalog-Row-Filter beschränken die sichtbaren Zeilen abhängig von der Anmeldeidentität.

Für neu aufgebaute Datenprodukte im Gold-Layer wird zusätzlich das Publish-to-Power-BI-Feature aus dem Workspace-Katalog genutzt: Ein Data-Engineer stellt eine neue aggregierte Umsatz-Tabelle bereit und legt daraus ein Power-BI-Dataset an, das das Reporting-Team als Startpunkt weiterentwickelt. Antwortzeiten liegen bei drei bis fünf Sekunden für einen Filter-Klick auf dem DirectQuery-Bericht mit warmem Warehouse und unter einer Sekunde für die Import-Berichte. Die Warehouse-Kosten skalieren mit der Nutzeraktivität; das Warehouse steht außerhalb der Berichtszeiten still.