Utiliser Git avec les Lakeflow Jobs
Les tâches Job peuvent extraire le code source directement depuis un repository Git distant.
Les types de tâches suivants prennent en charge les repository Git distants :
- Notebooks
- Scripts Python
- Fichiers SQL
- projets dbt (data build tool)
Toutes les tâches d'un job doivent référencer le même commit dans le repository distant. Lorsqu'une exécution de Job commence, Databricks prend un instantané de la Branch ou du commit spécifié, afin que toutes les tâches de cette exécution utilisent la même version du code.
Lorsque vous consultez l'historique d'exécution d'une tâche qui exécute du code stocké dans un dépôt Git distant, le volet Détails de l'exécution de la tâche inclut les détails Git, y compris le SHA de commit associé à l'exécution. Consultez Afficher l'historique d'exécution des tâches.
Les tâches configurées pour utiliser un repository Git distant ne peuvent pas écrire dans les fichiers du Workspace. Ces tâches doivent écrire des données temporaires dans un stockage éphémère attaché au nœud du Driver et des données persistantes dans un volume ou une table.
Source du repository Git/dossiers Git
Cette page aborde les tâches qui peuvent extraire le code source directement d’un repository Git distant. Les Workspaces prennent également en charge une fonctionnalité appelée dossiers Git, où un dossier de votre Workspace est synchronisé avec un repository Git. Une tâche peut utiliser un dossier Git comme source. Cependant, vous devez gérer la synchronisation avec le repository. L'utilisation d'un repository Git distant tel que décrit ici extrait automatiquement la nouvelle source, si disponible, au moment de l'exécution du Job.
Databricks recommande de référencer les chemins du workspace dans les dossiers Git uniquement pour une itération rapide et des tests pendant le développement. Pour les jobs de staging et de production, configurez les tâches pour qu'elles fassent référence à un repository Git distant à la place.
Configurer un fournisseur Git pour un Job
L'interface utilisateur des jobs comporte une boîte de dialogue pour configurer un repository Git distant. Cette boîte de dialogue est accessible depuis le volet **Détails du Job** sous l'en-tête **Git**, ou dans toute tâche configurée pour utiliser un **fournisseur Git**. Pour accéder à la boîte de dialogue, cliquez sur Ajouter les paramètres Git dans le volet Détails du Job .
Dans la boîte de dialogue **Git** (intitulée **informations Git** si elle est accessible lors de la configuration de la tâche), saisissez les détails suivants :
- L' URL du repository Git .
- Sélectionnez votre fournisseur Git dans la liste déroulante.
- Dans le champ **Référence Git**, saisissez l'identifiant d'une branch, d'un tag ou d'un commit qui correspond à la version du code source que vous souhaitez exécuter.
- Sélectionnez une **Branch**, un **tag** ou un **commit** dans la liste déroulante.
Vous ne devez spécifier qu'un seul des éléments suivants :
- branch : nom de la branch, par exemple,
main. - tag : le nom du tag, par exemple
release-1.0.0. - **commit** : Le hachage d'un commit spécifique, par
e0056d01exemple,.
La boîte de dialogue peut vous inviter avec les éléments suivants : Les identifiants Git pour ce compte sont manquants. Ajouter des identifiants . Vous devez configurer un repository Git distant avant de l'utiliser comme référence. Voir Configurer l'intégration Git pour les dossiers Git.
Lorsque vous consultez l'historique d'exécution d'une tâche qui exécute du code stocké dans un dépôt Git distant, le volet Détails de l'exécution de la tâche inclut les détails Git, y compris le SHA de commit associé à l'exécution. Consultez Afficher l'historique d'exécution des tâches.
Exécuter un job Git en tant que rôle
Aperçu
L'exécution d'un job en tant que rôle nécessite le contrôle d'accès basé sur les rôles (RBAC), qui est en préversion publique.
Si votre Workspace utilise RBAC, vous pouvez définir l'identité **Exécuter en tant que** d'un Job sur un groupe (rôle). Le Job clone ensuite son repository Git en utilisant les informations d'identification Git du rôle, donc un responsable doit d'abord configurer ces informations d'identification, sinon le Job échouera à cloner. Pour définir l'option **Exécuter en tant que** d'un Job sur un groupe, consultez Définir l'exécution en tant que groupe.
Pour corriger un Job qui échoue à cause d'un problème de code, utilisez l'une des approches d'authoring sur le repository et la Branch du Job. Assumez le rôle pour reproduire et corriger le problème sur les données du rôle, commit la correction, puis relancez le Job.
Récupération fragmentée pour les grands repository
Pour les grands repositories, vous pouvez utiliser la récupération fragmentée pour importer uniquement des répertoires spécifiques plutôt que le repository complet. L'extraction sparse réduit le temps d'extraction et l'utilisation des ressources par exécution de job.
Cependant, une configuration incorrecte peut entraîner une fragmentation du cache, ce qui dégrade les temps d'exécution dans l'ensemble de votre workspace. Cette section décrit les compromis et les problèmes qui peuvent survenir lors de l'utilisation de la récupération fragmentée.
Comment Databricks met en cache les extractions de repository
Databricks met en cache chaque extraction Git en fonction de quatre valeurs :
- Espace de travail
- URL du référentiel
- Hachage de commit exact
- Empreinte du modèle de récupération fragmentée (l'ensemble exact des chemins de dossiers)
Toute exécution de job qui correspond aux quatre critères réutilise une entrée du cache, qui reste valide pendant une semaine au maximum. Par exemple, si vous avez 3 jobs différents et qu'ils ont tous les mêmes critères, ils utilisent le même cache du repository jusqu'à ce qu'il y ait un nouveau commit (ou après 1 semaine).
Chaque modèle unique de récupération fragmentée crée une empreinte digitale distincte, et donc une entrée de cache distincte. Si 20 utilisateurs ajoutent chacun un dossier personnalisé à leur modèle, le système crée 20 clés de cache distinctes et importe l'arborescence du dossier partagé 20 fois, ce qui multiplie la charge sur votre workspace. La création d'un seul modèle de paiement fragmenté qui comprend l'ensemble de leurs 20 dossiers (par exemple, est un dossier parent), permet à un seul cache de fonctionner plus souvent et d'avoir de meilleures performances dans vos jobs. Le compromis est un nombre plus important de fichiers dans votre extraction.
Décidez d'utiliser le mode de récupération fragmentée
N'activez le sparse checkout que si votre cas d'utilisation répond aux deux critères suivants :
- Taille : votre repository est volumineux (par exemple, il dépasse 2 500 fichiers).
- Ciblage stable : La Branch cible est rarement mise à jour (par exemple, environ un commit par heure ou moins). Évitez les Branches qui changent rapidement en raison de flux de travail CI/CD automatisés.
Si vous utilisez le sparse checkout, votre organisation devrait également adopter l’une ou les deux stratégies de modèle suivantes :
- Standardisation : Utilisez trois modèles de paiement partagés ou moins au sein de l'organisation afin de maximiser les accès au cache.
- Micro-ciblage : Structurez les modèles afin que chacun cible un petit nombre de fichiers. Pour des performances optimales, ciblez moins de 200 fichiers.
Ceux-ci peuvent aider à minimiser votre taux d'importation.
Calculez votre taux d'importation
Avant d’activer Sparse Checkout, estimez votre taux d’importation projeté de Files Per Hour . Les limites s'appliquent au niveau du Workspace à travers tous les Jobs et utilisateurs.
Fichiers par heure = Job Runs par heure × Taux d'échecs de cache × Fichiers importés par échec
Facteur | Ce qui le motive |
|---|---|
Exécutions de Job par heure | Fréquence des Trigger pour tous les utilisateurs. |
Taux d'échec du cache | Fréquence des commits sur la Branch cible et nombre de motifs éparses uniques. |
Fichiers importés par manquement | Taille totale du repository ou taille du sous-ensemble de récupération fragmentée. |
Exemple : 180 exécutions/heure × 10 % taux de perte × 6 000 fichiers/perte = 108 000 fichiers/heure
Comparez votre résultat par rapport à ces seuils :
Fichiers importés par heure | Impact attendu sur Workspace |
|---|---|
Inférieur à 150 000 | Opération normale |
De 150 000 à 300 000 | Performances dégradées. Certains Jobs peuvent subir des retards ou des échecs. |
Plus de 300 000 | Les jobs ne se terminent pas de manière fiable. |
Bonnes pratiques
Standardiser les modèles
- Faites : publiez trois modèles fragmentés approuvés ou moins par repository. Les modèles partagés consolident la charge et optimisent les accès au cache.
- Ne pas : Autoriser les modèles personnalisés par équipe. Même un dossier supplémentaire crée une nouvelle entrée de cache et Trigger une réimportation complète.
Gérer la rotation des commits
- Faites : Orientez les jobs vers une branch de publication stable. Batch Merge dans les fenêtres de publication planifiées afin que plusieurs exécutions partagent le même commit mis en cache.
- Ne pas : utiliser des vérifications éparses avec des branches fréquemment mises à jour comme
masteroumain. Étant donné que le cache est basé sur le hachage de commit exact, chaque nouveau commit invalide le cache et provoque une réimportation complète pour chaque exécution de Job.
Gérer la charge
- À faire : Supprimez les fichiers binaires volumineux, les artefacts générés et les fichiers de données du contrôle de code source afin de réduire la taille du repository inconditionnellement.
- Ne laissez pas : des Jobs redondants s'exécuter à haute fréquence. Diminuez la fréquence de Trigger pour les Jobs qui ne nécessitent pas d'exécution continue, échelonnez les planifications ou consolidez les Jobs qui partagent le même paiement.
Gérer la rotation des commits avec une release branch
Lorsque les Jobs ciblent une Branch en évolution rapide comme master ou main, le hachage de commit change fréquemment, ce qui entraîne des échecs de cache à presque chaque exécution. L'utilisation d'une Branch de publication dédiée qui se met à jour selon un calendrier fixe améliore les taux de réussite du cache.
En dirigeant tous les jobs vers une Branch de publication horaire, toutes les exécutions de cette heure se résolvent au même commit hash et partagent la même entrée de cache.
Pour configurer une Branch de publication :
- Créez une Branch à long terme (par exemple,
release-candidate) dans votre repository Git. - Automatisez la mise à jour de cette Branch pour qu’elle corresponde à
masterselon un calendrier fixe, par exemple, au début de chaque heure. - Configurez vos jobs basées sur Git pour utiliser
release-candidatecomme référence Git cible.
Examinez ces compromis avant de les mettre en œuvre :
Considération | Description |
|---|---|
Délai de commit | Les jobs s'exécutent par rapport au code avec un décalage d'une heure au maximum par rapport à |
Fenêtre d'échec | Si le Job de coupe de la version échoue, la Branch n'est pas mise à jour pour cette heure et les Jobs continuent de s'exécuter par rapport au commit précédent. Databricks recommande de configurer des alertes sur le Job coupé. |
Exemple : automatiser avec GitHub Actions
Le workflow GitHub Actions suivant automatise la création d’une Branch de release horaire.
Étape 1 : Commit un fichier .github/workflows/cut-release-branch.yml dans votre repository :
name: Cut Hourly Release Candidate
on:
schedule:
- cron: '0 * * * *'
workflow_dispatch:
jobs:
update-branch:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- name: Checkout main branch
uses: actions/checkout@v4
with:
ref: main
fetch-depth: 0
- name: Update release-candidate branch
run: |
git push origin HEAD:release-candidate --force
Étape 2 : manuellement Trigger l’action GitHub Actions pour vérifier que la Branch release-candidate est créée.
Étape 3 : Mettez à jour vos Jobs existants pour utiliser release-candidate comme référence Git cible.
Activez la récupération fragmentée à l'aide de l'API Jobs
Pour activer le checkout épars, incluez un bloc sparse_checkout dans git_source lors de la création ou de la mise à jour d'un Job :
{
"git_source": {
"git_url": "https://github.com/example/my-repo",
"git_provider": "gitHub",
"git_branch": "release-candidate",
"sparse_checkout": {
"patterns": ["src/models", "src/utils"]
}
}
}
Chaque chaîne de caractères dans patterns est un chemin de répertoire relatif à la racine du repository. Tous les fichiers de chaque répertoire spécifié sont inclus dans l'extraction.