Dynamic Views

Eine Dynamic View ist eine gespeicherte Abfrage (SQL-View) in Databricks Unity Catalog (dem zentralen Datenkatalog für Zugriffsrechte), die pro Nutzer ein anderes Ergebnis liefert. Die Abfrage prüft während der Ausführung, wer sie startet und in welchen Gruppen dieser Nutzer steckt, und blendet daraufhin Zeilen aus oder ersetzt einzelne Werte durch Platzhalter. Die zugrundeliegende Tabelle (der Datenspeicher) bleibt unverändert; jeder Nutzer fragt dieselbe View ab und bekommt trotzdem einen individuell zugeschnittenen Ausschnitt.

Was ist eine Dynamic View?

Eine Dynamic View ist eine gewöhnliche gespeicherte Abfrage (SQL-View), die zusätzlich Kontext-Funktionen enthält: kleine eingebaute Befehle, mit denen die Abfrage abfragt, wer sie gerade ausführt und in welchen Gruppen dieser Nutzer steckt. Bei jeder Ausführung setzt Databricks diese Angaben ein und liefert nur die für den jeweiligen Nutzer freigegebenen Zeilen und Werte zurück. Technisch bleibt die Dynamic View eine ganz normale View; ihr einziger Unterschied zu einer klassischen View steckt in diesen Kontext-Funktionen innerhalb der Definition.

Databricks stellt für den Kontext-Zugriff drei zentrale Funktionen bereit: current_user() gibt den Login-Namen des Abfragenden zurück, is_account_group_member('gruppe') prüft die Mitgliedschaft in einer Unity-Catalog-Account-Gruppe (empfohlener Weg seit Unity Catalog), und is_member('gruppe') prüft eine Workspace-lokale Gruppe (Legacy-Modus aus der Zeit vor Unity Catalog). Kombinationen mit CASE-Ausdrücken erlauben es, im selben View verschiedene Spaltenwerte pro Gruppe zu maskieren, während WHERE-Klauseln über dieselben Funktionen die Zeilenfilterung steuern.

Zugriffstechnisch arbeitet das Modell zweistufig: Nutzer erhalten das SELECT-Recht ausschließlich auf die Dynamic View. Das Recht an der zugrundeliegenden Tabelle bleibt beim Owner. Ohne Grant auf die Basistabelle bleibt der direkte Rohzugriff verschlossen; die View wird zum einzigen Zugangspfad, und ihre Definition entscheidet über die Sichtbarkeit pro Nutzerkontext. Ein Grant auf die Basistabelle würde diese Kontrolle umgehen und wird deshalb bewusst ausgelassen.

Das Muster stammt aus der Hive-Ära und den frühen Databricks-Workspaces vor Unity Catalog. Es war jahrelang der Standard-Weg für Row-Level Security und Column Masking im Lakehouse, bevor Databricks 2023 native Row Filters und Column Masks an der Tabelle eingeführt hat (Public Preview 2023, GA 2024). Dynamic Views bleiben verfügbar und werden weiterhin dokumentiert, gelten in Unity Catalog aber nicht mehr als bevorzugtes Muster für plattformweite Regeln.

Abgrenzung zu klassischen Views, Row Filter, Column Mask und ABAC

Dynamic Views werden regelmäßig mit vier verwandten Mechanismen verwechselt. Die Unterschiede liegen an der Ebene, auf der die Zugriffsregel gebunden ist.

Eine klassische SQL-View liefert für alle Berechtigten dasselbe Ergebnis; die Zugriffskontrolle sitzt außerhalb der View-Definition (Grants). Eine Dynamic View unterscheidet sich technisch nur durch den Aufruf einer Kontext-Funktion in der Definition. Der Objekttyp bleibt derselbe, während die Funktion aus der View einen Zugriffskontroll-Mechanismus macht.

Row-Level Security in Unity Catalog nutzt eine Filter-Funktion, die per ALTER TABLE ... SET ROW FILTER an die Tabelle selbst gebunden wird. Der Filter gilt für jede Abfrage auf die Tabelle, unabhängig davon, welche View darüber liegt. Column Masking arbeitet analog auf Spaltenebene: Eine Maskierungsfunktion wird per ALTER TABLE ... ALTER COLUMN ... SET MASK an eine Spalte gebunden und wirkt bei jeder Abfrage auf diese Spalte. Dynamic Views binden Filter und Maskierung dagegen an eine einzelne View; jede geschützte Tabelle bekommt eine eigene View mit eigener Logik.

ABAC (Attribute-Based Access Control) operiert eine Ebene darüber. Eine Policy auf Account- oder Catalog-Ebene wertet Tags am Datenobjekt und Attribute des Nutzers aus und wirkt regelübergreifend über alle passend markierten Tabellen und Spalten. Dynamic Views wirken dagegen pro View: geeignet für einzelne Tabellen mit spezifischer Logik und ungeeignet für plattformweite Klassifizierungs-Regeln.

Beispiel: Regionale Zeilenfilterung und E-Mail-Maskierung in einer View

Eine Tabelle sales.orders enthält Aufträge aus mehreren Regionen im DACH-Raum. Analysten sollen nur Aufträge ihrer eigenen Region sehen, das Compliance-Team alle Aufträge inklusive der Klartext-E-Mail-Adressen der Kunden. Eine Dynamic View kapselt beide Regeln in einer Definition.

CREATE VIEW sales.orders_scoped AS
SELECT
  order_id,
  order_date,
  region,
  CASE
    WHEN is_account_group_member('compliance') THEN customer_email
    ELSE sha2(customer_email, 256)
  END AS customer_email,
  amount
FROM sales.orders
WHERE
  is_account_group_member('compliance')
  OR region = (
    SELECT region FROM governance.user_region_map
    WHERE user_email = current_user()
  );

Analysten erhalten SELECT ausschließlich auf sales.orders_scoped. Die Basistabelle sales.orders bleibt für sie unerreichbar. Die View filtert Zeilen anhand der Region-Zuordnung des ausführenden Nutzers und maskiert die E-Mail-Adresse für alle außerhalb der Gruppe compliance per SHA-256-Hash. Ein SQL-Warehouse-Query, ein Databricks-Notebook und ein JDBC-Client sehen dasselbe kontextabhängige Ergebnis.

Der Preis dieser Portabilität zeigt sich, sobald weitere geschützte Tabellen hinzukommen. Für jede neue Tabelle mit vergleichbaren Anforderungen muss eine eigene Dynamic View mit ähnlicher CASE- und WHERE-Logik gebaut werden. Änderungen an der Regel (etwa eine zusätzliche Ausnahme-Gruppe) bedeuten Änderungen an potenziell vielen View-Definitionen. Für plattformweite Klassifizierungs-Regeln greifen deshalb Row Filter, Column Mask oder ABAC-Policies auf Tag-Basis, während Dynamic Views ihre Stärke bei tabellenspezifischer Logik behalten.