Planifier les actualisations

Vous pouvez manuellement refresh une vue matérialisée ou une table de streaming autonome lorsque vous savez que les tables sources ont été mises à jour. Cependant, vous pouvez également définir un calendrier pour les refresh, que ce soit par heure, lorsque les tables sources sont mises à jour, ou par orchestration. Cette page décrit comment créer les planifications pour vos tables autonomes.

Vous pouvez également créer des notifications et définir le mode de performances pour vos actualisations planifiées.

Créer un planning

Vous pouvez configurer un pipeline autonome pour refresh automatiquement selon un planning défini, ou pour Trigger lorsque les données en amont sont modifiées. Le tableau suivant présente les différentes options pour la planification des refresh.

Méthode	Description	Exemple de cas d'usage
Manuel	Refresh à la demande à l'aide d'une instruction SQL `REFRESH`, ou via l'interface utilisateur du Workspace.	Développement, tests, mises à jour ad hoc.
`TRIGGER ON UPDATE`	Planifiez le pipeline pour un refresh automatique lorsque les données en amont changent.	Charges de travail de production avec des SLA de fraîcheur des données ou des périodes de refresh imprévisibles.
`SCHEDULE`	Planifier le refresh du pipeline à des intervalles de temps définis.	Exigences de refresh prévisibles et temporelles.
Tâche SQL dans un job.	Le refresh est orchestré via Lakeflow Jobs.	Pipelines complexes avec dépendances intersystèmes.

Méthode	Description	Exemple de cas d'usage
Manuel	Refresh à la demande à l'aide d'une instruction SQL `REFRESH`, ou via l'interface utilisateur du Workspace.	Développement, tests, mises à jour ad hoc.
`TRIGGER ON UPDATE`	Planifiez le pipeline pour un refresh automatique lorsque les données en amont changent.	Charges de travail de production avec des SLA de fraîcheur des données ou des périodes de refresh imprévisibles.
`SCHEDULE`	Planifier le refresh du pipeline à des intervalles de temps définis.	Exigences de refresh prévisibles et temporelles.
Tâche SQL dans un job.	Le refresh est orchestré via Lakeflow Jobs.	Pipelines complexes avec dépendances intersystèmes.

Même lorsque vous planifiez des rafraîchissements, vous pouvez exécuter un refresh manuel à tout moment si vous avez besoin de données mises à jour.

Manual refresh

Pour rafraîchir manuellement un pipeline, vous pouvez déclencher un refresh à partir de Databricks SQL ou utiliser l'interface utilisateur du Workspace.

REFRESH statement
Workspace UI

Pour refresh un pipeline à l'aide de Databricks SQL :

Dans le Éditeur SQL , exécutez l'instruction suivante :
SQL
```
REFRESH MATERIALIZED VIEW <table-name>;
```
Pour les tables de streaming, utilisez REFRESH STREAMING TABLE.

Pour plus d'informations, consultez REFRESH (MATERIALIZED VIEW ou STREAMING TABLE).

Trigger lors de la mise à jour

La clause TRIGGER ON UPDATE effectue automatiquement un refresh d'un pipeline lorsque les données sources en amont changent. Cela élimine le besoin de coordonner les plannings entre les pipelines. Le dataset reste à jour sans exiger de l'utilisateur qu'il sache quand les Jobs en amont se terminent ou qu'il maintienne une logique de planification complexe.

C'est l'approche recommandée pour les workloads de production, surtout lorsque les dépendances en amont ne s'exécutent pas selon des plannings prévisibles. Après avoir configuré le Trigger de mise à jour, le pipeline surveille ses tables sources et effectue un refresh automatiquement lorsque des changements sont détectés dans l'une des sources en amont.

Limitations

Limites de dépendance en amont : Un pipeline peut surveiller un maximum de 10 tables en amont et 30 vues en amont. Pour plus de dépendances, divisez la logique entre plusieurs pipelines.
Limites du Workspace : Un maximum de 1 000 pipelines avec TRIGGER ON UPDATE peuvent exister par workspace. Contactez l'assistance Databricks si plus de 1 000 sont nécessaires.
Intervalle minimal : L'intervalle de Trigger minimal est de 1 minute.

Les exemples suivants montrent comment définir un Trigger lors d'une mise à jour lors de la définition d'un pipeline.

Créez un pipeline avec Trigger à la mise à jour

Pour créer un pipeline qui se refresh automatiquement lorsque les données source changent, incluez la clause TRIGGER ON UPDATE dans l’instruction CREATE.

L'exemple suivant crée une table de streaming qui lit les commandes clients et se refresh chaque fois que la table source orders est mise à jour :

SQL
CREATE OR REFRESH STREAMING TABLE catalog.schema.customer_orders
  TRIGGER ON UPDATE
AS SELECT
    o.customer_id,
    o.name,
    o.order_id
FROM catalog.schema.orders o;

Limiter la fréquence refresh

Si les données en amont se rafraîchissent fréquemment, utilisez AT MOST EVERY pour plafonner la fréquence de refresh de la vue et limiter les coûts de compute. C'est utile lorsque les tables sources sont fréquemment mises à jour, mais que les consommateurs en aval n'ont pas besoin de données en temps réel. Le mot-clé INTERVAL est requis avant la valeur de temps.

L'exemple suivant limite la table de streaming à refresh au maximum toutes les 5 minutes, même si les données sources changent plus fréquemment :

SQL
CREATE OR REFRESH STREAMING TABLE catalog.schema.customer_orders
  TRIGGER ON UPDATE AT MOST EVERY INTERVAL 5 MINUTES
AS SELECT
    o.customer_id,
    o.name,
    o.order_id
FROM catalog.schema.orders o;

Scheduled refresh

Les planifications de refresh peuvent être définies directement dans la définition du pipeline pour actualiser la vue à intervalles de temps fixes. Cette approche est utile lorsque la cadence de mise à jour des données est connue et qu'un timing de refresh prévisible est souhaité.

Lorsqu'il y a une planification de refresh, vous pouvez toujours exécuter un refresh manuel à tout moment si vous souhaitez des données mises à jour.

Databricks prend en charge deux syntaxes de planification : SCHEDULE EVERY pour les intervalles simples et SCHEDULE CRON pour une planification précise. Les mots-clés SCHEDULE et SCHEDULE REFRESH sont sémantiquement équivalents.

Pour plus de détails sur la syntaxe et l'utilisation de la clause SCHEDULE, consultez clause CREATE STREAMING TABLE SCHEDULE ou clause CREATE MATERIALIZED VIEW SCHEDULE.

Lorsqu’un planning est créé, un nouveau job Databricks est automatiquement configuré pour traiter la mise à jour.

Pour afficher la planification, effectuez l'une des actions suivantes :

Exécutez l'instruction DESCRIBE EXTENDED à partir de l'éditeur SQL dans l'interface utilisateur de Databricks. See DESCRIBE TABLE.
Utilisez Catalog Explorer pour afficher le dataset. Le planning est listé dans l'onglet **Overview tab**, sous **Refresh status**. Consultez Qu'est-ce que l'Explorateur de catalogues ?.

Les exemples suivants montrent comment créer une vue matérialisée avec une planification :

Planifier à chaque intervalle de temps

Cet exemple planifie un refresh toutes les heures. La clause EVERY prend en charge les intervalles horaires, journaliers et hebdomadaires. Pour les intervalles infra-horaires, utilisez SCHEDULE CRON à la place.

SQL
CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.hourly_metrics
  SCHEDULE EVERY 1 HOUR
AS SELECT
    date_trunc('hour', event_time) AS hour,
    count(*) AS events
FROM catalog.schema.raw_events
GROUP BY 1;

Planifier à l'aide de cron

Cet exemple planifie un refresh toutes les 15 minutes, à la quart d'heure du fuseau horaire UTC :

SQL
CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.regular_metrics
  SCHEDULE CRON '0 */15 * * * ?' AT TIME ZONE 'UTC'
AS SELECT
    date_trunc('minute', event_time) AS minute,
    count(*) AS events
FROM catalog.schema.raw_events
WHERE event_time > current_timestamp() - INTERVAL 1 HOUR
GROUP BY 1;

Tâche SQL dans un job

Les refresh de pipeline peuvent être orchestrés via les Lakeflow Jobs en créant des tâches SQL qui incluent les commandes REFRESH. Cette approche intègre les pipeline refresh dans l'orchestration existante à l'aide de Jobs.

Il existe deux façons de créer un Job pour actualiser les tables de streaming :

Depuis l'éditeur SQL : Saisissez la REFRESH commande et cliquez sur le bouton Planifier pour créer un Job directement à partir de la query.
Depuis l'interface utilisateur Jobs : créez un nouveau Job, ajoutez un type de tâche SQL et attachez une query SQL ou un Notebook avec la commande REFRESH.

L'exemple suivant montre l'instruction SQL dans une tâche SQL qui refresh une table de streaming :

SQL
REFRESH STREAMING TABLE catalog.schema.sales;

Cette approche est appropriée lorsque :

Les pipelines complexes en plusieurs étapes ont des dépendances entre les systèmes.
L'intégration avec l'orchestration de job existante est requise.
Des alertes et un monitoring au niveau du Job sont nécessaires.

Les tâches SQL utilisent à la fois le SQL Warehouse attaché au Job et le compute Serverless qui exécute le refresh. Si l'utilisation de la planification basée sur la définition de table de streaming répond aux exigences, le passage à TRIGGER ON UPDATE ou SCHEDULE peut simplifier le workflow.

Ajouter un calendrier à un pipeline existant

Pour configurer la planification après la création, utilisez l'instruction ALTER STREAMING TABLE ou ALTER MATERIALIZED VIEW. Par exemple :

SQL
-- Alters the schedule to refresh the streaming table when its upstream
-- data gets updated.
ALTER STREAMING TABLE sales
  ADD TRIGGER ON UPDATE;

Modifiez une planification ou un trigger existant

Si un pipeline a déjà un programme ou un Trigger associé, utilisez ALTER SCHEDULE ou ALTER TRIGGER ON UPDATE pour modifier la configuration de refresh. Cela s'applique que vous passiez d'un programme à un autre, d'un trigger à un autre, ou que vous alterniez entre un programme et un trigger.

L’exemple suivant modifie un planning existant pour le refresh toutes les 5 minutes. Puisque la clause EVERY ne prend pas en charge les intervalles de minutes, utilisez une expression CRON pour les planifications infra-horaires :

SQL
ALTER STREAMING TABLE catalog.schema.my_table
  ALTER SCHEDULE CRON '0 */5 * * * ?';

Supprimer un planning ou un Trigger

Pour supprimer un planning, utilisez ALTER ... DROP:

SQL
ALTER STREAMING TABLE catalog.schema.my_table
  DROP SCHEDULE;

Suivre l'état d'un refresh

Vous pouvez afficher l'état d'un refresh en consultant le pipeline dans l'interface utilisateur des pipelines ou en consultant les refresh Information renvoyées par la commande DESCRIBE EXTENDED pour le dataset.

SQL
DESCRIBE TABLE EXTENDED <table-name>;

Vous pouvez également afficher le dataset dans l'Explorateur de catalogues et y consulter le statut de refresh :

Cliquez sur Catalogue dans la barre latérale.
Dans l'arborescence de l'Explorateur de catalogues à gauche, ouvrez le catalogue et sélectionnez le schéma où se trouve votre dataset.
Ouvrez l'élément Tables sous le schéma sélectionné, et cliquez sur la table de streaming ou la vue matérialisée.

À partir d'ici, vous pouvez utiliser les tabs sous le nom du dataset pour afficher et modifier les information concernant le dataset, notamment :

refresh Statut et historique
Le schéma de la table
Données d'exemple (nécessite un compute actif)
Autorisations
Traçabilité, y compris les tables et les autres pipelines dont dépend ce dataset
Informations sur l'utilisation
Moniteurs que vous avez créés pour ce dataset

Arrêter une active refresh

Pour arrêter un refresh actif dans l'interface utilisateur de Databricks, sur la page Détails du pipeline , cliquez sur Arrêter pour arrêter la mise à jour du pipeline. Vous pouvez également arrêter le refresh avec la CLI Databricks ou l'API POST /api/2.0/pipelines/{pipeline_id}/stop Opération dans l'API REST des Pipelines.

Affichez l'historique des exécutions pour une refresh planifiée

Si vous ouvrez votre dataset dans l'Explorateur de catalogues, le volet de détails sur le côté droit du Workspace affiche la planification de Refresh . Cliquer sur le planning (par exemple, le link Toutes les 1 heure ) vous amène à la page du job (géré par le système) qui exécute le planning. Vous pouvez voir l'historique des exécutions, y compris un graphe des exécutions des dernières 48 heures, indiquant la réussite ou l'échec et le temps d'exécution. Vous pouvez cliquer sur une exécution spécifique pour obtenir plus de détails.

Vous ne pouvez pas modifier ce Job géré par le système. Pour apporter des modifications à la planification, modifiez la définition du pipeline avec CREATE OR REFRESH ou avec ALTER. Voir Modifier une planification ou un Trigger existant.

Dépassements de délai pour les refresh

Les refresh de pipeline s'exécutent avec un délai d'expiration qui limite leur durée d'exécution. Pour les pipelines autonomes créés ou mis à jour le 14 août 2025 ou après, le délai d'expiration est capturé lorsque vous mettez à jour en exécutant CREATE OR REFRESH:

Si un STATEMENT_TIMEOUT est défini, cette valeur est utilisée. Voir STATEMENT_TIMEOUT.
Sinon, le délai d'expiration du SQL Warehouse utilisé pour exécuter la commande est utilisé. Voir Délai d'expiration de l'instruction.
Si le warehouse n'a pas de délai d'expiration configuré, un délai de 2 jours s'applique par default.

Le délai d'expiration est utilisé lors de la création initiale, mais aussi lors des scheduled refresh qui suivent.

Pour les tables de streaming qui ont été mises à jour pour la dernière fois avant le 14 août 2025, le délai d'expiration est défini sur 2 jours.

Exemple : Définir un délai d'expiration pour un refresh Vous pouvez contrôler explicitement la durée d'exécution d'un refresh en définissant un délai d'expiration au niveau de l'instruction lors de la création ou de la mise à jour du dataset :

SQL
SET STATEMENT_TIMEOUT = '6h';

CREATE OR REFRESH MATERIALIZED VIEW my_catalog.my_schema.my_mv
  SCHEDULE EVERY 12 HOURS
AS SELECT * FROM large_source_table;

Cela configure la vue matérialisée pour qu'elle soit rafraîchie toutes les 12 heures. Si un refresh prend plus de 6 heures, il expire et attend le prochain refresh planifié.

Comment les actualisations planifiées gèrent les délais d'attente

Les délais d'attente sont synchronisés uniquement lorsque vous exécutez explicitement CREATE OR REFRESH.

Les refresh planifiés continuent d’utiliser le délai d’expiration capturé lors du CREATE OR REFRESH le plus récent.
La modification du délai d’expiration du warehouse n’affecte pas à elle seule les refresh planifiés existants.

important

Après avoir modifié un délai d'expiration de warehouse, exécutez CREATE OR REFRESH à nouveau pour appliquer le nouveau délai d'expiration aux refresh programmées futures.

Recevez des notifications pour les refresh planifiés

info

Bêta

La fonctionnalité de notifications pour les refresh planifiés de DDL est en version bêta. Les administrateurs de Workspace peuvent contrôler l'accès à cette fonctionnalité depuis la page Aperçus en activant la préversion Job géré par le système pour les vues matérialisées et les tables de streaming . Voir Gérer les aperçus Databricks.

Lorsque vous créez une planification pour votre pipeline, vous pouvez la modifier pour recevoir des notifications. Il existe plusieurs façons de planifier des pipelines, et la réception des notifications dépend de la méthode que vous choisissez :

**Planifié avec un job** : pour obtenir des notifications d’une tâche SQL dans Lakeflow Jobs, modifiez la tâche et ajoutez des notifications. Voir Tâche SQL pour les jobs.

Vous disposez d'un large éventail d'options pour les notifications à recevoir et la manière de les recevoir. Consultez Ajouter des notifications sur un Job
Planifié avec une clause SCHEDULE : Pour recevoir des notifications d'un pipeline planifié par une clause SCHEDULE dans la définition SQL, modifiez-le dans le Catalog Explorer:
1. Ouvrir le dataset dans l'Explorateur de catalogues.
2. Dans l' Overview tab , sous refresh schedule , cliquez sur pour modifier le planning pour lequel vous souhaitez recevoir des notifications.
3. Sous Plus d'options , ajoutez ou modifiez des notifications.
  
  Vous avez la possibilité d'être notifié par e-mail au start, au succès ou à l'échec de la scheduled refresh. By default, le propriétaire est informé uniquement en cas d'échec.
  
  L'e-mail inclut un Link qui vous mène à l'historique d'exécution du Job géré par le système qui orchestre votre planning. Voir Afficher l'historique des exécutions pour un refresh planifié.

Sélectionnez un mode de performance pour les refresh programmées.

Le compute Serverless utilisé par le pipeline s'exécute en mode Performances optimisées lorsqu'il est exécuté via l'interface utilisateur.

Pour les pipelines planifiés dans la définition SQL, vous pouvez sélectionner le mode de performance de compute Serverless à l'aide du paramètre Performance optimized dans l'Explorateur de catalogues. Lorsque ce paramètre est désactivé (par default), le pipeline utilise le mode de performance standard. Le mode de performance standard est conçu pour réduire les coûts des charges de travail où une latence de lancement légèrement plus élevée est acceptable. Les charges de travail Serverless utilisant le mode de performance standard start généralement entre quatre et six minutes après avoir été Triggered, en fonction de la disponibilité du compute et de la planification optimisée.

Lorsque l'optimisation des performances est activée, votre pipeline est optimisé pour la performance, ce qui entraîne un Startup et une exécution plus rapides pour les charges de travail sensibles au temps.

Les deux modes utilisent le même SKU, mais le mode de performance standard consomme moins de DBU, ce qui reflète une utilisation moindre du compute.

info

Bêta

La modification du mode de performance pour les actualisations planifiées est en version bêta. Les administrateurs de Workspace peuvent contrôler l'accès à cette fonctionnalité depuis la page Aperçus en activant la préversion Job géré par le système pour les vues matérialisées et les tables de streaming . Voir Gérer les aperçus Databricks.

Par default, les pipelines utilisent le mode de performances optimisées lorsqu'ils sont exécutés de manière interactive dans l'interface utilisateur, le paramètre Performances optimisées du job lorsqu'il est planifié avec une tâche SQL, et le mode standard lorsqu'il est planifié. Pour définir le mode de calcul des pipelines programmés par une clause SCHEDULE dans la définition, modifiez la planification dans l'Explorateur de catalogue :

Ouvrir le dataset dans l'Explorateur de catalogues.
Dans la tab Vue d'ensemble , sous Planification de refresh , cliquez sur pour modifier la planification souhaitée.
Cochez Performances optimisées pour utiliser le mode optimisé pour les performances lors des futures refresh planifiées.

Créer un planning​

Manual refresh​

Trigger lors de la mise à jour​

Scheduled refresh​

Tâche SQL dans un job​

Ajouter un calendrier à un pipeline existant​

Modifiez une planification ou un trigger existant​

Supprimer un planning ou un Trigger​

Suivre l'état d'un refresh​

Arrêter une active refresh​

Affichez l'historique des exécutions pour une refresh planifiée​

Dépassements de délai pour les refresh​

Comment les actualisations planifiées gèrent les délais d'attente​

Recevez des notifications pour les refresh planifiés​

Sélectionnez un mode de performance pour les refresh programmées.​