Wat is er gebeurd met Databricks-opslagplaatsen?

Azure Databricks heeft nieuwe elementen van de gebruikersinterface geïmplementeerd waarmee gebruikers rechtstreeks kunnen werken met door Git-opslagplaats ondersteunde mappen uit de gebruikersinterface van de werkruimte, waardoor de vorige, afzonderlijke functiefunctionaliteit voor opslagplaatsen effectief wordt vervangen.

Wat betekent deze wijziging voor mij?

Als u een gebruiker bent van de functie Databricks-opslagplaatsen voor co-versiebeheer van op Git gebaseerde broncodebeheer van projectassets, is de kernfunctionaliteit niet gewijzigd. Het meest opvallende verschil is dat veel contextuele UI-bewerkingen nu verwijzen naar 'Git-mappen' in plaats van 'Opslagplaatsen'.

Een Databricks-map die wordt ondersteund door een Git-opslagplaats, kan bijvoorbeeld worden gemaakt door Nieuw en vervolgens Opslagplaats te selecteren in de gebruikersinterface:

Nu selecteert u Nieuw en kiest u Git-map. Zelfde ding, andere naam!

Deze wijziging biedt enkele verbeteringen die het werken met mappen met versiebeheer vereenvoudigen:

1. Betere organisatie van mappen: Git-mappen kunnen worden gemaakt op elk niveau van de structuur van het werkruimtebestand, zodat u uw Git-mappen kunt ordenen op een manier die het beste werkt voor uw project. U kunt bijvoorbeeld Git-mappen maken op /Workspace/Users/<user email>/level_1/level_2/level_3/<Git folder name>. Opslagplaatsen kunnen alleen worden gemaakt op een vast mapniveau, zoals de hoofdmap van de gebruikersmap Opslagplaatsen, zoals /Workspace/Repos/<user email>/<Repo name>.
   • Opmerking: Git-mappen kunnen op dit punt andere assets bevatten of die momenteel niet worden ondersteund door opslagplaatsen. Niet-ondersteunde assettypen, zoals DBSQL-assets en MLflow-experimenten, kunnen worden verplaatst naar Git-mappen. Serialisatieondersteuning voor extra assets wordt in de loop van de tijd toegevoegd.
2. Vereenvoudigd gedrag van de gebruikersinterface: deze wijziging brengt een algemene interactie tussen werkruimten en werkt rechtstreeks met Git in uw Databricks-werkruimte en vermindert de tijd die u besteedt aan het navigeren tussen uw werkruimte en uw door versie beheerde Git-mappen.

Wat is er veranderd, met name?

1. Git-mappen kunnen buiten de /Repos map worden gemaakt.
2. Git-mappen worden gemaakt door nieuwe>Git-map te selecteren in een Databricks-werkruimte. Hiermee maakt u een nieuwe Git-map onder /Workspace/Users/<user-email>/.
3. Git-mappen kunnen op verschillende diepten van de structuur van het werkruimtebestand worden gemaakt zolang ze zich onder /Workspace/Users/<user-email>bevinden. U kunt bijvoorbeeld Git-mappen maken op /Workspace/Users/<user-email>/level_1/level_2/level_3/<git-folder-name>. U kunt meerdere Git-mappen hebben onder /Workspace/Users/<user-email>.
4. Niet-ondersteunde assets zijn toegestaan in Git-mappen. Serialisatieondersteuning voor andere assettypen wordt in de loop van de tijd toegevoegd.
5. In tegenstelling tot opslagplaatsen kunt u geen nieuwe Git-map maken in Databricks zonder een URL voor een externe opslagplaats.

Aanvullende details

Bestaande opslagplaatsen die gebruikers hebben gemaakt, gaan niet weg. Gebruikers hoeven bestaande opslagplaatsen niet te migreren naar Git-mappen. Opslagplaatsen zijn geïntegreerd in de gebruikersinterface van de werkruimte en zijn niet langer een afzonderlijke ervaring op het hoogste niveau in de gebruikersinterface.

• Bestaande /Repos verwijzingen blijven werken: jobsen dbutils.notebook.run%run verwijzingen die gebruikmaken van notebooks die zich onder /Repos paden bevinden, blijven werken.
• De bestaande /Repos map wordt geconverteerd naar een normale map onder /Workspace als /Workspace/Repos, en eventuele speciale verwerking kan worden verwijderd. In zeldzame gevallen moet u mogelijk een aantal wijzigingen aanbrengen in uw werkruimte om deze omleiding te laten werken. Zie Verwijzingen naar werkruimteobjecten voor meer informatie.

Databricks raadt gebruikers aan om nieuwe Git-mappen te maken in plaats van opslagplaatsen als ze vanuit de Databricks-werkruimte verbinding moeten maken met Git-broncodebeheer. Door Git-opslagplaatsen en andere werkruimteassets te verplaatsen, kunnen Git-mappen beter worden gedetecteerd en eenvoudiger worden beheerd dan opslagplaatsen.

Git-mapmachtigingen Git-mappen hebben dezelfde machtigingen voor werkruimtemappen als andere werkruimtemappen. Gebruikers moeten over de machtiging beschikken om de CAN_MANAGE meeste Git-bewerkingen uit te voeren.

Welke DBR I moet gebruiken voor het uitvoeren van code in Git-mappen?

Voor consistente uitvoering van code tussen Git-mappen en verouderde opslagplaatsen raadt Databricks gebruikers aan alleen code uit te voeren in Git-mappen met DBR 15+.

Huidig gedrag van werkmap (CWD)

Databricks Runtime (DBR) versie 14 of hoger maakt het gebruik van relatieve paden mogelijk en biedt dezelfde huidige werkmapervaring (CWD) voor alle notebooks, waar u het notebook uitvoert vanuit de huidige werkmap. Het gedrag van huidige werkmap (CWD) kan inconsistent zijn tussen notebooks in een Git-map en een niet-Git-map voor oudere versies van de Databricks Runtime (DBR).

Gedrag van Python sys.path

Databricks Runtime (DBR) versie 14.3 of hoger biedt hetzelfde sys.path gedrag in Git-mappen als in verouderde opslagplaatsen. Met eerdere DBR-versies verschilt het gedrag van Git-mappen van oudere opslagplaatsen omdat de map met de hoofdopslagplaats niet automatisch wordt toegevoegd aan sys.path Git-mappen. Voor Python sys.path bevat een lijst met mappen die de interpreter doorzoekt bij het importeren van modules. Als u DBR 15 of hoger niet kunt gebruiken, kunt u handmatig een mappad toevoegen als sys.path tijdelijke oplossing.

Zie Python- en R-modules importeren voor voorbeelden van het toevoegen van mappen aan sys.path het gebruik van relatieve paden.

Prioriteit van Python-bibliotheek

Databricks Runtime (DBR) versie 14.3 of hoger biedt dezelfde prioriteit voor de Python-bibliotheek in Git-mappen als in verouderde opslagplaatsen.