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.

Un batch ne contient pas un nombre fixe de mises à jour. Chaque exécution comporte autant de mises à jour que le permet la limite de 10 000 caractères pour une valeur de paramètre de job. Le trigger ajoute les mises à jour au batch une par une et s’arrête avant la mise à jour qui dépasserait la limite ; le nombre dépend donc de la longueur de chaque mise à jour sérialisée.

La valeur du paramètre est au format JSON compact : une liste d'objets entre crochets séparés par des virgules, où chaque objet répertorie le nom complet du modèle, plus une version pour Model version is ready , ainsi qu'une version et un nom d'alias pour Model alias is set . Ces noms consomment la limite ; des noms de modèle et d'alias plus courts laissent donc de la place pour davantage de mises à jour à chaque exécution.

Par exemple, une mise à jour L’alias de modèle est défini pour un modèle nommé main.ml_models.fraud_detection à la version 123 avec l’alias champion se sérialise en 84 caractères :

JSON
{"full_name":"main.ml_models.fraud_detection","version":123,"alias_name":"champion"}

Chaque mise à jour après la première coûte également un caractère pour la virgule qui la sépare de la mise à jour précédente, et les crochets englobants en coûtent deux. Le nombre de mises à jour pouvant être incluses est donc le compte le plus élevé n pour lequel 2 + 84n + (n - 1) reste inférieur à 10 000, soit 117 mises à jour pour un total de 9 946 caractères.

En répétant ce calcul pour chaque condition, en utilisant le même nom de modèle et, lorsque la condition les inclut, une version à trois chiffres et l'alias champion:

État	Caractères par mise à jour	Mises à jour par exécution
Le modèle est créé	46	212
La version du modèle est prête.	60	163
L’alias de modèle est défini	84	117

Des noms plus longs réduisent ces nombres. Avec un nom de modèle de 200 caractères, une exécution comporte 46 mises à jour pour Le modèle est créé , 43 pour La version du modèle est prête et 39 pour L'alias du modèle est défini . Le remplacement de l'alias court par un alias de 50 caractères réduit le nombre de mises à jour pour L'alias du modèle est défini de 117 à 78.

Lorsque le nombre de mises à jour en attente dépasse la capacité d'une seule exécution, le Trigger reporte le reste sur les exécutions ultérieures, à raison d'un batch par intervalle d'interrogation. Des pics brefs sont attendus et se dissipent au cours des minutes suivantes. Si une étendue 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, finit par échouer et s'arrête. Voir Volume d'événements élevé et soutenu.

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

Un trigger de mise à jour de modèle fonctionne mieux pour les étendues où les mises à jour n’arrivent pas plus vite, en moyenne, qu’une seule exécution ne peut en traiter. Voir Mises à jour par batch.

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 :

Réduisez la fréquence des mises à jour afin qu’une seule exécution puisse suivre. Par exemple, réduisez la portée du trigger ou divisez le monitoring entre 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.
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 ( Temps minimum entre les déclencheurs et Attendre après la dernière modification ) contrôlent la fréquence de création des exécutions, mais ne modifient pas le nombre de mises à jour traitées par une exécution. Ils n’empêchent pas cet échec lorsque les mises à jour arrivent systématiquement plus vite qu’une exécution ne peut les traiter.

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 :

Dans la barre latérale de votre workspace Databricks, cliquez sur Tâches & Pipelines .
Dans la liste des jobs, cliquez sur le nom du job auquel vous souhaitez ajouter un trigger.
Dans le volet Détails du Job à droite, cliquez sur Ajouter un trigger .
Dans **Trigger type**, sélectionnez **Mise à jour du modèle**.
Sous **Portée**, sélectionnez **Modèle**, **Schéma** ou **Metastore**, puis spécifiez le modèle ou le schéma à surveiller.
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.
(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.
Pour valider la configuration, cliquez sur Tester le trigger . S'il n'y a pas d'erreurs, le bouton affiche Succès .
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}}:

Configurez la tâche **Pour chaque** pour {{job.trigger.model.updates}} qu'elle prenne comme entrée.
Configurez la tâche imbriquée pour lire les valeurs de chaque entrée fournies par l'itération.
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 exécution de job unique contient autant de mises à jour de modèle que le permet la limite de 10 000 caractères pour une valeur de paramètre de job, ce qui représente généralement plus de 100. Les mises à jour en attente supplémentaires sont traitées lors des exécutions ultérieures, à raison d'un batch par minute. Voir 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.

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

Mises à jour par batch​

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

Avant de commencer​

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

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

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

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

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

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

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

Limitations​

FAQ​

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