Bewährte Methoden für Unity Catalog

Dieses Dokument enthält Empfehlungen für die Benutzung von Unity Catalog und Delta Sharing, um Ihren Anforderungen an die Datengovernance gerecht zu werden.

Unity Catalog ist eine fein abgestimmte Governance-Lösung für Daten und KI auf der Databricks-Plattform. Es hilft, die Sicherheit und Verwaltung Ihrer Daten zu vereinfachen, indem es einen zentralen Ort zum Verwalten und Prüfen des Datenzugriffs bietet. Delta Sharing ist eine sichere Datenfreigabeplattform, mit der Sie Daten in Azure Databricks für Benutzer außerhalb Ihrer Organisation freigeben können. Die Plattform verwendet Unity Catalog, um das Freigabeverhalten zu verwalten und zu überwachen.

Bausteine für Datengovernance und Datenisolation

Um ein Datengovernancemodell und einen Datenisolationsplan zu entwickeln, der für Ihre Organisation geeignet ist, hilft es Ihnen, die primären Bausteine zu verstehen, die Ihnen beim Erstellen Ihrer Datengovernancelösung in Azure Databricks zur Verfügung stehen.

Die folgende Abbildung veranschaulicht die primäre Datenhierarchie in Unity Catalog (einige sicherungsfähige Objekte sind abgeblendet, um die Hierarchie der Objekte hervorzuheben, die unter Katalogen verwaltet werden).

Die Objekte in dieser Hierarchie umfassen Folgendes:

• Metastore: Ein Metastore ist der Objektcontainer der obersten Ebene in Unity Catalog. Metastores befinden sich auf Kontoebene und fungieren als oberster Baustein des pyramidenförmigen Azure Databricks-Datengovernancemodells.

  Metastores verwalten Datenressourcen (Tabellen, Sichten und Volumes) und die Berechtigungen, die den Zugriff auf diese regeln. Azure Databricks-Kontoadministratoren können für jede Region, in der sie tätig sind, einen Metastore erstellen und ihn mehreren Azure Databricks-Arbeitsbereichen in derselben Region zuweisen. Metastore-Administratoren können alle Objekte im Metastore verwalten. Sie haben keinen direkten Lese- oder Schreibzugriff auf Tabellen, die im Metastore registriert sind. Es besteht aber indirekt Zugriff, da sie den Besitz von Datenobjekten übertragen können.

  Der physische Speicher für einen bestimmten Metastore ist standardmäßig vom Speicher für jeden anderen Metastore in Ihrem Konto isoliert.

  Metastores bieten regionale Isolation, sind jedoch nicht als Einheiten der Datenisolation vorgesehen. Die Datenisolation sollte auf Katalogebene beginnen.

• Katalog: Kataloge sind die höchste Ebene in der Datenhierarchie (Katalog > Schema > Tabelle/Sicht/Volume), die vom Unity Catalog-Metastore verwaltet wird. Sie dienen als primäre Einheit der Datenisolation in einem typischen Azure Databricks-Datengovernancemodell.

  Kataloge stellen eine logische Gruppierung von Schemas dar. Sie sind in der Regel durch Datenzugriffsanforderungen voneinander abgegrenzt. Kataloge spiegeln häufig Organisationseinheiten oder Lebenszyklusbereiche in der Softwareentwicklung wieder. Sie können beispielsweise einen Katalog für Produktions- und einen für Entwicklungsdaten oder einen Katalog für Nicht-Kunden- und einen für vertrauliche Kundendaten auswählen.

  Kataloge können auf Metastore-Ebene gespeichert werden. Sie können einen Katalog aber auch so konfigurieren, dass er getrennt vom Rest des übergeordneten Metastores gespeichert wird. Wenn Ihr Arbeitsbereich für Unity Catalog automatisch aktiviert wurde, gibt es standardmäßig keinen Speicher auf Metastore-Ebene, und Sie müssen einen Speicherort angeben, wenn Sie einen Katalog erstellen.

  Wenn der Katalog die primäre Einheit der Datenisolation im Azure Databricks-Datengovernancemodell ist, ist der Arbeitsbereich die primäre Umgebung für das Arbeiten mit Datenressourcen. Metastore-Administratoren und Katalogbesitzer können den Zugriff auf Kataloge unabhängig von Arbeitsbereichen verwalten oder Kataloge mit bestimmten Arbeitsbereichen verknüpfen, um sicherzustellen, dass bestimmte Arten von Daten nur in diesen Arbeitsbereichen verarbeitet werden. Sie können beispielsweise separate Produktions- und Entwicklungsarbeitsbereiche oder einen separaten Arbeitsbereich für die Verarbeitung persönlicher Daten einrichten.

  Standardmäßig werden Zugriffsberechtigungen für ein sicherungsfähiges Objekt von den untergeordneten Elementen dieses Objekts geerbt. Kataloge stehen dabei ganz oben in der Hierarchie. Dies erleichtert das Einrichten von Standardzugriffsregeln für Ihre Daten und das Angeben unterschiedlicher Regeln auf jeder Hierarchieebene ausschließlich dort, wo Sie sie benötigen.

• Schema (Datenbank): Schemas, auch als Datenbanken bezeichnet, sind logische Gruppierungen von tabellarischen Daten (Tabellen und Sichten), nicht tabellarischen Daten (Volumes), Funktionen und Machine Learning-Modellen. Sie bieten Ihnen die Möglichkeit, den Zugriff auf Daten detaillierter zu organisieren und zu steuern, als es mit Katalogen möglich ist. In der Regel repräsentieren sie einen einzelnen Anwendungsfall, ein bestimmtes Projekt oder eine Team-Sandbox.

  Schemas können im selben physischen Speicher wie der übergeordnete Katalog gespeichert werden. Sie können einen Katalog aber auch so konfigurieren, dass er getrennt vom Rest des übergeordneten Katalogs gespeichert wird.

  Metastoreadministratoren, Besitzer übergeordneter Kataloge und Schemabesitzer können den Zugriff auf Schemas verwalten.

• Tabellen: Tabellen befinden sich in der dritten der drei Ebenen des Namespace von Unity Catalog. Sie enthalten Datenzeilen.

  Mithilfe von Unity Catalog können Sie verwaltete Tabellen und externe Tabellen erstellen.

  Bei verwalteten Tabellen verwaltet Unity Catalog den Lebenszyklus und das Dateilayout vollständig. Verwaltete Tabellen werden standardmäßig am Stammspeicherort gespeichert, den Sie beim Erstellen des Metastores konfiguriert haben. Sie können alternativ den Speicher für verwaltete Tabellen auf Katalog- oder Schemaebene isolieren.

  Externe Tabellen sind Tabellen, deren Datenlebenszyklus und Dateilayout mithilfe Ihres Cloudanbieters und anderer Datenplattformen statt mit Unity Catalog verwaltet werden. In der Regel werden externe Tabellen verwendet, um große Mengen vorhandener Daten zu registrieren, oder wenn Sie auch Schreibzugriff auf die Daten mithilfe von Tools außerhalb von Azure Databricks-Clustern oder Databricks SQL-Warehouses benötigen. Sobald eine externe Tabelle in einem Unity Catalog-Metastore registriert wurde, können Sie den Azure Databricks-Zugriff genauso verwalten und überwachen wie bei verwalteten Tabellen.

  Besitzer übergeordneter Kataloge und Schemabesitzer können den Zugriff auf Tabellen ebenso verwalten wie Metastoreadministratoren (indirekt).

• Ansichten: Eine Ansicht ist ein schreibgeschütztes Objekt, das sich aus einer oder mehreren Tabellen und Ansichten in einem Metastore ableitet.

• Zeilen und Spalten: Der Zugriff auf Zeilen- und Spaltenebene sowie die Datenmaskierung werden entweder mithilfe dynamischer Ansichten gewährt oder mit Zeilenfiltern und Spaltenmasken. Dynamische Ansichten sind schreibgeschützt.

• Volumes: Volumes befinden sich in der dritten der drei Ebenen des Unity Catalog-Namespace. Sie verwalten nicht tabellarische Daten. Sie können Volumes verwenden, um Dateien in einem beliebigen Format zu speichern, zu organisieren und darauf zuzugreifen, einschließlich strukturierter, halbstrukturierter und unstrukturierter Daten. Dateien in Volumes können nicht als Tabellen registriert werden.

• Modelle und Funktionen: Registrierte Modelle und benutzerdefinierte Funktionen sind zwar streng genommen keine Datenressourcen, können aber ebenfalls in Unity Catalog verwaltet werden und sich auf der niedrigsten Ebene in der Objekthierarchie befinden. Siehe Verwalten des Modelllebenszyklus im Unity-Katalog und benutzerdefinierte Funktionen (USER-Defined Functions, UDFs) im Unity-Katalog.

Planen Ihres Modells zur Datenisolation

Wenn eine Organisation eine Datenplattform wie Azure Databricks verwendet, sind häufig Datenisolationsgrenzen zwischen Umgebungen (z. B. Entwicklung und Produktion) oder zwischen Betriebseinheiten der Organisation erforderlich.

Isolationsstandards können für Ihre Organization abweichen, aber in der Regel beinhalten sie die folgenden Erwartungen:

• Benutzer erhalten ausschließlich basierend auf angegebenen Zugriffsregeln Zugriff auf Daten.
• Daten können nur von festgelegten Personen oder Teams verwaltet werden.
• Daten werden im Speicher physisch getrennt.
• Auf Daten kann nur in festgelegten Umgebungen zugegriffen werden.

Die Notwendigkeit einer Datenisolation kann zu isolierten Umgebungen führen, was sowohl die Datengovernance als auch die Zusammenarbeit unnötig erschweren kann. Azure Databricks löst dieses Problem mithilfe von Unity Catalog, das eine Reihe von Optionen zur Datenisolation bietet und gleichzeitig eine einheitliche Datengovernanceplattform bereitstellt. In diesem Abschnitt werden die in Azure Databricks verfügbaren Optionen zur Datenisolation sowie deren Verwendung erläutert, unabhängig davon, ob Sie ein zentralisiertes oder ein verteiltes Datengovernancemodell bevorzugen.

Benutzer erhalten Zugriff auf Daten ausschließlich basierend auf angegebenen Zugriffsregeln.

Die meisten Organisationen haben strenge Anforderungen hinsichtlich des Datenzugriffs, der auf internen oder gesetzlichen Anforderungen beruht. Typische Beispiele für Daten, die sicher aufbewahrt werden müssen, sind Informationen über Mitarbeitergehälter oder Kreditkarteninformationen. Der Zugriff auf diese Art von Informationen wird in der Regel streng kontrolliert und in regelmäßigen Abständen überprüft. Unity Catalog bietet Ihnen eine detaillierte Kontrolle über Datenressourcen innerhalb des Katalogs, um diese Branchenstandards zu erfüllen. Mit den Steuerelementen, die Unity Catalog bereitstellt, können Benutzer nur die Daten anzeigen und abfragen, für die sie die Berechtigung haben.

Daten können nur von festgelegten Personen oder Teams verwaltet werden.

Unity Catalog bietet Ihnen die Möglichkeit, zwischen zentralisierten und verteilten Governancemodellen zu wählen.

Im zentralisierten Governancemodell sind Ihre Governanceadministratoren die Besitzer des Metastores und können den Besitz jedes Objekts übernehmen sowie Berechtigungen erteilen und widerrufen.

In einem verteilten Governancemodell ist der Katalog bzw. eine Reihe von Katalogen die Datendomäne. Der Besitzer dieses Katalogs kann alle Ressourcen erstellen und besitzen sowie die Governance innerhalb dieser Domäne verwalten. Die Besitzer einer beliebigen Domäne können unabhängig von den Besitzern anderer Domänen arbeiten.

Unabhängig davon, ob Sie den Metastore oder Kataloge als Datendomäne auswählen, empfiehlt Databricks dringend, eine Gruppe als Metastoreadministrator bzw. Katalogbesitzer festzulegen.

Daten werden im Speicher physisch getrennt

Eine Organisation kann festlegen, dass Daten bestimmter Typen in bestimmten Konten oder Buckets in ihrem Cloudmandanten gespeichert werden.

Unity Catalog bietet die Möglichkeit, Speicherorte auf Metastore-, Katalog- oder Schemaebene zu konfigurieren, um diese Anforderungen zu erfüllen.

Angenommen, Ihre Organisation verfügt über eine Unternehmenscompliancerichtlinie, die erfordert, dass Produktionsdaten im Zusammenhang mit Personalressourcen sich im Container abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net befinden. In Unity Catalog können Sie diese Anforderung umsetzen, indem Sie einen Speicherort auf Katalogebene festlegen, z. B. einen Katalog namens hr_prod erstellen und ihm den Speicherort abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog zuweisen. Dies bedeutet, dass verwaltete Tabellen oder Volumes, die im hr_prod-Katalog erstellt wurden (z. B. mithilfe von CREATE TABLE hr_prod.default.table …) ihre Daten in abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog speichern. Optional können Sie festlegen, dass Speicherorte auf Schemaebene bereitgestellt werden, um Daten innerhalb von hr_prod catalog auf granularerer Ebene zu organisieren.

Wenn eine solche Speicherisolation nicht erforderlich ist, können Sie einen Speicherort auf Metaspeicherebene festlegen. Das Ergebnis ist, dass dieser Speicherort als Standardspeicherort zum Speichern von verwalteten Tabellen und Volumes in Katalogen und Schemas im Metastore dient.

Das System wertet die Hierarchie der Speicherorte von Schema zu Katalog zu Metastore aus.

Wenn beispielsweise eine Tabelle myCatalog.mySchema.myTable in my-region-metastore erstellt wird, wird der Speicherort der Tabelle gemäß der folgenden Regel bestimmt:

1. Wenn ein Speicherort für mySchema bereitgestellt wurde, wird sie dort gespeichert.
2. Andernfalls, wenn ein Speicherort auf myCatalog bereitgestellt wurde, wird sie dort gespeichert.
3. Wenn kein Speicherort auf myCatalog angegeben wurde, wird sie schließlich an dem Speicherort gespeichert, der my-region-metastore zugeordnet ist.

Auf Daten kann nur in festgelegten Umgebungen zugegriffen werden.

Organisatorische und Complianceanforderungen schreiben oft vor, dass bestimmte Daten, z. B. personenbezogene Daten, nur in bestimmten Umgebungen zugänglich sein dürfen. Möglicherweise möchten Sie auch Produktionsdaten von Entwicklungsumgebungen isolieren oder sicherstellen, dass bestimmte Datasets und Domänen nie miteinander verknüpft werden.

In Databricks ist der Arbeitsbereich die primäre Datenverarbeitungsumgebung, und Kataloge sind die primäre Datendomäne. Mit Unity Catalog können Metastoreadministrator*innen und Katalogbesitzer*innen Kataloge Arbeitsbereichen zuweisen oder sie an bestimmte Arbeitsbereiche „binden“. Mithilfe dieser sich an der Umgebung orientierenden Verknüpfungen können Sie sicherstellen, dass nur bestimmte Kataloge innerhalb eines Arbeitsbereichs verfügbar sind, unabhängig von den spezifischen Berechtigungen für Datenobjekte, die einem Benutzer gewährt werden.

Als Nächstes betrachten wir den Prozess der Einrichtung von Unity Catalog gemäß Ihren Anforderungen genauer.

Konfigurieren eines Unity Catalog-Metastores

Ein Metastore ist der Objektcontainer der obersten Ebene in Unity Catalog. Metastores verwalten Datenressourcen (Tabellen, Sichten und Volumes) sowie andere sicherungsfähige Objekte, die von Unity Catalog verwaltet werden. Eine vollständige Liste der sicherungsfähigen Objekte finden Sie unter Sicherungsfähige Objekte in Unity Catalog.

Dieser Abschnitt enthält Tipps zum Erstellen und Konfigurieren von Metastores. Wenn Ihr Arbeitsbereich für Unity Catalog automatisch aktiviert wurde, müssen Sie keinen Metastore erstellen, aber die in diesem Abschnitt dargestellten Informationen sind möglicherweise trotzdem hilfreich. Siehe Automatische Aktivierung von Unity Catalog.

Tipps zum Konfigurieren von Metastores:

• Sie sollten einen Metastore für jede Region einrichten, in der Sie über Azure Databricks-Arbeitsbereiche verfügen.

  Jeder Arbeitsbereich, der an einen einzelnen regionalen Metastore angefügt ist, besitzt Zugriff auf die vom Metastore verwalteten Daten. Wenn Sie Daten zwischen Metastores freigeben möchten, verwenden Sie Delta Sharing.

• Jeder Metastore kann mit einem verwalteten Speicherort (auch als Stammspeicherort bezeichnet) in Ihrem Cloudmandanten konfiguriert werden, der zum Speichern verwalteter Tabellen und verwalteter Volumes verwendet werden kann.

  Wenn Sie einen verwalteten Speicherort auf Metastoreebene erstellen möchten, müssen Sie sicherstellen, dass keine Benutzer direkten Zugriff darauf haben (d. h. über das Cloudkonto, das ihn enthält). Wenn Zugriff auf diesen Speicherort gewährt wird, könnte ein Benutzer Zugriffskontrollen in einem Unity Catalog-Metastore umgehen und die Überprüfbarkeit stören. Aus diesen Gründen sollte Ihr verwalteter Metastore-Speicher ein dedizierter Container sein. Sie sollten einen Container, der auch Ihr DBFS-Stammdateisystem ist oder zuvor ein DBFS-Stammdateisystem war, nicht wiederverwenden.

  Sie haben auch die Möglichkeit, verwalteten Speicher auf Katalog- und Schemaebene zu definieren und den Stammspeicherort des Metastore zu überschreiben. In den meisten Szenarien empfiehlt Databricks, verwaltete Daten auf Katalogebene zu speichern.

• Machen Sie sich mit den Berechtigungen der Administrator*innen von Arbeitsbereichen vertraut, die für Unity Catalog aktiviert sind. Überprüfen Sie Ihre vorhandenen Administratorzuweisungen für Arbeitsbereiche.

  Arbeitsbereichsadministrator*innen können Vorgänge für ihren Arbeitsbereich verwalten und beispielsweise Benutzer*innen und Dienstprinzipale hinzufügen, Cluster erstellen und andere Benutzer*innen als Arbeitsbereichsadministrator*innen delegieren. Wenn Ihr Arbeitsbereich automatisch für den Unity Catalog aktiviert wurde, haben Arbeitsbereichsadministratoren standardmäßig die Möglichkeit, Kataloge und viele andere Unity Catalog-Objekte zu erstellen. Weitere Informationen finden Sie unter Privilegien für Arbeitsbereichsadministratoren, wenn Arbeitsbereiche automatisch für Unity Catalog aktiviert werden.

  Arbeitsbereichsadministratoren haben auch die Möglichkeit, Arbeitsbereichsverwaltungsaufgaben durchzuführen, z. B. das Verwalten des Auftragsbesitzes und das Anzeigen von Notebooks, die ihnen indirekten Zugriff auf Daten gewähren, die in Azure Data Lake Storage registriert sind. „Arbeitsbereichsadministrator“ ist eine privilegierte Rolle, die Sie sorgfältig vergeben sollten.

• Wenn Sie Arbeitsbereiche verwenden, um den Benutzerdatenzugriff zu isolieren, empfiehlt sich die Verwendung von Bindungen zwischen Arbeitsbereichen und Katalogen. Mithilfe von Bindungen zwischen Arbeitsbereichen und Katalogen können Sie den Zugriff auf Kataloge durch Arbeitsbereichsgrenzen einschränken. So können Sie beispielsweise sicherstellen, dass Arbeitsbereichsadministrator*innen und Benutzer*innen nur aus einer Produktionsarbeitsbereichsumgebung (prod_workspace) auf Produktionsdaten in prod_catalog zugreifen können. Standardmäßig wird der Katalog für alle Arbeitsbereiche freigegeben, die an den aktuellen Metastore angefügt sind. Weitere Informationen finden Sie unter Einschränken des Katalogzugriffs auf bestimmte Arbeitsbereiche.

  Wenn Ihr Arbeitsbereich automatisch für Unity Catalog aktiviert wurde, ist der vorab bereitgestellte Arbeitsbereichkatalog standardmäßig an Ihren Arbeitsbereich gebunden.

Weitere Informationen finden Sie unter Erstellen eines Unity Catalog-Metastores.

Konfigurieren externer Speicherorte und Speicheranmeldeinformationen

Externe Speicherorte ermöglichen Unity Catalog das Lesen und Schreiben von Daten in Ihren Cloudmandanten im Namen von Benutzern. Externe Speicherorte werden als Pfad zu Cloudspeicher in Kombination mit Speicheranmeldeinformationen definiert, die für den Zugriff auf diesen Speicherort verwendet werden können.

Sie können externe Speicherorte verwenden, um externe Tabellen und externe Volumes in Unity Catalog zu registrieren. Der Inhalt dieser Entitäten befindet sich physisch in einem Unterpfad an einem externen Speicherort, auf den verwiesen wird, wenn ein Benutzer das Volume oder die Tabelle erstellt.

Eine Speicherberechtigung kapselt eine langfristige Cloud-Berechtigung, die Zugriff auf Cloud-Speicher bietet. Dabei kann es sich entweder um eine von Azure verwaltete Identität (dringend empfohlen) oder um einen Dienstprinzipal handeln. Die Verwendung einer verwalteten Azure-Identität hat die folgenden Vorteile gegenüber der Verwendung eines Dienstprinzipals:

• Bei verwalteten Identitäten müssen Sie keine Anmeldedaten verwalten oder Geheimnisse weitergeben.
• Wenn Ihr Azure Databricks-Arbeitsbereich in Ihrem eigenen VNet (auch als VNET-Einschleusung bezeichnet) bereitgestellt wird, können Sie eine Verbindung mit einem Azure Data Lake Storage Gen2-Konto herstellen, das durch eine Speicherfirewall geschützt ist.

Für eine erhöhte Datenisolation können Sie Dienstanmeldeinformationen, Speicheranmeldeinformationen und externe Speicherorte an bestimmte Arbeitsbereiche binden. Siehe (Optional) Zuweisen einer Dienstanmeldeinformationen zu bestimmten Arbeitsbereichen, (Optional) Zuweisen eines externen Speicherorts zu bestimmten Arbeitsbereichen und (Optional) Zuweisen einer Speicheranmeldeinformationen zu bestimmten Arbeitsbereichen.

Tipp

Externe Speicherorte bieten durch die Kombination von Speicheranmeldeinformationen und Speicherpfaden eine starke Kontrolle und Überprüfbarkeit des Speicherzugriffs. Um zu verhindern, dass Benutzer die von Unity Catalog bereitgestellte Zugriffssteuerung umgehen, sollten Sie sicherstellen, dass Sie die Anzahl der Benutzer mit direktem Zugriff auf jeden Container begrenzen, der als externer Speicherort verwendet wird. Aus demselben Grund sollten Sie keine Speicherkonten in DBFS bereitstellen, wenn sie auch als externe Speicherorte verwendet werden. Databricks empfiehlt das Migrieren von Bereitstellungen an Cloudspeicherorten zu externen Speicherorten innerhalb von Unity Catalog mithilfe des Katalog-Explorers.

Eine Liste der bewährten Methoden zum Verwalten externer Standorte finden Sie unter Verwalten externer Speicherorte, externer Tabellen und externer Volumes. Siehe auch Erstellen eines externen Speicherorts zum Verbinden des Cloudspeichers mit Azure Databricks.

Organisieren von Daten

Databricks empfiehlt die Verwendung von Katalogen, um eine Trennung in der Informationsarchitektur Ihrer Organisation bereitzustellen. Dies bedeutet häufig, dass Kataloge dem Umfang, dem Team oder der Geschäftseinheit der Softwareentwicklungsumgebung entsprechen. Wenn Sie Arbeitsbereiche als Datenisolationstool verwenden, z. B. verschiedene Arbeitsbereiche für Produktions- und Entwicklungsumgebungen oder einen bestimmten Arbeitsbereich für die Arbeit mit hochsensiblen Daten, können Sie einen Katalog auch an bestimmte Arbeitsbereiche binden. Dadurch wird sichergestellt, dass die gesamte Verarbeitung der angegebenen Daten im entsprechenden Arbeitsbereich verarbeitet wird. Weitere Informationen finden Sie unter Einschränken des Katalogzugriffs auf bestimmte Arbeitsbereiche.

Ein Schema (auch als Datenbank bezeichnet) ist die zweite der drei Ebenen im Namespace von Unity Catalog und wird zum Organisieren von Tabellen, Sichten und Volumes verwendet. Sie können Schemas verwenden, um Berechtigungen für Ihre Ressourcen zu organisieren und zu definieren.

Objekte, die von Unity Catalog gesteuert werden, können verwaltet oder extern sein:

• Verwaltete Objekte sind das Standardverfahren zum Erstellen von Datenobjekten in Unity Catalog.

  Unity Catalog verwaltet den Lebenszyklus und das Dateilayout für diese sicherungsfähigen Ressourcen. Sie sollten keine Tools außerhalb von Azure Databricks verwenden, um Dateien in verwalteten Tabellen oder Volumes direkt zu bearbeiten.

  Verwaltete Tabellen und Volumes werden im verwalteten Speicher gespeichert, der auf Metastore-, Katalog- oder Schemaebene für eine bestimmte Tabelle oder ein bestimmtes Volume vorhanden sein können. Siehe Daten werden physisch im Speicher getrennt.

  Verwaltete Tabellen und Volumes sind eine bequeme Lösung, wenn Sie einen verwalteten Speicherort für Ihre Inhalte bereitstellen möchten, ohne den Aufwand für die Erstellung und Verwaltung externer Speicherorte und Anmeldeinformationen betreiben zu müssen.

  Verwaltete Tabellen verwenden immer das Delta-Tabellenformat.

• Externe Objekte sind sicherungsfähige Ressourcen, deren Datenlebenszyklus und Dateilayout nicht von Unity Catalog verwaltet wird.

  Externe Volumes und Tabellen werden an einem externen Speicherort registriert, um Zugriff auf eine große Anzahl von Dateien zu ermöglichen, die bereits im Cloudspeicher vorhanden sind, ohne dass Datenkopieraktivitäten erforderlich sind. Verwenden Sie externe Objekte, wenn Sie über Dateien verfügen, die von anderen Systemen erstellt werden und für den Zugriff aus Azure Databricks bereitgestellt werden sollen, oder wenn Tools außerhalb von Azure Databricks direkten Zugriff auf diese Dateien benötigen.

  Externe Tabellen unterstützen Delta Lake und viele andere Datenformate, einschließlich Parquet, JSON und CSV. Sowohl verwaltete als auch externe Volumes können verwendet werden, um auf Dateien beliebiger Formate zuzugreifen und diese zu speichern: Daten können strukturiert, halbstrukturiert oder unstrukturiert sein.

Weitere Informationen zum Erstellen von Tabellen und Volumes finden Sie unter Was sind Tabellen und Ansichten? Und was sind Unity-Katalogvolumes?.

Verwalten externer Standorte, externer Tabellen und externer Volumes

Die folgende Abbildung stellt die Dateisystemhierarchie eines einzelnen Cloudspeichercontainers mit vier externen Speicherorten dar, die eine Speicheranmeldeinformation gemeinsam nutzen.

Sobald Sie externe Speicherorte in Unity Catalog konfiguriert haben, können Sie externe Tabellen und Volumes in Verzeichnissen innerhalb der externen Speicherorte erstellen. Anschließend können Sie Unity Catalog verwenden, um den Benutzer- und Gruppenzugriff auf diese Tabellen und Volumes zu verwalten. Dadurch können Sie bestimmten Benutzern oder Gruppen Zugriff auf bestimmte Verzeichnisse und Dateien im Cloudspeichercontainer erteilen.

Hinweis

Wenn Sie ein externes Volume definieren, UNTERLIEGT der Cloud-URI-Zugriff auf Daten unter dem Volumepfad den Berechtigungen, die auf dem Volume gewährt werden, nicht den Berechtigungen, die für den externen Speicherort gewährt werden, an dem das Volume gespeichert ist.

Empfehlungen für die Verwendung externer Speicherorte

Empfehlungen für die Erteilung von Berechtigungen für externe Speicherorte:

• Erteilen Sie die Berechtigung, externe Speicherorte zu erstellen, nur einem Administrator, der für die Einrichtung von Verbindungen zwischen Unity Catalog und Cloudspeicher zuständig ist, oder vertrauenswürdigen Datentechnikern.

  Externe Speicherorte ermöglichen den Zugriff aus dem Unity-Katalog auf einen breit angelegten Speicherort im Cloudspeicher, z. B. einen gesamten Bucket oder Container (abfss://my-container@storage-account.dfs.core.windows.net) oder einen breiten Unterpfad (abfss://my-container@storage-account.dfs.core.windows.net/path/to/subdirectory). Die Absicht besteht darin, dass ein Cloudadministrator an der Einrichtung einiger externer Speicherorte beteiligt sein kann und dann die Verantwortung für die Verwaltung dieser Speicherorte an einen Azure Databricks-Administrator in Ihrer Organisation delegiert. Der Azure Databricks-Administrator kann den externen Speicherort dann weiter in Bereiche mit präziseren Berechtigungen organisieren, indem er externe Volumes oder externe Tabellen mit bestimmten Präfixen unter dem externen Speicherort registriert.

  Da externe Speicherorte so umfangreich sind, empfiehlt Databricks, die Berechtigung CREATE EXTERNAL LOCATION nur einem Administrator zu erteilen, der die Aufgabe hat, Verbindungen zwischen Unity Catalog und Cloudspeicher festzulegen, oder vertrauenswürdigen Datentechnikern. Um anderen Nutzern differenzierteren Zugriff zu ermöglichen, empfiehlt Databricks, externe Tabellen oder Volumes zusätzlich zu externen Speicherorten zu registrieren und Benutzern über Volumes oder Tabellen Zugriff auf Daten zu erteilen. Da Tabellen und Volumes untergeordnete Elemente eines Katalogs und Schemas sind, verfügen Katalog- oder Schemaadministratoren über die ultimative Kontrolle über Zugriffsberechtigungen.

  Sie können auch den Zugriff auf einen externen Speicherort steuern, indem Sie ihn an bestimmte Arbeitsbereiche binden. Siehe (Optional) Zuweisen eines externen Speicherorts zu bestimmten Arbeitsbereichen.

• Erteilen Sie Endbenutzern keine allgemeinen Berechtigungen READ FILES oder WRITE FILES für externe Speicherorte.

  Dank der Verfügbarkeit von Volumes sollten Benutzer externe Speicherorte nur noch zum Erstellen von Tabellen, Volumes oder verwalteten Speicherorten verwenden. Sie sollten keine externen Speicherorte für pfadbasierten Zugriff für Data Science oder andere nicht tabellarische Datenanwendungsfälle nutzen.

  Volumes bieten Unterstützung für das Arbeiten mit Dateien mithilfe von SQL-Befehlen, dbutils, Spark-APIs, REST-APIs, Terraform und einer Benutzeroberfläche zum Durchsuchen, Hochladen und Herunterladen von Dateien. Darüber hinaus bieten Volumes eine FUSE-Einbindung, auf die im lokalen Dateisystem unter /Volumes/<catalog_name>/<schema_name>/<volume_name>/ zugegriffen werden kann. Die FUSE-Einbindung ermöglicht es Datenwissenschaftlern und ML-Ingenieuren, auf Dateien wie in einem lokalen Dateisystem zuzugreifen, wie es für viele Bibliotheken für maschinelles Lernen oder Betriebssysteme erforderlich ist.

  Wenn Sie direkten Zugriff auf Dateien an einem externen Speicherort erteilen müssen (z. B. zum Untersuchen von Dateien in Cloudspeicher, bevor ein Benutzer eine externe Tabelle oder ein externes Volume erstellt), können Sie READ FILES erteilen. Anwendungsfälle für die Erteilung von WRITE FILES sind selten.

Sie sollten externe Speicherorte verwenden, um die folgenden Aktionen auszuführen:

• Registrieren externer Tabellen und Volumes mithilfe der Befehle CREATE EXTERNAL VOLUME oder CREATE TABLE.
• Untersuchen vorhandener Dateien im Cloudspeicher, bevor Sie eine externe Tabelle oder ein externes Volume mit einem bestimmten Präfix erstellen. Die Berechtigung READ FILES ist eine Voraussetzung.
• Registrieren eines Speicherorts als verwalteter Speicher für Kataloge und Schemas anstelle des Metastore-Stammbuckets. Die Berechtigung CREATE MANAGED STORAGE ist eine Voraussetzung.

Weitere Empfehlungen für die Verwendung externer Speicherorte:

• Vermeiden von Pfadüberschneidungskonflikten: Erstellen Sie niemals externe Volumes oder Tabellen am Stamm eines externen Speicherorts.

  Wenn Sie externe Volumes oder Tabellen am Stamm des externen Speicherorts erstellen, können Sie keine weiteren externen Volumes oder Tabellen am externen Speicherort erstellen. Erstellen Sie stattdessen externe Volumes oder Tabellen in einem Unterverzeichnis innerhalb des externen Speicherorts.

Empfehlungen für die Verwendung externer Volumes

Sie sollten externe Volumes verwenden, um die folgenden Aktionen auszuführen:

• Registrieren von Zielbereichen für Rohdaten, die von externen Systemen generiert werden, um die Verarbeitung in frühen Phasen von ETL-Pipelines und anderen Datentechnikaktivitäten zu unterstützen.
• Registrieren von Stagingspeicherorten für die Erfassung, z. B. mithilfe von Auto Loader-, COPY INTO- oder CTAS-Anweisungen (CREATE TABLE AS).
• Bereitstellen von Dateispeicherorten für Data Scientists, Datenanalysten und Machine Learning-Techniker, die als Teil ihrer explorativen Datenanalyse und anderer Data Science-Aufgaben verwendet werden können, wenn verwaltete Volumes keine Option darstellen.
• Erteilen von Zugriff auf beliebige Dateien für Azure Databricks-Benutzer, die von anderen Systemen im Cloudspeicher erstellt und gespeichert werden, z. B. große Sammlungen unstrukturierter Daten (z. B. Bild-, Audio-, Video- und PDF-Dateien), die von Überwachungssystemen oder IoT-Geräten erfasst wurden, oder Bibliotheksdateien (JAR- und Python-Wheel-Dateien), die aus lokalen Abhängigkeitsverwaltungssystemen oder CI/CD-Pipelines exportiert werden.
• Speichern von Betriebsdaten, z. B. Protokollierungs- oder Prüfpunktdateien, wenn verwaltete Volumes keine Option darstellen.

Weitere Empfehlungen für die Verwendung externer Volumes:

• Databricks empfiehlt, externe Volumes aus einem externen Speicherort innerhalb eines Schemas zu erstellen.

Tipp

Verwenden Sie externe Volumes für Erfassunganwendungsfälle, in denen die Daten an einen anderen Speicherort kopiert werden (z. B. mit Auto Loader oder COPY INTO). Verwenden Sie externe Tabellen, wenn Sie Daten direkt als Tabelle abfragen möchten, ohne dass eine Kopie erforderlich ist.

Empfehlungen für die Verwendung externer Tabellen

Sie sollten externe Tabellen verwenden, um normale Abfragemuster für Daten zu unterstützen, die in einem Cloudspeicher gespeichert sind, wenn die Erstellung verwalteter Tabellen keine Option darstellt.

Weitere Empfehlungen für die Verwendung externer Tabellen:

• Databricks empfiehlt, externe Tabellen aus einem externen Speicherort innerhalb eines Schemas zu erstellen.
• Databricks rät aufgrund des Risikos von Konsistenzproblemen dringend davon ab, eine Tabelle als externe Tabelle in mehr als einem Metastore zu registrieren. Beispielsweise wird eine Änderung des Schemas in einem Metastore nicht im zweiten Metastore registriert. Verwenden Sie Delta Sharing zum Freigeben von Daten zwischen Metastores. Weitere Informationen finden Sie unter Sicheres Freigeben von Daten mithilfe von Delta Sharing.

Verwalten der Zugriffssteuerung

Jedes sicherungsfähige Objekt in Unity Catalog verfügt über eine*n Besitzer*in. Der Prinzipal, der ein Objekt erstellt, wird zum ursprünglichen Besitzer. Der Besitzer eines Objekts hat alle Berechtigungen für das Objekt, wie z. B. SELECT und MODIFY für eine Tabelle, sowie die Berechtigung, anderen Prinzipalen Berechtigungen für das sicherungsfähige Objekt zu erteilen. Nur Besitzer eines sicherungsfähigen Objekts haben die Berechtigung, anderen Prinzipalen Berechtigungen für dieses Objekt zu erteilen. Daher empfiehlt es sich, den Besitz aller Objekte für die Gruppe zu konfigurieren, die für die Verwaltung von Berechtigungen für das Objekt verantwortlich ist. Sowohl der Besitzer als auch Metastore-Administratoren können den Besitz eines sicherungsfähigen Objekts auf eine Gruppe übertragen. Wenn das Objekt in einem Katalog (z. B. einer Tabelle oder Ansicht) enthalten ist, kann der Katalog- und Schemabesitzer den Besitz des Objekts ändern.

Sicherungsobjekte in Unity Catalog sind hierarchisch, und Berechtigungen werden abwärts vererbt. Dies bedeutet: Durch das Gewähren einer Berechtigung für einen Katalog oder ein Schema wird die Berechtigung für alle aktuellen und zukünftigen Objekte im Katalog oder Schema automatisch gewährt. Weitere Informationen finden Sie unter Vererbungsmodell.

Um Daten aus einer Tabelle zu lesen oder anzuzeigen, muss ein Benutzer über die folgenden Berechtigungen verfügen:

• SELECT an der Tabelle oder Ansicht
• USE SCHEMA Schema, das Besitzer der Tabelle ist
• USE CATALOG im Katalog, der das Schema besitzt

USE CATALOG ermöglicht es dem Berechtigungsempfänger, den Katalog zu durchlaufen, um auf seine untergeordneten Objekte zuzugreifen, und USE SCHEMA ermöglicht es dem Berechtigungsempfänger, das Schema zu durchlaufen, um auf seine untergeordneten Objekte zuzugreifen. Damit sie beispielsweise Daten aus einer Tabelle auswählen können, müssen Benutzer die Berechtigung SELECT für diese Tabelle sowie die Berechtigung USE CATALOG für ihren übergeordneten Katalog sowie die Berechtigung USE SCHEMA für ihren übergeordnetes Schema haben. Daher können Sie diese Berechtigung verwenden, um den Zugriff auf Abschnitte Ihres Datennamespace auf bestimmte Gruppen zu beschränken. Ein gängiges Szenario besteht darin, ein Schema pro Team einzurichten, wobei nur dieses Team USE SCHEMA und CREATE im Schema hat. Das bedeutet, dass alle von Teammitgliedern erstellten Tabellen nur innerhalb des Teams geteilt werden können.

Sie können den Zugriff auf eine Tabelle mit der folgenden SQL-Syntax sichern:

GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

Sie können den Zugriff auf Spalten mithilfe einer dynamischen Ansicht in einem sekundären Schema sichern, wie in der folgenden SQL-Syntax gezeigt:

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  id,
  CASE WHEN is_account_group_member(< group_name >) THEN email ELSE 'REDACTED' END AS email,
  country,
  product,
  total
FROM
  < catalog_name >.< schema_name >.< table_name >;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;

Sie können den Zugriff auf Zeilen mithilfe einer dynamischen Ansicht in einem sekundären Schema sichern, wie in der folgenden SQL-Syntax gezeigt:

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  *
FROM
  < catalog_name >.< schema_name >.< table_name >
WHERE
  CASE WHEN is_account_group_member(managers) THEN TRUE ELSE total <= 1000000 END;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

Sie können Benutzern auch sicheren Zugriff auf Tabellen gewähren, indem Sie Zeilenfilter und Spaltenmasken verwenden. Weitere Informationen finden Sie unter Filtern vertraulicher Tabellendaten mithilfe von Zeilenfiltern und Spaltenmasken.

Weitere Informationen zu allen Berechtigungen in Unity Catalog finden Sie unter Verwalten von Berechtigungen in Unity Catalog.

Verwalten von Clusterkonfigurationen

Databricks empfiehlt die Verwendung von Cluster-Richtlinien, um die Möglichkeit zum Konfigurieren von Clustern basierend auf einer Reihe von Regeln einzuschränken. Mithilfe von Cluster-Richtlinien können Sie den Zugriff einschränken, um nur Cluster zu erstellen, die für Unity Catalog aktiviert sind. Die Verwendung von Cluster-Richtlinien reduziert die verfügbaren Auswahlmöglichkeiten, was den Cluster-Erstellungsprozess für Benutzer erheblich vereinfacht und sicherstellt, dass sie nahtlos auf Daten zugreifen können. Cluster-Richtlinien ermöglichen es Ihnen auch, die Kosten zu kontrollieren, indem Sie die maximalen Kosten pro Cluster begrenzen.

Um die Integrität der Zugriffskontrollen zu gewährleisten und strenge Isolationsgarantien durchzusetzen, erlegt Unity Catalog Sicherheitsanforderungen an Rechenressourcen auf. Aus diesem Grund führt Unity Catalog das Konzept des Zugriffsmodus eines Clusters ein. Unity Catalog ist standardmäßig sicher. Wenn ein Cluster nicht mit einem geeigneten Zugriffsmodus konfiguriert ist, kann der Cluster nicht auf Daten in Unity Catalog zugreifen. Weitere Informationen finden Sie unter Computeanforderungen.

Databricks empfiehlt den gemeinsamen Zugriffsmodus bei der gemeinsamen Nutzung eines Clusters und den Einzelbenutzer-Zugriffsmodus für automatisierte Aufträge und Machine Learning Workloads.

Im folgenden JSON finden Sie eine Richtliniendefinition für einen Cluster mit dem gemeinsamen Zugriffsmodus:

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9]*\\.x-scala.*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "USER_ISOLATION",
    "hidden": true
}
}

Die folgende JSON-Datei enthält eine Richtliniendefinition für ein automatisiertes Auftrags-Cluster mit dem Zugriffsmodus Einzelbenutzer:

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9].*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "SINGLE_USER",
    "hidden": true
},
"single_user_name": {
    "type": "regex",
    "pattern": ".*",
    "hidden": true
}
}

Überwachen des Zugriffs

Eine vollständige Data Governance-Lösung erfordert die Prüfung des Zugriffs auf Daten und die Bereitstellung von Warn- und Überwachungsfunktionen. Unity Catalog erfasst ein Überwachungsprotokoll von Aktionen, die für den Metastore ausgeführt werden, und diese Protokolle werden als Teil von Azure Databricks-Überwachungsprotokollen bereitgestellt.

Sie können mithilfe von Systemtabellen auf die Überwachungsprotokolle Ihres Kontos zugreifen. Weitere Informationen zur Überwachungsprotokollsystemtabelle finden Sie unter Überwachungsprotokollsystem-Tabellenverweis.

Unter Überwachen Ihrer Databricks Data Intelligence-Plattform mit Überwachungsprotokollen finden Sie Einzelheiten dazu, wie Sie vollständigen Einblick in kritische Ereignisse in Bezug auf Ihre Databricks Data Intelligence-Plattform erhalten.

Sicheres Freigeben von Daten mithilfe von Delta Sharing

Delta-Sharing ist ein offenes Protokoll, das von Databricks für die sichere Datenfreigabe mit anderen Organisationen oder anderen Abteilungen innerhalb Ihrer Organisation entwickelt wurde, unabhängig davon, welche Computerplattformen sie verwenden. Wenn Delta Sharing für einen Metastore aktiviert ist, führt Unity Catalog einen Delta Sharing-Server aus.

Um Daten zwischen Metastores freizugeben, können Sie Databricks-zu-Databricks-Delta Sharing nutzen. Dadurch können Sie Tabellen aus Metastores in verschiedenen Regionen registrieren. Diese Tabellen werden im verbrauchenden Metastore als schreibgeschützte Objekte angezeigt. Diesen Tabellen kann wie jedem anderen Objekt in Unity Catalog Zugriff gewährt werden.

Wenn Sie Databricks-zu-Databricks-Delta Sharing für die Freigabe zwischen Metastores verwenden, sollten Sie beachten, dass die Zugriffssteuerung auf einen Metastore beschränkt ist. Wenn ein sicherungsfähiges Objekt, z. B. eine Tabelle, über Zuweisungen verfügt und diese Ressource für einen kontointernen Metastore freigegeben wird, gelten die Zuweisungen aus der Quelle nicht für die Zielfreigabe. Für die Zielfreigabe müssen eigene Zuweisungen festgelegt werden.

Weitere Informationen

• Einrichten und Verwalten des Unity Catalog
• Was ist Delta Sharing?
• Upgrade von Hive-Tabellen und Sichten für Unity Catalog