Programmer des refresh

Vous pouvez refresh manuellement 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 programme de refresh, soit par heure, soit lorsque les tables sources sont mises à jour, ou par orchestration.

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

Créer un planning

Vous pouvez configurer un pipeline autonome pour qu’il refresh automatiquement selon un calendrier défini ou pour qu’il se déclenche lorsque les données en amont changent. Le tableau suivant présente les différentes options de 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 qu’il refresh automatiquement 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`	Planifiez le refresh du pipeline à des intervalles de temps définis.	Exigences de refresh prévisibles et basées sur le temps.
Tâche SQL dans un job	Le refresh est orchestré via Lakeflow Jobs.	Pipelines complexes avec des 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 qu’il refresh automatiquement 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`	Planifiez le refresh du pipeline à des intervalles de temps définis.	Exigences de refresh prévisibles et basées sur le temps.
Tâche SQL dans un job	Le refresh est orchestré via Lakeflow Jobs.	Pipelines complexes avec des dépendances intersystèmes.

Même lorsque vous programmez des refresh, vous pouvez effectuer un refresh manuel à tout moment si vous avez besoin de données à jour.

refresh manuel

Pour refresh manuellement un pipeline, vous pouvez lancer une refresh depuis Databricks SQL ou utiliser l'interface utilisateur du Workspace.

REFRESH statement
Workspace UI

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

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

Pour en savoir plus, consultez REFRESH (MATERIALIZED VIEW ou STREAMING TABLE).

Trigger lors de la mise à jour

La clause TRIGGER ON UPDATE refresh automatiquement un pipeline lorsque les données sources en amont changent. Cela évite d'avoir à coordonner les plannings entre les pipelines. Le dataset reste frais sans que l’utilisateur ait besoin de savoir quand les jobs en amont se terminent ou de maintenir une logique de planification complexe.

Il s’agit de l’approche recommandée pour les workloads de production, en particulier lorsque les dépendances en amont ne suivent pas des horaires prévisibles. Après avoir configuré le trigger à la mise à jour, le pipeline surveille ses tables sources et effectue automatiquement un refresh dès qu’il détecte des changements dans l’une des sources en amont.

Limites

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 vous avez besoin de plus de 1 000 éléments.
Intervalle minimal : l’intervalle minimal entre les Trigger est de 1 minute.

Les exemples suivants montrent comment définir un trigger lors de la mise à jour lors de la définition d’un pipeline.

Créer un pipeline avec un trigger lors de la mise à jour

Pour créer un pipeline qui refresh automatiquement lors du changement des données sources, incluez la clause TRIGGER ON UPDATE dans l’instruction CREATE.

L’exemple suivant crée une table de streaming qui lit les commandes des clients et refresh dès 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;

Fréquence de refresh de la limitation

Si les données en amont sont refresh fréquemment, utilisez AT MOST EVERY pour limiter la fréquence de refresh de la vue et réduire les coûts de compute. C'est utile quand les tables sources sont mises à jour fréquemment, 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 le refresh de la table de streaming à une fois toutes les 5 minutes maximum, 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;

refresh programmée

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

Lorsqu'il existe un planning de refresh, vous pouvez toujours exécuter une refresh manuelle à tout moment si vous souhaitez obtenir des données à 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, voir CLAUSE CREATE STREAMING TABLE SCHEDULE, ou CLAUSE CREATE MATERIALIZED VIEW SCHEDULE.

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

Pour voir le calendrier, effectuez l'une des actions suivantes :

Exécutez l’instruction DESCRIBE EXTENDED à partir de l’éditeur SQL dans l’interface utilisateur Databricks. Voir DESCRIBE TABLE.
Utilisez Catalog Explorer pour voir le dataset. La planification est listée dans l’onglet Présentation tab, sous État de l’refresh . Voir Qu'est-ce que Catalog Explorer ?.

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

Planification à chaque intervalle de temps

Cet exemple planifie une refresh toutes les heures. La clause EVERY prend en charge les intervalles d'heure, de jour et de semaine. Pour les intervalles inférieurs à une heure, 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 avec cron

Cet exemple planifie une refresh toutes les 15 minutes, au 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 Lakeflow Jobs en créant des tâches SQL qui incluent des commandes REFRESH. Cette approche intègre les refresh de pipeline dans l’orchestration existante via des jobs.

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

Depuis l’éditeur SQL : Écrivez la commande REFRESH et cliquez sur le bouton Planifier pour créer un job directement depuis la query.
Depuis l'interface utilisateur de 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;

remarque

Pour les vues matérialisées et les tables de streaming autonomes, l’orchestration d’un refresh via un job ne les exécute pas en continu. Chaque exécution de job effectue un Trigger refresh. L'exécution continue via un Job s'applique uniquement aux LakeFlow Pipelines. Voir Exécuter un pipeline continu avec un job continu.

Cette approche convient lorsque :

Des pipelines multi-étapes complexes impliquent des dépendances intersystèmes.
L’intégration avec l’orchestration de jobs existante est requise.
Une alerte 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 d'une planification basée sur la définition de table de streaming répond aux exigences, passer à TRIGGER ON UPDATE ou SCHEDULE peut simplifier le workflow.

Ajouter un calendrier à un pipeline existant

Pour définir 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;

Modifier un planning ou un trigger existant

Si un pipeline est déjà associé à un calendrier ou un trigger, utilisez ALTER SCHEDULE ou ALTER TRIGGER ON UPDATE pour modifier la configuration du refresh. Ceci s’applique que vous passiez d’un calendrier à un autre, d’un trigger à un autre ou que vous basculiez entre un calendrier et un trigger.

L'exemple suivant modifie un planning existant pour effectuer un refresh toutes les 5 minutes. Comme la clause EVERY ne prend pas en charge les intervalles en minutes, utilisez une expression CRON pour les planifications inférieures à l’heure :

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

Déposez un planning ou un trigger

Pour supprimer un calendrier, 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 affichant le pipeline dans l’interface utilisateur des Pipelines ou en affichant les information de refresh renvoyées par la commande DESCRIBE EXTENDED pour le dataset.

SQL
DESCRIBE TABLE EXTENDED <table-name>;

Alternativement, vous pouvez afficher le dataset dans l’Explorateur de catalogues et y consulter le statut du 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 que vous avez sélectionné et cliquez sur la table de streaming ou la vue matérialisée.

À partir de là, vous pouvez utiliser les tab sous le nom du dataset pour voir et modifier les informations sur le dataset, y compris :

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

Arrêter une refresh active

Pour arrêter une refresh active dans l'interface utilisateur Databricks, dans 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 Databricks CLI ou POST /api/2.0/pipelines/{pipeline_id}/stop Opération dans l'API REST Pipelines.

Afficher l'historique des exécutions d'une refresh planifiée

Si vous ouvrez votre dataset dans l’explorateur de catalogue, le volet de détails sur le côté droit du workspace affiche le programme de refresh . Cliquez sur le lien du planning (par exemple, Toutes les 1 heure ) pour accéder à la page du job pour le 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, avec les succès ou les échecs et le temps pris. 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 au planning, modifiez la définition du pipeline avec CREATE OR REFRESH ou avec ALTER. Voir Modifier un planning ou un trigger existant.

Délai d'expiration 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 cette date, le délai d'expiration est capturé lorsque vous effectuez une mise à jour en exécutant CREATE OR REFRESH:

Si une STATEMENT_TIMEOUT est définie, 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 des instructions.
Si le warehouse n'a pas de délai d'expiration configuré, une default de 2 jours s'applique.

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

Pour les tables de streaming dont la dernière mise à jour est antérieure au 14 août 2025, le délai d’expiration est fixé à 2 jours.

Exemple : définir un délai d'expiration pour un refresh Vous pouvez contrôler explicitement pendant combien de temps un refresh est autorisé à s'exécuter 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 = 21600;

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 être refresh toutes les 12 heures. Si un refresh prend plus de 6 heures, il expirera et attendra le prochain refresh prévu.

Comment les refresh programmées gèrent les délais d'expiration

Les délais d’expiration ne sont synchronisés que lorsque vous exécutez explicitement CREATE OR REFRESH.

Les refresh planifiées continuent d’utiliser le délai d’attente capturé lors du CREATE OR REFRESH le plus récent.
La modification du délai d'expiration du warehouse n'affecte pas les refresh planifiées existantes.

important

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

Recevoir des notifications pour les refresh programmées

info

Bêta

Les notifications pour la fonctionnalité de refresh programmées DDL sont en Bêta. Les administrateurs de Workspace peuvent contrôler l'accès à cette fonctionnalité à partir de la page Aperçus en acceptant l'aperçu du Job géré par le système pour les vues matérialisées et les tables de streaming . Consultez Gérer les aperçus Databricks.

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

Planifié avec un job : pour recevoir 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 concernant les notifications à recevoir et la manière de les recevoir. Voir Ajouter des notifications sur un job
Planifié avec une clause SCHEDULE : pour recevoir des notifications à partir d’un pipeline planifié par une clause SCHEDULE dans la définition SQL, modifiez-le dans l’ Explorateur de catalogue:
1. Ouvrez le dataset dans l'Explorateur de catalogues.
2. Dans le Présentation tab , sous Planning d’refresh, 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é de recevoir une notification par e-mail au start, au succès ou en cas d'échec de la refresh planifiée. Par default, le propriétaire est notifié uniquement en cas d'échec.
  
  L’e-mail contient un link qui vous dirige vers l’historique des exécutions du job géré par le système qui orchestre votre planning. Voir Voir 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 optimisé pour les performances lorsqu’il est exécuté via l’interface utilisateur.

Pour les pipelines programmés dans la définition SQL, vous pouvez sélectionner le mode de performance de calcul Serverless compute à l'aide du paramètre Performance optimisée dans Catalog Explorer. Lorsque ce paramètre est désactivé (the default), le pipeline utilise le mode de performance standard. Le mode de performance standard est conçu pour réduire les coûts pour les 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 en quatre à six minutes après leur Trigger, en fonction de la disponibilité des ressources de compute et de la planification optimisée.

Lorsque l’optimisation des performances est activée, votre pipeline est optimisé pour les performances, ce qui accélère le startup et l’exécution des 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 traduit une utilisation moindre du compute.

info

Bêta

La modification du mode de performance pour les refresh planifiées est en Bêta. Les administrateurs de Workspace peuvent contrôler l’accès à cette fonctionnalité à partir de la page Aperçus en optant pour l’aperçu Job géré par le système pour les vues matérialisées et les tables de streaming . Consultez Gérer les aperçus Databricks.

Par default, les pipelines utilisent le mode optimisé pour les performances 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 compute des pipelines planifiés par une clause SCHEDULE dans la définition, modifiez la planification dans l'explorateur de catalogue :

Ouvrez le dataset dans l'Explorateur de catalogues.
Dans le Vue d’ensemble tab, sous Programmation des refresh , cliquez sur pour modifier la planification que vous souhaitez modifier.
Cochez Optimisé pour la performance pour utiliser le mode optimisé pour la performance lors des prochaines refresh planifiées.

Créer un planning​

refresh manuel​

Trigger lors de la mise à jour​

refresh programmée​

Tâche SQL dans un job​

Ajouter un calendrier à un pipeline existant​

Modifier un planning ou un trigger existant​

Déposez un planning ou un trigger​

Suivre l'état d'un refresh​

Arrêter une refresh active​

Afficher l'historique des exécutions d'une refresh planifiée​

Délai d'expiration pour les refresh​

Comment les refresh programmées gèrent les délais d'expiration​

Recevoir des notifications pour les refresh programmées​

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