Wat is de standaard huidige werkmap?
In dit artikel wordt beschreven hoe de standaard huidige werkmap (CWD) werkt voor notebook- en bestandsuitvoering.
Notitie
Gebruik Databricks Runtime 14.0+ en standaardwerkruimteconfiguraties voor meer consistentie in (CWD)-gedrag in de hele werkruimte.
Er zijn twee standaard-CWD-gedrag voor code die lokaal wordt uitgevoerd in notebooks en bestanden:
- CWD retourneert de map met het notebook of script dat wordt uitgevoerd.
- CWD retourneert een map die het tijdelijke opslagvolume vertegenwoordigt dat aan het stuurprogramma is gekoppeld.
Dit CWD-gedrag is van invloed op alle code, inclusief %sh
En Python- of R-code die geen apache Spark gebruikt. Het gedrag wordt bepaald door de codetaal, de Databricks Runtime-versie, het werkruimtepad en de configuratie van de werkruimtebeheerder.
Voor Scala-code is de CWD de tijdelijke opslag die is gekoppeld aan het stuurprogramma.
Voor code in alle andere talen:
- In Databricks Runtime 14.0 en hoger is de CWD de map met het notebook of script dat wordt uitgevoerd. Dit geldt ongeacht of de code zich in
/Workspace/Repos
bevindt. - Voor notebooks met Databricks Runtime 13.3 LTS en hieronder is de CWD afhankelijk van of de code zich in
/Workspace/Repos
: - Voor code die buiten een pad wordt
/Workspace/Repos
uitgevoerd, is de CWD het tijdelijke opslagvolume dat aan het stuurprogramma is gekoppeld - Voor code die wordt uitgevoerd in een pad in
/Workspace/Repos
, is de CWD afhankelijk van de configuratie-instelling van uw beheerder en de DBR-versie van het cluster:- Voor werkruimten die zijn
enableWorkspaceFilesystem
ingesteld opdbr8.4+
oftrue
, op DBR-versies 8.4 en hoger, is de CWD de map die het notebook of script bevat dat wordt uitgevoerd. Op DBR-versies lager dan 8.4 is het tijdelijke opslagvolume gekoppeld aan het stuurprogramma - Voor werkruimten die zijn
enableWorkspaceFilesystem
ingesteld opdbr11.0+
, op DBR-versies 11.0 en hoger, is de CWD de map die het notebook of script bevat dat wordt uitgevoerd. In DBR-versies lager dan 11.0 is het tijdelijke opslagvolume gekoppeld aan het stuurprogramma - Voor werkruimten die zijn
enableWorkspaceFilesystem
ingesteld opfalse
, is de CWD het tijdelijke opslagvolume dat is gekoppeld aan het stuurprogramma
- Voor werkruimten die zijn
Haal de CWD op in uw code
Als u de werkruimte-CWD voor uw pijplijnnotitieblok wilt ophalen, roept u het aan os.getcwd()
. U moet de os
module (de standaardmodule voor de interactie van het Python-bestandssysteem) aan het begin van uw notebook importeren met import os
. Voorbeeld:
import os
...
cwd = os.getcwd()
U kunt de CWD ook instellen door aan te roepen os.chdir('/path/to/dir')
aan het begin van uw pijplijnnotebook. U kunt de CWD alleen instellen wanneer u een notebook uitvoert vanuit uw werkruimte waarvoor WSFS is ingeschakeld.
Wat is dit van invloed op workloads?
De grootste gevolgen voor workloads hebben te maken met bestands persistentie en locatie:
- In Databricks Runtime 13.3 LTS en hieronder worden voor code die wordt uitgevoerd in een pad buiten
/Workspace/Repos
een pad, gegevens opgeslagen op een standaardlocatie op een tijdelijke opslagvolume dat permanent wordt verwijderd wanneer het cluster wordt beëindigd. - In Databricks Runtime 14.0 en hoger worden met het standaardgedrag voor deze bewerkingen werkruimtebestanden gemaakt die zijn opgeslagen naast het actieve notebook dat wordt bewaard totdat deze expliciet is verwijderd.
Zie Werken met werkruimtebestanden voor opmerkingen over prestatieverschillen en andere beperkingen die inherent zijn aan werkruimtebestanden.
Terugkeren naar verouderd gedrag
U kunt de huidige werkmap voor elk notebook wijzigen met behulp van de Python-methode os.chdir()
. Als u ervoor wilt zorgen dat elk notebook gebruikmaakt van een CWD op de tijdelijke opslagvolumes die aan het stuurprogramma zijn gekoppeld, kunt u de volgende opdracht toevoegen aan de eerste cel van elke notebook en deze uitvoeren vóór elke andere code:
import os
os.chdir("/tmp")