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

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

Storleksgränser för filer och lagringsplatser

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

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

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

• Det totala antalet filer får inte överstiga 10 000.
• Det totala antalet notebook-filer får inte överstiga 5 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 lagringsplatser per arbetsyta

Du kan ha högst 2 000 lagringsplatser per arbetsyta.

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 Hantera filtillgångar i Databricks 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 och om du exporterar en hel lagringsplats ingår inte filer som inte är notebook-filer. Om du vill exportera använder du Databricks CLI – export av arbetsytor eller API:et för arbetsyta.

Säkerhet, autentisering och token

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

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 listan över tillåtna 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 Anslut 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.

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

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 Z ännu inte har uppdaterats, %run kan kommandot i notebook A starta den äldre versionen av notebook Z.notebook A 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-provider och inte en arbetsytesökväg) i stället. Mer information finns i Använda versionskontrollerad källkod i ett Azure Databricks-jobb.

Resurser

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