Partager via

Limites et références des répertoires Git de Databricks

Les sections suivantes spécifient des limites pour les dossiers Git Databricks et l’intégration Git. Pour plus d’informations générales, consultez Les limites des ressources.

Passer à :

Pour en savoir plus sur les types de ressources Databricks pris en charge dans les dossiers Git, consultez Quels types de ressources sont pris en charge par les dossiers Git ?.

Limites des fichiers et des référentiels

Azure Databricks n’applique pas de limite à la taille du référentiel. Toutefois :

  • La capacité des branches de travail est limitée à 1 Go.
  • Vous ne pouvez pas afficher les fichiers de plus de 10 Mo dans l’interface utilisateur Azure Databricks.
  • Les fichiers d’espace de travail individuels ont des limites de taille distinctes. Consultez Limitations.
  • Les branches locales peuvent rester dans le dossier Git associé pendant jusqu’à 30 jours après la suppression de la branche distante. Pour supprimer complètement une branche locale, supprimez le référentiel.

Databricks recommande de conserver le nombre total de ressources et de fichiers d’espace de travail inférieurs à 20 000.

Chaque opération Git est limitée à 2 Go de mémoire et 4 Go d’écritures de disque. Étant donné que les limites s’appliquent par opération, le clonage d’un référentiel de 5 Go échoue, mais le clonage d’un référentiel de 3 Go et l’ajout ultérieur de 2 Go réussit.

Si votre référentiel dépasse ces limites, vous pouvez recevoir une erreur ou un délai d’expiration pendant le clonage, bien que l’opération se termine toujours en arrière-plan.

Pour travailler avec des référentiels plus volumineux, essayez le checkout épars ou les commandes Git CLI.

Pour écrire des fichiers temporaires qui ne sont pas conservés après l’arrêt du cluster, utilisez $TEMPDIR. Cela évite de dépasser les limites de taille de branche et offre de meilleures performances que l’écriture dans un répertoire de travail (CWD) dans le système de fichiers de l’espace de travail. Consultez Où dois-je écrire des fichiers temporaires sur Azure Databricks ?.

Récupération des fichiers supprimés

La récupération des fichiers varie selon l’action. Certaines actions autorisent la récupération via le dossier Corbeille , tandis que d’autres ne le font pas. Les fichiers précédemment validés et envoyés à une branche distante peuvent être restaurés à l’aide de l’historique de validation Git du référentiel distant :

Action Le fichier est-il récupérable ?
Supprimer un fichier avec un navigateur d’espace de travail Oui, à partir du dossier Corbeille
Ignorer un nouveau fichier avec la boîte de dialogue du dossier Git Oui, à partir du dossier Corbeille
Ignorer un fichier modifié avec la boîte de dialogue Dossier Git Non, le fichier est parti
reset (dur) pour les modifications de fichier non validées Non, les modifications de fichier sont supprimées
reset (dur) pour les fichiers non validés, nouvellement créés Non, les modifications de fichier sont supprimées
Changer de branches avec la boîte de dialogue Dossier Git Oui, à partir du dépôt Git distant
Autres opérations Git, telles que la validation ou l’envoi (push) à partir de la boîte de dialogue de dossier Git Oui, à partir du dépôt Git distant
PATCH opérations de mise à jour /repos/id à partir de l’API Repos Oui, à partir du dépôt Git distant

Prise en charge de référentiel unique

Databricks recommande de ne pas créer de dossiers Git reposant sur des monorepos—c'est-à-dire des dépôts Git volumineux et à organisation unique contenant des milliers de fichiers dans de nombreux projets.

Configuration

Cette section traite du stockage de dossiers Git, de la prise en charge du serveur et des questions d’installation générales.

Stockage de contenu du référentiel

Azure Databricks clone temporairement le contenu du référentiel sur le disque dans le plan de contrôle. La base de données du plan de contrôle stocke les fichiers notebooks de la même manière que ceux de l’espace de travail principal. Des fichiers non-notebooks sont stockés sur un disque pendant au plus 30 jours.

Serveurs Git locaux et auto-hébergés

Les dossiers Git Databricks prennent en charge GitHub Enterprise, Bitbucket Server, Azure DevOps Server et GitLab en gestion autonome si le serveur est accessible via Internet. Consultez le serveur proxy Git pour les dossiers Git pour l’intégration locale.

Pour effectuer une intégration à un serveur Bitbucket, GitHub Enterprise Server ou une instance auto-managée GitLab qui n’est pas accessible à Internet, contactez votre équipe de compte Azure Databricks.

Types de ressources pris en charge

Pour plus d’informations sur les types d’artefacts pris en charge, consultez Quels types de ressources sont pris en charge par les dossiers Git ?.

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

Oui. Pour empêcher Git de suivre un fichier, ajoutez le nom de fichier (y compris l’extension) à un .gitignore fichier. Créez-en un ou utilisez un fichier existant cloné à partir de votre référentiel distant.

.gitignore fonctionne uniquement pour les fichiers non suivis. L’ajout d’un fichier déjà suivi à .gitignore n’empêche pas Git de le suivre.

Prise en charge des sous-modules Git

Les dossiers Git standard ne prennent pas en charge les sous-modules Git, mais les dossiers Git disposant d’un accès Git CLI peuvent les utiliser. Consultez Utiliser des commandes Git CLI (bêta).

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

Oui.

Gestion de la source

Cette section traite des branches, de la fusion et de la façon dont les dossiers Git gèrent les notebooks et les dépendances.

Tableaux de bord de notebooks et changements de branche

Les notebooks au format source Azure Databricks ne stockent pas d’informations de tableau de bord.

Pour conserver les tableaux de bord, remplacez le format .ipynb du notebook par (format Jupyter), qui prend en charge les définitions de tableau de bord et de visualisation par défaut. Pour conserver les données de visualisation, validez le notebook avec les résultats.

Consultez Gérer les validations de sortie de 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.

Suppression de branches

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

Priorité des dépendances Python

Les bibliothèques Python d’un dossier Git sont prioritaires sur les bibliothèques stockées ailleurs. Par exemple, si une bibliothèque est installée sur votre calcul Databricks et qu’une bibliothèque portant le même nom existe dans un dossier Git, la bibliothèque de dossiers Git est importée. Consultez Priorité de la bibliothèque Python.

Sécurité, authentification et jetons

Cette section traite des problèmes de chiffrement, de stockage de jetons et d’authentification avec les fournisseurs Git.

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

Vous pouvez obtenir une erreur « accès refusé » lors du clonage d’un référentiel si :

  • Votre espace de travail Azure Databricks utilise 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 les adresses IP Azure Databricks ou les utilisateurs.

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

Liste d'autorisation avec des jetons d'identification Microsoft Entra

Si vous utilisez l’ID Microsoft Entra pour l’authentification auprès d’Azure DevOps, la liste d’autorisation par défaut limite les URL Git à :

  • dev.azure.com
  • visualstudio.com

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

Chiffrement de dossiers Git

Azure Databricks chiffre le contenu du dossier Git à l’aide d’une clé par défaut. Les clés gérées par le client sont uniquement prises en charge pour le chiffrement des informations d’identification Git.

Stockage et accès des jetons GitHub

  • Le plan de contrôle Azure Databricks stocke les jetons d’authentification. Les employés peuvent uniquement y accéder via des informations d’identification temporaires auditées.
  • Azure Databricks enregistre la création et la suppression de jetons, mais pas l’utilisation. La journalisation des opérations Git vous permet d’auditer l’utilisation des jetons par l’application Azure Databricks.
  • GitHub Enterprise audite l’utilisation des jetons. D’autres services Git peuvent également proposer l’audit du serveur.

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

Non.

Les dossiers Git prennent-ils en charge SSH ?

Non. Les dossiers Git prennent uniquement en charge HTTPS.

Erreurs interlocataires Azure DevOps

Lorsque vous vous connectez à DevOps dans une location distincte, vous pouvez voir Unable to parse credentials from Azure Active Directory account. Si le projet Azure DevOps se trouve dans une location d’ID Microsoft Entra différente d’Azure Databricks, utilisez un jeton d’accès Azure DevOps. Consultez Se connecter à un dépôt Azure DevOps à l’aide d’un jeton.

CI/CD et MLOps

Cette section explique comment les opérations Git affectent l’état du notebook, les expériences MLflow et l’exécution des travaux.

Les modifications entrantes effacent l’état du bloc-notes

Les opérations Git qui modifient le code source du bloc-notes entraînent une perte d’état du bloc-notes, notamment les sorties de cellule, les commentaires, l’historique des versions et les widgets. Par exemple, git pull peut changer le code source du notebook, nécessitant que les dossiers Git Databricks écrasent le notebook existant. Les opérations telles que git commit, pushou la création d’une nouvelle branche n’affectent pas le code source et conservent l’état du notebook.

Important

Les expériences MLflow ne fonctionnent pas dans les dossiers Git avec DBR 14.x ou versions antérieures.

Expériences MLflow dans les dossiers Git

Il existe deux types d’expériences MLflow : un espace de travail et un bloc-notes. Consultez Organiser des exécutions de formation avec des expériences MLflow.

  • Expériences d’espace de travail : vous ne pouvez pas créer d’expériences MLflow d’espace de travail dans les dossiers Git. Log MLflow s’exécute sur une expérience créée dans un dossier d’espace de travail standard. Pour la collaboration multi-utilisateur, utilisez un dossier d’espace de travail partagé.

  • Expériences de notebooks : vous pouvez créer des expériences de notebooks dans un dossier Git de Databricks. Si vous enregistrez votre bloc-notes en tant que fichier .ipynb dans le contrôle de code source, MLflow journalise vers une expérience créée automatiquement. Le contrôle de code source ne vérifie pas l’expérience ou ses exécutions. Consultez Créer une expérience 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 Travaux Lakeflow avec du code source dans un référentiel distant sont stockées dans un stockage temporaire. Ces expériences persistent initialement après l'exécution du workflow, mais risquent d'être supprimées pendant le nettoyage planifié. Databricks recommande d’utiliser des expériences MLflow dans l'espace de travail avec Jobs et des sources Git distantes.

Avertissement

Le passage à une branche qui ne contient pas le notebook risque de perdre les données d’expérience MLflow associées. Cette perte devient permanente si vous n’accédez pas à la branche précédente dans les 30 jours.

Pour récupérer les données d’expérience manquantes avant l’expiration de 30 jours, restaurez le nom du bloc-notes d’origine, ouvrez le bloc-notes, puis cliquez sur l’icône Expérience dans le volet droit. Cela déclenche mlflow.get_experiment_by_name() et rétablit l’expérience et s’exécute. Après 30 jours, Azure Databricks purge les expériences MLflow orphelines pour la conformité RGPD.

Pour éviter la perte de données, évitez de renommer des notebooks dans un référentiel. Si vous renommez un bloc-notes, cliquez immédiatement sur l’icône d’expérience dans le volet droit.

Exécution de travaux pendant les opérations Git

Pendant une opération Git, certains notebooks peuvent être mis à jour alors que d’autres ne sont pas encore, provoquant un comportement imprévisible.

Par exemple, si notebook A appelle notebook Z en utilisant %run et qu'un travail commence pendant une opération Git, le travail peut exécuter le plus récent notebook A avec un notebook Z plus ancien. La tâche peut échouer ou exécuter des notebooks issus de différentes validations.

Pour éviter cela, configurez les tâches de travail pour utiliser votre fournisseur Git comme source au lieu d’un chemin d’accès à l’espace de travail. Consultez Utiliser Git avec des travaux.

Ressources

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

  • Last updated on