Share via


Was ist das aktuelle Standardarbeitsverzeichnis?

In diesem Artikel wird beschrieben, wie das standardmäßige aktuelle Arbeitsverzeichnis (Current Working Directory, CWD) für die Ausführung von Notebooks und Datei funktioniert.

Hinweis

Verwenden Sie Databricks Runtime 14.0 oder höher und Standardarbeitsbereichskonfigurationen für ein konsistenteres (CWD-)Verhalten im gesamten Arbeitsbereich.

Es gibt zwei standardmäßige CWD-Verhaltensweisen für Code, der lokal in Notebooks und Dateien ausgeführt wird:

  1. CWD gibt das Verzeichnis zurück, das das auszuführende Notebook oder Skript enthält.
  2. CWD gibt ein Verzeichnis zurück, das das an den Treiber angefügte kurzlebige Speichervolume darstellt.

Dieses CWD-Verhalten wirkt sich auf den gesamten Code aus, einschließlich %sh- und Python- oder R-Code, der nicht Apache Spark verwendet. Das Verhalten wird durch die Codesprache, die Databricks Runtime-Version, den Arbeitsbereichspfad und die Administratorkonfiguration des Arbeitsbereichs bestimmt.

Bei Scala-Code ist das CWD der kurzlebige Speicher, der an den Treiber angefügt ist.

Für Code in allen anderen Sprachen gilt Folgendes:

  • In Databricks Runtime 14.0 und höher ist das CWD das Verzeichnis mit dem ausgeführten Notebook oder Skript. Dies gilt unabhängig davon, ob sich der Code in /Workspace/Repos befindet.
  • Für Notebooks in Databricks Runtime 13.3 LTS und früheren Versionen hängt das CWD davon ab, ob sich der Code in /Workspace/Repos befindet:
  • Bei Code, der in einem Pfad außerhalb von /Workspace/Repos ausgeführt wird, ist das CWD das kurzlebige Speichervolume, das an den Treiber angefügt ist.
  • Bei Code, der in einem Pfad in /Workspace/Repos ausgeführt wird, hängt das CWD von der Administratorkonfigurationseinstellung und der Cluster-DBR-Version ab:
    • Bei Arbeitsbereichen, bei denen enableWorkspaceFilesystem auf dbr8.4+ oder true festgelegt ist, ist das CWD in DBR-Version 8.4 und höher das Verzeichnis mit dem ausgeführten Notebook oder Skript. Bei DBR-Versionen unter 8.4 ist es das kurzlebige Speichervolume, das an den Treiber angefügt ist.
    • Bei Arbeitsbereichen, bei denen enableWorkspaceFilesystem auf dbr11.0+ festgelegt ist, ist das CWD in DBR-Version 11.0 und höher das Verzeichnis mit dem ausgeführten Notebook oder Skript. Bei DBR-Versionen unter 11.0 ist es das kurzlebige Speichervolume, das an den Treiber angefügt ist.
    • Bei Arbeitsbereichen, bei denen enableWorkspaceFilesystem auf false festgelegt ist, ist das CWD das kurzlebige Speichervolume, das an den Treiber angefügt ist.

Wie wirkt sich dies auf Workloads aus?

Die größten Auswirkungen auf Workloads haben mit der Dateipersistenz und dem Dateispeicherort zu tun:

  • In Databricks Runtime 13.3 LTS und niedriger speichern bei Code, der in einem Pfad außerhalb von /Workspace/Repos ausgeführt wird, viele Codeschnipsel Daten an einem Standardspeicherort in einem kurzlebigen Speichervolume, das dauerhaft gelöscht wird, wenn der Cluster beendet wird.
  • In Databricks Runtime 14.0 und höher erstellt das Standardverhalten für diese Vorgänge Arbeitsbereichsdateien, die zusammen mit dem ausgeführten Notebook gespeichert und bis zum expliziten Löschen beibehalten werden.

Hinweise zu Leistungsunterschieden und anderen Einschränkungen von Arbeitsbereichsdateien finden Sie unter Verwenden von Arbeitsbereichsdateien.

Wiederherstellen des Legacyverhaltens

Sie können das aktuelle Arbeitsverzeichnis für jedes Notebook mit der Python-Methode os.chdir() ändern. Wenn Sie sicherstellen möchten, dass jedes Notebook ein CWD in den an den Treiber angefügten kurzlebigen Speichervolumes verwendet, können Sie der ersten Zelle jedes Notebooks folgenden Befehl hinzufügen und ihn vor jedem anderen Code ausführen:

import os

os.chdir("/tmp")