Unity Catalog Tags: Governance, ABAC und FinOps konsistent steuern
Die Kernaussagen auf einen Blick.
- Unity Catalog Tags helfen dabei, Datenobjekte eindeutig einzuordnen: Welche Daten sind sensibel, zu welcher Domäne gehören sie, wer ist verantwortlich und welche Kostenstelle ist betroffen?
- Der Nutzen entsteht nur, wenn Tags einheitlich vergeben werden. Wenn jedes Team eigene Begriffe nutzt, funktionieren Governance, Suche, Maskierung und Kostenberichte nur unvollständig.
- Für den Start reichen wenige verbindliche Angaben wie pii, domain, data_owner, cost_center und lifecycle. Diese Werte sollten klar definiert und technisch geprüft werden.
- Tags sollten nicht nachträglich per Hand gepflegt werden. Sie gehören in den Anlage- und Deployment-Prozess von Catalogs, Schemas und Datenprodukten, zum Beispiel über Terraform, CI/CD oder den Datenprodukt-Code.
Inhaltsverzeichnis
Fünf Schreibweisen für dieselbe Domäne
In vielen Plattform-Reviews zeigt sich ein ähnliches Bild: Unity Catalog steht, ein paar Teams haben Tags vergeben, ABAC ist bereits geplant, FinOps benötigt eine Kostenauswertung nach Domänen. Im bestehenden Tag-Bestand finden sich jedoch mehrere Schreibweisen für dieselbe Domäne, drei verschiedene Schlüssel für Klassifikation und zusätzlich gibt es Tags, deren Schlüssel und Werte keine klar definierte Bedeutung haben. Die geplante PII-Maskierung erfasst nur einen kleinen Teil der Tabellen, weil die erforderlichen Tags fehlen. FinOps muss die Auswertung weiterhin ausschließlich auf Compute-Tags stützen, weil sich ohne einheitliche Domänen-Tags Datenobjekte nicht zuverlässig den Kosten zuordnen lassen.
Diese Situation tritt häufig auf, sobald mehrere Teams parallel onboarden. Tags werden häufig einzeln für konkrete Anforderungen oder Pilotprojekte eingeführt; ein übergreifendes Tag-Modell fehlt dabei. Teams, die PII klassifizieren wollen, vergeben pii, pii_level, sensitivity, confidential parallel. Jeder einzelne Tag wirkt nachvollziehbar, gemeinsam ergeben sie jedoch kein konsistentes Modell.
Vor der Einführung weiterer Tags sollten drei Fragen beantwortet werden:
Zweck
Für welchen konkreten Zweck wird der Tag verwendet? Soll er Richtlinien, Kostenanalysen, Discovery oder mehrere dieser Bereiche unterstützen?
Verantwortung
Wer ist für die Vergabe verantwortlich und auf welcher Objektebene erfolgt sie, und wann muss er da sein?
Umgang mit Fehlern
Wie wird mit fehlenden oder ungültigen Tags umgegangen?
Ohne diese Festlegungen werden Tags lediglich zu zusätzlichen, uneinheitlich gepflegten Metadaten. Mit klaren Regeln können Tags dagegen als verbindende Schicht zwischen Datenobjekten und Policies dienen. Die Qualität des Tag-Modells beeinflusst wesentlich, ob Governance-Regeln zuverlässig greifen. Andernfalls bleibt die Governance von manueller Nachpflege abhängig.
Object Tags sind zusätzliche Informationen direkt am Datenobjekt. Sie beschreiben zum Beispiel, zu welcher Domäne eine Tabelle gehört, ob eine Spalte sensible Daten enthält oder für welche Umgebung ein Objekt gedacht ist.
Im Unity Catalog können solche Tags an vielen Objekten hinterlegt werden: an Catalogs, Schemas, Tabellen, Views, Spalten, Volumes, Funktionen und Modellen (Registered Model, Model Version), in Public Preview auch an External Metadata. Typische Beispiele sind domain=finance, environment=prod oder data-classification=pii.
Damit lassen sich Datenobjekte über die technische Verwaltung hinaus fachlich einordnen. Tags helfen bei Kosten-Auswertungen, bei der Suche nach verantwortlichen Teams, bei Governance-Regeln und bei automatischer Maskierung über ABAC.
Tags können über SQL (ALTER ... SET TAGS), die Catalog-UI oder Infrastruktur-Code vergeben werden, zum Beispiel mit dem Terraform-Provider oder dem Databricks SDK. Entscheidend ist aber nicht die technische Vergabe, sondern das Modell dahinter: Welche Tags sind Pflicht, wer darf sie setzen, und wie bleiben sie aktuell?
Für die Nutzung von Tags sind vier Punkte besonders wichtig:
Wirkung auf Policies
Tags auf Catalogs oder Schemas helfen dabei, darunterliegende Objekte einzuordnen. ABAC-Policies, Suchfilter und System-Table-Auswertungen können diese Informationen berücksichtigen. Spalten-Tags gelten dagegen nur für die jeweilige Spalte.
Kein Wildwuchs
Ohne Regeln entstehen schnell unterschiedliche Schreibweisen wie finance, Finance oder fin. Mit Governed Tags können erlaubte Namen und Werte zentral festgelegt werden, zum Beispiel data-classification mit den Werten none, low und high. Vordefinierte System Tags von Databricks können zusätzlich als Startpunkt für Klassifikation, Ownership oder Lifecycle genutzt werden.
Zentral auswertbar
Vergebene Tags können über System Tables abgefragt werden, zum Beispiel für Catalogs, Schemas, Tabellen und Spalten. Dadurch lässt sich prüfen, welche Objekte getaggt sind, wo Pflichtangaben fehlen und welche Daten für Kosten-, Audit- oder Governance-Auswertungen relevant sind.
Technische Grenzen
Pro Objekt sind nur begrenzt viele Tags möglich, und auch Spalten-Tags haben Limits. Außerdem sind Tag-Namen case-sensitiv: Sales und sales gelten als unterschiedliche Tags. Das unterstützt den Ansatz, lieber wenige, klar definierte Tags zu nutzen als viele uneinheitliche Sonderfälle.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
In Databricks gibt es mehrere Arten von Tags. Sie klingen ähnlich, erfüllen aber unterschiedliche Aufgaben und sollten deshalb getrennt betrachtet werden.
- Object Tags beschreiben Datenobjekte im Unity Catalog, zum Beispiel Catalogs, Schemas, Tabellen oder Volumes. Sie helfen bei Governance, Suche, Ownership, Lifecycle und ABAC-Policies.
- Column Tags hängen direkt an einzelnen Spalten. Sie sind besonders wichtig für sensible Daten, weil PII meist auf Spaltenebene erkannt und geschützt werden muss und nicht auf Tabellenebene sichtbar wird.
- Compute Tags gehören zu Clustern, Jobs oder Warehouses. Sie helfen dabei, Verbrauch und Kosten den richtigen Teams, Domänen oder Kostenstellen zuzuordnen.
| Object Tag | Column Tag | Compute Tag | |
|---|---|---|---|
| Hängt an | Catalog, Schema, Tabelle, Volume | einzelne Spalte | Cluster, Job, Warehouse |
| Wofür genutzt? | Governance, Suche, Ownership, ABAC | PII-Klassifikation, Maskierung | Kosten- und Verbrauchszuordnung |
| Vererbung | kann in Auswertungen über Ebenen hinweg genutzt werden | keine automatische Vererbung | keine Vererbung |
| Auswertbar über | system.information_schema.*_tags | system.information_schema.column_tags | system.billing.usage |
Alle drei Tag-Arten sind sinnvoll, sollten aber nicht vermischt werden. Compute Tags erklären, wo Rechenkosten entstehen. Object und Column Tags erklären, welche Daten betroffen sind und welche Governance-Regeln darauf wirken. Wie diese Mechanismen im Unity Catalog zusammenspielen, ordnen wir im Überblick zu Unity Catalog ein.
Für ABAC, FinOps und Discovery reichen meist wenige, klar definierte Tags. Mehr Tags machen das Modell selten besser und erhöhen vor allem den Pflegeaufwand. In vielen Plattformen decken vier bis sechs Pflichtfelder die wichtigsten Anforderungen ab.
| Zweck | Tag | Mögliche Werte | Wofür genutzt? |
|---|---|---|---|
| PII-Klassifikation | pii | none, low, high | Maskierung und ABAC-Policies |
| Domäne | domain | finance, sales, marketing, hr, operations | Suche, Zuständigkeit, Kosten-Auswertung |
| Ownership | data_owner | domain-team-id | Verantwortlichkeit bei Rückfragen, Audit oder Vorfällen |
| Kostenstelle | cost_center | cc-1234 | Kostenverteilung über Billing-Daten |
| Lifecycle | lifecycle | raw, curated, mart | Suche, Einordnung, Aufbewahrung |
| Schutzbedarf | confidentiality | internal, restricted, secret | zusätzliche Schutzregeln oder Row Filter |
Wichtig ist: Jeder Tag sollte einen klaren Zweck haben. Ein Tag ist nur sinnvoll, wenn er später in einer Policy, einem Report, einer Suche oder einem Audit-Prozess genutzt wird. Tags ohne konkrete Verwendung erzeugen nur zusätzliche Pflege.
Allgemeine Tags wie Domäne, Kostenstelle oder Lifecycle sollten möglichst früh und einheitlich gesetzt werden, zum Beispiel auf Catalog- oder Schema-Ebene. Spezifische Tags gehören dagegen direkt an das betroffene Objekt, etwa pii=high auf eine sensible Spalte.
Außerdem sollten erlaubte Werte verbindlich definiert werden. Wenn dieselbe Domäne einmal sales, einmal Sales und einmal vertrieb heißt, funktionieren Auswertungen und Policies nicht mehr zuverlässig.
Welche Tags Pflicht sind, hängt vom Unternehmen ab. PII-Klassifikation ist in vielen europäischen Setups zentral. Lifecycle kann für Aufbewahrung und Datenmanagement wichtig sein. Kostenstellen werden vor allem dann Pflicht, wenn Databricks-Verbrauch intern sauber zugeordnet oder verrechnet werden soll.
Governed Tags sorgen dafür, dass Tags im Unity Catalog nicht beliebig vergeben werden. Sie machen aus einem Tag-Modell eine verbindliche Regel: Welche Tags darf es geben? Welche Werte sind erlaubt? Welche Tags müssen gesetzt werden? Und wer darf sie ändern?
Das ist besonders wichtig, wenn Tags über die reine Beschreibung hinaus Governance-Regeln steuern. Ein Beispiel: Wenn eine ABAC-Policy auf pii=high reagiert, darf dieselbe Klassifikation nicht einmal als pii=hoch, einmal als pii=High und einmal als personenbezogen auftauchen. Sonst greifen Policies, Auswertungen und Suchfilter nicht zuverlässig.
Governed Tags helfen an drei Stellen:
Einheitliche Werte
Für Tags wie pii oder environment können erlaubte Werte festgelegt werden, zum Beispiel none, low, high oder dev, test, prod. Abweichende Werte werden direkt bei der Vergabe abgelehnt.
Pflicht ab Anlage
Wenn neue Catalogs, Schemas oder Tabellen bestimmte Angaben brauchen, etwa domain oder data_owner, können diese Tags verpflichtend gemacht werden. Dadurch entsteht die Zuordnung direkt beim Anlegen des Objekts.
Geschützte Tags
Nicht jedes Team sollte Tags wie pii oder confidentiality ändern können. Governed Tags erlauben eine klare Trennung: Governance- oder Security-Tags werden zentral verwaltet, während organisatorische Tags weiterhin bei den zuständigen Teams liegen können.
Wichtig ist die Reihenfolge. Governed Tags sollten erst eingeführt werden, wenn das fachliche Modell steht. Zuerst müssen Namen, erlaubte Werte und Verantwortlichkeiten geklärt sein. Danach kann Unity Catalog diese Regeln technisch erzwingen. Sonst wird nur ein unfertiges Tag-Modell verbindlich gemacht.
PII-Schutz steht und fällt mit der richtigen Klassifikation auf Spaltenebene. Personenbezogene Daten liegen fast immer in konkreten Spalten: E-Mail, Name, Geburtsdatum, Telefonnummer, IBAN oder Adresse.
Ein Tag auf Tabellen- oder Schema-Ebene kann anzeigen, dass ein Objekt sensible Daten enthält. Für automatische Maskierung reicht das aber nicht aus. Die Policy muss wissen, welche konkrete Spalte geschützt werden soll. Deshalb gehört die PII-Klassifikation direkt an die betroffene Spalte.
Dabei sind zwei Punkte wichtig:
- Spalten müssen einzeln klassifiziert werden. Ein pii-Tag auf einem Catalog oder Schema überträgt sich nicht automatisch auf alle Spalten darunter. Wenn eine sensible Spalte nicht getaggt ist, wird sie von einer Maskierungsregel auch nicht zuverlässig erfasst.
- Automatische Erkennung braucht fachliche Prüfung. Databricks kann sensible Felder erkennen und Vorschläge machen. Die Entscheidung, ob eine Spalte wirklich PII enthält und welche Schutzstufe gilt, bleibt aber eine fachliche Aufgabe der verantwortlichen Domäne.
In den meisten Fällen reicht ein kleines, festes Werteset wie none, low und high. Mit Governed Tags lässt sich sicherstellen, dass diese Werte einheitlich verwendet werden und keine Varianten wie hoch, High oder personal entstehen. So bleibt die Klassifikation über viele Tabellen hinweg verlässlich und kann als Grundlage für Auto-Masking und ABAC-Policies genutzt werden.
ABAC nutzt Tags im Unity Catalog, um Schutzregeln automatisch auf passende Datenobjekte anzuwenden. Eine zentrale Policy entscheidet anhand der Tags, wo sie greifen soll, und ersetzt damit die einzelne Verbindung jeder Tabelle oder Spalte mit einer Maskierungs- oder Filterregel.
Ein Beispiel: Eine Spalte ist mit pii=high markiert. Dann kann eine Policy festlegen, dass normale Nutzer nur eine maskierte Version sehen, während Compliance-Rollen den Originalwert lesen dürfen. Bei Row Filtern funktioniert das ähnlich: Eine Tabelle oder Spalte ist einer Region zugeordnet, und die Policy entscheidet anhand der Nutzergruppe, welche Zeilen sichtbar sind.
Der Vorteil liegt vor allem im geringeren Pflegeaufwand. Ohne ABAC muss dieselbe Regel immer wieder manuell an einzelne Tabellen oder Spalten gebunden werden. Mit ABAC greift sie automatisch dort, wo die passenden Tags gesetzt sind.
Wichtig sind dabei drei Punkte:
Spaltenebene
Personenbezogene Daten liegen meist in konkreten Spalten wie E-Mail, Name, Geburtsdatum oder IBAN. Fehlt dort das passende Tag, greift auch keine automatische Maskierung.
Möglichst weit oben
Angaben wie domain, cost_center oder lifecycle können oft auf Catalog- oder Schema-Ebene gesetzt werden. Das hilft bei Suche, Kosten-Auswertungen und übergreifenden Policies.
Größte Schwachstelle
Eine Policy kann nur schützen, was sie erkennt. Deshalb sollten Pflicht-Tags und erlaubte Werte über Governed Tags abgesichert werden.
ABAC reduziert vor allem den Pflegeaufwand. Row Filter und Column Masks greifen anhand der vergebenen Tags und müssen nicht mehr einzeln an jede Tabelle oder Spalte gebunden werden. Die Voraussetzung bleibt ein sauberes Tag-Modell. Wie ABAC Tags und Nutzergruppen verbindet, erklären wir im Überblick zu ABAC in Unity Catalog. Die Umsetzung mit Row Filtern und Column Masks ordnen wir in Row-Level-Security und Column Masking genauer ein.
Object Tags und Compute Tags erfüllen in Kosten-Auswertungen unterschiedliche Aufgaben.
Compute Tags hängen an Clustern, Jobs oder Warehouses und landen in system.billing.usage. Sie helfen dabei, Rechenkosten Teams, Jobs, Regionen oder Kostenstellen zuzuordnen. Ohne diese Tags bleibt der DBU-Verbrauch oft nur technisch sichtbar, aber fachlich schwer erklärbar.
Object Tags hängen an Datenobjekten im Unity Catalog, zum Beispiel an Catalogs, Schemas oder Tabellen. Sie zeigen, zu welcher Domäne, welchem Datenprodukt oder welchem Verantwortungsbereich ein Objekt gehört. Diese Informationen kommen vor allem aus den system.information_schema-Sichten.
Für eine brauchbare Kostenrechnung müssen beide Welten zusammenpassen. Compute Tags erklären, wo Rechenkosten entstehen. Object Tags erklären, welche Daten verarbeitet oder gespeichert werden. Wenn dieselben Werte genutzt werden, etwa cost_center=cc-1234 oder domain=finance, lassen sich Verbrauch, Datenprodukte und Verantwortlichkeiten sauberer zusammenführen.
Fehlen diese gemeinsamen Werte oder werden sie unterschiedlich geschrieben, entstehen schnell widersprüchliche Kosten- und Verantwortlichkeitszuordnungen. Wie System Tables für solche Auswertungen genutzt werden können, ordnen wir im Überblick zu System Tables in Unity Catalog ein.
Tags helfen dabei, Daten im Catalog gezielt zu finden, unabhängig davon, wie Tabellen oder Schemas benannt sind. Nutzer können zum Beispiel nach Domäne, Schutzbedarf oder Lifecycle suchen: etwa nach Tabellen mit domain=finance und pii=high.
Besonders wichtig ist der data_owner-Tag. Er zeigt, wer für ein Datenobjekt verantwortlich ist. Bei Rückfragen, Datenqualitätsproblemen oder Audit-Themen ist dadurch sofort klar, welches Team angesprochen werden muss.
Für Self-Service-Discovery ist vor allem die Kombination aus domain, lifecycle und data_owner hilfreich. Sie zeigt, zu welchem Bereich ein Objekt gehört, wie weit es aufbereitet ist und wer dafür verantwortlich ist. So lässt sich ein kuratiertes Datenprodukt leichter von einer Rohdaten-Tabelle unterscheiden, ohne die Namenskonvention kennen zu müssen.
Wie tagbasierte Suche und Self-Service-Discovery im Unity Catalog zusammenspielen, ordnen wir im Überblick zu Discovery in Unity Catalog ein.
Tags sollten nicht erst nachträglich ergänzt werden. Wenn ein Datenobjekt schon genutzt wird, bevor Domäne, Owner oder PII-Klassifikation gesetzt sind, entstehen schnell Lücken in Suche, Kosten-Auswertung und Governance. Deshalb gehören wichtige Tags direkt in den Erstellungs- und Deployment-Prozess.
Ein tragfähiges Modell verteilt die Verantwortung klar:
Plattform-Team
Setzt Pflicht-Tags auf Catalogs und Schemas, zum Beispiel domain, data_owner, cost_center und lifecycle. Tag Policies sorgen dafür, dass neue Objekte ohne diese Angaben gar nicht erst sauber bereitgestellt werden.
Domäne
Verantwortet fachliche Klassifikation. Tags wie pii oder confidentiality gehören an Tabellen und Spalten. Gerade bei personenbezogenen Daten braucht es fachliche Prüfung, weil nur die Domäne zuverlässig bewerten kann, wie sensibel ein Feld wirklich ist.
CI/CD
Technische Tags wie pipeline, dbt_model oder last_refresh werden automatisch aus Build- und Deployment-Prozessen gesetzt. Sie helfen bei Betrieb, Suche und Nachvollziehbarkeit.
Wichtig ist auch die Berechtigung: Nicht jeder Tabellen-Owner sollte sicherheitsrelevante Tags wie pii ändern dürfen. Über Governed Tags lässt sich festlegen, wer solche Tags setzen oder ändern darf. So bleiben fachliche Ownership und Governance-Kontrolle sauber getrennt.
Object Tags, Business Glossary und Lineage gehören alle zu Metadaten, erfüllen aber unterschiedliche Aufgaben.
Ein Tag ordnet ein Datenobjekt ein, zum Beispiel nach Domäne, Kostenstelle, Lifecycle oder PII-Klassifikation. Ein Glossareintrag erklärt, was ein fachlicher Begriff bedeutet, zum Beispiel „Kunde“, „Auftrag“ oder „Bestand“. Lineage zeigt, woher Daten kommen, wie sie verarbeitet werden und wohin sie weiterfließen.
| Object Tag | Business Glossary | Lineage | |
|---|---|---|---|
| Beantwortet | Wie ist das Objekt eingeordnet? | Was bedeutet der Begriff fachlich? | Woher kommen die Daten und wohin fließen sie? |
| Hängt an | Catalog, Schema, Tabelle, Spalte | Fachlicher Begriff | Beziehung zwischen Datenobjekten |
| Wofür genutzt? | ABAC, Discovery, Kosten-Auswertung | Semantik, Glossar-Suche, gemeinsame Begriffe | Impact-Analyse, Herkunftsnachweis |
| Entsteht durch | SQL, UI, Terraform, SDK | Fachliche Pflege im Glossar | Automatisch aus Abfragen und Jobs |
Ein Tag ersetzt also weder Glossar noch Lineage. Tags beschreiben Eigenschaften eines Datenobjekts. Das Glossary beschreibt die fachliche Bedeutung von Begriffen. Lineage zeigt den Datenfluss und die Abhängigkeiten.
Gerade bei personenbezogenen Daten werden Tags und Lineage gemeinsam wichtig. Ein pii=high-Tag zeigt, dass eine Spalte sensibel ist. Lineage zeigt, in welche Tabellen, Reports oder Datenprodukte diese Spalte weiterfließt. Für eine vollständige Bewertung braucht es beides: die Klassifikation über Tags und den Herkunfts- beziehungsweise Verwendungsnachweis über Lineage.
Wie Business-Begriffe sauber von technischen Tags getrennt werden, ordnen wir im Überblick zu Business Semantics in Unity Catalog ein. Das Glossary behandeln wir separat unter Glossary in Unity Catalog, Lineage im Überblick zu Lineage in Unity Catalog.
Tags liefern nur die technische Grundlage für Klassifikation. Welche Tags es gibt, welche Werte erlaubt sind und was sie fachlich bedeuten, muss das Unternehmen selbst festlegen.
Wichtige Grenzen:
Kein fertiges Standardmodell
Unity Catalog gibt keine verbindlichen Tags vor. Das Tag-Modell muss intern definiert werden.
Keine vollständige PII-Automatik
Databricks kann sensible Felder erkennen, ersetzt aber keine fachliche Prüfung.
Spalten einzeln klassifizieren
Ein PII-Tag auf Catalog- oder Schema-Ebene schützt nicht automatisch die Spalten darunter.
Wildwuchs ohne Governed Tags
Unterschiedliche Schreibweisen machen Auswertungen und Policies unzuverlässig.
Verzögerung in System Tables
Auswertungen über System Tables sind nicht zwingend in Echtzeit verfügbar; tag-basierte Reports können einen zeitlichen Versatz aufweisen.
Schema-Änderungen betroffen
Klassifizierte Spalten müssen bewusst enttaggt werden, bevor sie gelöscht werden können.
Migration bleibt fachliche Arbeit
Alte Excel-, Purview- oder Bestandsklassifikationen müssen zuerst bereinigt und vereinheitlicht werden.
Pragmatisch startet man mit einer Domäne, den wichtigsten Tabellen und einer klaren Schutzanforderung, zum Beispiel PII. Danach werden Tags, Werte und Verantwortlichkeiten festgelegt und schrittweise umgesetzt.
Fazit
Tags werden erst dann zur tragenden Governance-Schicht, wenn Modell, Werte und Verantwortlichkeiten vor der technischen Durchsetzung geklärt sind.
Tags im Unity Catalog verbinden Datenobjekte mit Governance-Regeln, Suche und Kosten-Auswertungen. Wenn Tags uneinheitlich vergeben werden, greifen ABAC-Policies nicht zuverlässig, Discovery bleibt mühsam und Kosten lassen sich nur schwer Domänen, Teams oder Datenprodukten zuordnen.
Die wichtigste Arbeit passiert vor der technischen Umsetzung: Welche Tags sind wirklich nötig, welche Werte sind erlaubt, und wer setzt sie wann? Erst wenn diese Fragen geklärt sind, entsteht ein Modell, das für ABAC, Auto-Masking, Discovery und Kosten-Auswertungen verlässlich genutzt werden kann.
Mein Vorschlag: Vier bis sechs Pflicht-Tags definieren, allgemeine Tags beim Anlegen von Catalogs und Schemas setzen, Governed Tags aktivieren und technische Tags über CI/CD oder Infrastructure as Code pflegen. Der Einstieg sollte mit einer klar abgegrenzten Domäne erfolgen. Danach kann das Modell schrittweise auf weitere Bereiche übertragen werden.
FAQ
Tags im Unity Catalog sind Schlüssel-Wert-Paare, die auf Catalog, Schema, Tabelle, View, Spalte und Volume vergeben werden. Sie steuern ABAC-Bedingungen, tragen FinOps-Aggregation über system.billing.* und Discovery-Filter im Catalog-Explorer. Sie werden per SQL, UI oder Terraform gesetzt und über system.information_schema-Sichten ausgelesen.
