Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Auf dieser Seite wird beschrieben, wie Sie den Zugriff auf den älteren Databricks Filesystem (DBFS)-Stamm und bereitstellungen in vorhandenen Azure Databricks-Arbeitsbereichen deaktivieren. Um dbFS-Stamm und Bereitstellungen auf Kontoebene für neue Arbeitsbereiche zu deaktivieren, verwenden Sie die Kontoeinstellung " Legacyfeatures deaktivieren ".
Nachdem Sie Ihre dateibasierten Workflows zu Unity-Katalogvolumes, externen Speicherorten oder Arbeitsbereichsdateien migriert haben, können Sie verhindern, dass Benutzer Daten in DBFS-Stamm- und DBFS-Bereitstellungen hochladen, ändern oder darauf zugreifen. Durch das Deaktivieren von DBFS-Root und Mounts wird Ihr Sicherheitsprofil verbessert, indem der Zugriff auf gemeinsam genutzten Speicher entfernt wird, der nicht von Unity Catalog gesteuert wird.
Was sind DBFS-Stamm- und Einhängepunkte?
DBFS ist ein verteiltes Dateisystem in Databricks-Arbeitsbereichen, auf die unter dem dbfs: URI-Schema zugegriffen werden kann und für die Interaktion mit cloudbasiertem Speicher verwendet wird. Das dbfs: URI-Schema wird verwendet, um auf mehrere Speicherbereiche in einem Arbeitsbereich zuzugreifen, darunter:
-
DBFS-Stamm: Der Bereich, auf den direkt unter dem Stamm des Dateisystems zugegriffen werden kann, z. B. beim Eingeben
dbfs:/. Alle Benutzer des Arbeitsbereichs können auf die unter dem DBFS-Stamm erstellten Inhalte zugreifen, mit Ausnahme der Inhalte, die unter einem der unten aufgeführten reservierten Präfixe stehen und jeweils speziellen Bedingungen unterliegen. Sehen Sie sich an, was ist der DBFS-Stamm?. -
DBFS-Bereitstellungen: Ein legacy-Ansatz zum Definieren des externen Cloudspeicherzugriffs, auf den zugegriffen werden kann
dbfs:/mnt/<mount_name>. Siehe Mount-Objektspeicher. -
Reservierte Azure Databricks-Präfixe: Das Präfix, das von Unity Catalog-Volumes verwendet wird, und andere Azure Databricks-Systempfade, wie
dbfs:/databricks-datasets/z. B. MLflow-Objektpfade. Beispiel:dbfs:/Volumes/.
Alle Pfade sind auch über Pfade im POSIX-Stil zugänglich. Siehe "Muss ich ein URI-Schema für den Zugriff auf Daten bereitstellen?".
Weitere Informationen zu DBFS, einschließlich DBFS-Stammverzeichnis und Einhängepunkten, finden Sie unter Was ist DBFS?
Was wird deaktiviert?
Nachdem Sie DBFS Root und Mounts deaktiviert haben:
- Der gesamte Zugriff auf DBFS-Stamm- und Bereitstellungselemente in vorhandenen Arbeitsbereichen ist deaktiviert und über alle Schnittstellen hinweg blockiert (UI, APIs, CLI, FUSE).
- Versuche, Dateien aus dem DBFS-Root und den Mounts zu lesen oder zu schreiben, schlagen mit einer Fehlermeldung fehl. Die Fehlermeldung "Public DBFS root" ist beispielsweise deaktiviert.
- Der DBFS-Browser und die Option " In DBFS hochladen " können nicht mehr über die Benutzeroberfläche zugegriffen werden. Jobs, Notebooks oder Skripte, die auf DBFS Root und Mounts verweisen, schlagen fehl, es sei denn, die Einstellung wird rückgängig gemacht.
- Auf die DBFS-Option kann nicht mehr über allgemeine Features zugegriffen werden, z. B.:
- Clusterbibliotheken
- Übermittlung des Clusterprotokolls
- MLflow-Nachverfolgungs-/Modellregistrierung (Nicht-UC)
- AutoML-Experimente
- Lakeflow Spark Declarative Pipelines
- Das Einbetten statischer Notizbuchdateien mit
/filesschlägt mit einem 500-Fehler fehl. Siehe Einbetten statischer Bilder in Notizbüchern. - Einbindungs-/Ausbündvorgänge werden blockiert.
- FileStore-Vorgänge werden blockiert.
- Wenn Sie den DBFS-Stamm und die Mounts in Ihrem Arbeitsbereich deaktivieren, werden auch Databricks-Runtime-Versionen unter 13.3 LTS deaktiviert.
Note
In DBFS-deaktivierten Arbeitsbereichen bietet der dbfs:/Workspace Pfad Zugriff auf Dateien im Arbeitsbereichsdateisystem. Dies erfordert Databricks Runtime 13.3 LTS oder höher.
Was ist nicht betroffen?
Das dbfs: URI-Schema ist weiterhin ein zentraler Bestandteil von Azure Databricks, und das Deaktivieren von DBFS-Root und DBFS-Mounts deaktiviert den dbfs: URI selbst nicht. Folgendes funktioniert weiterhin wie erwartet:
-
Unity-Katalogvolumes: Volumes bleiben über das
dbfs:/VolumesPräfix und den POSIX-Stilpfad/Volumesverfügbar. Weitere Informationen finden Sie unter "Muss ich ein URI-Schema für den Zugriff auf Daten bereitstellen?" und was sind Unity-Katalogvolumes? Siehe Herstellen einer Verbindung mit einem externen DBFS-Stammspeicherort (Legacy). -
Systempfade: Schreibgeschützte Daten bleiben unter Verwendung
dbfs:/databricks-datasets/und anderen Azure Databricks-Systempfaden verfügbar, z. B. den MLflow-Ressourcenpfaden. - Interne Arbeitsbereichssystemdaten: Dazu gehören Inhalte, die automatisch von Azure Databricks generiert werden, z. B. Notizbuchrevisionen, Auftragsausführungsdetails, Befehlsergebnisse und Spark-Protokolle. Siehe Arbeitsbereichsspeicher.
Note
Vorhandene Daten unter dem DBFS-Root und den Mounts werden nicht gelöscht. Wenn DBFS-Stamm und -Bereitstellungen mithilfe der Einstellung " DBFS-Stamm und Bereitstellungen auf Arbeitsbereichsebene deaktivieren" erneut aktiviert sind, werden die Daten erneut zugänglich.
Hier sind einige Beispiele für Pfade, die weiterhin zugänglich sind und von der Deaktivierung von DBFS Root und Mounts nicht betroffen sind:
| Category | Path | Description |
|---|---|---|
| Unity-Katalogvolumes | dbfs:/Volumes/<catalog>/<schema>/<volume>/<path>/<file_name> |
Für UC-Volumes reserviert und nur über UC-spezifische APIs zugänglich und unterliegen UC-Governanceregeln. Weitere Informationen finden Sie unter "Pfad für den Zugriff auf Dateien in einem Volume". |
| Systempfad | dbfs:/databricks/mlflow-registry dbfs:/databricks/mlflow-tracking |
Schreibgeschützte Pfade, die auf Inhalte verweisen, die von den internen APIs von Azure Databricks in Workspace-Systemdaten geschrieben wurden. |
| Systempfad | dbfs:/databricks-datasets/ |
Eine schreibgeschützte Collection von Datasets, die standardmäßig in Azure Databricks Arbeitsbereichen gemountet werden. Siehe Durchsuchen von DBFS-eingehängten Databricks-Datasets. |
Das dbfs: Präfix (URI-Schema) ist optional und kann in den meisten Fällen weggelassen werden. Siehe "Muss ich ein URI-Schema für den Zugriff auf Daten bereitstellen?".
Wann können Sie den DBFS-Stamm und die Einbindungen deaktivieren?
Sie können DBFS jederzeit deaktivieren. Wenn vorhandene Workflows jedoch weiterhin davon abhängen, können sie zusammenbrechen. Databricks empfiehlt, den DBFS-Stamm und die Mounts in nicht-kritischen Umgebungen erst nach Folgendem zu deaktivieren.
- Sie haben alle Workflows, die auf DBFS Root oder Mounts angewiesen sind, auf Unity Catalog Volumes, externe Speicherorte oder Arbeitsbereich-Dateien migriert.
- Sie haben alle Aufträge und Cluster auf Databricks Runtime 13.3 LTS oder höher aktualisiert.
Note
Bevor Sie fortfahren, können Sie die Observability-Skripts verwenden, um nach der verbleibenden DBFS-Stamm- und Bereitstellungsverwendung zu suchen.
Deaktivieren des DBFS-Stammverzeichnisses und der Einbindungen
Sie können DBFS Root und Mounts sowohl in bestehenden als auch in neuen Arbeitsbereichen deaktivieren.
Als Arbeitsbereichsadministrator führen Sie die folgenden Schritte aus, um das DBFS-Stammverzeichnis und die Einhängepunkte zu deaktivieren:
Melden Sie sich bei Ihrem Azure Databricks-Arbeitsbereich an.
Klicken Sie in der oberen rechten Ecke auf das Benutzerprofilsymbol, und wählen Sie "Einstellungen" aus.
Navigieren Sie zum Arbeitsbereichsadministrator, und klicken Sie auf "Sicherheit".
Setze Disable DBFS root and mounts auf Deaktiviert: DBFS root und Mounts können nicht verwendet werden.
Warten Sie bis zu 20 Minuten, bis die Einstellung wirksam wird.
Starten Sie alle ausgeführten Cluster neu.
- Verteilungsverzögerung: Es kann bis zu 20 Minuten dauern, bis die DBFS-Stamm- und Bereitstellungsdeaktivierung vollständig verteilt wird.
- Clusterneustart: Alle ausgeführten Compute- und SQL-Lagerhäuser müssen MANUELL neu gestartet werden, dies muss nach der 20-minütigen Verteilungszeit erfolgen, damit die Änderungen wirksam werden. Wenn sie nicht neu gestartet werden, können solche Cluster weiterhin auf DBFS Root und Mounts zugreifen.
Siehe Notizbuchbeispiel: Finden Sie lang laufende Berechnungen für ein Beispiel, um lang laufende Allzweckberechnungen zu identifizieren und neu zu starten.