Bewährte Methoden für Unity Catalog

Dieses Dokument enthält Empfehlungen für die Verwendung des Unity-Katalogs, um Ihre Datengovernanceanforderungen am effektivsten zu erfüllen. Eine Einführung in die Datengovernance in Azure Databricks finden Sie unter Data Governance mit Azure Databricks. Eine Einführung in den Unity-Katalog finden Sie unter "Was ist Unity-Katalog?".

Identitäten

Prinzipale (Benutzer, Gruppen und Dienstprinzipale) müssen auf der Kontoebene von Azure Databricks definiert werden, um Privilegien auf sicherheitsrelevante Objekte von Unity Catalog zu erhalten. Databricks empfiehlt, dass Sie SCIM verwenden, um Ihrem Azure Databricks-Konto über Ihren IdP Prinzipale bereitzustellen.

Bewährte Methoden:

• Vermeiden Sie (und deaktivieren Sie vorhandene) SCIM-Bereitstellung auf Arbeitsbereichsebene. Die Bereitstellung von Prinzipalen direkt für einen Arbeitsbereich sollte veralteten Arbeitsbereichen vorbehalten bleiben, die nicht für Unity Catalog aktiviert sind. Sie sollten die Bereitstellung vollständig auf Kontoebene verwalten.

• Definieren und Verwalten von Gruppen in Ihrem IdP. Sie sollten mit Ihren Organisationsgruppendefinitionen konsistent sein.

  Gruppen verhalten sich anders als Benutzer und Dienstprinzipale. Obwohl Benutzer und Dienstprinzipale, die Sie einem Arbeitsbereich hinzufügen, automatisch mit Ihrem Azure Databricksaccount synchronisiert werden, sind Gruppen auf Arbeitsbereichsebene nicht vorhanden. Wenn Sie über arbeitsbereichslokale Gruppen verfügen, sollten Sie sie manuell zu dem Konto migrieren, vorzugsweise indem Sie sie in Ihrem IdP replizieren (falls erforderlich) und sie für das Konto bereitstellen.

• Richten Sie Gruppen so ein, dass Sie sie effektiv verwenden können, um Zugriff auf Daten und andere sicherbare Elemente des Unity-Katalogs zu gewähren. Vermeiden Sie direkte Zuschüsse für Benutzer, wenn möglich.

• Verwenden Sie Gruppen, um die Besitzrechte den meisten sicherungsfähigen Objekten zuzuweisen.

• Vermeiden Sie das manuelle Hinzufügen von Benutzern zum Konto oder zum Arbeitsbereich. Vermeiden Sie das Ändern von Gruppen in Azure Databricks: Verwenden Sie Ihren IdP.

• Verwenden Sie Dienstprinzipale, um Jobs auszuführen. Dienstprinzipale ermöglichen die Automatisierung von Aufgaben. Wenn Sie Benutzer verwenden, um Aufträge auszuführen, die in die Produktion schreiben, riskieren Sie versehentlich das Überschreiben von Produktionsdaten.

Weitere Informationen finden Sie unter Verwalten von Benutzern, Dienstprinzipalen und Gruppen und Synchronisieren von Benutzern und Gruppen von Microsoft Entra ID mithilfe von SCIM.

Administratorrollen und leistungsstarke Berechtigungen

Das Zuweisen von Administratorrollen und leistungsstarken Berechtigungen wie ALL PRIVILEGES z. B. und MANAGE erfordert Sorgfalt:

• Verstehen Sie die Berechtigungen von Kontoadministratoren, Arbeitsbereichsadministratoren und Metastore-Administratoren, bevor Sie sie zuweisen. Siehe Administratorrechte im Unity Catalog.
• Weisen Sie diese Rollen nach Möglichkeit Gruppen zu.
• Metastore-Administratoren sind optional. Weisen Sie sie nur zu, wenn Sie sie benötigen. Anleitungen finden Sie unter (Optional) Zuweisen der Metastore-Administratorrolle.
• Weisen Sie Gruppen objektbesitz zu, insbesondere, wenn Objekte in der Produktion verwendet werden. Der Ersteller eines Objekts ist der erste Besitzer. Ersteller sollten die Besitzrechte an die entsprechenden Gruppen weitergeben.
• Nur Metastore-Administratoren, Besitzer und Benutzer mit den MANAGE Berechtigungen für ein Objekt können Berechtigungen für dieses Objekt gewähren. Besitzer von übergeordneten Katalogen und Schemas haben auch die Möglichkeit, Berechtigungen für alle Objekte im Katalog oder Schema zu gewähren. Seien Sie sparsam bei der Zuweisung von Besitzerzuordnungen und dem MANAGE-Recht.
• Seien Sie sparsam bei der Zuweisung von ALL PRIVILEGES, die alle Berechtigungen außer MANAGE umfasst.

Berechtigungszuweisung

Sicherungsobjekte in Unity Catalog sind hierarchisch, und Berechtigungen werden abwärts vererbt. Verwenden Sie diese Vererbungshierarchie, um ein effektives Berechtigungsmodell zu entwickeln.

Bewährte Methoden:

• Verstehen des Unterschieds zwischen USE CATALOG (oder USE SCHEMA) und BROWSE:

  • USE CATALOG | SCHEMA gewährt die Möglichkeit, Daten im Katalog oder Schema anzuzeigen. Allein gewähren diese Berechtigungen keinen Zugriff auf SELECT oder READ innerhalb der Objekte des Katalogs oder Schemas, sie sind jedoch eine Voraussetzung dafür, Benutzern diesen Zugriff zu gewähren. Gewähren Sie diesen Berechtigungen nur Benutzern, die Daten im Katalog oder Schema anzeigen können sollen.
  • USE CATALOG | SCHEMA, indem sie den Zugriff auf einen Katalog oder ein Schema einschränken, verhindert, dass Objektbesitzer (z. B. eine Tabellenerstellerin) benutzern, die keinen Zugriff auf dieses Objekt (Tabelle) haben sollten, versehentlich Zugriff auf dieses Objekt (Tabelle) zuweisen. Es ist üblich, ein Schema pro Team zu erstellen und USE SCHEMA sowie CREATE TABLE nur diesem Team zu gewähren (zusammen mit USE CATALOG im übergeordneten Katalog).
  • BROWSE kann allgemein auf Katalogebene gewährt werden, damit Benutzer die Metadaten anzeigen können, die den Objekten im Katalog zugeordnet sind.

• Verstehen Sie den Unterschied zwischen Objektbesitz und dem MANAGE-Privileg.

  • Der Besitzer eines Objekts verfügt über alle Berechtigungen für das Objekt, wie SELECT und MODIFY auf einer Tabelle, sowie über die Berechtigung zum Erteilen von Berechtigungen für das sicherbare Objekt an andere Principals und zum Übertragen des Besitzes an andere Principals.
  • Besitzer können das MANAGE-Privileg erteilen, um die Besitzrechte an einem Objekt an andere Prinzipale zu delegieren.
  • Katalog- und Schemabesitzer können den Besitz eines beliebigen Objekts im Katalog oder Schema übertragen.
  • Am besten konfigurieren Sie den Besitz oder vergeben das MANAGE-Recht für alle Objekte an eine Gruppe, die für die Verwaltung von Berechtigungen für das Objekt verantwortlich ist.

• Reservieren Sie direkten MODIFY-Zugriff auf Produktionstabellen für Dienstprinzipale.

Weitere Informationen finden Sie unter Verwalten von Berechtigungen im Unity-Katalog.

Metastores

Es folgen Regeln und bewährte Methoden zum Erstellen und Verwalten von Metastores:

• Pro Region kann nur ein Metaspeicher vorhanden sein. Alle Arbeitsbereiche in dieser Region teilen diesen Metaspeicher. Informationen zum Freigeben von Daten zwischen Regionen finden Sie unter "Regionsübergreifendes und plattformübergreifendes Teilen".

• Metastores stellen eine regionale Isolation bereit, sind jedoch nicht als Standardeinheiten der Datenisolation vorgesehen. Die Datenisolation beginnt in der Regel auf Katalogebene. Wenn Sie jedoch ein zentralisiertes Governancemodell bevorzugen, können Sie verwalteten Speicher auf Metastoreebene erstellen. Empfehlungen finden Sie unter "Verwalteter Speicher".

• Die Metastore-Administratorrolle ist optional. Empfehlungen zum Zuweisen eines optionalen Metastore-Administrators finden Sie unter Administratorrollen und leistungsstarke Berechtigungen.

Von Bedeutung

Registrieren Sie häufig verwendete Tabellen nicht als externe Tabellen in mehr als einem Metaspeicher. Wenn Sie dies tun, werden Änderungen an dem Schema, den Tabelleneigenschaften, Kommentaren und anderen Metadaten, die aufgrund von Schreibvorgängen in Metastore A auftreten, nicht bei Metastore B registriert. Sie können auch Konsistenzprobleme mit dem Azure Databricks-Commitdienst verursachen.

Kataloge und Schemas

Kataloge sind die primäre Datenisolationseinheit im typischen Unity Catalog-Datengovernancemodell. Schemas fügen eine zusätzliche Ebene der Organisation hinzu.

Bewährte Methoden für die Katalog- und Schemaverwendung:

• Organisieren Sie Daten und KI-Objekte in Katalogen und Schemas, die Organisationsbereiche und Projekte widerspiegeln. Dies bedeutet häufig, dass Kataloge einem Umgebungsbereich, Team, Geschäftseinheit oder einer Kombination dieser Entsprechen entsprechen. Dies erleichtert die Verwendung der Berechtigungshierarchie, um den Zugriff effektiv zu verwalten.
• Wenn Arbeitsumgebungen und Daten beide die gleichen Isolationsanforderungen aufweisen, können Sie einen Katalog an einen bestimmten Arbeitsbereich binden. Wenn dies erforderlich ist, erstellen Sie Kataloge, die auf einen begrenzten Satz von Arbeitsbereichen beschränkt werden können.
• Weisen Sie immer den Besitz von Produktionskatalogen und Schemas Gruppen zu, nicht einzelnen Benutzern.
• Gewähren Sie USE CATALOG und USE SCHEMA nur Benutzern, die die darin enthaltenen Daten anzeigen oder abfragen dürfen.

Weitere Informationen zum Gewähren von Berechtigungen für Kataloge und Schemas finden Sie unter "Berechtigungszuweisung".

Verwalteter Speicher

Verwaltete Tabellen und Volumes, Objekte, deren Lebenszyklus vollständig vom Unity-Katalog verwaltet wird, werden an Standardspeicherorten gespeichert, die als verwalteter Speicher bezeichnet werden. Sie können verwalteten Speicher auf Metastore-, Katalog- oder Schemaebene einrichten. Die Daten werden am niedrigsten verfügbaren Speicherort in der Hierarchie gespeichert. Ausführliche Informationen finden Sie unter "Hierarchie des verwalteten Speicherorts " und "Angeben eines verwalteten Speicherorts" im Unity-Katalog.

Bewährte Methoden für verwaltete Speicherorte:

• Bevorzugen Sie die Speicherung auf Katalogebene als primäre Datenisolation.

  Der Speicher auf Metastoreebene war in frühen Unity-Katalogumgebungen erforderlich, ist jedoch nicht mehr erforderlich.

• Wenn Sie einen verwalteten Speicherort auf Metastoreebene erstellen möchten, verwenden Sie einen dedizierten Container.

• Verwenden Sie keinen Container, auf den von außerhalb des Unity-Katalogs zugegriffen werden kann.

  Wenn ein externer Dienst oder Prinzipal direkt auf Daten am verwalteten Speicherort zugreift und dabei den Unity-Katalog umgeht, sind die Zugriffssteuerung und die Auditierbarkeit von verwalteten Tabellen und Volumes gefährdet.

• Verwenden Sie keinen Container, der für Ihr DBFS-Stammdateisystem verwendet wurde oder verwendet wurde.

• Wenn Sie über speicherintensive Workloads verfügen, verwenden Sie kein einzelnes Speicherkonto und keinen Container für verwalteten Speicher und andere externe Speicherorte.

  re:[ADLS]-Konten unterstützen standardmäßig 20.000 Anforderungen pro Sekunde. Dies kann zu einer Drosselung und Verlangsamung des Workloads führen. Die Verwendung mehrerer Container im selben Speicherkonto ändert dieses kontoweite Limit nicht. Sie sollten daher das Storage auf mehrere Storage-Kontos aufteilen.

  Solche Streifen wären für Unity-Katalog-Endbenutzer nicht sichtbar.

Verwaltete und externe Tabellen

Verwaltete Tabellen werden vollständig von Unity Catalog verwaltet. Das bedeutet, dass Unity Catalog sowohl die Governance als auch die zugrunde liegenden Datendateien für jede verwaltete Tabelle verwaltet. Sie befinden sich immer im Delta- oder Apache Iceberg-Format.

Externe Tabellen sind Tabellen, bei denen Unity Catalog den Zugriff über Azure Databricks verwaltet, aber für die Verwaltung des Datenlebenszyklus und des Dateilayouts Ihr Cloudanbieter und andere Datenplattformen verwendet werden. Wenn Sie eine externe Tabelle in Azure Databricks erstellen, geben Sie den Speicherort an, der sich auf einem Pfad befinden muss, der in einem externen Speicherort des Unity-Katalogs definiert ist.

Verwaltete Tabellen verwenden:

• Für die meisten Anwendungsfälle. Databricks empfiehlt verwaltete Tabellen und Volumes, da sie es Ihnen ermöglichen, die Funktionen und Leistungsoptimierungen des Unity-Katalogs vollständig zu nutzen, einschließlich:

  • Automatische Komprimierung
  • Automatische Optimierung
  • Schnelleres Lesen von Metadaten (Zwischenspeichern von Metadaten)
  • Intelligente Dateigrößenoptimierungen

  Neue Azure Databricks-Funktionen haben Vorrang vor verwalteten Tabellen.

• Für alle neuen Tabellen.

Externe Tabellen verwenden:

• Wenn Sie diese bereits verwenden und ein Upgrade vom Hive-Metastore auf den Unity-Katalog durchführen.

  • Die Verwendung externer Tabellen kann ein schnelles und nahtloses Upgrade mit nur einem Klick ermöglichen, ohne Daten zu verschieben.
  • Databricks empfiehlt, schließlich externe Tabellen zu verwalteten Tabellen zu migrieren.

• Wenn Sie über Anforderungen für die Notfallwiederherstellung für diese Daten verfügen, die von verwalteten Tabellen nicht erfüllt werden können.

  Verwaltete Tabellen können nicht in mehreren Metastores in derselben Cloud registriert werden.

• Wenn externe Leser oder Autoren in der Lage sein müssen, mit den Daten von außerhalb von Databricks zu interagieren.

  In der Regel sollten Sie den externen Zugriff auch auf die externen Tabellen vermeiden, die im Unity-Katalog registriert sind. Auf diese Weise umgehen Sie die Zugriffssteuerung, das Auditing und den Verlauf des Unity Catalogs. Es empfiehlt sich, verwaltete Tabellen zu verwenden und Daten über Regionen oder Cloudanbieter hinweg mithilfe der Delta-Freigabe freizugeben. Wenn Sie externen Zugriff auf externe Tabellen zulassen müssen, beschränken Sie sie auf Lesevorgänge, wobei alle Schreibvorgänge über Azure Databricks und Unity-Katalog erfolgen.

• Sie müssen Nicht-Delta- oder Nicht-Iceberg-Tabellen wie Parquet, Avro, ORC usw. unterstützen.

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. Siehe regionsübergreifendes und plattformübergreifendes Teilen.

Siehe auch Einführung in Azure Databricks-Tabellen.

Verwaltete und externe Speichervolumen

Verwaltete Volumes werden vollständig vom Unity-Katalog verwaltet, was bedeutet, dass Unity Catalog den Zugriff auf den Speicherort des Volumes in Ihrem Cloudanbieterkonto verwaltet. Externe Volumes stellen vorhandene Daten an Speicherorten dar, die außerhalb von Azure Databricks verwaltet werden, aber in Unity Catalog registriert sind, um den Zugriff innerhalb von Azure Databricks zu steuern und zu überwachen. Wenn Sie ein externes Volume in Azure Databricks erstellen, geben Sie dessen Speicherort an. Dieser muss sich an einem Pfad befinden, der an einem externen Speicherort von Unity Catalog definiert ist.

Verwaltete Volumes verwenden:

• Für die meisten Anwendungsfälle können Sie die Funktionalitäten der Governance von Unity Catalog voll ausschöpfen.
• Wenn Sie Tabellen auf Basis von Dateien in einem Volume erstellen möchten, ohne COPY INTO oder CTAS-Anweisungen (CREATE TABLE AS) auszuführen.

Verwenden Sie externe Volumes:

• Um Landebereiche für rohe Daten zu registrieren, die von externen Systemen erzeugt werden, um ihre Verarbeitung in den frühen Phasen von ETL-Pipelines und anderen Data Engineering-Aktivitäten zu unterstützen.
• Um Speicherorte für das Einbinden zu registrieren, zum Beispiel mit Auto Loader, COPY INTO oder CTAS-Anweisungen.
• 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.
• Um Azure Databricks Benutzern Zugriff auf beliebige Dateien zu gewähren, die von anderen Systemen erzeugt und in der Cloud gespeichert werden, z. B. große Sammlungen von unstrukturierten Daten (z. B. Bild-, Audio-, Video- und PDF-Dateien), die von Überwachungssystemen oder IoT-Geräten erfasst werden, oder Bibliotheksdateien (JARs und Python Raddateien), die aus lokalen Abhängigkeitsverwaltungssystemen oder CI/CD-Pipelines exportiert werden.
• Zum Speichern von Betriebsdaten, z. B. Protokollierungs- oder Prüfpunktdateien, wenn verwaltete Speicherplätze keine Option sind.

Weitere Empfehlungen für die Verwendung externer Volumes:

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

Tipp

Für das Einbinden von Daten an einen anderen Speicherort (z.B. mit Auto Loader oder COPY INTO) verwenden Sie externe Volumes. Verwenden Sie externe Tabellen, wenn Sie Daten direkt als Tabelle abfragen möchten, ohne dass eine Kopie erforderlich ist.

Siehe auch Verwaltete vs. externe Volumes und Externe Speicherorte.

Externe Speicherorte

Sicherungsobjekte für externe Speicherorte bieten durch die Kombination von Speicheranmeldeinformationen und Speicherpfaden eine starke Kontrolle und Auditierbarkeit des Speicherzugriffs. Es ist wichtig, zu verhindern, dass Benutzer direkt auf die container zugreifen, die als externe Standorte registriert sind, und die von Unity Catalog bereitgestellte Zugriffssteuerung umgehen.

So verwenden Sie externe Standorte effektiv:

• Stellen Sie sicher, dass Sie die Anzahl der Benutzer mit direktem Zugriff auf jeden Container beschränken, der als externer Speicherort verwendet wird.

• Stellen Sie keine Speicherkonten in DBFS bereit, 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.

• Gewähren Sie der Möglichkeit, externe Speicherorte nur für Administratoren zu erstellen, die mit dem Einrichten von Verbindungen zwischen Unity-Katalog und Cloudspeicher oder mit vertrauenswürdigen Datentechnikern beauftragt sind.

  Externe Speicherorte bieten von Unity Catalog aus Zugriff auf einen umfassenden Speicherort im Cloud Storage, z. B. einen ganzen Bucket oder Container (Bucket-Pfad) oder einen breiten Unterpfad (Bucket-Subpfad). 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.

• Gewähren Sie endbenutzern keine allgemeinen READ FILES oder WRITE FILES Berechtigungen für externe Speicherorte.

  Benutzer sollten keine externen Speicherorte verwenden, sondern Tabellen, Volumes oder verwaltete Speicherorte erstellen. Sie sollten keine externen Speicherorte für pfadbasierten Zugriff für Data Science oder andere nicht tabellarische Datenanwendungsfälle nutzen.

  Verwenden Sie Volumes, um pfadbasierten Zugriff auf nicht tabellarische Daten zu erhalten. Der Cloud-URI-Zugriff auf Daten unter dem Volumepfad unterliegt den auf dem Volume gewährten Berechtigungen, nicht den Berechtigungen, die für den externen Speicherort gewährt werden, an dem das Volume gespeichert ist.

  Mit Volumes können Sie mit Dateien mit SQL-Befehlen, dbutils, Spark-APIs, REST-APIs, Terraform und einer Benutzeroberfläche zum Durchsuchen, Hochladen und Herunterladen von Dateien arbeiten. 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.

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

  Wenn Sie externe Volumes oder Tabellen im Stammverzeichnis für externe Speicherorte erstellen, können Sie keine zusätzlichen externen Volumes oder Tabellen am externen Speicherort erstellen. Erstellen Sie stattdessen externe Volumes oder Tabellen in einem Unterverzeichnis innerhalb des externen Speicherorts.

Sie sollten externe Speicherorte nur verwenden, um Folgendes auszuführen:

• Registrieren externer Tabellen und Volumes mithilfe der Befehle CREATE EXTERNAL VOLUME oder CREATE TABLE.
• Registrieren Sie einen Speicherort als verwalteten Speicher. Die Berechtigung CREATE MANAGED STORAGE ist eine Voraussetzung.
• 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. Weisen Sie diese Berechtigung sparsam zu. Ausführliche Informationen finden Sie in der Empfehlung in der vorherigen Liste.

Externe Speicherorte im Vergleich zu externen Volumes

Bevor Volumes veröffentlicht wurden, wiesen einige Implementierungen von Unity Catalog READ FILES den Zugriff direkt auf externe Speicherorte für die Datenexploration zu. Mit der Verfügbarkeit von Volumes, die Dateien in einem beliebigen Format registrieren, einschließlich strukturierter, halbstrukturierter und unstrukturierter Daten, gibt es keinen echten Grund, externe Speicherorte für alles zu verwenden, sondern Tabellen, Volumes oder verwaltete Speicherorte zu erstellen. Ausführliche Informationen dazu, wann externe Speicherorte und wann Volumes verwendet werden sollen, finden Sie unter Verwaltete und externe Volumes und externe Speicherorte.

Regionsübergreifendes und plattformübergreifendes Teilen

Pro Region kann nur ein Metaspeicher vorhanden sein. Wenn Sie Daten zwischen Arbeitsbereichen in verschiedenen Regionen gemeinsam nutzen möchten, verwenden Sie Databricks-to-Databricks Delta Sharing.

Bewährte Methoden:

• Verwenden Sie Ihren Metaspeicher mit einer Region für alle Softwareentwicklungslebenszyklusbereiche und Geschäftseinheiten, z. B. Dev, Test, Prod, Sales und Marketing. Stellen Sie sicher, dass sich die Arbeitsbereiche, für die häufiger Zugriff auf freigegebene Daten erforderlich ist, in derselben Region befinden.
• Verwenden Sie Databricks-to-Databricks Delta Sharing zwischen Cloudregionen oder Cloudanbietern.
• Verwenden Sie Delta Sharing für Tabellen, auf die selten zugegriffen wird, da Sie für die Datenübertragungskosten von einer Cloudregion zur anderen verantwortlich sind. Wenn Sie häufig abgerufene Daten über Regionen oder Cloudanbieter hinweg freigeben müssen, lesen Sie: Überwachen und Verwalten der Delta-Sharing-Egress-Kosten (für Anbieter).

Beachten Sie die folgenden Einschränkungen, wenn Sie Databricks-to-Databricks Sharing verwenden:

• Liniendiagramme werden auf Metastore-Ebene erstellt und nicht über Region oder Plattformgrenzen hinweg. Dies gilt auch, wenn eine Ressource über Metastores innerhalb desselben Databricks-Kontos hinweg freigegeben wird: Linieninformationen aus der Quelle sind im Ziel nicht sichtbar und umgekehrt.
• Die Zugriffssteuerung wird auf Metastore-Ebene definiert und überschreitet keine Regions- oder Plattformgrenzen. Wenn einer Ressource Berechtigungen zugewiesen sind und diese Ressource einem anderen Metaspeicher im Konto freigegeben wird, gelten die Berechtigungen für diese Ressource nicht für die Zielfreigabe. Sie müssen Rechte auf der Zielfreigabe im Ziel gewähren.

Computekonfigurationen

Databricks empfiehlt die Verwendung von Computerrichtlinien, um die Möglichkeit zur Konfiguration von Clustern gemäß einer Reihe von Regeln zu beschränken. Mithilfe von Computerichtlinien können Sie Benutzer auf das Erstellen von Unity-Katalog-fähigen Clustern beschränken, insbesondere Cluster, die den Standardzugriffsmodus (vormals gemeinsam genutzter Zugriff) oder dedizierten Zugriffsmodus (früher einzelbenutzer- oder zugewiesener Zugriffsmodus) verwenden.

Nur Cluster, die einen dieser Zugriffsmodi verwenden, können im Unity-Katalog auf Daten zugreifen. Serverless-Compute und DBSQL-Compute unterstützen Unity Catalog.

Databricks empfiehlt den Standardzugriffsmodus für alle Workloads. Verwenden Sie den dedizierten Zugriffsmodus nur, wenn Ihre erforderliche Funktionalität nicht vom Standardzugriffsmodus unterstützt wird. Weitere Informationen finden Sie unter Zugriffsmodi.