Aller au contenu principal
Dernière mise à jour le

Trigger des Jobs lorsque les modèles sont mis à jour

Utilisez des déclencheurs de mise à jour de modèle pour exécuter automatiquement un Job lorsqu'une modification de modèle se produit dans Unity Catalog. Cette fonctionnalité remplace la nécessité de planifications cron ou de clusters persistants pour suivre les mises à jour de modèle.

info

Bêta

Les déclencheurs de mise à jour de modèle sont en version bêta.

Les Trigger de mise à jour de modèle sont conçus pour deux personas principaux :

  • Les data scientists peuvent Trigger des Jobs lorsqu'une nouvelle version de modèle est prête ou lorsqu'un alias est défini, sur un seul modèle ou sur plusieurs modèles à la fois. Par exemple, vous pouvez exécuter des Jobs de validation, de test ou de promotion automatiquement chaque fois qu'un modèle qu'ils possèdent est modifié. Voir Exemple : Valider les modèles sur de nouvelles versions ou des alias.
  • Les administrateurs peuvent surveiller tous les modèles à travers un metastore entier (ou un schéma). Par exemple, les administrateurs peuvent auditer automatiquement chaque nouveau modèle à mesure qu'il est créé. Consultez Exemple : Auditer les modèles à travers un schéma ou un metastore.

Fonctionnement des Trigger de mise à jour de modèle​

Un Trigger de mise à jour de modèle surveille un périmètre dans Unity Catalog pour un événement de modèle et déclenche l'exécution d'un job lorsqu'un événement correspondant se produit. Lorsque vous configurez un Trigger de mise à jour de modèle, vous choisissez une **étendue** et une **condition**.

Les portées disponibles incluent :

  • Modèle : Un modèle enregistré unique.
  • Schéma : tous les modèles d'un schéma.
  • Metastore : Tous les modèles dans le metastore. Seul un administrateur du métastore peut configurer un Trigger à l'échelle du métastore.

La condition détermine le moment de Trigger une exécution :

  • Le modèle est créé : Un nouveau modèle enregistré est créé dans l'étendue.
  • La version du modèle est prête : Une nouvelle version du modèle est prête dans la portée.
  • L'alias du modèle est défini : Un alias spécifié est appliqué à une version de modèle. Vous pouvez spécifier jusqu'à 10 alias par Trigger, et le Trigger répond lorsque l'un d'eux est appliqué.

Les déclencheurs de mise à jour de modèle n'entraînent pas de coûts supplémentaires autres que les coûts des fournisseurs de cloud.

Mises à jour par batch​

Les Trigger de mise à jour du modèle interrogent les nouveaux événements environ une fois par minute. Les modifications détectées à chaque intervalle d'interrogation sont traitées par lot et transmises à la prochaine exécution de job comme paramètres de job. Consultez les paramètres de Job associés aux Trigger de mise à jour du modèle.

Une seule exécution de Job traite au maximum neuf mises à jour. Lorsque plus de neuf mises à jour sont en attente, le Trigger en traite neuf dans l'exécution actuelle et reporte le reste aux exécutions ultérieures, un batch par intervalle d'interrogation. Cela signifie que le trigger draine les mises à jour en attente à un rythme allant jusqu'à neuf par minute (environ 540 par heure).

De brèves augmentations au-delà de ce taux sont normales et se résolvent au cours des minutes suivantes. Si une portée produit des mises à jour plus rapidement que le trigger ne peut les traiter pendant une période prolongée, le trigger s'exécute à chaque intervalle sans rattraper son retard et finit par échouer et s'arrêter. Voir Volume élevé et soutenu d'événements.

Volume d'événements élevé et soutenu​

Un trigger de mise à jour de modèle fonctionne mieux pour les étendues où les mises à jour arrivent à ou en dessous de neuf par minute en moyenne.

Pour éviter un arriéré croissant, un Trigger qui s'exécute à chaque intervalle d'interrogation en continu pendant environ une heure échoue et s'arrête. L'échec est signalé sur le trigger. Le Trigger ne se récupère pas automatiquement, et aucune autre exécution ne start tant que vous ne le récupérez pas manuellement.

Pour récupérer le Trigger :

  1. Réduisez la fréquence des mises à jour afin qu'elle ne dépasse plus neuf par minute. Par exemple, réduisez la portée du trigger ou répartissez le monitoring sur plusieurs triggers, comme décrit dans les recommandations ci-dessous. Si vous ignorez cette étape, le trigger échouera à nouveau après la récupération.
  2. Resetez le Trigger en le mettant en pause, puis en le reprenant. La mise en pause efface l'état accumulé du Trigger afin qu'il reprenne à partir du point actuel. Utilisez la section **Planifications et Trigger** du volet **Détails du Job**, ou définissez pause_status PAUSED sur puis sur UNPAUSED avec l'API Job. Consultez Gérer un Trigger existant.

Les options avancées Minimum time between Trigger et Wait after last change contrôlent la fréquence de création des exécutions, mais elles ne modifient pas le nombre de mises à jour traitées par une exécution. Elles n'empêchent pas cette défaillance lorsque les mises à jour dépassent constamment neuf par minute.

Pour surveiller une portée à volume élevé de manière fiable :

  • Limitez la portée de chaque Trigger. Utilisez des Triggers au niveau du schéma ou du modèle plutôt qu'un seul Trigger au niveau du metastore, afin qu'une surcharge dans une zone n'arrête pas le monitoring de l'ensemble du metastore.
  • Divisez le monitoring entre plusieurs Trigger et Job afin que chaque Trigger surveille une portée à faible volume.
  • Gardez le job déclenché léger et utilisez une tâche Pour chaque pour traiter chaque mise à jour. Voir Traiter les mises à jour de modèle avec une tâche Pour chaque.
  • Pour un volume élevé et soutenu sur un vaste champ d’application, contactez l’équipe de votre compte Databricks pour discuter des options.

Avant de commencer​

Les éléments suivants sont requis pour utiliser les Triggers de mise à jour du modèle :

  • Le Workspace doit disposer de Unity Catalog activé.
  • Vous devez disposer du privilège EXECUTE sur le modèle ou le schéma cible que vous souhaitez que le Trigger surveille. Sans EXECUTE, les lectures et écritures vers ces modèles pourraient échouer.
  • Pour configurer un Trigger délimité par un metastore, vous devez être un administrateur de metastore. Vous devez également vous accorder la permission EXECUTE sur chaque catalogue actuel et futur dans le métastore afin que le Job puisse accéder à tout modèle dans Unity Catalog.

Ajouter un Trigger de mise à jour de modèle​

Pour ajouter un Trigger de mise à jour de modèle à un Job existant :

  1. Dans la barre latérale de votre workspace Databricks, cliquez sur Tâches & Pipelines .

  2. Dans la liste des jobs, cliquez sur le nom du job auquel vous souhaitez ajouter un trigger.

  3. Dans le volet Détails du Job à droite, cliquez sur Ajouter un trigger .

  4. Dans **Trigger type**, sélectionnez **Mise à jour du modèle**.

  5. Sous **Portée**, sélectionnez **Modèle**, **Schéma** ou **Metastore**, puis spécifiez le modèle ou le schéma à surveiller.

  6. Sous Condition , sélectionnez l'événement à Trigger :

    • Le modèle est créé
    • La version du modèle est prête.
    • L'alias du modèle est défini . Spécifiez jusqu'à 10 alias à surveiller. Le Trigger répond lorsque l'un des alias spécifiés est défini.

  7. (Facultatif) Configurez les options avancées :

    • Minimum time between Trigger in seconds : Le temps minimal à attendre avant de déclencher un Trigger après une exécution précédente. Les modèles mis à jour pendant cette période ne Trigger une exécution qu'après l'expiration du délai d'attente. Utilisez ce paramètre pour contrôler la fréquence de création des exécutions.
    • Délai d'attente après la dernière modification en secondes : Le temps d'attente pour Trigger une exécution après une mise à jour du modèle. Une autre mise à jour du modèle pendant cette période Reset le minuteur. Ce paramètre peut être utilisé lorsque les mises à jour du modèle arrivent par batchs, et que le batch entier doit être traité après l'arrivée de toutes les mises à jour.

  8. Pour valider la configuration, cliquez sur Tester le trigger . S'il n'y a pas d'erreurs, le bouton affiche Succès .

  9. Cliquez sur Enregistrer .

Après avoir enregistré le Trigger, attendez environ une minute pour que le Trigger s'initialise. Le message « The Trigger will be evaluated soon » indique que l'initialisation est en cours. Après l'initialisation, tout événement de modèle correspondant dans la portée Trigger une exécution de Job.

Pour modifier, suspendre ou supprimer ce Trigger ultérieurement, utilisez la section Plannings & Triggers du volet Détails du Job . Consultez Gérer un Trigger existant.

remarque

Vous pouvez également configurer des déclencheurs de mise à jour de modèle à partir de l'API Jobs. Consultez Configurer un Trigger de mise à jour de modèle avec l'API Jobs.

Exemple : valider les modèles sur de nouvelles versions ou des alias​

Pour exécuter un Job de validation, de test ou de promotion lorsqu'un modèle change, configurez un Trigger avec l'étendue Modèle et la condition La version du modèle est prête ou L'alias du modèle est défini . Pour les changements d’alias, spécifiez les alias à surveiller, tels que prod et staging. Pour surveiller plusieurs modèles à la fois, utilisez plutôt l’étendue schéma . Après l’initialisation du Trigger, un changement correspondant à un modèle surveillé déclenche une exécution de Job.

Exemple : auditer les modèles dans un schéma ou un métastore​

Pour auditer chaque modèle créé dans un schéma ou un metastore, configurez un Trigger avec l'étendue Schema ou Metastore et la condition Model is created . Une fois le trigger initialisé, tout modèle créé dans le périmètre déclenche une exécution de Job qui peut enregistrer ou valider la modification.

Paramètres du Job associés aux Trigger de mise à jour de modèle​

Lorsqu'un trigger de mise à jour de modèle se déclenche, les informations sur les changements ayant déclenché l'exécution sont disponibles pour l'exécution du job via la référence de valeur dynamique {{job.trigger.model.updates}}. La valeur est une liste JSON des mises à jour du modèle dans le batch :

JSON
[
  {
    "full_name": "model.full.name1",
    "version": 123,
    "alias_name": "prod"
  }
]

Les champs sont renseignés comme suit :

  • full_name: Toujours renseigné avec le nom du modèle qui a été créé ou mis à jour.
  • version: Rempli pour les événements **La version du modèle est prête** avec la version qui est devenue prête, et pour les événements **L'alias du modèle est défini** avec la version dont l'alias a été défini.
  • alias_name: Renseigné uniquement pour les événements L’alias du modèle est défini avec le nom de l’alias qui a été défini.

Par exemple, la valeur du parameter pour chaque condition est la suivante :

  • Modèle créé :

    JSON
    [{ "full_name": "model.number.one" }, { "full_name": "model.number.two" }]

  • Version de modèle est prête :

    JSON
    [
      { "full_name": "model.number.one", "version": 7 },
      { "full_name": "model.number.two", "version": 3 }
    ]

  • L'alias de modèle est défini :

    JSON
    [
      { "full_name": "model.number.one", "version": 7, "alias_name": "prod" },
      { "full_name": "model.number.two", "version": 3, "alias_name": "staging" }
    ]

Pour rendre les mises à jour disponibles pour une tâche, ajoutez un paramètre de Job dont la valeur est {{job.trigger.model.updates}}. Pour ajouter un paramètre, cliquez sur Modifier les paramètres dans le panneau latéral du job, puis définissez la valeur du paramètre sur {{job.trigger.model.updates}}. Pour plus d’informations sur les paramètres de job, consultez Paramétrer les jobs.

Le notebook suivant lit un paramètre nommé events et traite les mises à jour de modèle transmises à l'exécution :

Python
import json

json_list = dbutils.widgets.get("events")
data = json.loads(json_list)

for item in data:
    print(f"Full Name: {item['full_name']}, Version: {item.get('version')}, Alias Name: {item.get('alias_name')}")

Traiter les mises à jour de modèle avec une tâche For each​

Une tâche For each exécute une tâche imbriquée une fois par élément dans une liste. Pour les Trigger de mise à jour de modèle, vous pouvez exécuter une itération par élément dans {{job.trigger.model.updates}}:

  1. Configurez la tâche **Pour chaque** pour {{job.trigger.model.updates}} qu'elle prenne comme entrée.
  2. Configurez la tâche imbriquée pour lire les valeurs de chaque entrée fournies par l'itération.
  3. Les valeurs de chaque mise à jour sont disponibles en tant que parameters de widget pour la tâche imbriquée.

Le Notebook suivant lit les valeurs par itération dans une tâche imbriquée :

Python
full_name = dbutils.widgets.get("full_name")
version = dbutils.widgets.get("version")
alias_name = dbutils.widgets.get("alias_name")

print(f"Full Name: {full_name}, Version: {version}, Alias Name: {alias_name}")

Configurez un Trigger de mise à jour de modèle avec l'API Jobs​

Vous pouvez configurer un Trigger de mise à jour de modèle en ajoutant un objet trigger à une Opération jobs/create, jobs/update, ou jobs/reset. L'exemple suivant utilise jobs/update:

JSON
{
  "job_id": 574587036927544,
  "new_settings": {
    "trigger": {
      "pause_status": "UNPAUSED",
      "model": {
        "securable_name": "main.default",
        "condition": "MODEL_ALIAS_SET",
        "aliases": ["alias1", "alias2"],
        "min_time_between_triggers_seconds": 3600,
        "wait_after_last_change_seconds": 120
      }
    },
    "parameters": [
      {
        "default": "{{job.trigger.model.updates}}",
        "name": "events"
      }
    ]
  }
}

Pour l'objet Trigger model :

  • securable_name: Le schéma ou le modèle à surveiller. Laissez vide ou omettez-le pour surveiller l'intégralité du metastore.
  • condition: L’un de MODEL_CREATED, MODEL_VERSION_READY ou MODEL_ALIAS_SET.
  • aliases: Les alias à surveiller. S'applique uniquement à la condition MODEL_ALIAS_SET.

Recevoir des notifications des Trigger de mise à jour de modèle ayant échoué​

Pour être informé si un Trigger de mise à jour de modèle échoue à l'évaluation, configurez les notifications par e-mail ou vers une destination système en cas d'échec du Job. Voir Ajouter des notifications à un job.

Limitations​

Les Trigger de mise à jour de modèle ont les limitations suivantes :

  • Un maximum de 100 Trigger de mise à jour de modèle peuvent être configurés par Workspace. Cette limite peut être augmentée au cas par cas.
  • Une seule exécution de Job traite au maximum neuf mises à jour de modèle. Les mises à jour supplémentaires en attente sont traitées lors des exécutions ultérieures, jusqu'à neuf par minute. Voir les mises à jour par batch.
  • Chaque Trigger de mise à jour de modèle peut surveiller jusqu'à 10 alias.
  • Si un Trigger s'exécute en continu à chaque intervalle d'interrogation pendant environ une heure, il échoue avec une erreur et cesse de déclencher des exécutions. Il ne se rétablit pas automatiquement : vous devez réduire le taux de mises à jour et ensuite Reset le Trigger en le mettant en pause et en le réactivant. Cela se produit lorsqu'une étendue produit des mises à jour plus rapidement que le Trigger ne peut les traiter pendant une période prolongée. Consulter Volume d'événements élevé et soutenu.
  • Pour configurer un Trigger délimité par le metastore, vous devez être un administrateur du metastore et vous accorder le privilège EXECUTE sur chaque catalogue actuel et futur dans Unity Catalog pour que le Job puisse accéder à un modèle quelconque.

FAQ​

Quand faut-il utiliser les Job de déploiement plutôt que les Trigger de mise à jour de modèle ?​

Utilisez les Trigger de mise à jour de modèle lorsque vous avez besoin de :

  • Surveiller les événements de création de modèles ou les modifications d'alias.
  • Surveiller les événements à une portée plus large qu'un simple modèle, comme un schéma ou un metastore.
  • Surveillez de nombreux modèles avec un seul Trigger, au lieu de configurer un Job distinct pour chaque modèle.

Utilisez des jobs de déploiement lorsque vous avez besoin d'un couplage d'interface utilisateur étroit et de logs d'activité concernant la relation entre la création de versions de modèles et l'exécution de jobs.

Sur cette page