Unity Catalog Business Semantics: Metric Views für BI, Genie und KI

Im Quartalsmeeting stehen drei Zahlen für denselben Sachverhalt im Raum: das Vertriebsdashboard zeigt 14,2 Millionen Umsatz, das Finance-Dashboard 12,7 Millionen, das Customer-Success-Dashboard meldet 9,4 Millionen ARR. Für jede Zahl gibt es eine eigene Erklärung und ein verantwortliches Team. Eine verbindliche Definition wird trotzdem nicht beschlossen. Zwei Wochen später aktiviert das Plattformteam Genie auf den gleichen Tabellen, mit der Erwartung, dass eine Frage in natürlicher Sprache eine eindeutige Antwort liefert. Genie liefert Antworten, die plausibel klingen, nutzt dabei aber nicht automatisch die fachlich richtige Definition.

In wachsenden Datenplattformen entsteht diese Situation schrittweise. Mehrere Bereiche bauen eigene Sichten und Kennzahlen auf derselben Datenbasis. Dabei verwendet jedes Team eine Definition, die für den eigenen Zweck passt, etwa für Begriffe wie Kunde oder Umsatz. Die bestehenden Definitionsunterschiede werden dadurch in das Lakehouse übernommen. Technische Governance und Lineage lösen diese fachlichen Unterschiede nicht von selbst. Werden Definitionen getrennt in BI-Tools und Dokumentationen gepflegt, greifen die einzelnen Plattformkomponenten auf unterschiedliche semantische Grundlagen zurück. Genie orientiert sich dann stark an technischen Namen, Kommentaren und Beispielen im jeweiligen Space. Power BI nutzt das semantische Modell des BI-Teams. Eine externe Lösung wie dbt nutzt ihre eigene Definition. Das Ergebnis bleiben unterschiedliche Kennzahlen für denselben fachlichen Sachverhalt.

Self-Service macht bestehende Definitionsunterschiede schneller sichtbar. Durch KI-gestützte Abfragen steigt zusätzlich das Risiko weiterer abweichender Interpretationen, da fachlich falsche Antworten trotzdem überzeugend klingen können.

Welche Tabelle ist für Umsatz verbindlich? Welche Definition gilt für einen aktiven Kunden? Warum zeigt Genie eine andere Zahl als das offizielle Dashboard? Gehören Kennzahlen ins Lakehouse oder ins BI-Tool? Welches Team übernimmt die Pflege, wenn das Datenprodukt-Team weiterzieht?

Eine weitere Tabelle löst das Definitionsproblem nicht. Benötigt wird ein gemeinsamer Ort für Begriffe, Kennzahlen und ihre Berechnung: sichtbar für BI, für Genie und für jeden KI-Assistenten, der auf Unternehmensdaten antworten soll. Databricks bündelt diese Funktionen unter Business Semantics in Unity Catalog. Sie bildet den nativen semantischen Layer der Databricks-Plattform.

Kommentare und Tags allein sorgen noch nicht dafür, dass eine Kennzahl überall gleich berechnet wird. Sie helfen beim Verständnis, legen aber keine Berechnung fest. Ein Kommentar auf der Spalte revenue kann sagen, dass es sich um signiertes Vertriebsvolumen handelt. Unterschiedliche Teams können weiterhin abweichende Filter und Aggregationen verwenden. Auch Genie kann ohne verbindliche Berechnung eine weitere Variante erzeugen.

Metric Views machen eine Kennzahl zu einem eigenen verwalteten Objekt in Unity Catalog. Eine Metric View für „Umsatz Vertriebssicht“ enthält die Quelltabelle, die Filter, die Aggregation und die Dimensionen. Quelle, Filter, Aggregation und Dimensionen werden an einer Stelle festgelegt und können von SQL, Genie und BI-Tools genutzt werden. Wenn ein Analyst in Databricks SQL „Umsatz nach Region“ abfragt, wenn Genie auf die Frage „Wie viel haben wir letztes Quartal gemacht?“ reagiert und wenn ein Power-BI-Bericht denselben Kennwert zieht, nutzen alle dieselbe Berechnung. Daniel Beach beschreibt Metric Views in seiner Analyse als first-class semantic-layer objects, die im Unity Catalog leben.

Zusätzlich kann die Materialisierung häufig genutzter Kennzahlen helfen. Metric Views lassen sich pre-aggregieren und inkrementell aktualisieren, die Query-Engine schreibt Anfragen automatisch auf die materialisierte Variante um. Dieselbe semantische Definition kann dadurch sowohl für flexible Analysen als auch für wiederkehrende Dashboard-Abfragen genutzt werden. Separat gepflegte Aggregationstabellen können dadurch teilweise entfallen.

Metric Views können in YAML definiert werden. Damit können sie als versionierbare Definitionen außerhalb eines einzelnen BI-Tools verwaltet werden. Bestehende Transformations-Tools wie dbt können Metric-View-Definitionen erzeugen. Plattformteams, die ihre Pipelines schon in Code führen, können Kennzahlendefinitionen in bestehende Review- und Deployment-Prozesse aufnehmen. Änderungen an Kennzahlen können dadurch versioniert und im Pull Request geprüft werden.

Der Unterschied zu reinen Metadaten ist wichtig: Kommentare beschreiben, Metric Views berechnen. Dadurch entsteht ausführbare Geschäftslogik statt ausschließlich dokumentierter Bedeutung.

Unity Catalog bietet vier Wege, Bedeutung an Daten zu bringen, die oft vermischt werden, aber unterschiedliche Aufgaben haben. Ohne klare Aufgabenverteilung landet dieselbe Information schnell in mehreren davon, oft mit widersprüchlichen Aussagen zum selben Begriff. Die Tabelle ordnet die vier nach Aufgabe:

Praktisch heißt das: Wer „aktiver Kunde“ sauber definieren will, braucht mehr als einen Glossar-Eintrag. Eine Metric View, die count_distinct(customer_id) WHERE last_activity_at >= current_date - interval '90 days' ausdrückt. Und einen Glossar-Eintrag, der den Begriff erklärt, auf die Metric View verweist und Synonyme wie „Active Account“ oder „Bestandskunde“ abbildet. Der Glossar-Eintrag erklärt den Begriff, die Metric View berechnet ihn. Tags ordnen das Ganze einer Domäne zu, Comments helfen beim Stöbern auf der Tabelle darunter.

Wer nur mit einem Glossar startet, hat am Ende oft eine lange Begriffsliste, ohne dass eine einzige Kennzahl verbindlich berechnet wird. Ein Setup mit nur Comments und Tags ergibt gut beschriftete Tabellen, aber weiterhin mehrere Wahrheiten für denselben Wert. Die vier Mechanismen tragen, wenn sie kombiniert werden. Wie ein UC-natives Glossar funktioniert und wo seine Grenze zur Metric View liegt, behandeln wir im Überblick zu Glossary in Unity Catalog; wie Tags als Träger semantischer Hinweise eingesetzt werden, im Überblick zu Tags in Unity Catalog.

In der Realität können Kennzahlen an mehreren Orten definiert werden, und häufig werden mehrere davon gleichzeitig genutzt. Power BI bringt sein Semantic Model mit, Tableau hat seine Calculations, dbt Semantic Layer wächst stark. Das wachsende Interesse an externen semantischen Layern zeigt, dass das Thema zunehmend plattformübergreifend betrachtet wird. Cube, AtScale und LookML decken denselben Anspruch in eigenen Architekturen ab.

Keine dieser Schichten löst alle Anforderungen allein. Entscheidend ist eine klare Aufteilung:

Drei Zielbilder sind besonders naheliegend:

Power BI verbindet sich im ersten Zielbild über den Databricks-Connector mit den UC-Objekten, das BI-Modell kann sich stärker auf Visualisierung, Benutzerführung und berichtsspezifische Logik konzentrieren.

Entscheidend ist vor allem, ob die Daten- und Analyseplattform langfristig auf Databricks konzentriert bleibt. Bei mehreren Datenplattformen kann eine zusätzliche plattformübergreifende Semantikschicht erforderlich sein. Wenn Databricks die zentrale Datenplattform ist, kann ein externer Layer oft entfallen. Auf der Konsumenten-Seite integrieren zunehmend mehr BI- und Katalogwerkzeuge die in Unity Catalog gepflegten Definitionen: Tableau, Sigma, Hex, ThoughtSpot, Omni, Atlan und Collibra haben Integrationen für UC Business Semantics angekündigt oder ausgerollt. Das verändert die Marktfrage. Ein externer Layer sollte dann eher UC-Definitionen nutzen, statt dieselben Kennzahlen erneut zu definieren.

Power BI bringt mit dem Semantic Model (vormals Dataset) eine eigene Semantik-Schicht mit: DAX-Measures, berechnete Spalten, Hierarchien, RLS-Regeln, Beziehungen. Diese Schicht ist nah am Reporting gebaut und an die Berichtswerkzeuge in Power BI gekoppelt. Sie verschwindet nicht, wenn Unity Catalog Metric Views eingeführt werden. Die Frage ist, welche Logik wohin gehört.

Die saubere Trennung ist einfach: Plattformweit verwendete Kennzahlen gehören in Unity Catalog, berichtsspezifische Darstellung und Interaktion bleiben im Power BI Semantic Model.

Praktisch heißt das: Das Power BI Semantic Model wird schlanker, aber nicht überflüssig. Wiederkehrende, plattformweit relevante Measures verlagern sich nach UC. Power BI bezieht sie über den Databricks-Connector und nutzt sie als Grundlage für visualisierungsnahe Aufbereitung. Wer das Power BI Semantic Model unverändert lässt und zusätzlich Metric Views einführt, pflegt dieselbe Logik doppelt und schafft zwei mögliche Wahrheiten.

Mein Vorschlag für den Übergang: Jede neue plattformweit relevante Kennzahl wird ab sofort als Metric View in UC angelegt. Bestehende DAX-Measures werden nicht pauschal migriert. Migriert werden Kennzahlen, die in mehreren Berichten genutzt werden oder von Genie verlässlich beantwortet werden sollen. Bericht-spezifische Sonderfälle bleiben in Power BI, klar als berichtsspezifisch markiert. Wie die Power-BI-Anbindung an Databricks technisch funktioniert, behandeln wir im Überblick zur Power-BI-Integration.

Business Semantics ersetzt keine fachliche Verantwortung und keine Freigabeprozesse. Auch produktseitig gibt es noch Grenzen, die vor einem produktiven Rollout bekannt sein sollten.

Diese Grenzen sprechen nicht gegen den Einsatz, aber gegen einen großen Rollout ohne Pilot. Wie der gesamte Unity Catalog als Governance- und Semantik-Schicht aufgebaut ist, zeigen wir im Überblick zu Unity Catalog auf Databricks.