Tags in Unity Catalog: Definition, Nutzung, Abgrenzung

Tags in Unity Catalog sind kurze Metadaten-Etiketten aus Schlüssel und Wert (etwa owner=finance-team oder pii=true), die an Datenobjekte im Databricks-Katalog geheftet werden. Sie liefern die maschinenlesbare Grundlage für Klassifikation sensibler Daten, Kostenzuordnung, Zugriffsregeln und die gezielte Suche im Katalog.

Was sind Tags in Unity Catalog?

Ein Tag ist ein Paar aus einem Schlüssel und einem Wert. Der Schlüssel benennt die Eigenschaft, die beschrieben wird (Besitzer, Sensitivität, Kostenstelle), der Wert liefert die konkrete Ausprägung. Typische Beispiele sind owner=finance-team, pii=true, costcenter=1234, environment=prod oder domain=sales. Ein Objekt kann mehrere Tags gleichzeitig tragen; die Etiketten stehen nebeneinander, ohne feste Reihenfolge.

Angeheftet werden Tags in Unity Catalog an mehreren Ebenen: an einen Catalog, ein Schema, eine Tabelle, eine einzelne Spalte, ein Volume für nicht-tabellare Daten wie CSV oder PDF, ein Registered Model in der Model Registry sowie an einen Job. Tags an höheren Ebenen wie Catalog oder Schema fallen nicht automatisch auf tieferliegende Objekte durch. Wer Vererbung braucht, formuliert eine Policy-Regel, die den Tag von der übergeordneten Ebene liest.

Databricks unterscheidet zwei Ausprägungen. Governed Tags sind kontrollierte Tags mit einem festen Schlüssel und einer geschlossenen Werteliste, gepflegt durch Data Stewards. Ein Beispiel ist die Sensitivitäts-Achse sensitivity=public|internal|confidential|restricted. Freie Tags erlauben beliebige Schlüssel-Wert-Paare ohne Prüfung. Sie sind schneller in der Anwendung; ohne dokumentierte Konvention leiden sie unter Tippfehlern, Synonymen und toten Werten.

Die Zuweisung läuft über SQL (ALTER TABLE prod.finance.orders SET TAGS ('pii' = 'true', 'domain' = 'finance')), über den Terraform-Provider, die REST-API oder die Databricks-UI. Automatisch werden Tags über Klassifikations-Scanner gesetzt, die regelbasiert (Spaltennamen, Format-Signaturen wie IBAN-Struktur) oder ML-gestützt arbeiten. Stewards bestätigen strittige Fälle und dokumentieren die Entscheidung am Objekt.

Der Grund, warum Tags in Unity Catalog eine so tragende Rolle spielen, liegt in ihrer Doppelfunktion. Sie sind einerseits ein Beschreibungswerkzeug (was ist das für ein Objekt?) und andererseits ein Steuerungsmedium für nachgelagerte Mechanismen: attributbasierte Zugriffsregeln lesen Tags als Objekt-Attribute, System Tables gruppieren die Nutzung nach Tags für Chargeback-Reports, die Katalog-Suche filtert Discovery-Ergebnisse nach Tags. Vier verschiedene Anwendungen teilen sich damit dasselbe Fundament.

Abgrenzung zu Business Semantics, System Tables, Data Classification und Metadaten

Tags werden häufig mit benachbarten Konzepten verwechselt, weil sich alle vier mit Metadaten am Katalog-Objekt beschäftigen und teilweise dieselben Werkzeuge nutzen. Die folgende Übersicht klärt die Grenzen entlang jeweils einer Achse.

Begriff	Achse	Kernunterschied
Business Semantics	Ausdruckskraft	Business Semantics ist die semantische Schicht am Katalog: Kennzahlen-Definitionen, Beziehungen zwischen Entitäten, Regeln für Berechnung und Interpretation. Tags sind Bausteine dieser Schicht, bleiben aber ein Beschreibungsmittel; ein Kennzahlen- oder Beziehungsmodell entsteht mit ihnen nicht.
System Tables	Perspektive	System Tables sind read-only Delta-Tabellen im system-Catalog für Billing, Audit, Lineage und Query-History. Tags erscheinen dort als Filter- und Gruppier-Attribut (Chargeback nach costcenter=, Audit-Filter nach pii=true). Der Tag lebt am Objekt, die System-Table ist die Auswertungs-Sicht.
Data Classification	Rolle	Data Classification ist die Governance-Disziplin: Einstufung von Objekten nach Sensitivität (Public/Internal/Confidential/Restricted) und Kategorie (PII, Finanzdaten, Trainingsdaten). Tags sind das technische Trägermedium, mit dem die Klassifikation am Objekt persistiert und für Zugriff, Maskierung und DLP verfügbar wird.
Metadaten allgemein	Umfang	Metadaten ist der Oberbegriff für alles, was ein Objekt beschreibt: Kommentare, Descriptions, Owner, Erstellungsdatum, Schema, Tags. Tags sind eine spezifische Form strukturierter Metadaten (Key–Value), unterscheiden sich vom Freitext-Kommentar (COMMENT ON TABLE) durch Maschinenlesbarkeit.

Die zentrale Verwechslung ist die zwischen Tag und Klassifikation. Ein Tag ist die technische Etikette am Objekt; die Klassifikation ist die Governance-Entscheidung, welche Etikette dort steht. Die Entscheidung, dass Kundendaten als sensitivity=confidential gelten, ist Klassifikation. Der SQL-Befehl, der den Tag setzt, ist Umsetzung. Wer beide Ebenen zusammenwirft, landet bei einer Tag-Landschaft ohne Betriebsmodell: Etiketten überall, aber ohne verlässliche Bedeutung.

Ähnlich verhält sich die Grenze zu attributbasierten Zugriffsregeln. Tags liefern die Objekt-Attribute, auf die eine ABAC-Policy zugreift. Die Policy selbst, also die Regel, die den Zugriff berechnet, ist ein eigenes Artefakt auf Account- oder Catalog-Ebene und lebt getrennt vom Tag. Ein Tag ohne Policy bleibt Beschreibung, eine Policy ohne Tags läuft leer.

Beispiel: Ein Governed-Tag-Set in einem Databricks-Konto

Ein Databricks-Konto in Azure Westeuropa richtet ein Governed-Tag-Set als Grundlage für vier Anwendungen ein. Das Steward-Team definiert vier kontrollierte Schlüssel: sensitivity mit den Werten public, internal, confidential, restricted; pii mit den Werten true und false; costcenter mit den Kostenstellen-Nummern aus SAP; domain mit den Werten finance, sales, hr und marketing. Freie Tags bleiben für Team-lokale Experimente erlaubt, laufen aber nicht in Policies ein.

Ein Klassifikations-Scanner läuft nächtlich über den prod-Catalog und schlägt Tags für neue oder geänderte Objekte vor:

sql

-- Automatische Zuweisung nach Steward-Bestaetigung
ALTER TABLE prod.finance.customers ALTER COLUMN email
  SET TAGS ('pii' = 'true', 'sensitivity' = 'confidential');

ALTER TABLE prod.finance.customers
  SET TAGS ('domain' = 'finance', 'costcenter' = '1234');

Die vier Anwendungen greifen auf dasselbe Tag-Fundament zu. Eine ABAC-Policy erlaubt Lesezugriff auf Spalten mit pii=true nur für Mitglieder der Gruppe data-compliance; sobald der Scanner einer neuen Tabelle das PII-Tag setzt, wirkt die Policy ohne weiteren Konfigurationsaufwand. Ein Chargeback-Report gruppiert system.billing.usage nach costcenter= und liefert monatlich pro Kostenstelle den DBU-Verbrauch. Die Discovery-Suche im Workspace filtert nach domain=finance und sensitivity<=internal, sodass Analyse-Zugriffe nur auf die freigegebenen Objekte fallen. Ein Audit-Report verknüpft system.access.audit mit den Tag-Metadaten und beantwortet die Frage, wer im letzten Quartal auf pii=true-Objekte zugegriffen hat.

Der ausschlaggebende Effekt: Eine einzige, gut gepflegte Tag-Taxonomie trägt Klassifikation, Zugriffskontrolle, Chargeback und Discovery gemeinsam. Ohne Tag-Fundament müssten alle vier Bereiche eigene Zuordnungslisten pflegen, jeweils mit eigenem Aktualisierungsstand und eigener Fehlerquelle.