Databricks und Unity Catalog als Governance-Einstieg

Begriffe vor dem Lesen

• ABAC — Attribute-Based Access Kontrollregel: Zugriff über Eigenschaften wie Land, Zweck, Sensitivität oder Vertragsstatus.

Databricks kann ein starker Governance-Einstieg sein, wenn der erste governed Use Case durch engineering-intensive Verarbeitung, Streaming, Machine Learning oder AI geprägt ist. Unity Catalog ergänzt eine gemeinsame Kontrollschicht für Daten- und AI-Assets. Zu einer Governance-Grundlage wird die Plattform jedoch erst, wenn fachliche Verantwortung, Identitäten, Kataloggrenzen, Ausführungsumgebungen, Lineage-Evidenz, Quality Verantwortung und Kostenverantwortung gemeinsam betrieben werden.

Die Entscheidungsfrage lautet deshalb nicht, ob Unity Catalog einen Katalog, Lineage oder Zugriffskontrollen bereitstellt. Entscheidend ist, ob die Organisation diese Fähigkeiten in ein überprüfbares Databricks Governance Operating Model überführen kann.

Herausforderung

Plattformauswahl beginnt häufig mit einer Feature-Liste:

• Kann die Plattform Tabellen und Modelle katalogisieren?
• Kann sie Zugriffsrechte durchsetzen?
• Kann sie sensible Daten klassifizieren?
• Kann sie Lineage darstellen?
• Kann sie Batch-, Streaming- und KI-Workloads ausführen?

Diese Fragen sind notwendig, aber nicht ausreichend. Eine Plattform kann Kontrollen implementieren, ohne die fachlichen Entscheidungen dahinter zu besitzen.

Unity Catalog modelliert governed Assets als Securable Objects. Die Hierarchie beginnt beim Metastore und führt über Catalogs und Schemas zu Objekten wie Tabellen, Views, Volumes, Funktionen und Modellen. Privileges können Benutzern, Service Principals und Gruppen zugewiesen werden. Dadurch entsteht eine technisch konsistente Kontrollschicht. Sie entscheidet jedoch nicht:

• wer für den fachlichen Zweck eines Data Products verantwortlich ist;
• wer die erlaubte Nutzung genehmigt;
• wer fachliche Ebene und semantische Bedeutung festlegt;
• wer eine Quality Exception akzeptiert;
• wer entscheidet, ob ein Modell oder Feature in einem neuen Kontext verwendet werden darf;
• wer für die Workloads bezahlt, die das Asset erzeugen und nutzen.

Drei Fehler treten besonders häufig auf.

Catalog Verantwortung wird mit Data Verantwortung verwechselt

Ein Catalog Owner oder ein Principal mit MANAGE kann Plattformobjekte und Kontrollen administrieren. Diese Rolle ist nicht automatisch der verantwortliche Data Owner. Die fachliche Verantwortung bleibt für Zweck, erlaubte Nutzung, Qualitätserwartungen, Risikoakzeptanz und Ausnahmeentscheidungen verantwortlich.

Workspace-Design wird mit Governance-Design verwechselt

Ein Workspace ist eine Ausführungs- und Kollaborationsumgebung. Er ist allein keine vollständige Daten-, Residency-, Zugriffs- oder Kostengrenze. Catalogs sind standardmäßig aus den Workspaces erreichbar, die am selben Metastore hängen, sofern Workspace Bindings sie nicht einschränken. Eine belastbare Umgebungstrennung benötigt deshalb explizite Entscheidungen zu Catalog, Workspace, Identität, Privileges, Storage und Compute.

Betrieb Lineage wird mit End-to-End-Evidenz verwechselt

Unity Catalog erfasst Lineage für unterstützte Databricks-Aktivitäten. First-Mile-Ingestion außerhalb von Databricks, unmanaged Copies, externe APIs und Last-Mile-BI-Tools können außerhalb dieses Betriebsgraphen bleiben. External Lineage Metadata oder eine andere Integration ist erforderlich, wenn diese Kanten für Impact Analysis oder Audit-Evidenz relevant sind.

Die Governance-Grenze besteht aus drei unterschiedlichen Ebenen:

Die Kontrollschicht implementiert Entscheidungen. Sie darf nicht unbemerkt zum Entscheidungsverantwortlichen werden.

Ansatz

Nutze Databricks mit Unity Catalog als Governance-Einstieg, wenn der erste governed Use Case erhebliche Engineering-, Lakehouse-, Streaming- oder AI-Fähigkeiten benötigt und die Organisation die Plattformgrenzen explizit betreiben kann.

Eine positive Startentscheidung weist typischerweise die meisten der folgenden Merkmale auf:

• Der erste Use Case benötigt skalierbare Transformationen, Streaming, Feature Engineering, Modellentwicklung oder kombinierte Data-and-KI-Workflows.
• Daten- und KI-Assets sollen über ein gemeinsames Objekt- und Privilege-Modell governed werden.
• Mehrere Workspaces benötigen einen gemeinsamen Metastore und konsistenten Datenzugriff.
• Produktionsjobs können unter kontrollierten Service Principals statt unter persönlichen Identitäten laufen.
• Catalog-, Schema- und Workspace-Grenzen lassen sich aus Domain-, Environment-, Residency- und Permitted-Use-Anforderungen ableiten.
• Betrieb Lineage kann für externe Quellen und Nutzer ergänzt werden.
• Quality-Evidenz und Incident Verantwortung können jedem governed Product zugeordnet werden.
• Compute-Verbrauch kann einem Product, Team, verantwortliche Person oder Cost Center zugerechnet werden.

Databricks sollte nicht allein deshalb ausgewählt werden, weil es den breitesten Engineering-Funktionsumfang bietet. Ein einfacheres governed Warehouse, eine BI-Plattform oder eine Verbesserung des Semantic Layers kann die bessere No-new-platform-Alternative sein, wenn das erste Problem auf stabile SQL-Transformationen, vertrauenswürdiges Reporting oder Metric Governance begrenzt ist und die Organisation die zusätzliche Engineering- und AI-Betriebsfläche nicht benötigt.

Die Hierarchie vor den Objekten entwerfen

Die technische Kontrollhierarchie muss in eine betriebliche Hierarchie übersetzt werden.

Für ein regionales Deployment ist der Metastore eine zentrale Architekturentscheidung. Databricks dokumentiert einen Metastore je Betriebsregion; die Workspaces der Region werden daran angebunden. Workspaces am selben Metastore sehen denselben Catalog Namespace. Ein Workspace erzeugt daher standardmäßig keinen unabhängigen Katalog.

Workspace-Catalog Binding kann einen Catalog auf ausgewählte Workspaces beschränken und eine Bindung als Read-only definieren. Das ist für die Trennung von Development und Production nützlich, darf aber nur als eine Kontrolle im gesamten Environment Model verstanden werden.

Cross-Workspace- und Cross-Catalog-Zugriffe müssen als Entscheidungen dokumentiert werden. Sie dürfen nicht zufällig aus Default Visibility oder breiten vererbten Grants entstehen.

Fachliche Verantwortung, Administration und Custodian-Verantwortung trennen

Ein minimales Verantwortung-Modell unterscheidet mindestens fünf Verantwortungsbereiche.

In einer kleinen Organisation kann eine Person mehrere Rollen übernehmen. Die Entscheidungen müssen trotzdem unterscheidbar bleiben. Ein Catalog Owner darf einen sensiblen Use Case nicht allein deshalb freigeben, weil die Plattform ihm das Erteilen des Zugriffs erlaubt.

Effektiven Zugriff statt nur direkte Grants prüfen

Databricks kennt Benutzer, Service Principals und Gruppen als Identitäten. Account-level Groups sollten der Standard für Zugriffszuweisungen sein. Produktionsjobs und automatisierte Deployments sollten, wo praktikabel, unter Service Principals laufen.

Ein Effective-Access-Review muss mehr als ein SELECT auf einer Tabelle berücksichtigen:

effektiver Zugriff
= Account-Identität
+ Gruppenmitgliedschaften
+ vererbte Privileges
+ direkte Privileges
+ Verantwortung- oder Admin-Rechte
+ Workspace- und Catalog-Binding
+ Row-Filter- und Column-Mask-Policies
+ ausführbare Funktionen und Compute-Pfad

Der Review sollte beantworten:

• Welche Identitäten können das Objekt entdecken?
• Welche Identitäten können es lesen, verändern, taggen oder verwalten?
• Welche Gruppen liefern vererbten Zugriff?
• Welcher Service Principal schreibt Produktionsdaten?
• Kann der Workspace den Catalog erreichen?
• Verändern Row Filters oder Column Masks das Ergebnis abhängig von der Identität?
• Kann ein verantwortliche Person oder Administrator den vorgesehenen Freigabeprozess umgehen?
• Wird Zugriff entfernt, wenn eine Person die Rolle wechselt oder das Unternehmen verlässt?

Das Ziel ist keine lange Grant-Liste. Das Ziel ist erklärbarer, testbarer und widerrufbarer Zugriff.

Klassifikation und Policy als governed Workflows behandeln

Unity Catalog unterstützt Tags auf Securable Objects, Governed Tags mit kontrollierten Werten und Berechtigungen, automatisierte Data Classification, tabellenspezifische Row Filters und Column Masks sowie tagbasierte Attribute-based Policies.

Diese Mechanismen benötigen getrennte Verantwortung-Entscheidungen:

• Der Data Owner genehmigt die Permitted-Use-Regel.
• Der Steward verwaltet Klassifikation und Review Status.
• Security oder Privacy definiert Richtlinie Standards.
• Das Plattformteam implementiert wiederverwendbare Richtlinie Functions und Guardrails.
• Engineering verifiziert das Verhalten auf dem unterstützten Compute.
• Audit- oder kontrollverantwortliche Person prüfen Evidenz und Ausnahmen.

Automatisierte Klassifikation ist Evidenz, keine finale Genehmigung. Ein erkannter PII-Tag kann einen Control Workflow auslösen, bestimmt aber weder rechtmäßigen Zweck noch Retention, Consent oder fachliche Kritikalität.

Tagbasierte Policies können bei skalierbaren Kontrollen die objektweise Administration reduzieren. Table-level Filters und Masks können für isolierte Fälle weiterhin sinnvoll sein. Die Entscheidung muss Scope, Policy Verantwortung, Betrieb Requirements, Performance, Testbarkeit und aktuelle Cloud-spezifische Verfügbarkeit berücksichtigen.

Lineage durch externe Evidenz vervollständigen

Die Evidenzkette eines governed Products sollte Folgendes abdecken:

Quelle
→ Ingestion
→ Transformation oder Streaming
→ governed Tabelle oder Feature
→ Modell oder analytisches Product
→ BI-, API- oder AI-Consumer

Für jeden Schritt werden mindestens benötigt:

• Code- und Deployment-Version;
• verantwortlicher verantwortliche Person;
• technischer Betreiber;
• Klassifikation;
• Access Richtlinie;
• Lineage;
• Quality Tests;
• Incident verantwortliche Person;
• Kostenzuordnung;
• Approval Record.

Unity Catalog kann unterstützte Betrieb Lineage innerhalb von Databricks automatisch erfassen. External Metadata und External Lineage können vorgelagerte Systeme und nachgelagerte Consumer ergänzen, die nicht automatisch beobachtet werden. Diese Beziehungen benötigen weiterhin Verantwortung und Pflege. Eine manuell angelegte Lineage-Kante, die nie überprüft wird, ist keine verlässliche Evidenz.

Audit Logs und System Tables ergänzen die operative Evidenz, beantworten aber unterschiedliche Fragen:

• Lineage zeigt Beziehungen und Flüsse.
• Audit-Evidenz zeigt Aktionen und Zugriffsereignisse.
• Quality-Evidenz zeigt, ob das Product vereinbarte Kontrollen erfüllt hat.
• Change Records zeigen, welche genehmigte Version deployed wurde.
• Incident Records zeigen, wer bei einem Evidenzfehler reagiert hat.

Unmanaged Extracts und externe Consumer müssen als explizite Gaps dargestellt werden, bis sie integriert, eingeschränkt oder über eine befristete Ausnahme akzeptiert sind.

Compute und Kosten als Teil der Governance behandeln

Engineering- und AI-Plattformen erzeugen eine zusätzliche Governance-Dimension: Auch die Ausführung besitzt Owner, Policies und Kosten.

Das Operating Model sollte definieren:

• erlaubte Compute-Typen je Environment;
• Einsatz von Standard, Dedicated oder Serverless, soweit passend;
• unterstützte Betriebs- und Library-Patterns;
• Identitäten für Produktionsjobs;
• Netzwerk- und External-Access-Kontrollen;
• Resource Tags und Cost-Center-Regeln;
• Budgetgrenzen und Eskalation;
• Verantwortung für idle, fehlgeschlagene oder ausufernde Workloads;
• Aufbewahrung von Evidenz für Jobs, Pipelines, Modelle und Endpoints.

Serverless kann die Infrastrukturadministration reduzieren, entfernt aber nicht die Verantwortung. Aktuelle Serverless Limitations, unterstützte Sprachen, Netzwerkverhalten, Policy Support und regionale Verfügbarkeit müssen für Cloud und Workload geprüft werden.

Databricks Billing System Tables, darunter system.billing.usage, können Nutzung Ressourcen, Identitäten, Produkten und Custom Tags zuordnen. Diese Evidenz wird erst nutzbar, wenn Tagging Model und Cost Owner vor dem Production Deployment verpflichtend sind.

Checkliste

Nutze die Readiness Checkliste, bevor Databricks als Einstieg freigegeben wird.

Dokumentiere die Entscheidung mit dem Tool Governance Starting-Point Decision.

Ein Readiness Result sollte eines von vier expliziten Ergebnissen verwenden:

• Bereit für den Proof of Value: Grenzen, Owner und Validierungstests sind ausreichend definiert.
• Bedingte Readiness: Databricks ist plausibel, aber benannte Gaps müssen im Proof of Value geschlossen werden.
• Blockiert: Ein wesentliches Residency-, Identity-, Kontrollregel-, Operating-Capacity- oder Kostenproblem verhindert einen verantwortbaren Start.
• No-new-platform-Alternative: Das erste governed Ergebnis kann sicherer mit der bestehenden Plattform und einer engeren Governance-Maßnahme erreicht werden.

Artefakt

Das erforderliche Artefakt ist ein Databricks Governance Operating Model, kein allgemeines Architekturdiagramm.

Dokumentiere mindestens die folgenden Felder:

decision:
  firstGovernedUseCase:
  businessOutcome:
  targetConsumers:
  criticality:
  cloud:
  region:
  accountAndMetastoreDesign:
  catalogAndSchemaBoundaries:
  workspaceAndEnvironmentModel:
  dataOwner:
  dataSteward:
  technicalOwner:
  identitySource:
  accountGroups:
  productionServicePrincipals:
  privilegeModel:
  classificationTaxonomy:
  governedTags:
  rowAndColumnPolicyModel:
  policyOwner:
  lineageCoverage:
  externalLineageGaps:
  auditEvidence:
  qualityTests:
  qualityThresholds:
  incidentOwner:
  computeModel:
  costAttribution:
  budgetOwner:
  deploymentAndChangeModel:
  unresolvedGaps:
  validationTests:
  decisionOutcome:
  noRegretNextStep:
  reviewDate:

Das Operating Model weist außerdem die wiederkehrenden Verantwortungen zu.

Verantwortung muss Personalwechsel überstehen. Nutze Gruppen, Service Principals, managed Deployment Processes und Review Dates statt das Wissen eines einzelnen Administrators.

Tools

Ein Proof of Value sollte Governance-Verhalten testen, nicht nur Workload Performance.

1. Grenze Test

Erzeuge einen Development- und einen Production Catalog. Binde den Production Catalog nur an den genehmigten Production Workspace, definiere den vorgesehenen Access Mode und verifiziere den verweigerten Zugriff aus einem nicht gebundenen Workspace.

2. Identity and Privilege Test

Provisioniere Account Groups und einen Production Service Principal. Erteile Zugriff über Gruppen, führe den Production Workload über den Service Principal aus und dokumentiere den effektiven Zugriff eines Developers, Consumers, Stewards und Administrators.

3. Policy and Classification Test

Wende einen Governed Classification Tag auf sensible Spalten an. Implementiere die ausgewählte Row- oder Column-Policy, teste positive und negative Fälle und dokumentiere, wer die Regel genehmigt, implementiert und verändern kann.

4. Evidence Chain Test

Verfolge eine Quelle durch Ingestion, Transformation, ein governed Product und einen externen Consumer. Ergänze External Lineage für fehlende Kanten, verknüpfe die deployed Code Version, füge Quality Results hinzu und prüfe Audit-Evidenz.

5. Failure and Incident Test

Erzwinge einen Quality-Threshold-Verstoß oder einen Access-Policy-Fehler. Prüfe, ob der Workload wie vorgesehen fehlschlägt oder quarantined wird, ob der richtige Owner informiert wird und ob Remediation und Ausnahmeentscheidung dokumentiert werden.

6. Cost Accountability Test

Tagge den Workload mit Product-, Environment- und Cost-Center-Metadaten. Frage Billing-Evidenz ab, gleiche sie mit dem verantwortlichen Budget Owner ab und teste die Eskalationsgrenze.

Infrastructure as Code sollte dort eingesetzt werden, wo es Wiederholbarkeit für Metastores, Workspace Assignment, Catalogs, Grants, Policies und Compute Configuration verbessert. Automatisierung implementiert genehmigte Entscheidungen; sie darf Verantwortung oder Permitted-Use-Regeln nicht erfinden.

Ressourcen

Die folgenden offiziellen Databricks-Ressourcen wurden für diesen Entscheidungsartikel geprüft. Product Behavior, Cloud Support, Preview Status, Licensing und regionale Verfügbarkeit müssen für das konkrete Deployment erneut validiert werden.

• What is Unity Catalog?
• Unity Catalog securable objects
• Unity Catalog privileges reference
• Create a Unity Catalog metastore
• Workspace-catalog binding
• Identity best practices
• Governed tags
• Data Classification
• Row filters and column masks
• Create and manage ABAC policies
• Lineage in Unity Catalog
• External lineage
• Audit log system table
• Monitor costs using system tables
• Serverless compute limitations
• Databricks pricing and platform tiers