Bewährte Methoden für DBFS und Unity Catalog

Unity Catalog führt eine Reihe von neuen Konfigurationen und Konzepten ein, die einen völlig anderen Ansatz für die Datenverwaltung verfolgen als DBFS. Dieser Artikel beschreibt mehrere bewährte Methoden für die Arbeit mit externen Unity Catalog-Speicherorten und DBFS.

Databricks rät für die meisten Anwendungsfälle in Unity Catalog-fähigen Databricks-Arbeitsbereichen davon ab, DBFS und eingebundenen Cloudobjektspeicher zu verwenden. Dieser Artikel beschreibt einige Szenarien, in denen Sie eingebundenen Cloudobjektspeicher verwenden sollten. Beachten Sie, dass Databricks die Verwendung des DBFS-Stamms in Verbindung mit Unity Catalog nicht empfiehlt, es sei denn, Sie müssen dort gespeicherte Dateien oder Daten in Unity Catalog migrieren.

Wie wird DBFS in Unity Catalog-fähigen Arbeitsbereichen verwendet?

Aktionen, die für Tabellen in hive_metastore ausgeführt werden, verwenden Legacy-Datenzugriffsmuster, die von DBFS verwaltete Daten und Speicheranmeldeinformationen enthalten können. Verwaltete Tabellen im Arbeitsbereichsumfang hive_metastore werden im DBFS-Stamm gespeichert.

Wie funktioniert DBFS im Zugriffsmodus für Einzelbenutzer?

Cluster, die mit dem Zugriffsmodus für Einzelbenutzer konfiguriert sind, verfügen über vollständigen Zugriff auf DBFS, einschließlich aller Dateien im DBFS-Stamm und eingebundener Daten.

Wie funktioniert DBFS im freigegebenen Zugriffsmodus?

Der freigegebene Zugriffsmodus kombiniert die Unity Catalog-Datengovernance mit Legacytabellen-ACLs von Azure Databricks. Zugriff auf Daten in hive_metastore ist nur für Benutzer verfügbar, denen explizit Berechtigungen erteilt wurden.

Um mit Dateien direkt mit DBFS zu interagieren, müssen Sie über ANY FILE-Berechtigungen verfügen. Da ANY FILE es Benutzern ermöglicht, die ACLs für Legacytabellen in hive_metastore zu umgehen und auf alle von DBFS verwalteten Daten zuzugreifen, empfiehlt Databricks, bei der Gewährung dieses Rechtes vorsichtig zu sein.

DBFS nicht mit externen Unity Catalog-Speicherorten verwenden

Unity Catalog sichert den Zugriff auf Daten an externen Speicherorten durch die Verwendung vollständiger Cloud-URI-Pfade zur Identifizierung von Berechtigungen für verwaltete Objektspeicherverzeichnisse. DBFS-Einbindungen verwenden ein völlig anderes Datenzugriffsmodell, das Unity Catalog vollständig umgeht. Databricks empfiehlt, Cloudobjektspeichervolumes zwischen DBFS-Bereitstellungen und UC-externen Volumes nicht wiederzuverwenden, einschließlich der Freigabe von Daten über Arbeitsbereiche oder Konten hinweg.

Sichern des verwalteten Unity Catalog-Speichers

Unity Catalog mit verwalteten Speicherorten zum Speichern von Datendateien für verwaltete Tabellen und Volumes.

Databricks empfiehlt Folgendes für verwaltete Speicherorte:

• Verwenden Sie neue Speicherkonten oder Buckets.
• Definieren Sie eine benutzerdefinierte Identitätsrichtlinie für Unity Catalog.
• Beschränken Sie den gesamten Zugriff auf Azure Databricks, die vom Unity Catalog verwaltet werden.
• Beschränken Sie den gesamten Zugriff auf Identitätszugriffsrichtlinien, die für Unity Catalog erstellt wurden.

Hinzufügen vorhandener Daten zu externen Speicherorten

Es ist möglich, vorhandene Speicherkonten über externe Speicherorte in Unity Catalog zu laden. Aus Sicherheitsgründen empfiehlt Databricks, Speicherkonten nur dann in externe Speicherorte zu laden, wenn alle anderen Speicheranmeldeinformationen und Zugriffsmuster widerrufen wurden.

Laden Sie niemals ein Speicherkonto, das als DBFS-Stamm verwendet wird, als externen Speicherort in Unity Catalog.

Unity Catalog-Dateisystemzugriff ignoriert Clusterkonfigurationen

Unity Catalog beachtet keine Clusterkonfigurationen für Dateisystemeinstellungen. Das bedeutet, dass die Hadoop-Dateisystemeinstellungen für die Konfiguration des benutzerdefinierten Verhaltens mit Cloudobjektspeicher beim Zugriff auf Daten mit Unity Catalog nicht funktionieren.

Einschränkung für den Zugriff auf mehrere Pfade

Sie können zwar im Allgemeinen Unity Catalog und DBFS gemeinsam verwenden, aber Pfade, die gleich sind oder eine Über-/Unterordnungsbeziehung haben, können nicht im selben Befehl oder derselben Notebookzelle mit unterschiedlichen Zugriffsmethoden referenziert werden.

Wenn beispielsweise die externe Tabelle foo in hive_metastore an der Position a/b/c definiert ist und eine externe Position in Unity Catalog an a/b/ definiert ist, würde der folgende Code einen Fehler auslösen:

spark.read.table("foo").filter("id IS NOT NULL").write.mode("overwrite").save("a/b/c")

Dieser Fehler würde nicht auftreten, wenn diese Logik in zwei Zellen unterteilt wird:

df = spark.read.table("foo").filter("id IS NOT NULL")

df.write.mode("overwrite").save("a/b/c")