Azure Databricks Gränser och referens för Git-mappar

Den här sidan beskriver storleksbegränsningar, funktioner som stöds, säkerhetsöverväganden och CI/CD-beteende för Databricks Git-mappar. Allmänna Databricks-resursgränser finns i Resursgränser. Mer information om tillgångstyper som stöds i Git-mappar finns i Tillgångstyper som stöds i Git-mappar.

Fil- och lagringsplatsens gränser

Azure Databricks tillämpar inte någon gräns för lagringsplatsens storlek. Följande begränsningar gäller dock:

• Arbetsgrenar är begränsade till 1 GB.
• Du kan inte visa filer som är större än 10 MB i Azure Databricks användargränssnittet.
• Varje Git-åtgärd stöder upp till 2 GB minne och 4 GB diskskrivningar.
• Enskilda arbetsytefiler har separata storleksgränser. Se Begränsningar.

Databricks rekommenderar att du håller det totala antalet arbetsytetillgångar och filer under 20 000.

Eftersom gränserna gäller per åtgärd misslyckas kloningen av en lagringsplats på 5 GB, men kloning av en lagringsplats på 3 GB och senare tillägg av 2 GB lyckas. Om lagringsplatsen överskrider dessa gränser kan du få ett fel eller en timeout under kloningen, även om åtgärden fortfarande kan slutföras i bakgrunden.

Om du vill arbeta med större lagringsplatser, kan du prova en gles utcheckning eller Git CLI-kommandon. Om du vill skriva temporära filer som inte sparas efter klusteravstängningen använder du $TEMPDIR. Detta undviker att överskrida gränserna för mappstorlek och ger bättre prestanda än att skriva till en "arbetskatalog (CWD)" i arbetsytans filsystem. Se Var ska jag skriva temporära filer på Azure Databricks?.

Lokala grenar kan finnas kvar i den associerade Git-mappen i upp till 30 dagar efter att fjärrgrenen har tagits bort. Ta bort lagringsplatsen om du vill ta bort en lokal gren helt.

Minska lagringsplatsens storlek

Om ditt repository överskrider storleksgränserna på grund av stora filer kommer det inte att minska repositoryts storlek att lägga till dem till .gitignore. Filer som redan har checkats in till Git finns kvar i lagringsplatsens historik även när de läggs till i .gitignore.

Så här minskar du lagringsplatsens storlek:

• Använd Git-verktyg som git filter-repo eller BFG-Repo-Cleaner för att ta bort stora filer från incheckningshistoriken. Det här skriver om historiken och kräver force-push till din fjärrlagringsplats.
• Klona endast specifika kataloger. Se Konfigurera gles utcheckningsläge.
• Flytta orelaterad kod till separata lagringsplatser.

Mer information finns i Ta bort känsliga data från en lagringsplats i GitHub dokumentationen.

Stöd för monorepo

Databricks rekommenderar att du inte skapar Git-mappar som backas upp av monorepos – stora Git-lagringsplatser med en enda organisation med tusentals filer i många projekt. Att klona ett monorepo kan överskrida Git-mappens begränsningar för minne och disk och göra Git-operationer långsammare. Om lagringsplatsen innehåller flera projekt kan du överväga att dela upp den eller använda en gles utcheckning för att begränsa vilka kataloger som klonas. Se Konfigurera gles utcheckningsläge.

Konfiguration

Alla Git-standardfunktioner fungerar inte i Git-mappar och innehållet lagras på ett annat sätt än i en lokal klon. I följande avsnitt beskrivs hur lagring fungerar, vilka servrar som stöds och hur funktioner som .gitignore och undermoduler fungerar.

Arkivinnehållslagring

Azure Databricks klonar tillfälligt lagringsplatsens innehåll till disken i kontrollplanet. Kontrollplansdatabasen lagrar notebook-filer som de i huvudarbetsytan. Filer som inte är notebook-filer lagras på disken i upp till 30 dagar.

Lokala och lokalt installerade Git-servrar

Databricks Git-mappar stöder GitHub Enterprise, Bitbucket Server, Azure DevOps Server och GitLab Självhanterat om servern är åtkomlig via internet. Se Git Proxy Server för Git-mappar för lokal integrering.

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

Tillgångstyper som stöds

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

stöd för .gitignore-filen

Git-mappar stöder .gitignore filer. Om du vill förhindra att Git spårar en fil lägger du till filnamnet (inklusive tillägget) i en .gitignore fil. Skapa en eller använd en befintlig fil som klonas från fjärrlagringsplatsen.

.gitignore fungerar endast för ospårade filer. Att lägga till en redan bekräftad fil i .gitignore tar inte bort den från Git-historiken eller minskar lagringsplatsens storlek. Information om hur du tar bort incheckade filer finns i Minska lagringsplatsens storlek.

Stöd för Git-undermodul

Git-standardmappar stöder inte Git-undermoduler, men Git-mappar med Git CLI-åtkomst kan använda dem. Se Använda Git CLI-kommandon (Beta).

stöd för Azure Data Factory

Azure Data Factory (ADF) stöder Git-mappar.

Källhantering

Några åtgärder fungerar annorlunda i Git-mappar än i ett git-standardarbetsflöde, särskilt när det gäller notebook-filer och borttagning av grenar.

Dashboardar och ändringar i grenar för notebookar

Azure Databricks-notebooks i sitt ursprungliga format lagrar inte information om instrumentpaneler.

Om du vill bevara instrumentpaneler ändrar du notebook-formatet till .ipynb (Jupyter-format), som stöder definitioner för instrumentpaneler och visualiseringar som standard. Spara visualiseringsdata genom att spara notebook-filen med utdata.

Se Hantera IPYNB-notebook-utdataincheckningar.

Stöd för sammanslagning av grenar

Git-mappar stöder sammanslagning av grenar. Du kan också skapa en pull-begäran och slå samman via git-providern.

Ta bort grenar

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

Python beroendeprioritet

Python bibliotek i en Git-mapp har företräde framför bibliotek som lagras någon annanstans. Om ett bibliotek till exempel är installerat på databricks-beräkningen och ett bibliotek med samma namn finns i en Git-mapp importeras Git-mappbiblioteket. Se Python biblioteksprioritet.

Säkerhet, autentisering och token

Azure Databricks lagrar Git-autentiseringsuppgifter i kontrollplanet, inte i din lokala miljö. Följande avsnitt beskriver hur Innehållet i Git-mappen krypteras, hur token lagras och granskas och vad du ska göra om du stöter på autentiseringsproblem.

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

Du kan få felet "nekad åtkomst" när du klonar en lagringsplats om:

• Din Azure Databricks-arbetsyta använder Azure DevOps med Microsoft Entra ID autentisering.
• Du har aktiverat en princip för villkorlig åtkomst i Azure DevOps och en Microsoft Entra ID princip för villkorlig åtkomst.

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

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

Allowlist med Microsoft Entra ID-tokens

Om du använder Microsoft Entra ID för att autentisera med Azure DevOps begränsar standardlistan Git-URL:er till:

• dev.azure.com
• visualstudio.com

Mer information finns i Tillåtna git-URL-listor.

Git-mappkryptering

Azure Databricks krypterar Innehållet i Git-mappen med hjälp av en standardnyckel. Kundhanterade nycklar stöds endast för kryptering av Git-autentiseringsuppgifter.

GitHub tokenlagring och åtkomst

• Det Azure Databricks kontrollplanet lagrar autentiseringstoken. Anställda kan bara komma åt dem via granskade tillfälliga autentiseringsuppgifter.
• Azure Databricks loggar skapande och borttagning av token, men inte användning. Med Git-åtgärdsloggning kan du granska tokenanvändningen av Azure Databricks-programmet.
• GitHub Enterprise granskar tokenanvändning. Andra Git-tjänster kan också erbjuda servergranskning.

GPG-commit-signering

Git-mappar stöder inte GPG-signering av incheckningar.

SSH-stöd

Git-mappar stöder endast HTTPS, inte SSH.

Azure DevOps gränsöverskridande fel

När du ansluter till DevOps i en separat klient kan du se Unable to parse credentials from Azure Active Directory account. Om Azure DevOps-projektet finns i en annan Microsoft Entra ID-organisation än Azure Databricks, använder du en Azure DevOps-åtkomsttoken. Se Personlig åtkomsttoken.

CI/CD och MLOps

Om du kör jobb mot filer i en Git-mapp bör du vara medveten om hur Git-åtgärder kan påverka notebook-tillstånd och MLflow-experiment på ett sätt som kanske inte är uppenbart.

Inkommande ändringar rensar anteckningsblockets tillstånd

Git-åtgärder som ändrar källkoden för notebook-filer resulterar i förlust av notebook-tillstånd, inklusive cellutdata, kommentarer, versionshistorik och widgetar. Kan till exempel git pull ändra källkoden för notebook-filer, vilket kräver att Git-mappar skriver över den befintliga notebook-filen. Åtgärder som git commit, pusheller att skapa en ny gren påverkar inte källkoden och bevarar notebook-tillstånd.

MLflow-experiment i Git-mappar

Det finns två typer av MLflow-experiment: arbetsyta och anteckningsbok. Se Ordna träningskörningar med MLflow-experiment.

• Arbetsyteexperiment: Du kan inte skapa MLflow-experiment för arbetsytor i Git-mappar. Log MLflow körs till ett experiment som skapats i en vanlig arbetsytemapp. Använd en delad arbetsmapp för samarbete med flera användare.

• Notebook-experiment: Du kan skapa notebook-experiment i en Databricks Git-mapp. Om du checkar in anteckningsboken i källkontrollen som en .ipynb fil kör MLflow loggen till ett automatiskt skapat experiment. Källkontrollen lämnar inte in experimentet eller dess utföranden. Se Skapa notebokexperiment.

Förhindra dataförlust i MLflow-experiment

Notebook-MLflow-experiment som skapats med Lakeflow-jobb med källkod i ett fjärrarkiv sparas i tillfällig lagring. Dessa experiment kvarstår först efter arbetsflödets körning, men riskerar att tas bort vid schemalagd rensning. Databricks rekommenderar att du använder arbetsyte-MLflow-experiment med jobb och fjärr-Git-källor.

Köra jobb under Git-åtgärder

Under en Git-åtgärd kan vissa notebook-filer uppdateras medan andra inte är det ännu, vilket orsakar oförutsägbart beteende.

Till exempel, om notebook A anropar notebook Z med hjälp av %run och ett jobb startar under en Git-åtgärd, kan jobbet köra det senaste notebook A med en äldre notebook Z. Jobbet kan misslyckas eller köra notebook-filer från olika incheckningar.

Undvik detta genom att konfigurera jobb för att använda din Git-leverantör som källa istället för en sökväg till arbetsytan. Se Använda Git med Lakeflow-jobb.

Nästa steg

• Felsöka Git-mappfel
• Skapa och hantera Git-mappar
• Konfigurera Git-integrering för Git-mappar