Unity Catalog Glossary: Fachbegriffe an Tabellen und Spalten verankern

Im Quartalsmeeting werden drei unterschiedliche Umsatzzahlen vorgestellt: Vertrieb meldet 14,2 Millionen, Finance 12,7 Millionen, Customer Success spricht von 9,4 Millionen ARR. Jede Zahl lässt sich erklären, stammt aus einem eigenen Dashboard und wird von einem eigenen Team verantwortet. Eine verbindliche Definition von Umsatz gibt es trotzdem nicht. Im Audit-Gespräch zwei Monate später fragt der Prüfer, wer den Begriff Umsatz im Konzern verantwortet. Eine klare Antwort gibt es nicht, weil die Definition gleichzeitig in Confluence, Collibra und einem Tableau-Modell gepflegt wird und niemand weiß, welche Version gilt.

In wachsenden Datenplattformen entsteht dieses Problem meist schrittweise. Ein Datenprodukt-Team beschreibt seine Tabellen, ein BI-Team baut sein Semantic Model, ein Compliance-Team klassifiziert PII-Spalten. Jedes Team baut seine eigene Begriffswelt auf. Die Definitionen liegen verteilt in unterschiedlichen Tools, aber keine Definition ist verbindlich mit der Tabelle oder Spalte verbunden, aus der die Zahl berechnet wird. Im Unity Catalog selbst ist die fachliche Definition nicht sichtbar. In Collibra steht die Definition, aber der direkte Bezug zur produktiven Tabelle fehlt. In Confluence findet sich ein Wiki, das seit zwei Jahren nicht aktualisiert wurde.

Welche Definition von „aktiver Kunde“ ist verbindlich, wenn drei Teams drei verschiedene Sichten haben? Wer ist fachlich verantwortlich für die Definition von Customer Lifetime Value, wenn das Datenprodukt-Team weiterzieht? Warum widersprechen sich KPI-Reports auf Vorstandsebene, obwohl alle dieselbe Tabelle nutzen? Wie sieht ein Audit-Trail für die Änderung einer Compliance-Klassifikation aus? Wo ist sichtbar, welche Tabelle oder Spalte eine bestimmte Definition tatsächlich verwendet?

Eine weitere Wiki-Seite löst dieses Problem nicht. Benötigt wird eine Begriffsschicht direkt an den Datenobjekten: mit klarer Verantwortung, Änderungshistorie und Bezug zum Asset. Unity Catalog bringt diese Schicht als Glossary-Funktion mit. Das Glossar bleibt ein Glossar. Entscheidend ist, dass es direkt an der Datenplattform verankert wird.

Data Dictionary, Business Glossary und Data Catalog sollten getrennt verstanden werden: Das Data Dictionary beschreibt technische Details wie Datentyp, Name und Wertebereich. Das Business Glossary beschreibt, was ein Begriff fachlich bedeutet. Der Data Catalog macht technische Informationen, fachliche Bedeutung, Lineage und Berechtigungen gemeinsam auffindbar. Das UC-Glossary ist der Glossary-Anteil dieser drei Schichten, verankert im Catalog und getrennt vom Dictionary und vom Semantik-Modell.

Ohne Pflegeprozess veraltet ein Glossar genauso schnell wie ein Wiki. Die technische Verknüpfung mit Tabellen und Spalten hilft nur, wenn klar ist, wer Begriffe fachlich verantwortet und Änderungen pflegt.

Jeder wichtige Begriff braucht einen fachlichen Steward. Für zentrale Begriffe sollte eine verantwortliche Rolle oder Person benannt sein. Diese Person pflegt Definition, Verknüpfungen mit Datenobjekten und spätere Änderungen. Die Verantwortung sollte fachlich in der Domäne liegen, nicht beim Plattform-Team. Das Plattform-Team betreibt die technische Struktur, der Steward verantwortet den Inhalt. Unity Catalog kann diese Trennung über Berechtigungen abbilden: Stewards bearbeiten ihre Begriffe, das Plattform-Team verwaltet die Glossar-Struktur.

Ein typisches Beispiel ist „Aktiver Kunde“. Vertrieb und Finance nutzen dafür oft unterschiedliche Definitionen. Für den Vertrieb kann ein aktiver Kunde jemand sein, der in den letzten 12 Monaten gekauft hat. Für Finance kann es ein Kunde mit offener Rechnung im laufenden Geschäftsjahr sein.

Im Glossar sollten diese Definitionen nicht vermischt werden. Beide Begriffe werden getrennt geführt, klar benannt, mit eigenen Stewards und den passenden Datenobjekten verknüpft. So ist sichtbar, welche Definition gemeint ist, wer sie verantwortet und auf welcher Datenbasis sie beruht. Eine Auswertung nach „Aktiver Kunde“ liefert dann nicht blind eine Zahl, sondern macht zuerst die zugrunde liegende Definition klar.

Viele Unternehmen nutzen bereits Collibra, Atlan oder Alation, bevor Unity Catalog als Glossar-Schicht dazukommt. Diese Tools bringen reife Workflows, Stewardship-Oberflächen und Reporting-Funktionen mit. Die entscheidende Frage ist deshalb nicht: externes Tool oder Unity Catalog? Sondern: Wo liegt die verbindliche Verbindung zwischen Begriff und Datenobjekt?

Externe Glossar-Tools pflegen Begriffe häufig als eigene Objekte und verbinden sie über Connectoren oder Links mit Databricks-Assets. Das kann gut funktionieren, führt im Alltag aber schnell zu einer Lücke: Das Glossar wird gepflegt, ist aber nicht dort sichtbar, wo Nutzer tatsächlich mit Tabellen, Spalten und Berechtigungen arbeiten.

Der UC-native Ansatz setzt näher am Datenobjekt an. Begriffe werden direkt mit Tabellen, Spalten oder anderen Assets in Unity Catalog verbunden. Freigabeprozesse, Stewardship-Dashboards und Reporting können über externe Tools ergänzt werden, ohne diese Verbindung zu verlieren.

Drei Modelle sind typisch:

Unity Catalog als alleinige Begriffsschicht. Das passt, wenn Databricks die zentrale Datenplattform ist und kein umfangreiches externes Governance-Tool benötigt wird. UC ist stark bei Definition, Asset-Bindung und Nähe zur Datenplattform. Schwächer ist es heute bei komplexen Freigabeprozessen und umfangreichem Governance-Reporting.

Collibra, Atlan oder Alation als ergänzende Workflow-Schicht. Das externe Tool übernimmt dann Freigaben, Stewardship, Reporting und gegebenenfalls die Cross-System-Sicht über Databricks hinaus. Unity Catalog bleibt aber der Ort, an dem Begriffe verbindlich mit Databricks-Objekten verbunden sind. Über Integrationen wie die Collibra Databricks Integration oder Atlan-Databricks-Connectoren können Metadaten zwischen den Systemen ausgetauscht werden.

Glossar im Wiki oder SharePoint. Das ist oft der Startpunkt, aber keine belastbare Begriffsschicht in der Datenplattform. Ein Wiki kann Übergangsdokumentation sein. Es fehlt aber die feste Verbindung zu Tabellen, Spalten, Ownern und Berechtigungen. Für prüfungsrelevante Kennzahlen oder zentrale Fachbegriffe reicht das langfristig meist nicht aus.

Die UC-native Begriffsschicht ist noch im Aufbau. Die technische Grundlage ist nutzbar, aber Workflows und Oberflächen sind noch nicht so ausgereift wie bei spezialisierten Tools. Diese Einschränkungen sollten vor einem Rollout offen besprochen werden.

Metric Views sind seit April 2026 als Schicht selbst GA, die Materialisierung läuft als Preview. Genie Spaces ziehen daraus schon heute Synonyme, Display Names und Beispielfragen für die Genie Ontology: die Verbindung zu Genie entsteht heute vor allem über gepflegte Tags, Beschreibungen und Metric Views.

Die Konsequenz für den Rollout: Unity Catalog kann heute die verbindliche Asset-Verknüpfung tragen. Für komplexe Workflows, Reporting und Stewardship-Oberflächen kann ein externes Tool oder eine eigene Automatisierung ergänzt werden.

Ein Unity Catalog Glossary schafft verbindliche Kurzdefinitionen und verbindet Begriffe mit Tabellen, Spalten oder Views. Es ersetzt aber keine vollständige Governance- oder Dokumentationsschicht.