Databricks Unity Catalog: Zentrale Kennzahlen für Power BI

Vertrieb und Controlling nutzen dieselben Daten, melden aber unterschiedliche Umsätze: Häufig liegt das nicht an fehlerhaften Tabellen, sondern an abweichenden Berechnungsregeln. Mit Databricks Unity Catalog lassen sich solche Regeln in Metric Views zentral festlegen. Eine neue Veröffentlichungsfunktion soll diese Definitionen nun auch in Power BI Semantic Models bringen. Für mittelständische Unternehmen mit Azure Databricks und Power BI ist das ein interessanter Ansatz: Die vertraute Berichtsoberfläche bleibt, während gemeinsame Kennzahlen näher an der Datenplattform gepflegt werden.

Kurz gesagt: Mit „Publish to Power BI“ können Unternehmen Unity Catalog Metric Views als Tabellen mit Dimensionen und DAX Measures in Power BI Semantic Models veröffentlichen. Die Funktion ist als Private Preview beschrieben und kann doppelte Kennzahlenpflege reduzieren; automatische Aktualisierungen erfordern eine entsprechende Orchestrierung über Power BI tasks in Lakeflow Jobs. Für die Zugriffskontrolle ist entscheidend, ob Power BI DirectQuery oder Import mode verwendet.

Was ist neu an Databricks Unity Catalog für Power BI?

Neu ist die Möglichkeit, zentral definierte Unity Catalog Metric Views direkt in Power BI Semantic Models zu veröffentlichen, statt ihre Kennzahlenlogik dort separat nachzubauen.

Eine Metric View beschreibt fachliche Kennzahlen und die Dimensionen, nach denen sie ausgewertet werden. Dazu gehören beispielsweise Nettoumsatz, Auftragsanzahl oder Umsatz je Kunde sowie Merkmale wie Standort, Produktgruppe und Vertriebsgebiet.

Beim Veröffentlichen wird jede Metric View zu einer Tabelle im Power BI Semantic Model. Ihre Dimensionen erscheinen als Spalten, ihre Measures als DAX Measures. Auch Beschreibungen und Anzeigeformate, etwa für Währungen oder Prozentwerte, werden übernommen.

Power BI fragt dabei die Metric View ab, nicht unmittelbar deren zugrunde liegende Tabellen. Joins innerhalb der Metric View werden in Databricks ausgeführt. Bereits eingebundene Dimensionen stehen dadurch in Power BI als Spalten bereit; diese Verknüpfungen musst du dort nicht erneut modellieren.

Das ersetzt allerdings nicht automatisch sämtliche bestehenden Power BI-Modelle. Entscheidend ist, welche fachlichen Definitionen sich sinnvoll zentralisieren lassen und welche berichtsspezifischen Anforderungen zusätzlich bestehen.

Warum ist das für den deutschen Mittelstand relevant?

Die Integration ist vor allem für Unternehmen relevant, die Azure Databricks als Datenplattform und Power BI für Berichte einsetzen und dieselben Kennzahlen bislang mehrfach pflegen.

In solchen Umgebungen entstehen Berechnungen oft verteilt: im Data Engineering, in einzelnen Power BI-Modellen und später noch einmal für KI-Anwendungen. Ändert sich eine Definition, müssen mehrere Verantwortliche nachziehen. Bleibt eine Kopie unverändert, widersprechen sich Auswertungen trotz gemeinsamer Datenbasis.

Beispiel: Nettoumsatz einheitlich festlegen

Ein typisches, hypothetisches Szenario: Ein mittelständischer Hersteller möchte Nettoumsatz nach Werk und Produktgruppe auswerten. Vor der technischen Umsetzung muss er festlegen:

• Werden Gutschriften dem Rechnungsmonat oder dem ursprünglichen Verkaufsmonat zugeordnet?
• Welche internen Lieferungen werden ausgeschlossen?
• Welcher Wechselkurs gilt für Fremdwährungsumsätze?
• Wie werden nachträgliche Korrekturen berücksichtigt?

Sind diese Regeln verbindlich definiert, kann eine Metric View die gemeinsame Berechnungsgrundlage bilden. Power BI und Databricks-Anwendungen wie AI/BI dashboards oder Genie können dieselben Definitionen nutzen. Vergleichbare Ergebnisse setzen dabei weiterhin gleiche Filter, Datenstände und Zugriffsrechte voraus.

Der Nutzen liegt also nicht allein im Veröffentlichen von Metadaten. Du reduzierst die Zahl der Stellen, an denen fachliche Logik unabhängig voneinander verändert wird. Dafür braucht deine Datenplattform neben Technik auch klare Verantwortlichkeiten für Kennzahlen.

Wie funktionieren Veröffentlichung und laufende Aktualisierung?

Die Veröffentlichung erfolgt entweder manuell über Catalog Explorer oder automatisiert durch einen Power BI task innerhalb eines Lakeflow Job.

Für einen ersten Test genügt der manuelle Weg: Metric View vorbereiten, „Publish to Power BI“ auswählen, mit Power BI-Anmeldedaten anmelden und den Ziel-Workspace bestimmen. In der beschriebenen Vorbereitung müssen Eingaben für Measures als Dimensionen ergänzt und alle Felder benannt sein.

Aus einer Veröffentlichung wird ein geregelter Prozess

Für einen dauerhaften Betrieb solltest du die Veröffentlichung in deine Datenverarbeitung einbinden. Ein Power BI task kann beispielsweise nach der Aktualisierung vorgelagerter Tabellen oder nach einem Zeitplan laufen. So lassen sich neue Dimensionen sowie geänderte oder zusätzliche Measures in das Zielmodell übertragen.

Wichtig ist die Richtung: Die Synchronisierung läuft von Unity Catalog nach Power BI, nicht zurück. Änderst du ein veröffentlichtes Measure direkt in Power BI, wird diese Änderung nicht in die Metric View übernommen.

Lege deshalb fest, wo verbindliche Kennzahlen geändert werden dürfen. Gemeinsame Definitionen gehören in diesem Ansatz nach Databricks; lokale Ergänzungen in Power BI brauchen eine klare Abgrenzung. Andernfalls entsteht trotz zentraler Technik erneut widersprüchliche Logik.

Welche Governance gilt bei DirectQuery und Import mode?

Bei DirectQuery greifen die Unity Catalog-Zugriffskontrollen für die Abfragen; im Import mode gelten für die nach Power BI geladene Datenkopie die dortigen Berechtigungen.

Diese Unterscheidung ist für sensible Vertriebs-, Finanz- oder Personaldaten wesentlich. Ein zentral gepflegtes Measure bedeutet nicht automatisch, dass jede Nutzung seiner Daten denselben Sicherheitsmechanismen unterliegt.

• DirectQuery: Power BI fragt die Daten in Databricks ab. Unity Catalog-Zugriffskontrollen und Sicherheitsrichtlinien bleiben für diese Abfragen wirksam.
• Import mode: Daten werden nach Power BI geladen. Berechtigungen und Aktualisierung dieser Kopie müssen im Power BI-Betrieb geregelt werden.

Für dein Azure-Umfeld solltest du deshalb Identitäten, Workspace-Zugriffe und gegebenenfalls zeilenbezogene Einschränkungen im Zusammenspiel testen. Ebenso wichtig: Wer darf veröffentlichen, wer darf das Semantic Model bearbeiten und wer lediglich Berichte nutzen? Die Integration ersetzt weder diese Entscheidungen noch eine Datenschutzprüfung.

Was solltest du vor einem Einsatz prüfen?

Die Funktion ist eine Private Preview. Der Zugang erfolgt laut Ankündigung über das zuständige Databricks-Account-Team. Plane daher zunächst einen abgegrenzten Test statt einer sofortigen Umstellung geschäftskritischer Berichte.

Der beschriebene Funktionsumfang umfasst unter anderem Standardaggregationen, Distinct Counts, Verhältniszahlen, gefilterte und zusammengesetzte Measures sowie Window Measures. Ob deine vorhandenen Berechnungen vollständig abgedeckt werden, solltest du anhand konkreter Modelle prüfen.

Eine sinnvolle Prüfliste für den Pilot

• Fachlichkeit: Stimmen Ergebnisse einschließlich Sonderfällen mit der freigegebenen Kennzahlendefinition überein?
• Modellierung: Kommen Dimensionen, DAX Measures, Beschreibungen und Formate korrekt an?
• Berechtigungen: Sehen unterschiedliche Nutzergruppen ausschließlich die vorgesehenen Daten?
• Änderungen: Was passiert mit abhängigen Berichten, wenn Felder umbenannt oder entfernt werden?
• Betrieb: Wie werden fehlgeschlagene Veröffentlichungen erkannt und korrigiert?
• Wirtschaftlichkeit: Welche Antwortzeiten und Databricks-Compute-Kosten entstehen unter realistischer Berichtslast?

Bei Leistungsversprechen ist Zurückhaltung sinnvoll. Die Nutzung von Metric View Materialization für Power BI-Abfragen wird als bevorstehende Erweiterung beschrieben, nicht als bereits verfügbare Grundlage. Triff deine Architekturentscheidung deshalb anhand gemessener Ergebnisse im eigenen Setup. Eine gezielte Databricks Beratung kann dabei helfen, Modellierung, Berechtigungen und Betrieb gemeinsam zu bewerten.

Was das für dich bedeutet

Wenn dein Unternehmen bereits Azure Databricks und Power BI nutzt, eröffnet die Integration einen Weg zu weniger doppelter Kennzahlenpflege. Power BI bleibt die Oberfläche für Fachbereiche, während gemeinsam genutzte Definitionen zentral verwaltet werden können. Bestehende Berichte werden dadurch jedoch nicht automatisch vereinheitlicht: Fachliche Abstimmung, Modellprüfung und ein kontrollierter Veröffentlichungsprozess bleiben notwendig.

Starte mit einem überschaubaren Fachbereich und verbindlich definierten Kennzahlen. Du möchtest prüfen, ob dieser Ansatz zu deiner Datenarchitektur passt? Sprich mit Ailio über deinen Databricks- und Power BI-Piloten.

Redaktionelle Einordnung auf Basis eines Beitrags im Databricks-Blog.