Trigger des Jobs lorsque les tables sources sont mises à jour

Vous pouvez utiliser des Trigger de mise à jour de table pour Trigger l’exécution de votre Job lorsque les tables sources sont mises à jour. Utilisez cette fonctionnalité pour exécuter un job lorsque de nouvelles données sont prêtes, sans nécessiter un cluster en fonctionnement continu ni connaître les processus qui mettent à jour une table.

info

Bêta

Le déclenchement de Jobs sur les tables et vues OpenSharing et sur les tables système est en version bêta. Consultez Ajouter un Trigger aux tables système et OpenSharing.

Comment les Triggers de mise à jour de table fonctionnent

Un Trigger de mise à jour de table vérifie les mises à jour de table, et lorsqu'une table est mise à jour, le Job est exécuté. Le trigger peut s'exécuter lorsqu'une table est mise à jour, ou lorsque toutes les tables surveillées par le trigger sont mises à jour. Les Trigger de mise à jour des tables n'entraînent pas de coûts supplémentaires autres que les coûts du fournisseur de cloud associés à l'énumération des tables et à la lecture des mises à jour à partir de l'emplacement de stockage.

Un trigger de mise à jour de table peut être configuré pour surveiller une ou plusieurs tables afin de détecter des modifications de données telles que les mises à jour, les Merge et les suppressions. Ces tables peuvent être des tables gérées Unity Catalog Delta et Iceberg, des tables externes Unity Catalog basées sur Delta Lake, des vues matérialisées, des tables de streaming, et des vues Unity Catalog ou des vues métriques qui dépendent de tables prises en charge. Lorsque vous sélectionnez plusieurs tables, vous pouvez spécifier si un Job est Trigger lorsque l'une ou l'ensemble des tables sont mises à jour.

Vous pouvez également configurer des Trigger sur les tables et vues OpenSharing, et sur les tables système (Beta). Consultez Ajouter un Trigger aux tables OpenSharing et système.

Ajoutez un Trigger de mise à jour de table

Pour ajouter un trigger de mise à jour de table à un Job existant :

1. Dans la navigation de gauche de votre Workspace, cliquez sur Jobs et pipelines .

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

3. Dans le volet de droite, sous Schedules & Triggers , cliquez sur Ajouter un Trigger .

4. Dans Type de Trigger, sélectionnez Mise à jour de table .

5. Sous Tables , ajoutez les tables que vous souhaitez surveiller pour les mises à jour.

   Si vous sélectionnez plusieurs tables, configurez une option sous Trigger lorsque pour spécifier si vous souhaitez qu'un Job soit déclenché lorsque Toutes les tables sont mises à jour ou lorsque N'importe quelle table est mise à jour .

6. (Facultatif) Configurez les options avancées en cliquant sur Avancé .

   • Temps minimum entre les Trigger en secondes : Le temps minimum à attendre pour déclencher une exécution après la fin d'une exécution précédente. Les tables mises à jour pendant cette période ne Trigger une exécution qu'après l'expiration du temps d'attente. Databricks attend ce laps de temps avant de Trigger une exécution, même si les tables surveillées sont mises à jour.
   • Délai d’attente après la dernière modification en secondes : temps d'attente avant de Trigger une exécution après une mise à jour de table. Les mises à jour supplémentaires de la table pendant cette période Reset le minuteur. Ce paramètre peut être utilisé lorsque les mises à jour de table arrivent par batchs, et que le batch entier doit être traité après la mise à jour de toutes les tables.

remarque

Si les deux options sont utilisées, le trigger attend le délai minimal entre les triggers, puis attend la durée définie après la dernière modification. Par exemple, si vous avez un temps minimal de 120 secondes et un délai après les dernières modifications de 60 secondes, l'exécution ne Trigger qu'après au moins 120 secondes, même si une mise à jour de table a lieu dans les 60 premières secondes. De plus, si une mise à jour intervient après 5 secondes, puis une autre après 115 secondes, le délai après la dernière modification signifie qu'une exécution n'est pas déclenchée avant 175 secondes.

7. Pour valider la configuration, cliquez sur Tester le trigger .

8. Cliquez sur Enregistrer .

remarque

Vous pouvez également configurer des Trigger de mise à jour de table à partir de l'API Jobs. Ajoutez un objet trigger à une opération jobs/create, jobs/update, ou jobs/reset.

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.

Ajouter un trigger à OpenSharing et aux tables système

info

Bêta

Cette fonctionnalité est en bêta.

En plus des tables locales, vous pouvez configurer des triggers de mise à jour de table pour surveiller les données partagées avec votre workspace via OpenSharing et les tables système. Par exemple, vous pouvez Trigger un Job chaque fois que de nouveaux enregistrements de facturation sont ajoutés à une table système, ou chaque fois qu'un fournisseur met à jour une table partagée.

Vous pouvez Trigger les objets partagés suivants :

• Tables OpenSharing
• Vues OpenSharing
• Vues métriques OpenSharing
• Vues matérialisées OpenSharing
• Tables de streaming OpenSharing
• Tables système

Passez en revue les limites de trigger OpenSharing, puis suivez les étapes de la section Ajouter un trigger de mise à jour de table et sélectionnez les tables, vues ou tables système partagées que vous souhaitez surveiller.

Limitations du Trigger OpenSharing

• Cette fonctionnalité prend en charge Databricks-to-Databricks OpenSharing uniquement. Databricks-à-Open sharing n'est pas pris en charge.

• To Trigger on shared tables and views, the beta must be enabled on both the recipient and provider sides:

  • Triggers de mise à jour de table sur OpenSharing (destinataire) : une version bêta au niveau du Workspace, activée dans le Workspace du destinataire où le Trigger est créé.
  • Trigger de mise à jour de table sur OpenSharing (fournisseur) : une version bêta au niveau du compte, activée dans le compte fournisseur qui possède les données partagées.

  Pour les tables système, seule la version bêta du destinataire est requise. Pour activer cette option, consultez Gérer les versions préliminaires de Databricks.

• L'utilisateur qui crée le Trigger doit disposer du privilège SELECT sur l'objet partagé ou la table système.

Table update Trigger with file events

Pour des performances et une évolutivité optimales, activez les événements de fichier sur l'emplacement externe où les tables sont stockées. Cette étape de configuration unique améliore l'efficacité des Trigger de mise à jour de table et débloque d'autres fonctionnalités, y compris Auto Loader plus performants et les Trigger d'arrivée de fichiers.

Lorsque les événements de fichier sont activés, Databricks suit automatiquement les métadonnées d'ingestion à l'aide des notifications de modification du fournisseur de cloud, ce qui entraîne des mises à jour de table plus rapides et plus efficaces.

Si vos tables se trouvent dans le stockage de niveau racine du metastore, convertissez-les d'abord en un emplacement externe, puis activez les événements de fichier sur cet emplacement.

Pour les questions courantes concernant les événements de fichier, consultez la FAQ sur les événements de fichier.

paramètres de Job associés aux Trigger de mise à jour des tables

Lorsque vous utilisez des Trigger de mise à jour de table pour un Job, trois nouvelles références de valeur dynamique sont disponibles pour être utilisées comme valeurs de paramètre dans le Job.

• {{job.trigger.table_update.updated_tables}} - Une liste JSON des tables mises à jour depuis la dernière exécution de job.
• {{job.trigger.table_update.`<catalog.schema.table>`.commit_timestamp.iso_datetime}} - le Timestamp de commit le plus récent qui a servi de Trigger pour l'exécution du Job.
• {{job.trigger.table_update.`<catalog.schema.table>`.version}} - la version de commit la plus récente qui a déclenché l'exécution du Job.

Pour commit_timestamp et version, il existe plusieurs versions de la référence de valeur dynamique. Chaque table surveillée a un <catalog.schema.table> avec le nom entièrement qualifié de la table pour laquelle vous souhaitez des données. S'il n'y a qu'une seule table surveillée dans le trigger, vous voyez une valeur sans le <catalog.schema.table>. Par exemple, vous pouvez utiliser {{job.trigger.table_update.commit_timestamp.iso_datetime}}.

Pour plus d'informations sur les paramètres de job, consultez Paramétrer les jobs.

Recevoir des notifications des Trigger de mise à jour de table ayant échoué

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

Limitations

Les triggers de mise à jour des tables ont les limitations suivantes :

• Vous pouvez sélectionner jusqu'à 10 tables gérées ou Delta par Trigger.
• Pour les tables résidant dans des emplacements sans événements de fichiers, un maximum de 1 000 Jobs peuvent être configurés avec un Trigger de mise à jour de table.
• Un maximum de 1 000 triggers de mise à jour de table sur des objets OpenSharing ou des tables système peut être créé par workspace.

Les Triggers sur les **vues Unity Catalog** présentent les limitations supplémentaires suivantes :

• Les Trigger de mise à jour des tables ne prennent en charge que la surveillance des vues Unity Catalog ou des vues de métriques qui dépendent de tables également prises en charge par les Trigger de mise à jour des tables. Notamment : les vues suivantes ne sont pas prises en charge.

  • Vues qui utilisent read_files (elles peuvent lire à partir d'une table prise en charge qui lit des fichiers, mais ne peuvent pas utiliser directement read_files).
  • Vues qui dépendent de tables qui ne sont pas dans Unity Catalog.
  • Vues qui dépendent de tables fédérées.

• La création de déclencheurs pour les vues contenant des dépendances non prises en charge réussit toujours, mais aucune exécution de job n'est déclenchée lorsqu'une dépendance non prise en charge est mise à jour.

• Les Trigger de mise à jour de table surveillent les modifications apportées aux tables dépendantes d'une vue et considèrent la vue mise à jour si l'une des tables dépendantes est mise à jour. Il est possible qu'une exécution de job soit déclenchée pour des changements de données qui sont filtrés par la définition de la vue.

• Les tables sources d'une vue sont prises en compte dans la limite de 10 tables par Trigger.

  • Par exemple, si une vue dépend de 11 tables, il n'est pas possible de l'utiliser dans un trigger de mise à jour de table. De même, un trigger avec deux vues, chacune dépendant de 6 tables, compte pour 12 tables.

• Il existe une limite distincte de 10 vues dépendantes par vue surveillée.

  • Par exemple, si une vue dépend de 11 autres vues, il n'est pas possible de l'utiliser dans un Trigger de mise à jour de table, même si cela n'enfreint pas la règle des 10 tables par Trigger.