Dynamic Views in Unity Catalog: Wann sie sinnvoll bleiben und wann Policies besser passen
Wann Dynamic Views in Unity Catalog sinnvoll bleiben, wann Row Filter, Column Masks und ABAC besser passen und wie bestehende Views sauber migriert werden.
Die Kernaussagen auf einen Blick.
- Dynamic Views in Unity Catalog sind Views mit nutzerabhängiger Logik über und . Sie können Zeilen filtern oder Spalten je nach Nutzergruppe maskieren.
- Die Mechanik bleibt sinnvoll für bestehende Hive-Metastore-Migrationen, fachliche View-Modelle und komplexe Sonderlogik. Für neue wiederkehrende Schutzregeln ist sie aber meist nicht mehr der beste Default.
- Row Filter, Column Masks und ABAC sind wartungsärmer, wenn dieselbe Regel über viele Tabellen oder Spalten gelten soll, etwa PII-Masking, Mandantenfilter oder tagbasiertes Auto-Masking.
- Mein Vorschlag: Bestehende Dynamic Views inventarisieren, nach Logiktyp und Nutzung bewerten und schrittweise dort ablösen, wo zentrale Policies dieselbe Schutzfunktion übernehmen können. Neue Standardregeln sollten direkt über Row Filter, Column Masks oder ABAC umgesetzt werden.
Inhaltsverzeichnis
Dynamic Views werden schnell zur Wartungslast
Die Migration vom Hive-Metastore auf Unity Catalog ist durch, die Catalogs stehen, die Gruppen liegen in SCIM. Trotzdem sind weiterhin 40 Dynamic Views aus dem bisherigen Hive-Setup produktiv. Einige beziehen sich auf Tabellen, deren Datenmodell inzwischen überarbeitet wurde, andere enthalten Regeln für Mandanten oder Rollen, die heute nicht mehr in dieser Form existieren. Eine regelmäßige Prüfung findet kaum statt, da die verteilte Logik nur noch schwer vollständig nachvollziehbar ist. Die Definitionen liegen verteilt im SQL der einzelnen Views, jede View enthält eigene Filter- und Maskierungsbedingungen.
Probleme entstehen insbesondere, wenn sich die zugrunde liegenden Tabellen weiterentwickeln. Eine neue personenbezogene Spalte wird in Bronze aufgenommen und nach Silver weitergegeben, die bestehende View berücksichtigt diese Spalte jedoch nicht automatisch. Abhängig von der View-Definition kann die Spalte dadurch ungeschützt weitergegeben oder vollständig ausgeblendet werden. Da die View technisch weiterhin funktioniert, bleibt die fehlende Schutzregel möglicherweise unbemerkt.
Im anschließenden Review stellen sich regelmäßig dieselben Fragen:
- Welche der bestehenden Dynamic Views sind überhaupt noch produktiv?
- Wer ist heute fachlich und technisch für die jeweilige View verantwortlich?
- Wie wird sichergestellt, dass neue sensible Spalten unmittelbar von der passenden Schutzregel erfasst werden?
- Ist eine Überarbeitung der bestehenden View weiterhin sinnvoll, oder lässt sich die Anforderung mit einer zentralen Policy langfristig besser abbilden?
Dynamic Views bleiben technisch vollständig nutzbar. Für neue, wiederkehrende Zugriffsregeln sind sie jedoch meist nicht mehr die wartungsärmste Standardlösung. Unity Catalog bietet inzwischen eine zentrale Policy-Schicht für Row Filtering und Column Masking, die einzelne Views ablösen kann.
Was sind Dynamic Views in Unity Catalog?
Eine Dynamic View ist eine dauerhaft registrierte Unity-Catalog-View mit nutzerabhängiger Logik. Ihre Definition ruft Kontextfunktionen wie current_user() und is_account_group_member() auf. Damit lassen sich Zeilen abhängig vom Nutzer ausblenden und Spaltenwerte unterschiedlich darstellen. Konsumenten erhalten ausschließlich SELECT auf die View. Ein direkter Zugriff auf die Basistabelle wird für diese Nutzer ausgeschlossen. Die View liefert nur die Daten, die gemäß Identität und Gruppenmitgliedschaft freigegeben sind. Databricks beschreibt das Verfahren in der Dokumentation zu Dynamic Views als feingranulare Zugriffskontrolle über eine View-Definition.
Das Muster wurde bereits im Hive-Metastore für feingranulare Zugriffskontrollen verwendet. Eigenständige Row-Filter- und Column-Mask-Policies standen dort noch nicht zur Verfügung, und dynamische Views waren deshalb der übliche Weg für nutzerabhängige Datensichten. Unity Catalog hat die Funktionen current_user() und is_account_group_member() übernommen, sodass bestehende Hive-Views nach der Migration weiterlaufen. Diese Kompatibilität erleichtert Migrationen, führt aber zugleich dazu, dass historisch entstandene View-Landschaften langfristig weiterbetrieben werden, ohne Teil eines bewusst entworfenen Zielmodells zu sein.
Zur Abgrenzung gegenüber anderen View- und Tabellenarten: Dynamic Views sind keine Materialized Views, keine Streaming Tables und keine Temporary Views. Materialized Views speichern vorberechnete Ergebnisse und optimieren deren Aktualisierung. Dynamic Views wenden ihre Zugriffslogik bei jeder Abfrage an. Temporary Views bestehen nur innerhalb der jeweiligen Spark- oder SQL-Session. Dynamic Views sind dauerhaft registrierte Catalog-Objekte, deren Zugriffsregeln Bestandteil der SQL-Definition sind.
Welche Werkzeuge Unity Catalog für feingranulare Zugriffskontrolle sonst noch bietet, ordnen wir im Überblick zu Unity Catalog ein.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Wie funktionieren Dynamic Views?
Grundlage der dynamischen Logik sind die Kontextfunktionen von Databricks. current_user() liefert die Identität des aktuell zugreifenden Nutzers. is_account_group_member('group_name') prüft, ob der Nutzer Mitglied einer bestimmten Account-Gruppe ist. Beide Funktionen können direkt in Filter- und CASE-Bedingungen eingebunden werden. Zeilenfilter werden meist in der WHERE-Klausel umgesetzt, und Spaltenwerte werden häufig über CASE-Ausdrücke abhängig von der Nutzerrolle verändert.
Daneben existieren zwei verwandte Funktionen, die in Bestandsstrecken regelmäßig auftauchen. session_user() liefert wie current_user() die E-Mail des anfragenden Nutzers und wird in der aktuellen Databricks-Dokumentation als bevorzugte Variante geführt. is_member('group_name') prüft die Workspace-Gruppe und stammt aus der Hive-Metastore-Zeit. Für Unity Catalog empfiehlt Databricks ausdrücklich is_account_group_member(), weil die Gruppenzuordnung dort auf Account-Ebene konsistent über alle Workspaces gilt. Bestehende is_member()-Aufrufe aus migrierten Views sollten im Rahmen der Inventur erfasst und auf die UC-Variante umgestellt werden.
Ein einfaches Beispiel: Eine Vertriebs-View kann beispielsweise regionale Datensätze anhand der Gruppenzugehörigkeit einschränken. Die View-Definition prüft is_account_group_member('sales_dach') in der WHERE-Klausel und filtert die Tabelle entsprechend. Für PII-Spalten wie customer_email wird ein CASE gesetzt, das die Spalte für Mitglieder einer compliance-Gruppe im Klartext liefert. Für andere Nutzer wird stattdessen ein maskierter oder pseudonymisierter Wert ausgegeben.
Damit die Regel nicht umgangen werden kann, dürfen Konsumenten keinen direkten Lesezugriff auf die Basistabelle besitzen. Andernfalls könnten Nutzer die View umgehen und die ungeschützten Quelldaten direkt abfragen. Daraus folgt: Der Zugriff auf die Basistabelle sollte ausschließlich für technische oder administrative Rollen vorgesehen sein. Fachliche Konsumenten verwenden nur die geschützte View. Das gilt sowohl für klassische Filter-Views als auch für Spaltenmasken in View-Definitionen.
Für Audit-Zwecke finden sich die View-Zugriffe in system.access.audit. Sichtbar wird der View-Name, der konsumierende Principal und der Query-Zeitpunkt. Das Audit protokolliert jedoch nicht, welcher konkrete Zweig der View-Logik für einzelne Werte angewendet wurde. Damit lässt sich nicht auf Datensatzebene nachvollziehen, welche Maskierungsvariante ausgegeben wurde.
Wann sind Dynamic Views noch sinnvoll?
Dynamic Views sind heute nicht mehr der Standard für jede Zugriffregel. Für neue Anforderungen sind Row Filters, Column Masks oder ABAC oft besser wartbar. In einigen Fällen bleiben Dynamic Views aber sinnvoll.
Bestehende View-Strukturen aus Hive. Bei einer Migration lassen sich alte Views oft nicht sofort ablösen. Wenn viele Reports, Jobs oder BI-Modelle darauf aufbauen, können Dynamic Views zunächst weiterlaufen. Wichtig ist nur: Sie sollten klar als Legacy markiert sein und einen Ablösungsplan haben.
Komplexe fachliche Views. Manche Views sind nicht nur Zugriffsschicht, sondern bilden bereits ein fachliches Modell ab: mit Joins, berechneten Spalten und spezieller Filterlogik. Wenn diese Logik zusammengehört, kann es sinnvoller sein, sie in der View zu lassen, statt sie künstlich auf Row Filter oder Column Masks aufzuteilen.
Sehr spezifische Filterregeln. Manche Regeln hängen direkt an konkreten Spaltenwerten, zum Beispiel status = 'closed' oder value > 100000. Solche Logik lässt sich nicht sauber über Tags abbilden. Ob hier eine Dynamic View oder ein Row Filter besser passt, hängt von Wartbarkeit, Standards und Verantwortung ab.
Die Grundregel bleibt: Dynamic Views sollten begründete Ausnahmen sein, nicht der Default. Sie brauchen klare Owner, regelmäßige Reviews und eine dokumentierte Rolle im Berechtigungsmodell.
Wann sind Policies die bessere Antwort?
Row Filters und Column Masks sind meist die bessere Wahl, wenn dieselbe Schutzregel immer wieder gebraucht wird. Die Logik wird zentral definiert und direkt an Tabellen oder Spalten gebunden. Databricks beschreibt beide Mechanismen als SQL-Funktionen, die bei jeder Abfrage angewendet werden.
Drei Fälle eignen sich besonders gut:
PII-Maskierung über viele Tabellen
E-Mail, Telefonnummer oder Kundennummer sollen überall gleich behandelt werden. Berechtigte sehen den Klartext, alle anderen eine maskierte Variante. Eine zentrale Column Mask ersetzt viele einzelne Dynamic Views.
Mandantentrennung pro Zeile
Nutzer sollen nur Datensätze aus ihrem Mandanten, ihrer Region oder ihrem Verantwortungsbereich sehen. Eine zentrale Row-Filter-Funktion deckt diese Zuordnung ab, statt für jede Tabelle eine eigene View zu bauen.
Automatische Maskierung über Tags
Sauber getaggte Spalten wie `pii=true` werden automatisch geschützt, sobald die Klassifizierung greift, ohne dass die View angefasst werden muss.
Genau hier wird ABAC interessant. Wann sich eine solche tag-getriebene Policy-Schicht lohnt, ordnen wir im Überblick zu ABAC in Unity Catalog ein.
Dynamic Views vs. Row Filter, Column Mask und ABAC
Der Unterschied liegt vor allem darin, wo die Zugriffslogik gepflegt wird. Dynamic Views enthalten die Logik direkt in der View. Row Filters, Column Masks und ABAC verlagern sie stärker in zentrale Regeln.
| Aspekt | Dynamic View | Row Filter, Column Mask, ABAC |
|---|---|---|
| Ort der Logik | in der einzelnen View | zentral an Tabelle, Spalte oder Tag |
| Neue sensible Spalten | View muss angepasst werden | Mask oder Tag zuweisen |
| Wiederverwendung | eher begrenzt | gut für wiederkehrende Regeln |
| Mandantenlogik | oft eigene View-Varianten | zentrale Filterlogik möglich |
| Audit und Wartung | Logik steckt in View-Definitionen | Regeln sind expliziter zu prüfen |
| Bestehende Hive-Views | können weitergeführt werden | Migration oder Umbau nötig |
Als Faustregel: Dynamic Views passen, wenn die View ohnehin eine fachliche Sicht mit eigener Logik bildet. Row Filters, Column Masks und ABAC passen besser, wenn dieselbe Schutzregel über viele Tabellen oder Spalten hinweg gelten soll.
Wo Row Filters und Column Masks im Detail sitzen und welche Grenzen sie haben, vertiefen wir im Überblick zu Row-Level Security und Column-Masking in Unity Catalog.
Automatische Maskierung bedeutet: Wenn eine neue sensible Spalte dazukommt, greift eine bestehende Maskierungsregel automatisch. Das funktioniert gut über Tags und Policies. Dynamic Views sind dafür weniger geeignet, weil ihre Logik fest in der View-Definition steht.
Eine Dynamic View zeigt nur die Spalten, die in ihrer SQL-Definition enthalten sind. Kommt eine neue PII-Spalte dazu, passiert deshalb eines von zwei Dingen: Entweder sie erscheint gar nicht in der View, weil die View eine feste Struktur hat. Oder sie gelangt bei SELECT * ungeprüft in die View, ohne dass automatisch eine passende Maskierung greift.
Für PII-Schutz bedeutet das: Jede Schemaänderung muss geprüft werden. Neue Spalte erkennen, bewerten, View anpassen, testen und deployen. Das ist machbar, wird aber bei vielen Tabellen und regelmäßigen Änderungen schnell aufwendig.
Tags lösen dieses Problem anders. Wenn eine neue Spalte das Tag pii=true bekommt, greift die bestehende Maskierungsregel automatisch. Die View muss dafür nicht angepasst werden. Genau deshalb sind tagbasierte Policies für wiederkehrende Schutzregeln meist der bessere Default.
Migration von Dynamic Views zu Row Filter und Column Mask
Bestehende Dynamic Views sollten nicht auf einmal ersetzt werden. Besser ist eine schrittweise Migration nach Domäne, Datenklasse oder Konsumentengruppe. So lassen sich neue Policies testen, ohne bestehende Reports, Jobs oder BI-Modelle ungeplant zu brechen.
Inventur
Dynamic Views auflisten, Owner zuordnen und prüfen, ob sie Filterlogik, Maskierung oder fachliche Modellierung enthalten.
Pilot
Eine kleine, klar abgegrenzte Regel neu bauen, zum Beispiel E-Mail-Maskierung oder Region-Filter, danach mit einer bekannten Konsumentengruppe testen.
Rollout
Tags ergänzen, Row Filters und Column Masks an Tabellen oder Spalten binden und Konsumenten schrittweise auf den neuen Zugriff umstellen.
Cleanup
Nicht mehr benötigte Views entfernen, Berechtigungen prüfen und die Dokumentation aktualisieren.
Der Pilot sollte bewusst klein bleiben. Eine Datenklasse, eine Filterregel und eine klar bekannte Nutzergruppe reichen für den Anfang aus. So wird sichtbar, welche technischen Anpassungen, Abstimmungen und Tests wirklich nötig sind.
Wichtig ist auch die kontrollierte Umstellung der Konsumenten. Wenn eine Dynamic View durch Row Filter und Column Mask ersetzt wird, greifen BI-Tools, Reports oder Jobs künftig oft direkt auf die geschützte Basistabelle zu. Das muss mit den betroffenen Teams abgestimmt und getestet werden. Für eine Übergangszeit kann ein Parallelbetrieb sinnvoll sein.
Die View sollte erst entfernt werden, wenn alle aktiven Konsumenten migriert sind. Jede Migrationswelle braucht deshalb ein klares Ende. Sonst entsteht ein dauerhaftes Parallelmodell aus alten Views und neuen Policies, das später schwer zu prüfen ist.
Was ist vor dem produktiven Einsatz zu prüfen?
Dynamic Views sind technisch einfach zu verstehen, können im Betrieb aber trotzdem Fragen zu Performance, Audit und Compute aufwerfen.
Performance testen
Dynamic Views können Joins, CASE-Logik, berechnete Spalten und Gruppenprüfungen enthalten. Die Laufzeit hängt von der gesamten View-Definition ab, nicht nur von der Basistabelle. Nur der eigene Datenbestand und Query-Mix zeigen, ob eine Dynamic View oder ein Row Filter schneller läuft.
Audit-Grenzen kennen
`system.access.audit` zeigt View-Name, Principal und Zeitpunkt, nicht aber, welcher Logik-Zweig innerhalb der View für einzelne Werte gegriffen hat. Kritische Views brauchen deshalb eigene Dokumentation und Testfälle.
Compute vorab klären
Dynamic Views verhalten sich nicht in jeder Runtime- und Compute-Konstellation gleich. Vor dem Rollout prüfen, ob SQL Warehouses, Shared Compute, Dedicated Compute und Jobs zuverlässig funktionieren, inklusive Serverless-Kosten in der Cluster-Policy-Planung.
Die praktische Regel: Dynamic Views nicht nur fachlich prüfen, sondern auch mit den echten Zugriffswegen, typischen Abfragen und vorgesehenen Compute-Setups testen.
Grenzen von Dynamic Views in Unity Catalog
Dynamic Views bleiben ein Werkzeug, das Unity Catalog ausdrücklich anbietet. Für neue Schutzregeln sind RBAC, ABAC und Row-Level Security aber Best Practice. Zwei strukturelle Einschränkungen machen deutlich, warum:
Logik liegt verteilt statt zentral. Eine Plattform mit 40 Dynamic Views verteilt dieselbe Art von Zugriffslogik auf zahlreiche einzelne SQL-Definitionen. Eine zentrale Übersicht der wirksamen Bedingungen muss zusätzlich aufgebaut werden, übergreifende Änderungen erfordern die Identifikation und Anpassung aller betroffenen Views. RBAC, Row Filters und Column Masks definieren ihre Regeln einmal zentral und binden sie an Tabellen, Spalten oder Gruppen.
Neue sensible Spalten werden nicht automatisch einer Maskierungsregel zugeordnet. Eine View kennt nur, was in ihrer Definition steht. Auto-Masking lässt sich mit Views allein nicht erreichen. Genau diese Lücke schließt ABAC über tagbasierte Policies. Jede neue Spalte mit dem passenden Tag wird automatisch erfasst, ohne dass eine View angefasst werden muss.
Für neue wiederkehrende Zugriffsregeln sollten deshalb zuerst RBAC für den Grundzugriff, Row-Level Security für Zeilenfilter, Column Masks für Spaltenmaskierung und ABAC für tagbasierte Standards geprüft werden. Dynamic Views bleiben darüber hinaus für fachlich geprägte Sichten und Bestandsstrecken aus dem Hive Metastore sinnvoll, sind aber nicht mehr Best Practice.
Fazit
Dynamic Views bleiben sinnvoll für fachliche Sichten und Hive-Altlasten, aber für neue wiederkehrende Zugriffsregeln sind Row Filter, Column Masks und ABAC die wartungsärmere Wahl.
Dynamic Views bleiben sinnvoll, wenn eine View ohnehin eine eigenständige fachliche Konsumentensicht abbildet und die nutzerabhängige Logik eng mit diesem Modell verbunden ist. Auch während einer schrittweisen Migration aus dem Hive Metastore können sie weiterlaufen, solange ein dokumentierter Ablösungs-Plan dahintersteht. Neue Dynamic Views sollten nur noch in begründeten Ausnahmefällen entstehen.
Ein klar dokumentierter Restbestand fachlich begründeter Dynamic Views kann dauerhaft Teil des Plattformmodells bleiben. Ein unkontrolliert wachsender Bestand ohne Ownership und regelmäßige Reviews erhöht dagegen Wartungs-, Audit- und Sicherheitsrisiken.
Bestehende Dynamic Views inventarisieren und einen begrenzten Pilot für eine Datenklasse als Row Filter oder Column Mask umsetzen.
FAQ
Dynamic Views sind reguläre Unity-Catalog-Views, deren Definition Kontextfunktionen wie und nutzt, um Zeilen zu filtern oder Spalten je nach anfragendem Nutzer umzuschreiben. Berechtigung läuft über auf die View; die zugrunde liegende Tabelle bleibt für Konsumenten unzugänglich. Sichtbar wird nur das, was die Gruppen-Mitgliedschaft erlaubt.
