Limiti e domande frequenti per l'integrazione di Git con le cartelle Git di Databricks

Le cartelle Git di Databricks e l'integrazione git hanno limiti specificati nelle sezioni seguenti. Per informazioni generali, vedere Limiti di Databricks.

Limiti di dimensioni file e repository

Azure Databricks non applica un limite alle dimensioni di un repository. Tuttavia:

• I rami di lavoro sono limitati a 200 MB.
• I singoli file dell'area di lavoro sono soggetti a un limite di dimensioni separato. Per altre informazioni, vedere Limitazioni.
• I file di dimensioni superiori a 10 MB non possono essere visualizzati nell'interfaccia utente di Azure Databricks.

Databricks consiglia di usare un repository:

• Il numero totale di tutti i file non supera 10.000.
• Il numero totale di notebook non supera 5.000.

Per qualsiasi operazione Git, l'utilizzo della memoria è limitato a 2 GB e le scritture su disco sono limitate a 4 GB. Poiché il limite è per operazione, si verifica un errore se si tenta di clonare un repository Git con dimensioni correnti di 5 GB. Tuttavia, se si clona un repository Git con dimensioni pari a 3 GB in un'operazione e quindi si aggiungono 2 GB in un secondo momento, l'operazione pull successiva avrà esito positivo.

Se il repository supera questi limiti, potrebbe essere visualizzato un messaggio di errore. È anche possibile che venga visualizzato un errore di timeout quando si clona il repository, ma l'operazione potrebbe essere completata in background.

Per usare il repository più grande dei limiti di dimensioni, provare a eseguire il checkout di tipo sparse.

Se è necessario scrivere file temporanei che non si desidera mantenere dopo l'arresto del cluster, scrivere i file temporanei per $TEMPDIR evitare di superare i limiti delle dimensioni dei rami e restituisce prestazioni migliori rispetto alla scrittura nella directory di lavoro corrente (CWD) se CWD si trova nel file system dell'area di lavoro. Per altre informazioni, vedere Dove scrivere file temporanei in Azure Databricks?.

Numero massimo di cartelle Git per area di lavoro

È possibile avere un massimo di 2.000 cartelle Git per area di lavoro. Se sono necessarie altre informazioni, contattare il supporto tecnico di Databricks.

Supporto di Monorepo

Databricks consiglia di non creare cartelle Git supportate da monorepos, in cui un monorepo è un repository Git di grandi dimensioni con molte migliaia di file in molti progetti.

Configurazione della cartella Git

Dove è archiviato il contenuto del repository di Azure Databricks?

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

Le cartelle Git supportano server Git locali o self-hosted?

Le cartelle Git di Databricks supportano GitHub Enterprise, Bitbucket Server, Azure DevOps Server e l'integrazione self-managed di GitLab, se il server è accessibile da Internet. Per informazioni dettagliate sull'integrazione di cartelle Git con un server Git locale, vedere Git Proxy Server per le cartelle Git.

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

Quali tipi di asset di Databricks sono supportati dalle cartelle Git?

Per informazioni dettagliate sui tipi di asset supportati, vedere Gestire gli asset di file nelle cartelle Git di Databricks.

Le cartelle Git supportano .gitignore i file?

Sì. Se si aggiunge un file al repository e non si vuole che venga rilevato da Git, creare un .gitignore file o usarne uno clonato dal repository remoto e aggiungere il nome del file, inclusa l'estensione.

.gitignore funziona solo per i file non già rilevati da Git. Se si aggiunge un file già rilevato da Git a un .gitignore file, il file viene ancora rilevato da Git.

È possibile creare cartelle di primo livello che non sono cartelle utente?

Sì, gli amministratori possono creare cartelle di primo livello a una singola profondità. Le cartelle Git non supportano livelli di cartella aggiuntivi.

Le cartelle Git supportano i moduli secondari Git?

No. È possibile clonare un repository che contiene moduli secondari Git, ma il modulo secondario non viene clonato.

Azure Data Factory supporta le cartelle Git?

Sì.

Gestione del codice sorgente

Perché i dashboard del notebook scompaiono quando si esegue il pull o il checkout di un ramo diverso?

Questa è attualmente una limitazione perché i file di origine del notebook di Azure Databricks non archiviano le informazioni del dashboard del notebook.

Se si desidera mantenere i dashboard nel repository Git, modificare il formato del notebook in .ipynb (formato notebook jupyter). Per impostazione predefinita, .ipynb supporta le definizioni di dashboard e visualizzazione. Se si desidera mantenere i dati del grafo (punti dati), è necessario eseguire il commit del notebook con output.

Per informazioni sul commit degli .ipynb output dei notebook, vedere Allow commiting notebook output (Consenti il commit dell'output .ipynbdel notebook).

Le cartelle Git supportano l'unione dei rami?

Sì. È anche possibile creare una richiesta pull e unirsi tramite il provider Git.

È possibile eliminare un ramo da un repository di Azure Databricks?

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

Se una libreria è installata in un cluster e una libreria con lo stesso nome viene inclusa in una cartella all'interno di un repository, quale libreria viene importata?

La libreria nel repository viene importata. Per altre informazioni sulla precedenza della libreria in Python, vedere Precedenza della libreria Python.

È possibile eseguire il pull della versione più recente di un repository da Git prima di eseguire un processo senza basarsi su uno strumento di orchestrazione esterno?

No. In genere è possibile integrarlo come pre-commit nel server Git in modo che ogni push in un ramo (main/prod) aggiorni il repository Production.

È possibile esportare un repository?

È possibile esportare notebook, cartelle o un intero repository. Non è possibile esportare file non notebook. Se si esporta un intero repository, i file non del notebook non sono inclusi. Per esportare, usare il workspace export comando nell'interfaccia della riga di comando di Databricks o usare l'API dell'area di lavoro.

Sicurezza, autenticazione e token

Problema con un criterio di accesso condizionale (CAP) per Microsoft Entra ID (in precedenza Azure Active Directory)

Quando si tenta di clonare un repository, è possibile che venga visualizzato un messaggio di errore "accesso negato" quando:

• Azure Databricks è configurato per l'uso di Azure DevOps con l'autenticazione microsoft Entra ID.
• È stato abilitato un criterio di accesso condizionale in Azure DevOps e un criterio di accesso condizionale di Microsoft Entra ID.

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

Per altre informazioni, vedere Criteri di accesso condizionale.

Elenco elementi consentiti con token di Azure AD

Se si usa Azure Active Directory (AAD) 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 Consenti elenchi che limitano l'utilizzo del repository remoto.

Il contenuto delle cartelle Git di Azure Databricks è crittografato?

Il contenuto delle cartelle Git di Azure Databricks viene crittografato da Azure Databricks usando una chiave predefinita. La crittografia che usa chiavi gestite dal cliente non è supportata tranne quando si crittografa le credenziali Git.

Come e dove vengono archiviati i token GitHub in Azure Databricks? Chi avrebbe accesso da Azure Databricks?

• I token di autenticazione vengono archiviati nel piano di controllo di Azure Databricks e un dipendente di Azure Databricks può accedere solo tramite credenziali temporanee controllate.
• Azure Databricks registra la creazione e l'eliminazione di questi token, ma non il relativo utilizzo. Azure Databricks ha la registrazione che tiene traccia delle operazioni Git che possono essere usate per controllare l'utilizzo dei token dall'applicazione Azure Databricks.
• GitHub enterprise controlla l'utilizzo dei token. Altri servizi Git potrebbero anche avere il controllo del server Git.

Le cartelle Git supportano la firma gpg dei commit?

No.

Le cartelle Git supportano SSH?

No, solo HTTPS.

Errore durante la connessione di Azure Databricks a un repository Di Azure DevOps in una tenancy diversa

Quando si tenta di connettersi a DevOps in una tenancy separata, è possibile che venga visualizzato il messaggio Unable to parse credentials from Azure Active Directory account. Se il progetto Azure DevOps si trova in una tenancy dell'ID Entra di Microsoft diversa da Azure Databricks, è necessario usare un token di accesso da Azure DevOps. Vedere Connettersi ad Azure DevOps usando un token DevOps.

CI/CD e MLOps

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 output delle celle, commenti, cronologia delle versioni e widget. Ad esempio, git pull può modificare il codice sorgente di un notebook. In questo caso, le cartelle Git di Databricks devono sovrascrivere il notebook esistente per importare le modifiche. git commit e push o la creazione di un nuovo ramo non influiscono sul codice sorgente del notebook, quindi lo stato del notebook viene mantenuto in queste operazioni.

Importante

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

È possibile creare un esperimento MLflow in un repository?

Esistono due tipi di esperimenti MLflow: area di lavoro e notebook. Per informazioni dettagliate sui due tipi di esperimenti MLflow, vedere Organizzare le esecuzioni di training con esperimenti MLflow.

Nelle cartelle Git è possibile chiamare mlflow.set_experiment("/path/to/experiment") per un esperimento MLflow di entrambi i tipi e registrarli, ma tale esperimento e le esecuzioni associate non verranno controllate nel controllo del codice sorgente.

Esperimenti MLflow dell'area di lavoro

Non è possibile creare esperimenti MLflow dell'area di lavoro in una cartella Git di Databricks (cartella Git). Se più utenti usano cartelle Git separate per collaborare allo stesso codice ml, il log MLflow viene eseguito in un esperimento MLflow creato in una normale cartella dell'area di lavoro.

Esperimenti MLflow 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, è possibile registrare le esecuzioni di MLflow in un esperimento MLflow creato e associato automaticamente. Per altre informazioni, vedere Creazione di esperimenti di notebook.

Evitare la perdita di dati negli esperimenti MLflow

Avviso

Ogni volta che si passa a un ramo che non contiene il notebook, si rischia di perdere i dati dell'esperimento MLflow associati. Questa perdita diventa permnanent se il ramo precedente non è accessibile entro 30 giorni.

Per recuperare i dati dell'esperimento mancanti prima della scadenza di 30 giorni, rinominare nuovamente il notebook con il nome originale, aprire il notebook, fare clic sull'icona "esperimento" nel riquadro a destra (che chiama in modo efficace anche l'API mlflow.get_experiment_by_name() ) e sarà possibile visualizzare l'esperimento e le esecuzioni ripristinate. Dopo 30 giorni, tutti gli esperimenti MLflow orfani verranno eliminati per soddisfare i criteri di conformità gdpr.

Per evitare questa situazione, Databricks consiglia di evitare di rinominare completamente i notebook nei repository oppure, se si rinomina un notebook, fare clic sull'icona "esperimento" nel riquadro a destra immediatamente dopo la ridenominazione di un notebook.

Avviso

Gli esperimenti MLflow del notebook creati usando flussi di lavoro di Databricks con codice sorgente in un repository remoto vengono archiviati in una posizione di archiviazione temporanea. Questi esperimenti vengono mantenuti inizialmente dopo l'esecuzione del flusso di lavoro, ma sono a rischio di eliminazione in un secondo momento durante la rimozione pianificata dei file nell'archiviazione temporanea. Databricks consiglia di usare esperimenti MLflow dell'area di lavoro con flussi di lavoro e origini Git remote.

Cosa accade se un processo notebook è in esecuzione in un'area di lavoro mentre è in corso un'operazione Git?

In qualsiasi momento, mentre è in corso un'operazione Git, alcuni notebook nel repository potrebbero essere stati aggiornati mentre altri non lo sono. Ciò può causare un comportamento imprevedibile.

Si supponga, ad esempio, di notebook A chiamare notebook Z usando un %run comando . Se un processo in esecuzione durante un'operazione Git avvia la versione più recente di notebook A, ma notebook Z non è ancora stato aggiornato, il %run comando nel notebook A potrebbe avviare la versione precedente di notebook Z. Durante l'operazione Git, gli stati del notebook non sono prevedibili e il processo potrebbe non riuscire o eseguirlo notebook A e notebook Z da commit diversi.

Per evitare questa situazione, usare invece processi basati su Git (dove l'origine è un provider Git e non un percorso dell'area di lavoro). Per altre informazioni, vedere Usare il codice sorgente controllato dalla versione in un processo di Azure Databricks.

Risorse

Per informazioni dettagliate sui file dell'area di lavoro di Databricks, vedere Che cosa sono i file dell'area di lavoro?.