English version

Unity Catalog & Governance

Diese Lektion zeigt dir, wie du deinen Databricks Workspace so organisierst, dass mehrere Teams (Data Engineers, Data Scientists, Analystinnen, nachgelagerte Konsumenten) sicher zusammenarbeiten können. Am Ende kannst du eine Katalogstruktur entwerfen, Berechtigungen vergeben und die Datenherkunft (Lineage) durch deine Wetter-zu-Strom-Pipeline erklären.

Der dreistufige Namensraum

Unity Catalog führt für alle Datenobjekte eine dreistufige Namenskonvention ein:^[1]

catalog.schema.table

-- Beispiele aus deiner Domäne:
prod.bronze.weather_raw
prod.silver.weather_ts
prod.silver.dim_assets
prod.gold.forecast_ts
dev.silver.weather_ts        -- Kopie für die Dev-Umgebung

Empfohlene Katalogstruktur für Wetter-zu-Strom

Das Berechtigungsmodell

Unity Catalog nutzt ein hierarchisches Berechtigungsmodell. Grants vererben sich nach unten (Catalog → Schema → Tabelle). Ein Deny auf einer beliebigen Ebene blockiert den Zugriff.^[2]

-- Grant-Muster für dein Team

-- 1. Service Principal der Pipeline: Vollzugriff auf prod
GRANT USE CATALOG ON CATALOG prod TO `pipeline-service-principal`;
GRANT USE SCHEMA ON SCHEMA prod.bronze TO `pipeline-service-principal`;
GRANT USE SCHEMA ON SCHEMA prod.silver TO `pipeline-service-principal`;
GRANT USE SCHEMA ON SCHEMA prod.gold TO `pipeline-service-principal`;
GRANT ALL PRIVILEGES ON SCHEMA prod.bronze TO `pipeline-service-principal`;
GRANT ALL PRIVILEGES ON SCHEMA prod.silver TO `pipeline-service-principal`;
GRANT ALL PRIVILEGES ON SCHEMA prod.gold TO `pipeline-service-principal`;

-- 2. Data Scientists: prod lesen, dev + sandbox schreiben
GRANT USE CATALOG ON CATALOG prod TO `data-scientists`;
GRANT SELECT ON SCHEMA prod.silver TO `data-scientists`;
GRANT SELECT ON SCHEMA prod.gold TO `data-scientists`;
GRANT ALL PRIVILEGES ON CATALOG dev TO `data-scientists`;
GRANT ALL PRIVILEGES ON CATALOG sandbox TO `data-scientists`;

-- 3. Analystinnen: prod gold + silver lesen, sandbox schreiben
GRANT USE CATALOG ON CATALOG prod TO `analysts`;
GRANT SELECT ON SCHEMA prod.silver TO `analysts`;
GRANT SELECT ON SCHEMA prod.gold TO `analysts`;
GRANT ALL PRIVILEGES ON CATALOG sandbox TO `analysts`;

-- 4. Nachgelagerte Systeme: nur gold lesen
GRANT USE CATALOG ON CATALOG prod TO `trading-system`;
GRANT USE SCHEMA ON SCHEMA prod.gold TO `trading-system`;
GRANT SELECT ON SCHEMA prod.gold TO `trading-system`;

Service Principals vs. Benutzerkonten

Data Lineage

Unity Catalog verfolgt die Datenherkunft automatisch — welche Tabellen aus welchen lesen und welche Jobs welche Ergebnisse erzeugt haben.^[3]

Lineage beantwortet für dein Team entscheidende Fragen:

• Auswirkungsanalyse: "Wenn ich das Schema von dim_assets ändere, was geht nachgelagert kaputt?"
• Ursachenforschung: "Diese Prognose sieht falsch aus — welche Bronze-Daten und welche Modellversion haben sie erzeugt?"
• Compliance: "Weise nach, dass das Handelssystem ausschließlich aus validierten Gold-Tabellen liest."

Entscheidungen beim Katalogdesign

Option A: Kataloge nach Umgebung (empfohlen)

prod.bronze.weather_raw
prod.silver.weather_ts
dev.bronze.weather_raw
dev.silver.weather_ts

Pro: Klare Trennung. Ein einziger GRANT gibt vollen Dev-Zugriff. Prod ist standardmäßig abgeriegelt.
Contra: Abfragen müssen zwischen den Umgebungen den Katalognamen wechseln (durch Parametrisierung entschärft).

Option B: Kataloge nach Domäne

weather.bronze.raw_forecasts
weather.silver.asset_ts
power.gold.forecasts

Pro: Naheliegend für sehr große Organisationen mit vielen Domänen.
Contra: Die Trennung der Umgebungen erfordert Grants je Schema. Für ein Produkt mit einem Team unnötig komplex.

dim_assets verwalten: das Stammdaten-Problem

Dein Anlagenregister (Parks, Turbinen, Standorte) sind Stammdaten — es ändert sich selten, hat dann aber überproportionale Auswirkungen. Unity Catalog hilft dir dabei:

-- Der Tabellenkommentar dokumentiert Verantwortung und Änderungsprozess
COMMENT ON TABLE prod.silver.dim_assets IS 
  'Asset master data. Source of truth for all geo-locations and hierarchy.
   Owner: data-engineering team.
   Update process: PR-reviewed changes via dev.silver.dim_assets → promotion job.
   Breaking changes require downstream notification.';

-- Spaltenkommentare für bessere Auffindbarkeit
COMMENT ON COLUMN prod.silver.dim_assets.parent_asset_id IS 
  'FK to parent asset (park). NULL if this row IS a park.';
COMMENT ON COLUMN prod.silver.dim_assets.hub_height_m IS 
  'Turbine hub height in metres. Used for wind speed extrapolation. NULL for parks.';

Änderungsmanagement für Stammdaten

1. Änderungen erfolgen in dev.silver.dim_assets (Engineers haben Schreibrechte)
2. Validierung: die Silver-Pipeline in dev laufen lassen und prüfen, ob die Joins noch greifen
3. Überführung: ein kontrollierter Job kopiert nach prod.silver.dim_assets (per MERGE)
4. Die Lineage zeigt, welche nachgelagerten Tabellen betroffen sind

Tags und Klassifizierung

Unity Catalog unterstützt Tags für Auffindbarkeit und Governance-Richtlinien:

-- Tabellen nach Datenklassifizierung taggen
ALTER TABLE prod.silver.weather_ts SET TAGS ('pii' = 'none', 'retention' = '2years');
ALTER TABLE prod.gold.forecast_ts SET TAGS ('pii' = 'none', 'sla' = 'hourly');
ALTER TABLE prod.silver.dim_assets SET TAGS ('data_class' = 'master_data');

-- Spalten taggen (nützlich bei sensiblen Standortdaten, falls nötig)
ALTER TABLE prod.silver.dim_assets ALTER COLUMN latitude SET TAGS ('geo' = 'true');
ALTER TABLE prod.silver.dim_assets ALTER COLUMN longitude SET TAGS ('geo' = 'true');

Verständnis prüfen

Primärquelle

Wie es weitergeht

Mit der Governance im Rücken behandelt die nächste Lektion Feature Engineering & den Feature Store — wie du Silver-Zeitreihen in ML-taugliche Features überführst, Feature-Tabellen verwaltest und reproduzierbares Modelltraining ermöglichst.

Fragen zur Katalogstruktur, zur Vererbung von Berechtigungen oder zur Verwaltung teamübergreifender Zugriffe? Frag deinen Lehrer.

Rechtliches: Impressum