Limites et FAQ relatives à l’intégration de Git à des dossiers Git Databricks

L’intégration de dossiers Git Databricks et Git présente des limites qui sont spécifiées dans les sections suivantes. Pour obtenir des informations générales, consultez Limites de Databricks

Limites de taille de fichier et de dépôt

Azure Databricks n’impose pas de limite à la taille d’un dépôt. Toutefois :

• Les branches de travail sont limitées à 500 gigaoctets (Mo).
• Les fichiers supérieurs à 10 Mo ne peuvent pas être consultés dans l’interface utilisateur Azure Databricks.
• Les fichiers individuels de l’espace de travail sont soumis à une limite de taille distincte. Pour en savoir plus, consultez les Limitations.

Databricks recommande que dans un référentiel :

• Le nombre total de tous les fichiers ne dépasse pas 10 000.
• Le nombre total de notebooks ne dépasse pas 5 000.

Pour toute opération Git, l’utilisation de la mémoire est limitée à 2 Go et les écritures sur disque sont limitées à 4 Go. La limite étant fixée par opération, un échec se produit si vous tentez de cloner un repo Git dont la taille actuelle est de 5 Go. Toutefois, si vous clonez un dépôt Git de 3 Go en une seule opération et que vous y ajoutez 2 Go par la suite, l’opération de téléchargement suivante réussira.

Vous pouvez recevoir un message d’erreur si votre référentiel dépasse ces limites. Il se peut également que vous receviez une erreur de délai d’expiration lors du clonage du référentiel, mais l’opération pourrait se terminer en arrière-plan.

Pour utiliser un référentiel supérieur aux limites de taille, essayez d’effectuer une extraction éparse.

Si vous devez écrire des fichiers temporaires que vous ne souhaitez pas conserver après l’arrêt du cluster, l’écriture des fichiers temporaires dans $TEMPDIR évite de dépasser les limites de taille des branches et offre de meilleures performances que l’écriture dans le répertoire de travail actuel (CWD) si le CWD se trouve dans le système de fichiers de l’espace de travail. Pour plus d’informations, voir Où dois-je écrire les fichiers temporaires sur Azure Databricks ?.

Nombre maximal de dossiers Git par espace de travail

Vous pouvez au plus avoir 2 000 dossiers Git par espace de travail. Si vous avez besoin d’un nombre supérieur, contactez le support Databricks.

Prise en charge de référentiel unique

Databricks recommande de ne pas créer de dossiers Git soutenus par des monorepos, où un monorepo est un grand référentiel Git à organisation unique avec plusieurs milliers de fichiers à travers de nombreux projets.

Configuration des dossiers Git

Où est stocké le contenu d’un dépôt Azure Databricks ?

Le contenu d’un dépôt est temporairement cloné sur disque dans le plan de contrôle. Les fichiers de notebook Azure Databricks sont stockés dans la base de données du plan de contrôle, tout comme les notebooks dans l’espace de travail principal. Des fichiers non-notebooks sont stockés sur un disque pendant au plus 30 jours.

Les dossiers Git prennent-ils en charge les serveurs Git locaux ou auto-hébergés ?

Les dossiers Git Databricks prennent en charge l’intégration managée autogérée GitHub Enterprise, Bitbucket Server, Azure DevOps Server et GitLab, si le serveur est accessible par Internet. Pour obtenir plus de détails sur l’intégration de dossiers Git à un serveur Git local, lisez Serveur proxy Git pour dossiers Git.

Pour intégrer un serveur Bitbucket, un serveur GitHub Enterprise ou une instance d'abonnement autogérée GitLab qui n'est pas accessible par Internet, contactez l'équipe de votre compte Azure Databricks.

Quels types de ressources Databricks sont pris en charge par des dossiers Git ?

Pour obtenir plus d’informations sur les types de ressource pris en charge, lisez Gérer des ressources de fichiers dans des dossiers Git Databricks.

Les dossiers Git prennent-ils en charge les fichiers .gitignore ?

Oui. Si vous ajoutez un fichier à votre dépôt et que vous ne souhaitez pas qu’il soit suivi par Git, créez un fichier .gitignore ou utilisez un clone à partir de votre dépôt distant et ajoutez le nom de fichier, y compris l’extension.

.gitignore fonctionne uniquement pour les fichiers qui ne sont pas déjà suivis par Git. Si vous ajoutez un fichier déjà suivi par Git à un fichier .gitignore, le fichier est toujours suivi par Git.

Puis-je créer des dossiers de niveau supérieur qui ne sont pas des dossiers utilisateur ?

Oui, les administrateurs peuvent créer des dossiers de niveau supérieur à une profondeur. Les dossiers Git ne prennent pas en charge des niveaux de dossiers supplémentaires.

Les dossiers Git prennent-ils en charge les sous-modules Git ?

Non. Vous pouvez cloner un dépôt contenant des sous-modules Git, mais les sous-modules ne sont pas clonés.

Azure Data Factory (ADF) prend-il en charge les dossiers Git ?

Oui.

Gestion de la source

Pourquoi les tableaux de bord du notebook disparaissent-ils lorsque j’extrais ou bascule vers une autre branche ?

Il s’agit actuellement d’une limitation, car les fichiers sources du notebook Azure Databricks ne stockent pas les informations relatives au tableau de bord du notebook.

Si vous souhaitez conserver les tableaux de bord dans le référentiel Git, remplacez le format du notebook par .ipynb (le format de notebook Jupyter). Par défaut, .ipynb prend en charge les définitions de tableau de bord et de visualisation. Si vous souhaitez conserver les données du graphique (points de données), vous devez valider le notebook avec des sorties.

Pour en savoir plus sur la validation des sorties de notebook .ipynb, consultez l’article Autoriser la validation de la sortie du notebook .ipynb.

Les dossiers Git prennent-ils en charge la fusion de branche ?

Oui. Vous pouvez également créer une demande de tirage (pull request) et de la fusionner par le biais de votre fournisseur Git.

Puis-je supprimer une branche d’un dépôt Azure Databricks ?

Non. Pour supprimer une branche, vous devez travailler dans votre fournisseur Git.

Si une bibliothèque est installée sur un cluster et si une bibliothèque du même nom est incluse dans un dossier au sein d’un dépôt, quelle bibliothèque est importée ?

La bibliothèque figurant dans le dépôt est importée. Pour plus d’informations sur la priorité de la bibliothèque dans Python, consultez Priorité de la bibliothèque Python.

Puis-je extraire la dernière version d’un dépôt à partir de Git avant d’exécuter un travail sans me servir d’un outil d’orchestration externe ?

Non. En général, vous pouvez l’intégrer en tant que pré-validation sur le serveur Git de sorte que chaque envoi à une branche (principale/produit) met à jour le dépôt Production.

Puis-je exporter un dépôt ?

Vous pouvez exporter des notebooks, des dossiers ou un dépôt entier. Vous ne pouvez pas exporter de fichiers non-notebooks. Si vous exportez un dépôt entier, les fichiers non-notebooks ne sont pas inclus. Si vous souhaitez exporter, utilisez la commande workspace export dans l’interface CLI Databricks ou utilisez l’API Espace de travail.

Sécurité, authentification et jetons

Problème avec une stratégie d'accès conditionnel (CAP) pour Microsoft Entra ID

Lorsque vous essayez de cloner un référentiel, vous pouvez obtenir un message d’erreur « Accès refusé » dans les cas suivants :

• Azure Databricks est configuré pour utiliser Azure DevOps avec l’authentification Microsoft Entra ID.
• Vous avez activé une stratégie d’accès conditionnel dans Azure DevOps et une stratégie d’accès conditionnel Microsoft Entra ID.

Pour résoudre ce problème, ajoutez une exclusion à la stratégie d’accès conditionnel (CAP) pour l’adresse IP ou les utilisateurs d’Azure Databricks.

Pour en savoir plus, référez-vous à la section Politiques en matière d’accès conditionnel.

Liste verte avec des jetons Azure AD

Si vous utilisez Azure Active Directory (AAD) pour l’authentification auprès d’Azure DevOps, la liste verte par défaut limite les URL Git aux URL suivantes :

• dev.azure.com
• visualstudio.com

Pour plus d’informations, consultez Les listes vertes limitent l’utilisation du dépôt distant.

Les contenus des dossiers Git Azure Databricks sont-ils chiffrés ?

Les contenus des dossiers Git Azure Databricks sont chiffrés par Azure Databricks en utilisant une clé par défaut. Le chiffrement à l’aide de clés gérées par le client n’est pas pris en charge, sauf lorsqu’il s’agit de chiffrer les informations d’identification Git.

Comment et où les jetons GitHub sont-ils stockés dans Azure Databricks ? Qui aurait accès à partir d’Azure Databricks ?

• Les jetons d’authentification sont stockés dans le plan de contrôle Azure Databricks, et un employé d’Azure Databricks ne peut y accéder qu’à l’aide d’informations d’identification temporaires qui sont auditées.
• Azure Databricks journalise la création et la suppression de ces jetons, mais pas leur utilisation. Azure Databricks intègre une journalisation qui suit des opérations Git, qui pourraient être utilisées pour auditer l’utilisation des jetons par l’application Azure Databricks.
• GitHub Enterprise audite l’utilisation des jetons. D’autres services Git peuvent également avoir un audit de serveur Git.

Les dossiers Git prennent-ils en charge la signature GPG des commits ?

Non.

Les dossiers Git prennent-ils en charge SSH ?

Non, uniquement HTTPS.

Erreur lors de la connexion d’Azure Databricks à un référentiel Azure DevOps dans une autre location

Quand vous essayez de vous connecter à DevOps dans une location distincte, vous recevez le message Unable to parse credentials from Azure Active Directory account. Si le projet Azure DevOps se trouve dans une location Microsoft Entra ID différente d’Azure Databricks, vous devez utiliser un jeton d’accès d’Azure DevOps. Consultez la section Se connecter à un référentiel Azure DevOps à l’aide d’un jeton DevOps.

CI/CD et MLOps

Les modifications entrantes suppriment l’état du notebook

Les opérations Git qui modifient le code source du notebook entraînent la perte de l’état du notebook, y compris les sorties des cellules, les commentaires, l’historique des versions et les widgets. Par exemple, git pull peut modifier le code source d’un notebook. Dans ce cas, les dossiers Git Databricks doivent remplacer le notebook existant pour importer les modifications. git commit et push ou la création d’une nouvelle branche n’affectent pas le code source du notebook, de sorte que l’état de celui-ci est préservé dans ces opérations.

Puis-je créer une expérience MLflow dans un dépôt ?

Il existe deux types d’expériences MLflow : un espace de travail et un bloc-notes. Pour obtenir plus d’informations sur les deux types d’expériences MLflow, consultez Organiser des exécutions d’apprentissage avec des expériences MLflow.

Dans des dossiers Git, vous pouvez appeler mlflow.set_experiment("/path/to/experiment") pour une expérience MLflow de l’un des types et y journaliser des exécutions, mais cette expérience et les exécutions associées ne sont pas archivées dans un contrôle de code source.

Expériences MLflow d’espace de travail

Vous ne pouvez pas créer des expériences MLflow d’espace de travail dans un dossier Git Databricks (dossier Git). Si plusieurs utilisateurs utilisent des dossiers Git distincts pour collaborer sur le même code ML, journalisez des exécutions MLflow dans une expérience MLflow créée dans un dossier d’espace de travail normal.

Expériences MLflow de notebook

Vous pouvez créer des expériences de notebook dans un dossier Git Databricks. Si vous archivez votre notebook dans un contrôle de code source en tant que fichier .ipynb, vous pouvez journaliser des exécutions MLflow dans une expérience MLflow automatiquement créée et associée. Pour obtenir plus d’informations, parcourez la création d’expériences de notebook.

Empêcher la perte de données dans les expériences MLflow

Les expériences MLflow de notebook créées à l’aide de Databricks Jobs avec du code source dans un référentiel distant sont stockées dans un emplacement de stockage temporaire. Ces expériences persistent initialement après l’exécution du flux de travail, mais risquent d’être supprimées ultérieurement lors de la suppression planifiée de fichiers dans un stockage temporaire. Databricks recommande d’utiliser des expériences MLflow d’espace de travail avec Jobs et des sources Git distantes.

Que se passe-t-il si un travail notebook est en cours d’exécution dans un espace de travail alors qu’une opération Git est en cours ?

À tout moment pendant une opération Git en cours, certains notebooks dans le dépôt peuvent avoir été mis à jour et d’autres non. Cela peut entraîner un comportement imprévisible.

Prenons un exemple où notebook A appelle notebook Z avec une commande %run. Si un travail, exécuté pendant une opération Git, lance la version la plus récente de notebook A, mais que notebook Z n’a pas encore été mis à jour, alors la commande %run du notebook A risque de lancer l’ancienne version de notebook Z. Pendant l’opération Git, les états du notebook ne sont pas prévisibles et le travail peut échouer ou exécuter notebook A et notebook Z à partir de commits différents.

Pour éviter cette situation, utilisez plutôt des travaux basés sur Git (où la source est un fournisseur Git et non un chemin d’accès à l’espace de travail). Pour obtenir plus d’informations, consultez Utiliser du code source contrôlé par version dans une tâche Azure Databricks.

Ressources

Pour plus d’informations sur les fichiers d’espace de travail Databricks, consultez Que sont les fichiers d’espace de travail ?.