Dela via

Begränsningar och vanliga frågor och svar om Git-integrering med Databricks Git-mappar

  • Artikel

Databricks Git-mappar och Git-integrering har gränser som anges i följande avsnitt. Allmän information finns i Databricks-gränser.

Hoppa till:

Fil- och lagringsplatsens gränser

Azure Databricks tillämpar ingen gräns för storleken på en lagringsplats. Observera följande:

  • Arbetsgrenar är begränsade till 1 GIGABYTE (GB).
  • Filer som är större än 10 MB kan inte visas i Azure Databricks-användargränssnittet.
  • Enskilda arbetsytefiler omfattas av en separat storleksgräns. Mer information finns i Begränsningar.

Databricks rekommenderar att du gör det på en lagringsplats:

  • Det totala antalet arbetsytetillgångar och filer får inte överstiga 20 000.

För alla Git-åtgärder är minnesanvändningen begränsad till 2 GB och diskskrivningar är begränsade till 4 GB. Eftersom gränsen är per åtgärd får du ett fel om du försöker klona en Git-lagringsplats som är 5 GB i aktuell storlek. Men om du klonar en Git-lagringsplats som är 3 GB i storlek i en åtgärd och sedan lägger till 2 GB till den senare, kommer nästa pull-åtgärd att lyckas.

Du kan få ett felmeddelande om lagringsplatsen överskrider dessa gränser. Du kan också få ett timeout-fel när du klonar lagringsplatsen, men åtgärden kan slutföras i bakgrunden.

Om du vill arbeta med lagringsplatser som är större än storleksgränserna kan du prova att checka ut sparsamt.

Om du måste skriva temporära filer som du inte vill behålla när klustret har stängts av skriver du de temporära filerna för att undvika att $TEMPDIR överskrida gränserna för grenstorlek och ger bättre prestanda än att skriva till den aktuella arbetskatalogen (CWD) om CWD finns i arbetsytans filsystem. Mer information finns i Var ska jag skriva temporära filer på Azure Databricks?.

Maximalt antal Git-mappar per arbetsyta

Du kan ha högst 2 000 Git-mappar per arbetsyta. Kontakta Databricks-supporten om du behöver mer.

Återställa filer som tagits bort från Git-mappar på din arbetsyta

Åtgärder för arbetsytor på Git-mappar varierar i filåterställbarhet. Vissa åtgärder tillåter återställning via papperskorgen medan andra inte gör det. Filer som tidigare checkats in och push-överförts till en fjärrgren kan återställas med hjälp av Git-incheckningshistoriken för git-fjärrlagringsplatsen. Den här tabellen beskriver varje åtgärds beteende och återställningsbarhet:

Åtgärd Går det att återställa filen?
Ta bort fil med arbetsytans webbläsare Ja, från papperskorgen
Ignorera en ny fil med dialogrutan Git-mapp Ja, från papperskorgen
Ignorera en ändrad fil med dialogrutan Git-mapp Nej, filen är borta
reset (hårt) för icke-begärda filändringar Nej, filändringarna är borta
reset (hårt) för ogenomförda, nyligen skapade filer Nej, filändringarna är borta
Växla grenar med dialogrutan Git-mapp Ja, från en fjärransluten Git-lagringsplats
Andra Git-åtgärder (incheckning och push-överföring osv.) från dialogrutan Git-mapp Ja, från en fjärransluten Git-lagringsplats
PATCH åtgärder som uppdaterar /repos/id från Repos API Ja, från en fjärransluten Git-lagringsplats

Stöd för monorepo

Databricks rekommenderar att du inte skapar Git-mappar som backas upp av monorepos, där en monorepo- är en stor Git-lagringsplats med en enda organisation med tusentals filer i många projekt.

Tillgångstyper som stöds i Git-mappar

Endast vissa Azure Databricks-tillgångstyper stöds av Git-mappar. En tillgångstyp som stöds kan serialiseras, versionskontrolleras och push-överföras till git-lagringsplatsen som stöds.

För närvarande är de tillgångstyper som stöds:

Tillgångstyp Details
Arkiv Filer är serialiserade data och kan innehålla allt från bibliotek till binärfiler till kod till bilder. Mer information finns i Vad är arbetsytefiler?
Notebook-fil Notebook-filer är specifikt de filformat för notebook-filer som stöds av Databricks. Notebook-filer anses vara en separat Azure Databricks-tillgångstyp från filer eftersom de inte serialiseras. Git-mappar avgör en notebook-fil med filnamnstillägget (till exempel .ipynb) eller filnamnstillägg som kombineras med en särskild markör i filinnehåll (till exempel en # Databricks notebook source kommentar i början av .py källfilerna).
Mapp En mapp är en Azure Databricks-specifik struktur som representerar serialiserad information om en logisk gruppering av filer i Git. Som förväntat upplever användaren detta som en "mapp" när de visar en Azure Databricks Git-mapp eller kommer åt den med Azure Databricks CLI.
Query (offentlig förhandsversion) Databricks SQL-frågor (DBSQL) kan sparas som IPYNB-notebookar (tillägg: .dbquery.ipynb). Git-stöd för DBSQL-frågor kräver att du aktiverar nya SQL-redigeraren. Frågeställningar som skapats med den nya SQL-redigerarfunktionen inaktiverad kan placeras i en Git-mapp men kan inte läggas till i fjärrlagringsplatsen.

Azure Databricks-tillgångstyper som för närvarande inte stöds i Git-mappar innehåller följande:

  • Aviseringar
  • Instrumentpaneler (inklusive äldre instrumentpaneler)
  • Experiment
  • Genie-blanksteg

Observera följande begränsningar i filnamngivning när du arbetar med dina tillgångar i Git:

  • En mapp får inte innehålla en notebook-fil med samma namn som en annan notebook-fil, fil eller mapp på samma Git-lagringsplats, även om filtillägget skiljer sig åt. (För notebook-filer i källformat gäller .py tillägget python, .scala Scala, .sql SQL och .r R. För NOTEBOOK-filer i IPYNB-format är .ipynbtillägget .) Du kan till exempel inte använda en notebook-fil i källformat med namnet test1.py och en IPYNB-anteckningsbok med namnet test1 i samma Git-mapp eftersom python-notebook-filen (test1.py) i källformat kommer att serialiseras som test1 och en konflikt uppstår.
  • Tecknet / stöds inte i filnamn. Du kan till exempel inte ha en fil med namnet i/o.py i din Git-mapp.

Om du försöker utföra Git-åtgärder på filer med namn som har dessa mönster visas meddelandet "Fel vid hämtning av Git-status". Om du får det här felet oväntat granskar du filnamnen för tillgångarna på git-lagringsplatsen. Om du hittar filer med namn som har dessa motstridiga mönster byter du namn på dem och försöker igen.

Kommentar

Du kan flytta befintliga tillgångar som inte stöds till en Git-mapp, men du kan inte checka in några ändringar som gjorts på fjärrlagringsplatsen.

Notebook-format

Mer information om notebook-format för Git-mappar finns i Notebook-format.

Vanliga frågor och svar: Konfiguration av Git-mapp

Var lagras Azure Databricks-lagringsplatsens innehåll?

Innehållet i en lagringsplats klonas tillfälligt på disken i kontrollplanet. Azure Databricks Notebook-filer lagras i kontrollplansdatabasen precis som notebook-filer på huvudarbetsytan. Filer som inte är notebook-filer lagras på disken i upp till 30 dagar.

Stöder Git-mappar lokala eller lokalt installerade Git-servrar?

Databricks Git-mappar stöder GitHub Enterprise, Bitbucket Server, Azure DevOps Server och Självhanterad GitLab-integrering om servern är tillgänglig via Internet. Mer information om hur du integrerar Git-mappar med en lokal Git-server finns i Git Proxy Server för Git-mappar.

Om du vill integrera med en Bitbucket Server, GitHub Enterprise Server eller en självhanterad GitLab-prenumerationsinstans som inte är internettillgänglig kan du kontakta ditt Azure Databricks-kontoteam.

Vilka Databricks-tillgångstyper stöds av Git-mappar?

Mer information om tillgångstyper som stöds finns i Tillgångstyper som stöds i Git-mappar.

Stöder Git-mappar .gitignore filer?

Ja. Om du lägger till en fil på lagringsplatsen och inte vill att den ska spåras av Git skapar du en fil eller använder en .gitignore klonad från fjärrlagringsplatsen och lägger till filnamnet, inklusive tillägget.

.gitignore fungerar bara för filer som inte redan spåras av Git. Om du lägger till en fil som redan spåras av Git i en .gitignore fil spåras filen fortfarande av Git.

Kan jag skapa mappar på den översta nivån som inte är användarmappar?

Ja, administratörer kan skapa mappar på den översta nivån till ett enda djup. Git-mappar stöder inte ytterligare mappnivåer.

Stöder Git-mappar Git-undermoduler?

Nej. Du kan klona en lagringsplats som innehåller Git-undermoduler, men undermodulen klonas inte.

Har Azure Data Factory (ADF) stöd för Git-mappar?

Ja.

Källhantering

Varför försvinner instrumentpaneler för notebook-filer när jag hämtar eller checkar ut en annan gren?

Detta är för närvarande en begränsning eftersom Azure Databricks notebook-källfiler inte lagrar information om instrumentpanelen för notebook-filer.

Om du vill bevara instrumentpaneler i Git-lagringsplatsen ändrar du notebook-formatet till .ipynb (Jupyter Notebook-format). Som standard .ipynb stöder instrumentpanels- och visualiseringsdefinitioner. Om du vill bevara grafdata (datapunkter) måste du checka in anteckningsboken med utdata.

Mer information om hur .ipynb du checkar in notebook-utdata finns i Tillåt incheckning av .ipynb notebook-utdata.

Stöder Git-mappar sammanslagning av grenar?

Ja. Du kan också skapa en pull-begäran och slå samman via git-providern.

Kan jag ta bort en gren från en Azure Databricks-lagringsplats?

Nej. Om du vill ta bort en gren måste du arbeta i git-providern.

Om ett bibliotek är installerat på ett kluster och ett bibliotek med samma namn ingår i en mapp i en lagringsplats, vilket bibliotek importeras?

Biblioteket på lagringsplatsen importeras. Mer information om bibliotekspriorens i Python finns i Prioritet för Python-bibliotek.

Kan jag hämta den senaste versionen av en lagringsplats från Git innan jag kör ett jobb utan att förlita mig på ett externt orkestreringsverktyg?

Nej. Vanligtvis kan du integrera detta som en förhandsincheckning på Git-servern så att varje push-överföring till en gren (main/prod) uppdaterar lagringsplatsen Produktion.

Kan jag exportera en lagringsplats?

Du kan exportera notebook-filer, mappar eller en hel lagringsplats. Du kan inte exportera filer som inte är notebook-filer. Om du exporterar en hel lagringsplats ingår inte filer som inte är notebook-filer. Om du vill exportera använder du workspace export kommandot i Databricks CLI eller använder API:et För arbetsyta.

Säkerhet, autentisering och token

Problem med en princip för villkorlig åtkomst (CAP) för Microsoft Entra-ID

När du försöker klona en lagringsplats kan du få felmeddelandet "nekad åtkomst" när:

  • Azure Databricks är konfigurerat för att använda Azure DevOps med Microsoft Entra ID-autentisering.
  • Du har aktiverat en princip för villkorlig åtkomst i Azure DevOps och en princip för villkorsstyrd åtkomst för Microsoft Entra-ID.

Lös problemet genom att lägga till ett undantag i principen för villkorsstyrd åtkomst (CAP) för IP-adressen eller användare av Azure Databricks.

Mer information finns i Principer för villkorsstyrd åtkomst.

Tillåt lista med Azure AD-token

Om du använder Azure Active Directory (AAD) för att autentisera med Azure DevOps, begränsar tillåtelselistan Git-URL:er till:

  • dev.azure.com
  • visualstudio.com

Mer information finns i Tillåt listor som begränsar fjärr lagringsplatsens användning.

Krypteras innehållet i Azure Databricks Git-mappar?

Innehållet i Azure Databricks Git-mappar krypteras av Azure Databricks med hjälp av en standardnyckel. Kryptering med kundhanterade nycklar stöds inte förutom när du krypterar dina Git-autentiseringsuppgifter.

Hur och var lagras GitHub-token i Azure Databricks? Vem skulle ha åtkomst från Azure Databricks?

  • Autentiseringstoken lagras i Azure Databricks-kontrollplanet och en Azure Databricks-anställd kan bara få åtkomst via en tillfällig autentiseringsuppgift som granskas.
  • Azure Databricks loggar skapandet och borttagningen av dessa token, men inte deras användning. Azure Databricks har loggning som spårar Git-åtgärder som kan användas för att granska användningen av token från Azure Databricks-programmet.
  • GitHub Enterprise granskar tokenanvändning. Andra Git-tjänster kan också ha Git-servergranskning.

Stöder Git-mappar GPG-signering av incheckningar?

Nej.

Stöder Git-mappar SSH?

Nej, bara HTTPS.

Det gick inte att ansluta Azure Databricks till en Azure DevOps-lagringsplats i en annan klientorganisation

När du försöker ansluta till DevOps i en separat klientorganisation kan du få meddelandet Unable to parse credentials from Azure Active Directory account. Om Azure DevOps-projektet har ett annat Microsoft Entra-ID än Azure Databricks måste du använda en åtkomsttoken från Azure DevOps. Se Ansluta till Azure DevOps med en DevOps-token.

CI/CD och MLOps

Inkommande ändringar rensar notebook-tillståndet

Git-åtgärder som ändrar källkoden för notebook-filen resulterar i förlust av notebook-tillstånd, inklusive cellutdata, kommentarer, versionshistorik och widgetar. Kan till exempel git pull ändra källkoden för en notebook-fil. I det här fallet måste Databricks Git-mappar skriva över den befintliga notebook-filen för att importera ändringarna. git commit och push eller att skapa en ny gren påverkar inte notebook-källkoden, så notebook-tillståndet bevaras i dessa åtgärder.

Viktigt!

MLflow-experiment fungerar inte i Git-mappar med DBR 14.x eller lägre versioner.

Kan jag skapa ett MLflow-experiment i en lagringsplats?

Det finns två typer av MLflow-experiment: arbetsyta och notebook-fil. Mer information om de två typerna av MLflow-experiment finns i Ordna träningskörningar med MLflow-experiment.

I Git-mappar kan du anropa mlflow.set_experiment("/path/to/experiment") ett MLflow-experiment av någon av typerna och loggkörningar till det, men experimentet och de associerade körningarna checkas inte in i källkontrollen.

MLflow-experiment för arbetsyta

Du kan inte skapa MLflow-experiment för arbetsytan i en Databricks Git-mapp (Git-mapp). Om flera användare använder separata Git-mappar för att samarbeta med samma ML-kod körs MLflow-loggen till ett MLflow-experiment som skapats i en vanlig arbetsytemapp.

MLflow-experiment för notebook-filer

Du kan skapa notebook-experiment i en Databricks Git-mapp. Om du checkar in anteckningsboken i källkontrollen som en .ipynb fil kan du logga MLflow-körningar till ett automatiskt skapat och associerat MLflow-experiment. Mer information finns i skapa notebook-experiment.

Förhindra dataförlust i MLflow-experiment

MLflow-experiment för notebook-filer som skapats med Databricks-jobb med källkod på en fjärrlagringsplats lagras på en tillfällig lagringsplats. De här experimenten bevaras först efter arbetsflödets körning men riskerar att tas bort senare under schemalagd borttagning av filer i tillfällig lagring. Databricks rekommenderar att du använder MLflow-experiment för arbetsytor med jobb och fjärranslutna Git-källor.

Varning

Varje gång du växlar till en gren som inte innehåller notebook-filen riskerar du att förlora associerade MLflow-experimentdata. Den här förlusten blir permnanent om den tidigare grenen inte nås inom 30 dagar.

Om du vill återställa saknade experimentdata innan 30 dagar går ut byter du namn på anteckningsboken tillbaka till det ursprungliga namnet, öppnar anteckningsboken, klickar på "experiment"-ikonen till höger (detta anropar även API:et mlflow.get_experiment_by_name() ) och du kommer att kunna se det återställda experimentet och körningarna. Efter 30 dagar rensas alla överblivna MLflow-experiment för att uppfylla GDPR-efterlevnadsprinciper.

För att förhindra den här situationen rekommenderar Databricks att du antingen undviker att byta namn på anteckningsböcker helt och hållet, eller om du byter namn på en anteckningsbok klickar du på ikonen "experiment" till höger direkt efter att du har bytt namn på en notebook-fil.

Vad händer om ett notebook-jobb körs på en arbetsyta medan en Git-åtgärd pågår?

När som helst medan en Git-åtgärd pågår kan vissa notebook-filer på lagringsplatsen ha uppdaterats medan andra inte har gjort det. Det kan leda till ett oväntat beteende.

Anta till exempel att notebook A anrop notebook Z använder ett %run kommando. Om ett jobb som körs under en Git-åtgärd startar den senaste versionen av , men notebook A ännu inte har uppdaterats, notebook Z kan kommandot i notebook A starta den äldre versionen av %run.notebook Z Under Git-åtgärden är notebook-tillstånden inte förutsägbara och jobbet kan misslyckas eller köras notebook A och notebook Z från olika incheckningar.

Undvik den här situationen genom att använda Git-baserade jobb (där källan är en Git-leverantör och inte en arbetsytesökväg) istället. Mer information finns i Använda Git med jobb.

Resurser

Mer information om Databricks-arbetsytefiler finns i Vad är arbetsytefiler?.