Azure Databricks limites et références des dossiers Git

Cette page couvre les limites de taille, les fonctionnalités prises en charge, les considérations de sécurité et le comportement CI/CD pour les dossiers Git Databricks. Pour connaître les limites générales des ressources Databricks, consultez les limites des ressources. Pour en savoir plus sur les types de ressources pris en charge dans les dossiers Git, consultez Types de ressources pris en charge dans 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, les limites suivantes s’appliquent :

• 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.
• Chaque opération Git prend en charge jusqu’à 2 Go de mémoire et 4 Go d’écritures de disque.
• Les fichiers d’espace de travail individuels ont des limites de taille distinctes. Consultez Limitations.

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

É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 ?.

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.

Réduire la taille du référentiel

Si votre référentiel dépasse les limites de taille en raison de fichiers volumineux, l’ajout de ces .gitignore fichiers ne réduit pas la taille du référentiel. Les fichiers déjà validés dans Git restent dans l’historique du référentiel, même lorsqu’ils sont ajoutés à .gitignore.

Pour réduire la taille du référentiel :

• Utilisez des outils Git tels que git filter-repo ou BFG Repo-Cleaner pour supprimer les fichiers volumineux de l’historique des validations. Cela réécrit l'historique et nécessite un push forcé vers votre référentiel distant.
• Clonez uniquement des répertoires spécifiques. Consultez Configurer le mode d’extraction éparse.
• Déplacez du code non lié vers des référentiels distincts.

Pour plus d’informations, consultez Removing sensitive data from a repository in the GitHub documentation.

Prise en charge de Monorepo

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. Le clonage d’un monorepo peut dépasser les limites de mémoire et de disque du dossier Git et ralentir les opérations Git. Si votre référentiel contient plusieurs projets, envisagez de le fractionner ou d’utiliser l’extraction éparse pour limiter les répertoires clonés. Consultez Configurer le mode d’extraction éparse.

Configuration

Toutes les fonctionnalités Git standard ne fonctionnent pas dans les dossiers Git, et le contenu est stocké différemment de celui d’un clone local. Les rubriques suivantes expliquent le fonctionnement du stockage, les serveurs pris en charge et le comportement des fonctionnalités telles .gitignore que les sous-modules.

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 Databricks Git prennent en charge GitHub Entreprise, Bitbucket Server, Azure DevOps Server et GitLab auto-gérés si le serveur est accessible à Internet. Consultez le serveur proxy Git pour les dossiers Git pour l’intégration locale.

Pour effectuer l'intégration à une instance Bitbucket Server, GitHub Enterprise Server ou GitLab auto-géré qui n'est pas accessible par Internet, contactez votre équipe de compte Azure Databricks.

Types de ressources pris en charge

Pour plus d’informations sur les types de ressources pris en charge, consultez Types de ressources pris en charge dans les dossiers Git.

Prise en charge des fichiers .gitignore

Les dossiers Git prennent en charge les fichiers .gitignore. 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à validé à .gitignore ne le supprime pas de l’historique Git et ne réduit pas la taille du dépôt. Pour supprimer des fichiers validés, consultez Réduire la taille du référentiel.

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).

prise en charge de Azure Data Factory

Azure Data Factory (ADF) prend en charge les dossiers Git.

Gestion de la source

Certaines opérations fonctionnent différemment dans les dossiers Git que dans un flux de travail Git standard, en particulier autour des notebooks et de la suppression de branche.

Tableaux de bord de bloc-notes et modifications de branche

Les notebooks Azure Databricks au format source ne stockent pas les informations du 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.

Prise en charge du fusionnement des branches

Les répertoires Git prennent en charge la fusion de branches. 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.

Précédence des dépendances Python

Python bibliothèques dans 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é des bibliothèques Python.

Sécurité, authentification et jetons

Azure Databricks stocke les informations d’identification Git dans le plan de contrôle, et non dans votre environnement local. Les rubriques suivantes expliquent comment le contenu du dossier Git est chiffré, comment les jetons sont stockés et audités, et comment procéder si vous rencontrez des problèmes d’authentification.

Problème avec une politique 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 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 d'autorisation avec des jetons Microsoft Entra ID

Si vous utilisez Microsoft Entra ID pour l’authentification avec 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 d’URL Git.

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.

GitHub stockage et accès aux jetons

• 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 journalise 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.

Signature de validation GPG

Les dossiers Git ne prennent pas en charge la signature GPG des validations.

Prise en charge SSH

Les dossiers Git prennent uniquement en charge HTTPS, et non SSH.

Erreurs d'interlocution 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 différente de Microsoft Entra ID que Azure Databricks, utilisez un jeton d’accès Azure DevOps. Consultez le jeton d’accès personnel.

CI/CD et MLOps

Si vous exécutez des travaux sur des fichiers dans un dossier Git, sachez comment les opérations Git peuvent affecter l’état du notebook et les expériences MLflow, de manière qui ne sont pas évidentes.

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 modifier le code source du bloc-notes, les dossiers Git devant remplacer le bloc-notes 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.

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.

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. Voir l'utilisation de Git avec Lakeflow Jobs.

Étapes suivantes

• Résoudre les erreurs de dossier Git
• Créer et gérer des dossiers Git
• Configurer l’intégration Git pour les dossiers Git