Business Intelligence auf Databricks: vom Dashboard-Wildwuchs zur gemeinsamen Datenbasis
Die Kernaussagen auf einen Blick.
- Business Intelligence auf Databricks beginnt nicht beim Dashboard, sondern bei einer gemeinsamen Datenbasis, klar definierten Kennzahlen und einer passenden Abfrage-Infrastruktur.
- Der größte Nutzen entsteht, wenn Power BI, Tableau, AI/BI Dashboards und Genie auf dieselben kuratierten Tabellen und KPI-Definitionen zugreifen.
- Databricks muss bestehende BI-Tools nicht automatisch ersetzen.
- Häufig ist eine Kombination sinnvoll: Databricks stellt Daten, Berechtigungen und Compute bereit, während etablierte Werkzeuge das Reporting übernehmen.
- Vor dem Ausbau von Self-Service und natürlichsprachlichen Abfragen sollten das semantische Modell, die Zugriffsregeln und die Verantwortlichkeiten geklärt sein.
Inhaltsverzeichnis
Fünf BI-Tools sind keine Strategie
In vielen Unternehmen sind BI-Landschaften über Jahre gewachsen.
Der Vertrieb arbeitet mit Power BI, weil Microsoft 365 ohnehin im Einsatz ist. Das Marketing nutzt Tableau, weil eine Agentur die ersten Dashboards damit aufgebaut hat. Das Controlling verwendet ein spezialisiertes Reporting-Werkzeug und für das Management werden die wichtigsten Zahlen zusätzlich in Excel zusammengestellt.
Jedes dieser Werkzeuge kann für seinen Zweck funktionieren. Problematisch wird es, wenn jedes Team auch eine eigene Datenbasis und eigene Kennzahlendefinitionen pflegt.
Dann entstehen typische Fragen:
- Warum zeigt Power BI einen anderen Umsatz als der Controlling-Bericht?
- Welche Stornos wurden berücksichtigt?
- Welche Wechselkurse wurden verwendet?
- Welcher Kundenstatus gilt als aktiv?
- Welche Auswertung ist für das Management verbindlich?
Die Ursache ist häufig nicht das BI-Tool. Sie liegt darunter: in getrennten Datenmodellen, individuell aufgebauten Datenextrakten und unterschiedlich definierten Kennzahlen.
Ein Tool-Wechsel löst dieses Problem nicht automatisch. Wenn ein Unternehmen Power BI durch Looker oder Tableau durch AI/BI Dashboards ersetzt, ohne die gemeinsame Datenbasis zu klären, wird die bestehende Inkonsistenz lediglich in ein neues Frontend übertragen.
Eine belastbare BI-Strategie sollte deshalb zuerst vier Fragen beantworten:
- Welche Tabellen und Datenprodukte sind für das Reporting verbindlich?
- Wo werden Kennzahlen fachlich definiert?
- Welche Nutzergruppen benötigen welches BI-Werkzeug?
- Wie werden Self-Service, Berechtigungen und Compute-Kosten gesteuert?
Databricks kann für diese Architektur die gemeinsame Daten- und Abfrageschicht bereitstellen. Die sichtbaren Dashboards können weiterhin in Power BI, Tableau, AI/BI oder anderen Werkzeugen entstehen.
Dieser Artikel betrachtet die BI-Architektur deshalb entlang von vier Bereichen: Datenbasis, Compute, Visualisierung und Self-Service.
Was ist Business Intelligence auf Databricks?
Bei einer Lakehouse-BI-Architektur greifen Reporting-, Analyse- und Self-Service-Anwendungen direkt auf die kuratierten Daten im Lakehouse zu.
Die Daten liegen beispielsweise als Delta-Tabellen unter Unity Catalog. Databricks SQL und SQL Warehouses stellen die Abfrageleistung bereit. Als Frontend lassen sich unterschiedliche Werkzeuge einsetzen: AI/BI Dashboards, Power BI, Tableau, Looker, Sigma, Hex oder eigene Anwendungen.
Der wesentliche Unterschied zu vielen klassischen BI-Architekturen liegt in der gemeinsamen Datenbasis.
In traditionellen Umgebungen entstehen häufig zusätzliche Data Marts, BI-Datenbanken, Extracts und proprietäre semantische Modelle. Jede zusätzliche Kopie kann eigene Aktualisierungszyklen, Berechtigungen und Kennzahlendefinitionen mitbringen.
In einer Lakehouse-Architektur sollen möglichst viele Konsumenten auf dieselben freigegebenen Gold-Tabellen zugreifen.
Das bedeutet beispielsweise:
Power-BI-Report
Liest die monatlichen Umsatzdaten aus derselben Gold-Tabelle.
AI/BI Dashboard
Verwendet dieselbe Tabelle wie der Power-BI-Report.
Genie Space
Beantwortet Fragen auf derselben Datengrundlage in natürlicher Sprache.
Data-Science-Team
Nutzt die Daten für eine Prognose, ohne eigene Kopie.
Idealerweise greifen alle Anwendungen auf dieselbe Definition von Umsatz, Kunde oder Bestellung zurück.
Der Vorteil liegt daher nicht primär in einem neuen Dashboard-Werkzeug. Er liegt darin, Datenaufbereitung, Berechtigungen, Lineage und Abfrage-Compute auf einer gemeinsamen Plattform zu organisieren.
Bestehende Power-BI- oder Tableau-Landschaften müssen dafür nicht kurzfristig ersetzt werden. Databricks kann zunächst die Datenbasis darunter vereinheitlichen. Erst anschließend lässt sich entscheiden, welche neuen Anwendungsfälle mit nativen Databricks-Werkzeugen umgesetzt werden sollen.
Die übergeordnete Einordnung findet sich in der Databricks-Architektur.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Die vier Bereiche einer Databricks-BI-Architektur
Eine BI-Plattform auf Databricks lässt sich in vier Bereiche unterteilen.
| Bereich | Zentrale Frage | Typische Komponenten | Ziel |
|---|---|---|---|
| Datenbasis | Welche Tabellen und Kennzahlen sind verbindlich? | Unity Catalog, Gold-Tabellen, Views, dbt, semantisches Modell | Einheitliche Daten und KPI-Definitionen |
| Compute und Abfrage | Wie werden BI-Abfragen performant und wirtschaftlich ausgeführt? | SQL Warehouses, Databricks SQL | Skalierbare Abfragen für Reporting und Self-Service |
| Visualisierung | Wie werden Informationen für unterschiedliche Nutzergruppen aufbereitet? | AI/BI Dashboards, Power BI, Tableau, Looker, Sigma | Verlässliche Reports und Dashboards |
| Self-Service | Wie können Fachanwender eigene Fragen stellen? | Genie Spaces, semantische Modelle, Search- und Analysewerkzeuge | Kontrollierter Zugang ohne tiefgehende SQL-Kenntnisse |
Diese Bereiche hängen eng zusammen.
Ein Genie Space benötigt kuratierte Tabellen, verständliche Fachbegriffe und ein SQL Warehouse. Ein Power-BI-Report benötigt ebenfalls eine verlässliche Datenbasis und ausreichend Compute für Refreshes oder DirectQuery-Abfragen.
Für die Einführung ist daher eine sinnvolle Priorisierung wichtig:
Fachliche Daten und Kennzahlen klären
Bevor neue Werkzeuge angebunden werden, muss klar sein, welche Tabellen und KPI-Definitionen verbindlich gelten.
Berechtigungen und Abfrage-Compute einrichten
Unity Catalog regelt den Zugriff, SQL Warehouses stellen die Abfrageleistung für Reporting und Self-Service bereit.
Bestehende und neue BI-Werkzeuge anbinden
Power BI, Tableau, AI/BI Dashboards oder Genie greifen auf dieselbe kuratierte Datenbasis zu.
Self-Service schrittweise öffnen
Natürlichsprachliche Abfragen werden erst für klar abgegrenzte Fachbereiche freigegeben, sobald die Datenbasis stabil ist.
Prototypen können natürlich früher entstehen. Skalieren sollte Self-Service aber erst dann, wenn Datenbasis und Kennzahlendefinitionen stabil genug sind.
gemeinsame Tabellen und verbindliche Kennzahlen
Die wichtigste Grundlage einer BI-Plattform ist nicht das Dashboard, sondern eine verlässliche Datenbasis.
Auf Databricks besteht sie typischerweise aus drei Bausteinen: Unity Catalog für Berechtigungen, Ownership und Lineage, kuratierten Gold-Tabellen für fachliche Auswertungen sowie einem semantischen Modell für Kennzahlen und Begriffe.
Unity Catalog
Steuert Berechtigungen, Ownership und Lineage für alle Tabellen, Spalten und Zeilen.
Gold-Tabellen
Kuratierte Tabellen und Views, die für fachliche Auswertungen vorbereitet sind.
Semantisches Modell
Definiert Kennzahlen, Begriffe und Zeitvergleiche für konsistente Berichte.
Unity Catalog steuert den Zugriff
Unity Catalog regelt, welche Nutzer und Gruppen auf Tabellen, Spalten oder Zeilen zugreifen dürfen.
Diese Regeln können unabhängig davon gelten, ob die Daten über Power BI, ein AI/BI Dashboard, Genie oder den SQL Editor abgefragt werden.
Dadurch lässt sich die Zugriffslogik stärker an der Datenplattform zentralisieren. Zusätzliche Berechtigungen im BI-Tool können weiterhin notwendig sein, beispielsweise für Arbeitsbereiche, Reports oder Apps. Die eigentliche Datenfreigabe bleibt jedoch am Datenobjekt nachvollziehbar.
Die Gold-Schicht stellt fachlich nutzbare Daten bereit
In der Gold-Schicht entstehen Tabellen und Views, die für konkrete Berichte, Analysen oder Fachbereiche vorbereitet sind.
Beispiele sind:
- dim_customer
- fact_orders
- fact_service_cases
- kpi_revenue_monthly
Diese Objekte sollten nicht nur technisch korrekt sein. Sie müssen auch fachliche Fragen eindeutig beantworten:
- Was zählt als Auftrag?
- Wann wird Umsatz gebucht?
- Wie werden Stornos berücksichtigt?
- Welche Währung ist verbindlich?
- Welche Kunden werden einer Region zugeordnet?
Ob diese Tabellen mit dbt, SQL, Lakeflow Declarative Pipelines oder PySpark aufgebaut werden, ist eine wichtige technische Entscheidung. Für die BI-Nutzer ist jedoch entscheidender, dass die Ergebnisse verlässlich und verständlich sind.
Das semantische Modell definiert Kennzahlen und Begriffe
Das semantische Modell verbindet technische Daten mit der fachlichen Sprache des Unternehmens.
Dort wird beispielsweise festgelegt:
- wie Umsatz berechnet wird,
- welche Dimensionen für Filterungen zur Verfügung stehen,
- wie Zeitvergleiche funktionieren,
- welche Hierarchien gelten,
- welche Kennzahlen zertifiziert sind,
- wer die fachliche Verantwortung übernimmt.
In klassischen BI-Architekturen liegt diese Logik häufig im jeweiligen BI-Werkzeug, etwa in einem Power-BI-Semantic-Model, in LookML oder in einer Tableau-Datenquelle.
Das kann sinnvoll sein, führt bei mehreren BI-Werkzeugen aber schnell zu doppelten Definitionen.
Eine mögliche Alternative ist, einen Teil der Logik näher an die Datenbasis zu verschieben:
- in versionierte SQL-Views,
- in dbt-Modelle,
- in einen Metric Layer wie Cube oder den dbt Semantic Layer,
- in gemeinsam genutzte fachliche Tabellen.
Nicht jede Kennzahl muss vollständig aus dem BI-Tool herausgelöst werden. Wichtig ist vielmehr, eindeutig festzulegen, welche Definition an welcher Stelle führend ist.
Die vorgelagerte Aufbereitung dieser Daten erfolgt in der Data-Engineering-Schicht.
SQL Warehouses richtig einsetzen
SQL Warehouses stellen die Rechenleistung für Dashboards, BI-Tools, SQL-Abfragen und Genie bereit.
Welche Konfiguration sinnvoll ist, hängt vor allem von vier Faktoren ab:
- Anzahl gleichzeitiger Nutzer,
- Komplexität der Abfragen,
- gewünschte Antwortzeit,
- zeitliche Verteilung der Last.
Databricks bietet unterschiedliche Warehouse-Varianten, darunter Serverless sowie klassische und Pro-Konfigurationen. Die genaue Auswahl sollte pro Cloud, Region, Netzwerk- und Sicherheitsanforderung geprüft werden.
Serverless SQL Warehouses eignen sich häufig für interaktive und schwankende BI-Lasten, weil sie schnell bereitstehen und automatisch skalieren können.
Andere Warehouse-Varianten können sinnvoll sein, wenn besondere Netzwerk-, Sicherheits- oder Konfigurationsanforderungen bestehen.
SQL-Warehouse-Typen im Vergleich.
Serverless, Pro und Classic unterscheiden sich in Cold-Start, Engine-Features und Preis pro DBU: die Wahl hängt vom BI-Lastprofil ab.
Größe und Parallelität sind unterschiedliche Probleme
Bei der Dimensionierung werden häufig zwei Fragestellungen vermischt.
Ein größeres Warehouse kann einzelne komplexe Abfragen beschleunigen. Wenn dagegen viele Nutzer gleichzeitig Abfragen ausführen, ist vor allem die Parallelität entscheidend.
Ein Beispiel:
Öffnen 200 Nutzer am Montagmorgen dasselbe Dashboard, entstehen viele gleichzeitige Abfragen. Ein größeres einzelnes Compute-Cluster löst dieses Problem nicht zwangsläufig. Je nach Workload können zusätzliche Cluster, Caching, optimierte Datenmodelle oder ein Import-Modell im BI-Tool sinnvoller sein.
Vor dem Sizing sollten daher mindestens folgende Kennzahlen betrachtet werden:
- Anzahl paralleler Abfragen,
- durchschnittliche und maximale Laufzeit,
- Warteschlangen,
- Scan-Volumen,
- Cache-Nutzung,
- tägliche Lastspitzen,
- Refresh-Zeitfenster.
Workloads sinnvoll trennen
Für Transparenz und Kostenkontrolle kann es sinnvoll sein, unterschiedliche Workloads auf getrennten Warehouses auszuführen, etwa Management-Reporting, Self-Service-Analysen, Power-BI-Refreshes, Genie Spaces, Ad-hoc-Abfragen und AI Functions. Dadurch lassen sich Größenlimits, Auto-Stop, Skalierung und Kostenstellen gezielter konfigurieren.
Hilfreich sind außerdem kurze Auto-Stop-Zeiten für sporadische Workloads, Tags zur Kostenzuordnung, eine regelmäßige Auswertung der Query History, Limits für besonders teure Abfragen und die Optimierung häufig genutzter Gold-Tabellen.
Compute-Kosten lassen sich damit nicht nur über kleinere Warehouses reduzieren. Häufig bringen bessere Datenmodelle, weniger Daten-Scans und eine saubere Trennung der Workloads den größeren Effekt.
Die zugrunde liegende Databricks-SQL-Engine ist die Schicht, über die diese Warehouses ihre Leistung entfalten. AI Functionsermöglichen darüber hinaus Modellaufrufe direkt im SQL-Editor, ohne separate ML-Infrastruktur.
native Dashboards oder bestehendes BI-Tool?
Auf der Visualisierungsebene stellt sich die sichtbarste Architekturfrage: Sollen Reports direkt in Databricks entstehen oder bleibt ein bestehendes BI-Tool das zentrale Frontend?
Beide Varianten sind möglich.
AI/BI Dashboards
AI/BI Dashboards sind direkt in Databricks integriert.
Sie eignen sich besonders für:
- neue Dashboards auf Lakehouse-Daten,
- operative und plattformnahe Auswertungen,
- Berichte für Databricks-Nutzer,
- schnell umsetzbare Fachbereichsanalysen,
- Anwendungsfälle ohne bestehende BI-Tool-Abhängigkeit.
Da die Dashboards direkt auf Databricks SQL und Unity Catalog aufsetzen, sind keine zusätzlichen Datenkopien für das Visualisierungswerkzeug notwendig.
Für sehr komplexe Berichte, bestehende Management-Reportings oder hochgradig individualisierte Layouts können Power BI und Tableau weiterhin umfangreichere Funktionen und eine größere vorhandene Skill-Basis bieten.
Power BI auf Databricks
Die Kombination aus Power BI und Databricks ist in Microsoft-geprägten Unternehmen besonders verbreitet.
Dabei stehen im Wesentlichen zwei Zugriffsmodelle zur Verfügung.
Import wählen, wenn
- schnelle Interaktionen im Report im Vordergrund stehen
- geplante Aktualisierungszyklen ausreichen
- eine zusätzliche Datenkopie im Power-BI-Modell akzeptabel ist
DirectQuery wählen, wenn
- aktuelle Daten ohne Wartezeit auf den nächsten Refresh gefordert sind
- die zusätzliche Compute-Last auf dem SQL Warehouse tragbar ist
- keine zusätzliche Datenkopie entstehen soll
Welche Variante besser passt, hängt unter anderem ab von:
- Datenmenge,
- gewünschter Aktualität,
- Nutzerzahl,
- Abfragekomplexität,
- Kostenmodell,
- bestehenden Power-BI-Kapazitäten.
Häufig kommen auch Mischformen zum Einsatz.
Weitere BI- und Analysewerkzeuge
Tableau, Looker, Sigma, Hex und andere Tools können über passende Konnektoren auf Databricks SQL zugreifen.
Ob ein zusätzliches Werkzeug sinnvoll ist, sollte nicht allein anhand einzelner Funktionen entschieden werden. Wichtiger sind:
- bestehende Lizenzen,
- vorhandene Skills,
- Nutzergruppen,
- Embedded-Anforderungen,
- Governance-Funktionen,
- gewünschte Interaktionsform,
- Migrationsaufwand.
Für spezielle Anwendungen kann auch eine eigene Datenanwendung sinnvoll sein. Wenn Nutzer nicht nur Daten betrachten, sondern Eingaben machen, Szenarien rechnen oder Prozesse auslösen sollen, ist eine App häufig passender als ein klassisches Dashboard.
Die gemeinsame Databricks-Datenbasis erlaubt damit unterschiedliche Frontends. Entscheidend ist, dass nicht jedes Frontend wieder eigene Kennzahlen und Datenpipelines aufbaut.
Fragen an die Daten ohne eigenes SQL
Viele Fachanwender benötigen keine weiteren Dashboards. Sie möchten konkrete Fragen stellen, die in bestehenden Berichten nicht vorbereitet wurden.
Beispiele sind:
- Welche Kunden haben im letzten Quartal weniger bestellt?
- Welche Produkte weisen aktuell die höchste Retourenquote auf?
- Wie hat sich der Umsatz in einer bestimmten Region entwickelt?
- Welche Service-Tickets enthalten Hinweise auf Kündigungsabsichten?
Databricks Genie ermöglicht solche Abfragen in natürlicher Sprache.
Ein Genie Space wird für einen klar definierten Datenbereich eingerichtet. Dabei werden unter anderem festgelegt:
- verfügbare Tabellen und Spalten,
- fachliche Begriffe,
- Beispielabfragen,
- Berechnungslogiken,
- Hinweise zur Interpretation,
- Zugriffsrechte.
Genie übersetzt die Frage in eine SQL-Abfrage und führt sie über ein SQL Warehouse aus. Nutzer können dadurch nachvollziehen, auf welcher Abfrage die Antwort basiert.
Die fachliche Qualität hängt von der Kuratierung ab
Ein Genie Space ist kein allgemeiner Chatbot, der automatisch das gesamte Unternehmen versteht.
Gute Ergebnisse setzen voraus, dass:
- die ausgewählten Tabellen fachlich zusammenpassen,
- Spalten verständlich beschrieben sind,
- Kennzahlen eindeutig definiert sind,
- Synonyme und Fachbegriffe gepflegt werden,
- typische Fragen getestet wurden,
- Berechtigungen korrekt gesetzt sind.
Die Qualität des zugrunde liegenden Modells ist wichtig. Für die fachliche Zuverlässigkeit ist jedoch besonders entscheidend, wie gut der Space vorbereitet und laufend gepflegt wird.
Genie benötigt klare Verantwortlichkeiten
Für jeden produktiven Genie Space sollte ein verantwortliches Team oder eine Owner-Rolle benannt sein.
Diese Verantwortung umfasst beispielsweise:
- neue Tabellen aufnehmen,
- veraltete Tabellen entfernen,
- Fachbegriffe aktualisieren,
- problematische Antworten prüfen,
- Beispielabfragen ergänzen,
- Änderungen an KPI-Definitionen nachziehen.
AI Functions als Ergänzung
AI Functions adressieren einen anderen Anwendungsfall.
Sie ermöglichen es, Modellfunktionen direkt in SQL- oder Datenverarbeitungsprozesse einzubinden, etwa für die Klassifikation von Tickets, die Extraktion von Informationen aus Freitext, Zusammenfassungen, Übersetzungen oder die Kategorisierung von Produktinformationen.
Genie beantwortet Fragen von Nutzern. AI Functions reichern Daten innerhalb einer Pipeline oder Abfrage an. Beide Funktionen ergänzen sich, sollten aber architektonisch getrennt betrachtet werden.
Konsolidierung oder Koexistenz?
Unternehmen müssen nicht jedes bestehende BI-Werkzeug durch Databricks ersetzen.
In der Praxis gibt es drei realistische Zielbilder.
1. Stärkere Konsolidierung auf Databricks
AI/BI Dashboards werden zum bevorzugten Werkzeug für neue Reports. Genie übernimmt ausgewählte Self-Service-Anwendungsfälle. Bestehende Power-BI- oder Tableau-Berichte werden schrittweise reduziert.
Vorteile:
- weniger zusätzliche BI-Plattformen,
- gemeinsame Berechtigungen,
- direkter Zugriff auf Lakehouse-Daten,
- weniger Datenkopien,
- einheitlicheres Betriebsmodell.
Herausforderungen:
- bestehende Reports müssen neu aufgebaut werden,
- Nutzer benötigen Schulungen,
- einige Visualisierungs- und Reporting-Funktionen fehlen möglicherweise,
- Migration und Akzeptanz brauchen Zeit.
Dieses Modell passt vor allem zu Unternehmen, die noch keine stark etablierte BI-Landschaft haben oder ihre Tool-Anzahl bewusst reduzieren möchten.
2. Bestehende BI-Tools bleiben das Frontend
Power BI, Tableau oder Looker bleiben die zentrale Oberfläche. Databricks stellt darunter die konsolidierte Datenbasis und die SQL-Abfrageleistung bereit.
Vorteile:
- vorhandene Skills und Lizenzen bleiben nutzbar,
- bestehende Reports müssen nicht sofort migriert werden,
- Nutzer arbeiten weiter in bekannten Werkzeugen,
- Databricks vereinheitlicht trotzdem Daten und Governance.
Herausforderungen:
- ein Teil der semantischen Logik bleibt möglicherweise im BI-Tool,
- Berechtigungen müssen über mehrere Ebenen verstanden werden,
- zusätzliche Datenkopien oder Refresh-Prozesse bleiben bestehen,
- Plattform- und BI-Team müssen eng zusammenarbeiten.
Dieses Modell ist besonders sinnvoll, wenn Power BI oder Tableau bereits fest im Unternehmen verankert sind.
3. Hybride Aufgabentrennung
In einer hybriden Architektur erhält jedes Werkzeug einen klar definierten Einsatzbereich.
Beispielsweise:
- Power BI für Management- und Standardreporting,
- AI/BI Dashboards für plattformnahe Analysen,
- Genie für kuratierte Fachbereichsfragen,
- Tableau für komplexe Visualisierungen,
- eigene Anwendungen für interaktive Datenprodukte.
Diese Variante ist in vielen Unternehmen am realistischsten. Sie funktioniert allerdings nur mit verbindlichen Regeln.
Dazu sollte dokumentiert werden:
- Welches Tool ist für welche Nutzergruppe vorgesehen?
- Wo werden Kennzahlen definiert?
- Welche Reports gelten als verbindlich?
- Welche neuen Tools dürfen eingeführt werden?
- Wer verantwortet den Betrieb?
- Wann wird ein bestehendes Werkzeug abgelöst?
Ohne solche Regeln entwickelt sich eine hybride Architektur schnell wieder zu einer unkontrollierten Tool-Landschaft.
Die eigentliche Entscheidung lautet daher nicht „Databricks oder Power BI". Sie lautet: Welche Aufgaben übernimmt Databricks, welche Aufgaben bleiben im BI-Tool und wo liegt die führende fachliche Definition?
Vom Dashboard-Wildwuchs zur gesteuerten BI-Plattform
Die Entwicklung einer BI-Plattform lässt sich grob in drei Reifegrade einteilen.
Stufe 1: Getrennte BI-Inseln
Mehrere BI-Werkzeuge greifen auf unterschiedliche Datenquellen, Extracts und Data Marts zu.
Typische Merkmale sind:
- abweichende KPI-Definitionen,
- eigene Datenpipelines pro BI-Tool,
- viele Excel-Auswertungen,
- unklare Report-Verantwortung,
- doppelte Berechtigungslogik,
- keine durchgängige Lineage.
Die Abstimmung über Zahlen benötigt viel Zeit und hängt häufig vom Wissen einzelner Mitarbeiter ab.
Stufe 2: Gemeinsame Lakehouse-Datenbasis
Die wichtigsten BI-Werkzeuge greifen zunehmend auf kuratierte Gold-Tabellen in Databricks zu.
Typische Merkmale sind:
- Unity Catalog für zentrale Datenberechtigungen,
- gemeinsame Gold-Tabellen,
- erste verbindliche KPI-Definitionen,
- SQL Warehouses für BI-Abfragen,
- Power BI, Tableau oder andere Tools als bestehende Frontends,
- erste Pilotprojekte mit AI/BI Dashboards oder Genie.
In dieser Phase wird die Datenbasis vereinheitlicht, während die bestehende BI-Landschaft zunächst weitgehend erhalten bleibt.
Stufe 3: Gesteuerte BI- und Self-Service-Plattform
Die eingesetzten Werkzeuge haben klar definierte Aufgaben.
Typische Merkmale sind:
- verbindliches semantisches Modell,
- zertifizierte Datenprodukte und Kennzahlen,
- getrennte Compute-Ressourcen je Workload,
- klare Zuständigkeiten für Reports und Genie Spaces,
- kontrollierter Self-Service,
- dokumentierte Tool-Strategie,
- aktives Kosten- und Nutzungsmonitoring,
- vollständige Lineage für wichtige Reports.
In dieser Stufe können AI/BI Dashboards und Genie eine größere Rolle spielen. Entscheidend ist jedoch nicht, ob alle externen BI-Tools abgeschafft wurden. Entscheidend ist, ob Daten, Kennzahlen, Zugriffe und Verantwortlichkeiten konsistent gesteuert werden.
Der Übergang von Stufe 2 zu Stufe 3 ist vor allem organisatorisch.
Dafür müssen Unternehmen festlegen:
- Wer verantwortet das semantische Modell?
- Wer zertifiziert Kennzahlen?
- Wer betreibt SQL Warehouses?
- Wer pflegt Genie Spaces?
- Welches Tool ist für welchen Bericht vorgesehen?
- Wie werden veraltete Reports und Datenprodukte abgeschaltet?
Grenzen von Business Intelligence auf Databricks
Databricks kann Datenbasis, Compute, Governance und native BI-Funktionen eng miteinander verbinden. Trotzdem ersetzt die Plattform nicht automatisch jedes bestehende BI-Werkzeug.
AI/BI Dashboards
Bei komplexen Enterprise-Reports, individuellen Layouts oder tiefen Microsoft-Integrationen bieten Power BI und Tableau weiterhin Vorteile.
Genie
Erzeugt technisch gültige SQL-Abfragen, die fachlich trotzdem nicht der gewünschten Definition entsprechen können, abhängig von Datenkontext und Kuratierung.
SQL-Warehouse-Kosten
Interaktive BI-Workloads erzeugen schwankende Last. Ohne Auto-Stop, Tagging und Workload-Trennung steigen die Kosten schnell.
Self-Service
Mehr Self-Service bedeutet nicht automatisch bessere Entscheidungen: unklare Tabellen und Kennzahlen erzeugen neue Interpretationen.
Bestehende BI-Investitionen
Report-Bibliotheken, Berechtigungskonzepte und Embedded Analytics lassen sich nicht kurzfristig ablösen.
AI/BI Dashboards decken nicht jeden Reporting-Anwendungsfall ab
AI/BI Dashboards eignen sich für viele neue und plattformnahe Anwendungsfälle.
Bei komplexen Enterprise-Reports können Power BI oder Tableau weiterhin Vorteile bieten, beispielsweise bei:
- sehr individuellen Layouts,
- umfangreichen bestehenden Report-Bibliotheken,
- speziellen Visualisierungen,
- tiefen Microsoft-Integrationen,
- etablierten Veröffentlichungs- und Freigabeprozessen.
Vor einer Migration sollte deshalb nicht nur die Zahl der Reports betrachtet werden. Entscheidend sind auch Nutzung, Komplexität, Zielgruppe und Wartungsaufwand.
Genie ist nur so verlässlich wie sein Datenkontext
Genie kann technisch gültige SQL-Abfragen erzeugen, die fachlich trotzdem nicht der gewünschten Definition entsprechen.
Das Risiko steigt, wenn:
- Tabellen schlecht beschrieben sind,
- mehrere Kennzahlen denselben Namen tragen,
- ungeeignete Tabellen freigegeben wurden,
- Geschäftsbegriffe fehlen,
- keine Beispielabfragen gepflegt werden,
- Änderungen nicht nachgezogen werden.
Ein produktiver Genie Space benötigt deshalb fachliche Tests, Monitoring und klare Verantwortlichkeiten.
SQL-Warehouse-Kosten benötigen aktive Steuerung
Interaktive BI-Workloads können stark schwankende Last erzeugen.
Kosten steigen unter anderem durch:
- dauerhaft laufende Warehouses,
- zu große Compute-Konfigurationen,
- fehlendes Auto-Stop,
- viele parallele DirectQuery-Abfragen,
- ineffiziente Datenmodelle,
- unnötig große Tabellen-Scans,
- gemeinsame Warehouses für sehr unterschiedliche Workloads.
Kostenkontrolle sollte daher von Anfang an Teil der Architektur sein und nicht erst nach dem ersten ungewöhnlich hohen Monatsverbrauch beginnen.
Self-Service kann neue Inkonsistenzen erzeugen
Mehr Self-Service bedeutet nicht automatisch bessere Entscheidungen.
Wenn Fachanwender auf unklare Tabellen und uneinheitliche Kennzahlen zugreifen, entstehen zusätzliche Interpretationen derselben Daten. Natürlichsprachliche Abfragen können dieses Problem sogar verstärken, weil Ergebnisse sehr einfach und überzeugend präsentiert werden.
Self-Service sollte deshalb auf kuratierte Datenprodukte begrenzt und mit Governance verbunden werden.
Bestehende BI-Investitionen lassen sich nicht kurzfristig ablösen
Power BI, Tableau und andere BI-Plattformen sind häufig tief in Prozesse und Anwendungen integriert.
Dazu gehören:
- Report-Bibliotheken,
- Schulungen,
- Berechtigungskonzepte,
- Embedded Analytics,
- Mobile-Nutzung,
- Abonnements und Exporte,
- Freigabeprozesse,
- Supportstrukturen.
Eine Ablösung ist deshalb mehr als eine technische Migration. Sie verändert Arbeitsweisen, Verantwortlichkeiten und teilweise Geschäftsprozesse.
In vielen Unternehmen ist es wirtschaftlicher, zunächst die Datenbasis zu vereinheitlichen und die Frontends schrittweise zu bewerten.
Fazit
Business Intelligence auf Databricks beginnt nicht mit der Entscheidung für ein neues Dashboard-Werkzeug.
Die wichtigste Grundlage ist eine gemeinsame Datenbasis: kuratierte Gold-Tabellen, verbindliche KPI-Definitionen, nachvollziehbare Berechtigungen, ein passendes SQL-Warehouse-Konzept und klare Verantwortlichkeiten. Erst auf dieser Basis sollte entschieden werden, welche Werkzeuge für welche Nutzergruppen sinnvoll sind.
Power BI oder Tableau können weiterhin das zentrale Frontend bleiben. AI/BI Dashboards eignen sich für neue und plattformnahe Auswertungen. Genie kann Self-Service für klar abgegrenzte Fachbereiche ergänzen.
Eine hybride Architektur ist dabei kein Nachteil, solange die Aufgaben eindeutig verteilt sind.
Für jede BI-Plattform sollten deshalb fünf Fragen beantwortet sein:
- Wo werden Kennzahlen verbindlich definiert?
- Welche Tabellen sind für das Reporting freigegeben?
- Welches Tool ist für welche Zielgruppe vorgesehen?
- Wer verantwortet Reports, Datenprodukte und Genie Spaces?
- Wie werden Nutzung, Qualität und Compute-Kosten überwacht?
Der sinnvollste Einstieg ist eine Bestandsaufnahme der vorhandenen BI-Landschaft. Dabei sollten nicht nur Lizenzen und Reports gezählt werden. Entscheidend ist, welche Datenquellen, Kennzahlendefinitionen und Verantwortlichkeiten hinter den jeweiligen Werkzeugen liegen.
Auf dieser Grundlage lässt sich entscheiden, ob der nächste Schritt eine konsolidierte Gold-Schicht, ein semantisches Modell, eine SQL-Warehouse-Optimierung oder ein erster klar begrenzter Genie-Anwendungsfall sein sollte.
Wo liegen die größten Hebel in eurer BI-Landschaft?
In einem Analytics-Assessment analysieren wir eure Datenbasis, BI-Werkzeuge, Kennzahlendefinitionen und Compute-Struktur. Als Ergebnis erhaltet ihr eine priorisierte Zielarchitektur und konkrete nächste Schritte für eure BI-Plattform.
- welche KPIs heute mehrfach oder unterschiedlich definiert werden
- welche Reports auf getrennten Datenquellen basieren
- welche Datenprodukte sich als gemeinsame Gold-Schicht eignen
- welche BI-Tools weiterhin einen klaren Nutzen haben
- wo AI/BI Dashboards oder Genie sinnvoll eingesetzt werden können
- wie sich SQL-Warehouse-Kosten transparenter steuern lassen
- welcher Migrations- und Konsolidierungspfad realistisch ist
FAQ
Business Intelligence auf Databricks bedeutet, dass Reports, Dashboards und Self-Service-Analysen auf einer gemeinsamen Lakehouse-Datenbasis aufsetzen. Die Daten liegen typischerweise in kuratierten Delta-Tabellen unter Unity Catalog. SQL Warehouses stellen die Abfrageleistung bereit. Als Frontend können AI/BI Dashboards, Power BI, Tableau und andere BI-Werkzeuge eingesetzt werden.
