Azure Databricks limiti delle cartelle Git e riferimento

Questa pagina illustra i limiti di dimensioni, le funzionalità supportate, le considerazioni sulla sicurezza e il comportamento CI/CD per le cartelle Git di Databricks. Per i limiti generali delle risorse di Databricks, vedere Limiti delle risorse. Per informazioni sui tipi di asset supportati nelle cartelle Git, vedere Tipi di asset supportati nelle cartelle Git.

Limiti di file e repository

Azure Databricks non applica un limite alle dimensioni del repository. Tuttavia, si applicano i limiti seguenti:

  • I rami di lavoro sono limitati a 1 GB.
  • Non è possibile visualizzare file di dimensioni superiori a 10 MB nell'interfaccia utente Azure Databricks.
  • Ogni operazione Git supporta fino a 2 GB di memoria e 4 GB di scritture su disco.
  • I singoli file dell'area di lavoro hanno limiti di dimensioni separati. Vedere Limitazioni.

Databricks consiglia di mantenere il numero totale di asset e file dell'area di lavoro sotto 20.000.

Poiché i limiti si applicano per operazione, la clonazione di un repository da 5 GB ha esito negativo, ma la clonazione di un repository da 3 GB e l'aggiunta di 2 GB ha esito positivo. Se il repository supera questi limiti, è possibile che venga visualizzato un errore o un timeout durante la clonazione, anche se l'operazione potrebbe essere ancora completata in background.

Per usare repository di grandi dimensioni, provare il sparse checkout o i comandi della CLI di Git. Per scrivere file temporanei che non vengono mantenuti dopo l'arresto del cluster, usare $TEMPDIR. Ciò evita di superare i limiti delle dimensioni dei rami e offre prestazioni migliori rispetto alla scrittura in una directory di lavoro (CWD) nel file system dell'area di lavoro. Vedi Dove dovrei scrivere i file temporanei su Azure Databricks?.

I rami locali possono rimanere nella cartella Git associata per un massimo di 30 giorni dopo l'eliminazione del ramo remoto. Per rimuovere completamente un ramo locale, eliminare il repository.

Ridurre le dimensioni del repository

Se il repository supera i limiti di dimensioni dovuti a file di grandi dimensioni, l'aggiunta di tali file a .gitignore non ridurrà le dimensioni del repository. I file già sottoposti a commit in Git rimangono nella cronologia del repository anche quando aggiunti a .gitignore.

Per ridurre le dimensioni del repository:

  • Usare strumenti Git come git filter-repo o BFG Repo-Cleaner per rimuovere file di grandi dimensioni dalla cronologia dei commit. Questa procedura riscrive la cronologia e richiede il push forzato nel repository remoto.
  • Clonare solo directory specifiche. Consultare Configurare la modalità di checkout tipo sparse.
  • Spostare il codice non correlato in repository separati.

Per altre informazioni, vedere Rimuovere i dati sensibili da un repository nella documentazione di GitHub.

Supporto di Monorepo

Databricks consiglia di non creare cartelle Git supportate da monorepos, ovvero repository Git di grandi dimensioni e a organizzazione singola con migliaia di file in molti progetti. La clonazione di un monorepo può superare i limiti di memoria e disco della cartella Git e rallentare le operazioni di Git. Se il tuo repository contiene più progetti, considera la suddivisione o l'uso del checkout sparse per limitare le directory clonate. Consultare Configurare la modalità di checkout tipo sparse.

Configurazione

Non tutte le funzionalità Git standard funzionano nelle cartelle Git e il contenuto viene archiviato in modo diverso rispetto a un clone locale. Gli argomenti seguenti illustrano il funzionamento dell'archiviazione, i server supportati e il comportamento delle funzionalità come .gitignore e dei moduli secondari.

Archiviazione del contenuto del repository

Azure Databricks clona temporaneamente il contenuto del repository su disco nel piano di controllo. Il database del piano di controllo archivia file di notebook come quelli nell'area di lavoro principale. I file non notebook vengono archiviati su disco per un massimo di 30 giorni.

Server Git in sede e autogestiti

Le cartelle Git di Databricks supportano GitHub Enterprise, Bitbucket Server, Azure DevOps Server e GitLab self-managed se il server è accessibile da Internet. Consultare il Git Proxy Server per la gestione delle cartelle Git per l'integrazione in sede.

Per eseguire l'integrazione con un server Bitbucket, GitHub Enterprise Server o un'istanza self-managed di GitLab non accessibile da Internet, contattare il team dell'account Azure Databricks.

Tipi di asset supportati

Per informazioni dettagliate sui tipi di asset supportati, vedere Tipi di asset supportati nelle cartelle Git.

Supporto dei file con estensione gitignore

Le cartelle Git supportano i file .gitignore. Per impedire a Git di tenere traccia di un file, aggiungere il nome file (inclusa l'estensione) a un .gitignore file. Crearne uno o usare un file esistente clonato dal repository remoto.

.gitignore funziona solo per i file non registrati. L'aggiunta di un file già commitato a .gitignore non lo rimuove dalla cronologia di Git né riduce le dimensioni del repository. Per rimuovere i file di cui è stato eseguito il commit, vedere Ridurre le dimensioni del repository.

Supporto del modulo secondario Git

Le cartelle Git standard non supportano i moduli secondari Git, ma le cartelle Git con accesso all'interfaccia della riga di comando Git possono usarle. Consulta Utilizzare i comandi della CLI Git (Beta).

supporto di Azure Data Factory

Azure Data Factory (ADF) supporta le cartelle Git.

Gestione delle fonti

Alcune operazioni funzionano in modo diverso nelle cartelle Git rispetto a un flusso di lavoro Git standard, in particolare per i notebook e l'eliminazione di rami.

Dashboard dei notebook e modifiche ai branch

I taccuini nel formato di origine di Azure Databricks non archiviano le informazioni del dashboard.

Per mantenere i cruscotti, modificare il formato del notebook in .ipynb (formato Jupyter), che supporta le definizioni di cruscotti e visualizzazioni per impostazione predefinita. Per mantenere i dati di visualizzazione, eseguire il commit del notebook con output.

Consulta Gestire i commit di output del notebook IPYNB.

Supporto per l'unione dei rami

Le cartelle Git supportano l'unione dei rami. È anche possibile creare una richiesta pull e unire tramite il provider Git.

Eliminazione di rami

Per eliminare un ramo, è necessario lavorare nel provider Git.

Precedenza delle dipendenze di Python

Python librerie in una cartella Git hanno la precedenza sulle librerie archiviate altrove. Ad esempio, se una libreria è installata nel calcolo di Databricks e una libreria con lo stesso nome esiste in una cartella Git, viene importata la libreria di cartelle Git. Consultare Precedenza delle librerie di Python.

Sicurezza, autenticazione e token

Azure Databricks archivia le credenziali Git nel piano di controllo, non nell'ambiente locale. Gli argomenti seguenti illustrano come vengono crittografati i contenuti delle cartelle Git, come vengono archiviati e controllati i token e cosa fare se si verificano problemi di autenticazione.

Problema con un criterio di accesso condizionale (CAP) per Microsoft Entra ID

È possibile che venga visualizzato un errore di accesso negato durante la clonazione di un repository se:

  • L'area di lavoro di Azure Databricks usa Azure DevOps con l'autenticazione di Microsoft Entra ID.
  • È stato abilitato un criterio di accesso condizionale in Azure DevOps e un criterio di accesso condizionale Microsoft Entra ID.

Per risolvere questo, aggiungere un'esclusione ai criteri di accesso condizionale (CAP) per gli indirizzi IP o gli utenti di Azure Databricks.

Per altre informazioni, vedere Criteri di accesso condizionale.

Lista consentiti con token di Microsoft Entra ID

Se si usa Microsoft Entra ID per l'autenticazione con Azure DevOps, l'elenco di indirizzi consentiti predefinito limita gli URL Git a:

  • dev.azure.com
  • visualstudio.com

Per altre informazioni, vedere Elenchi di indirizzi consentiti per URL Git.

Crittografia cartelle Git

Azure Databricks crittografa il contenuto della cartella Git usando una chiave predefinita. Le chiavi gestite dal cliente sono supportate solo per la crittografia delle credenziali Git.

Archiviazione e accesso ai token GitHub

  • Il piano di controllo Azure Databricks archivia i token di autenticazione. I dipendenti possono accedervi solo tramite credenziali temporanee controllate.
  • Azure Databricks registra la creazione e l'eliminazione dei token, ma non l'utilizzo. La registrazione delle operazioni Git consente di controllare l'utilizzo dei token dall'applicazione Azure Databricks.
  • GitHub Enterprise controlla l'utilizzo dei token. Altri servizi Git possono anche offrire il controllo del server.

Firma del commit GPG

Le cartelle Git non supportano la firma gpg dei commit.

Supporto SSH

Le cartelle Git supportano solo HTTPS, non SSH.

Errori cross-tenancy di Azure DevOps

Quando ci si connette a DevOps in una tenancy separata, è possibile che venga visualizzato Unable to parse credentials from Azure Active Directory account. Se il progetto Azure DevOps si trova in una tenancy Microsoft Entra ID diversa da quella di Azure Databricks, usare un token di accesso Azure DevOps. Vedere Token di accesso personale.

CI/CD e MLOps

Se si eseguono processi su file in una cartella Git, tenere presente come le operazioni Git possono influire sullo stato del notebook e sugli esperimenti MLflow in modi che potrebbero non essere evidenti.

Le modifiche in ingresso cancellano lo stato del notebook

Le operazioni Git che modificano il codice sorgente del notebook comportano la perdita dello stato del notebook, inclusi gli output delle celle, i commenti, la cronologia delle versioni e i widget. Ad esempio, git pull può modificare il codice sorgente del notebook, richiedendo alle cartelle Git di sovrascrivere il notebook esistente. Le operazioni come git commit, pusho la creazione di un nuovo ramo non influiscono sul codice sorgente e mantengono lo stato del notebook.

Importante

Gli esperimenti MLflow non funzionano nelle cartelle Git con Databricks Runtime 14.x o versioni precedenti.

Esperimenti MLflow nelle cartelle Git

Esistono due tipi di esperimenti MLflow: area di lavoro e notebook. Vedi Come organizzare le esecuzioni di training con esperimenti di MLflow.

  • Esperimenti dell'area di lavoro: non è possibile creare esperimenti MLflow dell'area di lavoro nelle cartelle Git. Registra le esecuzioni di MLflow in un esperimento creato in una normale cartella del workspace. Per la collaborazione multiutente, usare una cartella dell'area di lavoro condivisa.

  • Esperimenti di notebook: è possibile creare esperimenti di notebook in una cartella Git di Databricks. Se si archivia il notebook nel controllo del codice sorgente come .ipynb file, MLflow esegue il log in un esperimento creato automaticamente. Il controllo del codice sorgente non effettua il check-in nell'esperimento o nelle relative esecuzioni. Consulta Crea un esperimento di notebook.

Evitare la perdita di dati negli esperimenti MLflow

Gli esperimenti notebook MLflow creati utilizzando Lakeflow Jobs con codice sorgente in un repository remoto vengono memorizzati in memoria temporanea. Questi esperimenti vengono mantenuti inizialmente dopo l'esecuzione del flusso di lavoro, ma rischiano l'eliminazione durante la pulizia pianificata. Databricks consiglia di utilizzare esperimenti di MLflow nell'area di lavoro con lavori e origini Git remote.

Avviso

Il passaggio a un ramo che non contiene il notebook rischia di perdere i dati dell'esperimento MLflow associati. Questa perdita diventa permanente se non si visita il ramo precedente entro 30 giorni.

Per recuperare i dati dell'esperimento mancanti prima della scadenza di 30 giorni, ripristinare il nome originale del notebook, aprire il notebook e fare clic sull'icona Esperimento nel riquadro destro. Questo attiva mlflow.get_experiment_by_name(), recupera l'esperimento e lo esegue. Dopo 30 giorni, Azure Databricks elimina gli esperimenti MLflow orfani per la conformità al GDPR.

Per evitare la perdita di dati, evitare di rinominare i notebook in un repository. Se si rinomina un notebook, fare clic immediatamente sull'icona dell'esperimento nel riquadro destro.

Esecuzione di processi durante le operazioni Git

Durante un'operazione Git, alcuni notebook potrebbero essere aggiornati mentre altri non sono ancora, causando un comportamento imprevedibile.

Ad esempio, se notebook A chiama notebook Z utilizzando %run e un processo viene avviato durante un'operazione Git, il processo potrebbe eseguire la versione più recente di notebook A con un più vecchio notebook Z. Il processo potrebbe non riuscire o eseguire notebook da commit diversi.

Per evitare questo problema, configurare le attività di lavoro per utilizzare il tuo provider Git come origine anziché un percorso dell'area di lavoro. Vedere Usare Git con processi Lakeflow.

Passaggi successivi

  • Last updated on