Aller au contenu principal
Dernière mise à jour le

Limites et référence des dossiers Git Databricks

Cette page traite des limites de taille, des fonctionnalités prises en charge, des considérations de sécurité et du comportement CI/CD des dossiers Git Databricks. Pour les limites générales des ressources Databricks, consultez Limites de ressources. Pour en savoir plus sur les types d'assets pris en charge dans les dossiers Git, consultez Types d'assets pris en charge dans les dossiers Git.

Limites des fichiers et des dépôts​

Databricks n'impose pas de limite sur la taille d'un repository. Cependant, les limites suivantes s'appliquent :

  • Les branches de travail sont limitées à 1 Go.
  • Vous ne pouvez pas afficher les fichiers de plus de 10 Mo dans l'interface utilisateur Databricks.
  • Chaque opération Git prend en charge jusqu'à 2 Go de mémoire et 4 Go d'écritures sur disque.
  • Les fichiers de workspace individuels ont des limites de taille distinctes. Consulter Limitations.

Databricks recommande de maintenir le nombre total d'actifs et de fichiers du workspace inférieur à 20 000.

Étant donné que les limites s'appliquent par opération, le clonage d'un repository de 5 Go échoue, mais le clonage d'un repository de 3 Go suivi de l'ajout de 2 Go réussit. Si votre repository dépasse ces limites, vous pourriez recevoir une erreur ou un délai d'expiration lors du clonage, bien que l'opération puisse toujours s'effectuer en arrière-plan.

Pour travailler avec des repositories plus volumineux, essayez le checkout sparse ou les commandes Git CLI. Pour écrire des fichiers temporaires qui ne persistent pas après l'arrêt du cluster, utilisez $TEMPDIR. Cela évite de dépasser les limites de taille de branch et offre de meilleures performances que l'écriture dans un répertoire de travail (CWD) dans le système de fichiers du workspace. Voir Où dois-je écrire les fichiers temporaires sur Databricks ?.

Les Branch locales peuvent rester dans le dossier Git associé pendant un maximum de 30 jours après la suppression de la Branch distante. Pour supprimer entièrement une Branch locale, supprimez le repository.

Réduire la taille du repository​

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

Pour réduire la taille du repository :

  • Utilisez des outils Git comme git filter-repo ou BFG Repo-Cleaner pour supprimer les fichiers volumineux de l'historique des commits. Cela réécrit l'historique et nécessite de forcer le push vers votre repository distant.
  • Cloner uniquement des répertoires spécifiques. Consultez Configurer le mode de récupération fragmentée.
  • Déplacez le code non lié dans des repositories séparés.

Pour en savoir plus, consultez Removing sensitive data from a repository dans la documentation GitHub.

Prise en charge du monorepo​

Databricks déconseille la création de dossiers Git basés sur des *monorepos* — des repository Git volumineux, appartenant à une seule organisation et contenant des milliers de fichiers répartis sur de nombreux projets. Le clonage d'un monorepo peut dépasser les limites de mémoire et de disque d'un dossier Git et ralentir les opérations Git. Si votre repository contient plusieurs projets, vous pouvez envisager de le diviser ou d'utiliser le mode de récupération fragmentée pour limiter les répertoires clonés. Consulter Configurer le mode de récupération fragmentée.

Configuration​

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

Stockage de contenu du repository​

Databricks clone temporairement le contenu des repository sur un disque dans le plan de contrôle. La base de données du plan de contrôle stocke les fichiers Notebook comme ceux du Workspace principal. Les fichiers non Notebook sont stockés sur le disque pendant 30 jours maximum.

Serveurs Git on-premise et auto-hébergés​

Les dossiers Git Databricks prennent en charge GitHub Enterprise, Bitbucket Server, Azure DevOps Server et GitLab Self-managed si le serveur est accessible via Internet. Consultez Serveur proxy Git pour les dossiers Git pour l'intégration on-premise.

Pour s'intégrer à une instance autogérée Bitbucket Server, GitHub Enterprise Server ou GitLab qui n'est pas accessible sur internet, veuillez contacter votre équipe de compte Databricks.

Types d'asset pris en charge​

Pour plus de détails sur les types d'actifs pris en charge, consultez la page Types d'actifs 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 fichier .gitignore. Créez-en un ou utilisez un fichier existant cloné depuis votre repository 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 ni ne réduit la taille du repository. Pour supprimer les fichiers validés, consultez la page Réduire la taille du repository.

Prise en charge des sous-modules Git​

Les dossiers Git standard ne prennent pas en charge les sous-modules Git, mais les dossiers Git avec accès CLI Git peuvent les utiliser. Voir Utiliser les commandes CLI Git (Bêta).

Gestion des sources​

Quelques opérations fonctionnent différemment dans les dossiers Git que dans un workflow Git standard, notamment en ce qui concerne les notebooks et la suppression de branch.

Tableaux de bord Notebook et modifications de Branch​

Les Notebooks au format source Databricks ne stockent pas les informations de tableau de bord.

Pour préserver les tableaux de bord, modifiez le format du notebook en .ipynb (format Jupyter), qui prend en charge les définitions de tableau de bord et de visualisation par default. Pour préserver les données de visualisation, commit le notebook avec les sorties.

Voir Gérer les commits des sorties de Notebook IPYNB.

Prise en charge de la fusion de Branch​

Les dossiers Git prennent en charge la fusion des Branch. Vous pouvez également créer une pull request et Merge via votre fournisseur Git.

Suppression de branches​

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

Priorité des dépendances Python​

Les bibliothèques Python dans un dossier Git prévalent sur les bibliothèques stockées ailleurs. Par exemple, si une bibliothèque est installée sur votre compute Databricks et qu’une bibliothèque portant le même nom existe dans un dossier Git, la bibliothèque du dossier Git est importée. Veuillez consulter la page Précédence des bibliothèques Python.

Sécurité, authentification et jetons​

Databricks stocke les identifiants Git dans le plan de contrôle, et non dans votre environnement local. Les rubriques suivantes décrivent comment le contenu des dossiers Git est chiffré, comment les jetons sont stockés et audités, et ce qu'il faut faire si vous rencontrez des problèmes d'authentification.

Chiffrement du dossier Git​

Databricks chiffre le contenu des dossiers Git à l'aide d'une clé default. Les clés gérées par le client ne sont prises en charge que pour le chiffrement des identifiants Git.

Stockage et accès des jetons GitHub​

  • Le plan de contrôle Databricks stocke les jetons d'authentification. Les employés ne peuvent y accéder que via des identifiants temporaires audités.
  • Databricks Logs la création et la suppression de jetons, mais pas leur utilisation. La journalisation des opérations Git vous permet d'auditer l'utilisation des jetons par l'application Databricks.
  • GitHub Enterprise audite l'utilisation des jetons. D'autres services Git pourraient également proposer l'audit de serveur.

Signature de commit GPG​

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

Support SSH​

Les dossiers Git ne prennent en charge que HTTPS, pas SSH.

CI/CD et MLOps​

Si vous exécutez des Jobs sur des fichiers dans un dossier Git, soyez conscient de la manière dont les opérations Git peuvent affecter l'état du notebook et les expérimentations MLflow de manière qui pourrait ne pas être évidente.

Les modifications entrantes effacent l'état du notebook​

Les Opérations Git qui modifient le code source du Notebook entraînent une perte de l'état du Notebook, y compris les sorties de cellule, les commentaires, l'historique des versions et les widgets. Par exemple, git pull peut modifier le code source du Notebook, nécessitant que les dossiers Git écrasent le Notebook existant. Les Opérations comme git commit, push, ou la création d'une nouvelle Branch n'affectent pas le code source et préservent l'état du Notebook.

important

Les expérimentations MLflow ne fonctionnent pas dans les dossiers Git avec Databricks Runtime 14.x ou versions antérieures.

Experimentations MLflow dans les dossiers Git​

Il existe deux types d’expérimentations MLflow : Workspace et Notebook . Voir Organiser les exécutions d’entraînement avec les expérimentations MLflow.

  • Expérimentations Workspace : vous ne pouvez pas créer d'expérimentations MLflow Workspace dans les dossiers Git. Consignez les exécutions MLflow dans une expérimentation créée dans un dossier Workspace ordinaire. Pour la collaboration multi-utilisateurs, utilisez un dossier de Workspace partagé.

  • Expérimentations de Notebook : Vous pouvez créer des expérimentations de Notebook dans un dossier Git Databricks. Si vous enregistrez votre Notebook dans le contrôle de source en tant que fichier .ipynb, les exécutions MLflow sont enregistrées dans une Experimentation automatiquement créée. Le contrôle de code source n'archive pas l'Experimentation ou ses exécutions. Consultez Créer une experimentation Notebook.

Éviter la perte de données dans les expérimentations MLflow​

Les expérimentations MLflow des Notebooks créées à l'aide de Lakeflow Jobs avec le code source dans un repository distant sont stockées dans un stockage temporaire. Ces expérimentations persistent initialement après l'exécution du workflow, mais risquent d'être supprimées lors du nettoyage planifié. Databricks recommande d'utiliser les expérimentations MLflow du Workspace avec des Jobs et des sources Git distantes.

attention

Passer à une branch qui ne contient pas le notebook risque d'entraîner la perte des données d'Expérimentation MLflow associées. Cette perte devient permanente si vous ne visitez pas la branch précédente dans les 30 jours.

Pour récupérer les données d'Experimentation manquantes avant l'expiration de 30 jours, restaurez le nom d'origine du Notebook, ouvrez le Notebook, et cliquez sur Icône d'expérimentation dans le volet droit. Cela déclenche mlflow.get_experiment_by_name() et récupère l'expérimentation et les exécutions. Après 30 jours, Databricks supprime les expérimentations MLflow orphelines pour la conformité GDPR.

Pour éviter la perte de données, évitez de renommer les notebooks dans un repository. Si vous renommez un notebook, cliquez immédiatement sur l'icône d'expérimentation dans le volet de droite.

Exécution de Jobs pendant les Opérations Git​

Lors d'une Opération Git, certains Notebooks peuvent être mis à jour tandis que d'autres ne le sont pas encore, ce qui entraîne un comportement imprévisible.

Par exemple, si notebook A appelle notebook Z en utilisant %run et qu'un Job démarre pendant une opération Git, le Job pourrait exécuter la dernière version de notebook A avec une version plus ancienne de notebook Z. Le job peut échouer ou exécuter des notebooks à partir de différents commits.

Pour éviter cela, configurez les tâches de Job afin qu'elles utilisent votre fournisseur Git comme source plutôt qu'un chemin de Workspace. Consultez Utiliser Git avec les Lakeflow Jobs.

Étapes suivantes​

Sur cette page