Utiliser des vues matérialisées dans Databricks SQL

Cet article explique comment créer et actualiser des vues matérialisées dans Databricks SQL pour améliorer les performances et réduire le coût de vos charges de travail de traitement et d’analyse des données.

Qu’est-ce qu’une vue matérialisée ?

Dans Databricks SQL, les vues matérialisées sont des tables gérées par le catalogue Unity qui stockent physiquement les résultats d’une requête. Contrairement aux vues standard, qui calculent les résultats à la demande, les vues matérialisées mettent en cache les résultats et les mettent à jour à mesure que les tables sources sous-jacentes changent, soit selon une planification, soit automatiquement.

Les vues matérialisées conviennent parfaitement aux charges de travail de traitement des données, telles que le traitement d’extraction, de transformation et de chargement (ETL). Les vues matérialisées fournissent un moyen simple et déclaratif de traiter les données à des fins de conformité, de correction, d’agrégation ou de capture des changements de données (CDC). Les vues matérialisées rendent également les transformations simples à utiliser en nettoyant, enrichissant et dénormalisant les tables de base. En pré-calculant des requêtes coûteuses ou fréquemment utilisées, les vues matérialisées réduisent la latence des requêtes et la consommation des ressources. Dans de nombreux cas, ils peuvent calculer de manière incrémentielle les modifications des tables sources, améliorer davantage l’efficacité et l’expérience des utilisateurs finaux.

Voici quelques cas d’usage courants pour les vues matérialisées :

Maintenir un tableau de bord BI à jour avec une latence de requête minimale de l’utilisateur final.
Réduction de l’orchestration ETL complexe avec une logique SQL simple.
Création de transformations complexes en couches.
Les cas d’utilisation qui demandent des performances constantes avec des insights à jour.

Lorsque vous créez une vue matérialisée dans un entrepôt Databricks SQL, un pipeline sans serveur est créé pour traiter la création et l’actualisation de la vue matérialisée. Vous pouvez surveiller l’état des opérations d’actualisation dans l’Explorateur de catalogues. Voir afficher les détails avec DESCRIBE EXTENDED.

Exigences

Les vues matérialisées créées dans Databricks SQL sont soutenues par un pipeline sans serveur. Votre espace de travail doit prendre en charge les pipelines serverless pour utiliser cette fonctionnalité.

Conditions requises pour créer ou actualiser des vues matérialisées :

Vous devez utiliser un entrepôt SQL pro ou serverless compatible avec Unity Catalog.
Pour actualiser une vue matérialisée, vous devez être dans l’espace de travail qui l’a créée.
Pour actualiser de façon incrémentielle une vue matérialisée à partir de tables Delta, les tables sources doivent avoir activé le suivi des lignes.
Le propriétaire (l’utilisateur qui crée la vue matérialisée) doit disposer des autorisations suivantes :
- Privilège SELECT sur les tables de base référencées par la vue matérialisée
- Privilèges USE CATALOG et USE SCHEMA sur le catalogue et le schéma contenant les tables sources pour la vue matérialisée
- Privilèges USE CATALOG et USE SCHEMA sur le catalogue cible et le schéma pour la vue matérialisée
- Privilèges CREATE TABLE et CREATE MATERIALIZED VIEW sur le schéma contenant la vue matérialisée
Pour actualiser une vue matérialisée, vous devez disposer du REFRESH privilège sur la vue matérialisée.

Votre espace de travail doit se trouver dans une région qui prend en charge les entrepôts SQL serverless.

Conditions requises pour interroger des vues matérialisées :

Vous devez être le propriétaire de la vue matérialisée, ou avoir SELECT sur la vue matérialisée, ainsi que USE SCHEMA et USE CATALOG sur ses parents.
Vous devez utiliser l’une des ressources de calcul suivantes :
- Entrepôt SQL
- Interfaces de pipelines déclaratifs Spark Lakeflow
- Calcul du mode d’accès standard (anciennement mode d’accès partagé)
- Mode d’accès dédié (anciennement mode d’accès utilisateur unique) sur Databricks Runtime 15.4 et versions ultérieures, tant que l’espace de travail est activé pour le calcul serverless. Consultez le contrôle d’accès affiné sur le calcul dédié.
  
  Si vous êtes le propriétaire de la vue matérialisée, vous pouvez utiliser une ressource de calcul en mode d’accès dédié qui exécute Databricks Runtime entre 14.3 et versions ultérieures.

Pour en savoir plus sur les autres restrictions relatives à l’utilisation des vues matérialisées, consultez Limitations.

Créer une vue matérialisée

Les opérations de vue matérialisée de Databricks SQL utilisent le entrepôt Databricks SQL pour créer et charger des données dans la vue matérialisée. La création d’une vue matérialisée est une opération synchrone, ce qui signifie que la commande CREATE MATERIALIZED VIEW se bloque jusqu’à ce que la vue matérialisée soit créée et que le chargement initial des données soit terminé. Un pipeline serverless est automatiquement créé pour chaque vue matérialisée Databricks SQL. Lorsque la vue matérialisée est actualisée, le pipeline traite cette actualisation.

Pour créer une vue matérialisée, utilisez l’instruction CREATE MATERIALIZED VIEW. Pour envoyer une instruction de création, utilisez l’éditeur SQL dans l’interface utilisateur Azure Databricks, l’interface CLI Databricks SQL ou l’API Databricks SQL.

L’utilisateur qui crée une vue matérialisée est le propriétaire de la vue matérialisée.

L’exemple suivant crée la vue matérialisée mv1 à partir de la table de base base_table1 :

-- This query defines the materialized view:
CREATE OR REPLACE MATERIALIZED VIEW mv1
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

Lorsque vous créez une vue matérialisée à l’aide de l’instruction CREATE OR REPLACE MATERIALIZED VIEW , l’actualisation initiale des données et la population commencent immédiatement. Cela ne consomme pas de calcul SQL Warehouse. Au lieu de cela, un pipeline serverless est utilisé pour la création et les actualisations suivantes.

Les commentaires de colonne d’une table de base sont automatiquement propagés à la nouvelle vue matérialisée lors de la création uniquement. Pour ajouter une planification, des contraintes de table ou d’autres propriétés, modifiez la définition de vue matérialisée (la requête SQL).

La même instruction SQL actualise une vue matérialisée si elle est appelée une heure ultérieure ou selon une planification. Une actualisation effectuée de cette façon agit comme toute autre actualisation. Pour plus d’informations, consultez Actualiser une vue matérialisée.

Pour en savoir plus sur la configuration d’une vue matérialisée, consultez Configurer des vues matérialisées dans Databricks SQL. Pour en savoir plus sur la syntaxe complète pour créer une vue matérialisée, consultez CREATE MATERIALIZED VIEW. Pour en savoir plus sur le chargement de données dans différents formats et à partir de différents emplacements, consultez Charger des données dans des pipelines.

Charger des données à partir de systèmes externes

Les vues matérialisées peuvent être créées sur des données externes à l’aide de Lakehouse Federation pour les sources de données prises en charge. Pour plus d’informations sur le chargement de données à partir de sources non prises en charge par Lakehouse Federation, consultez Options de format de données. Pour obtenir des informations générales sur le chargement des données, notamment des exemples, consultez Charger des données dans des pipelines.

Masquer les données sensibles

Vous pouvez utiliser des vues matérialisées pour masquer les données sensibles aux utilisateurs accédant à la table. Pour ce faire, vous devez créer la requête afin qu’elle n’inclue pas ces données dans la première place. Toutefois, vous pouvez également masquer des colonnes ou filtrer des lignes en fonction des autorisations de l’utilisateur interrogeant. Par exemple, vous pouvez masquer la tax_id colonne pour les utilisateurs qui ne se trouvent pas dans le groupe HumanResourcesDept. Pour ce faire, utilisez la syntaxe ROW FILTER et MASK lors de la création de la vue matérialisée. Pour plus d’informations, consultez Filtres de lignes et masques de colonne.

Actualiser une vue matérialisée

L’actualisation d’une vue matérialisée met à jour la vue pour refléter les dernières modifications apportées à la table de base au moment de l’actualisation.

Lorsque vous définissez une vue matérialisée, l’instruction CREATE OR REPLACE MATERIALIZED VIEW est utilisée à la fois pour créer la vue et pour l’actualiser pour toutes les actualisations planifiées. Vous pouvez également utiliser l’instruction REFRESH MATERIALIZED VIEW pour actualiser la vue matérialisée sans avoir à fournir à nouveau la requête. Consultez REFRESH (MATERIALIZED VIEW ou STREAMING TABLE) pour plus d’informations sur la syntaxe SQL et les paramètres de cette commande. Pour en savoir plus sur les types de vues matérialisées qui peuvent être actualisées de manière incrémentielle, consultez Actualisation incrémentielle pour les vues matérialisées.

Pour envoyer une instruction d’actualisation, utilisez l’éditeur SQL dans l’interface utilisateur Azure Databricks, un notebook attaché à un entrepôt SQL, l’interface CLI Databricks SQL ou l’API Databricks SQL.

Le propriétaire et tout utilisateur à qui a été accordé le privilège REFRESH sur la table peuvent actualiser la vue matérialisée.

L’exemple suivant actualise la vue matérialisée mv1 :

REFRESH MATERIALIZED VIEW mv1;

L’opération est synchrone par défaut, ce qui signifie que la commande se bloque jusqu’à ce que l’opération d’actualisation soit terminée. Pour effectuer une actualisation asynchrone, vous pouvez ajouter le ASYNC mot clé :

REFRESH MATERIALIZED VIEW mv1 ASYNC;

Comment les vues matérialisées Databricks SQL sont-elles actualisées ?

Les vues matérialisées créent et utilisent automatiquement des pipelines serverless pour traiter les opérations d’actualisation. L’actualisation est gérée par le pipeline et la mise à jour est surveillée par l’entrepôt SQL Databricks utilisé pour créer la vue matérialisée. Les vues matérialisées peuvent être mises à jour à l’aide d’un pipeline qui s’exécute selon un calendrier. Les vues matérialisées créées par Databricks SQL sont toujours exécutées en mode déclenché. Consultez Mode pipeline déclenché ou continu.

Les vues matérialisées sont actualisées à l’aide de l’une des deux méthodes.

Actualisation incrémentielle : le système évalue la requête de la vue pour identifier les modifications qui se sont produites après la dernière mise à jour et fusionne uniquement les données nouvelles ou modifiées.
Actualisation complète : si une actualisation incrémentielle ne peut pas être effectuée ou n’est pas rentable, le système exécute l’intégralité de la requête et remplace les données existantes dans la vue matérialisée par les nouveaux résultats.

La structure de la requête et le type de données sources déterminent si l’actualisation incrémentielle est prise en charge. Pour prendre en charge l’actualisation incrémentielle, les données sources doivent être stockées dans des tables Delta, avec le suivi des lignes et le flux de données de modification activés. Pour voir si une requête est incrémentielle, utilisez l’instruction Databricks SQL EXPLAIN CREATE MATERIALIZED VIEW . Après avoir créé une vue matérialisée, vous pouvez surveiller son comportement d’actualisation pour vérifier s’il est mis à jour de façon incrémentielle ou via une actualisation complète.

Par défaut, Azure Databricks utilise un modèle de coût pour choisir l’option plus rentable entre l’actualisation complète et incrémentielle. Vous pouvez remplacer ce comportement pour préférer les actualisations incrémentielles ou complètes en définissant une REFRESH POLICY définition SQL de la vue matérialisée.

Pour plus d’informations sur les types d’actualisation et sur la façon d’optimiser les actualisations incrémentielles, consultez Actualisation incrémentielle pour les vues matérialisées.

Actualisations asynchrones

Par défaut, les opérations d’actualisation sont effectuées de manière synchrone. Vous pouvez également définir une opération d’actualisation asynchrone. Cela peut être défini à l’aide de la commande Refresh avec le ASYNC mot clé. Voir REFRESH (MATERIALIZED VIEW ou STREAMING TABLE). Le comportement associé à chaque approche est le suivant :

Synchrone : une actualisation synchrone empêche les autres opérations de continuer tant que l’actualisation n’est pas terminée. Si le résultat est nécessaire pour l’étape suivante, par exemple lors du séquencement des opérations d’actualisation dans des outils d’orchestration tels que Lakeflow Jobs, utilisez une actualisation synchrone. Pour orchestrer des vues matérialisées avec un travail, utilisez le type de tâche SQL. Consultez les offres d'emploi Lakeflow.
Asynchrone : une actualisation asynchrone démarre un travail en arrière-plan sur le calcul serverless lorsqu’une actualisation de vue matérialisée commence, ce qui permet à la commande de retourner avant la fin du chargement des données. Ce type d’actualisation peut économiser sur le coût, car l’opération ne contient pas nécessairement de capacité de calcul dans l’entrepôt où la commande est lancée. Si l’actualisation devient inactive et qu’aucune autre tâche n’est en cours d’exécution, l’entrepôt peut s’arrêter pendant que l’actualisation utilise d’autres calculs disponibles. De plus, les actualisations asynchrones prennent en charge le démarrage de plusieurs opérations en parallèle.

Planifier les actualisations de vue matérialisée

Vous pouvez configurer une vue matérialisée Databricks SQL pour qu’elle s’actualise automatiquement en fonction d’une planification définie ou pour se déclencher lorsque des données en amont sont modifiées. Le tableau suivant présente les différentes options de planification des actualisations.

Méthode	Descriptif	Exemple de cas d’usage
Manuel	Actualisation à la demande à l’aide d’une instruction SQL `REFRESH` ou via l’interface utilisateur de l’espace de travail.	Développement, test, mises à jour ad hoc.
`TRIGGER ON UPDATE`	Définissez la vue matérialisée à actualiser automatiquement lorsque les données en amont changent.	Charges de travail de production avec des SLA de rafraîchissement des données ou des périodes de rafraîchissement imprévisibles.
`SCHEDULE`	Définissez la vue matérialisée à actualiser à intervalles de temps définis.	Exigences d’actualisation prévisibles basées sur le temps.
Tâche SQL dans un travail	L’actualisation est orchestrée par les tâches Lakeflow.	Pipelines complexes avec dépendances entre systèmes.

Actualisation manuelle

Pour actualiser manuellement une vue matérialisée, vous pouvez appeler une actualisation à partir de Databricks SQL ou utiliser l’interface utilisateur de l’espace de travail.

Instruction REFRESH

Pour actualiser un pipeline à l’aide de Databricks SQL :

Dans Éditeur SQL, exécutez l’instruction suivante :
```
REFRESH MATERIALIZED VIEW <mv-name>;
```

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

Interface utilisateur de l’espace de travail

Pour actualiser un pipeline dans l’interface utilisateur de l’espace de travail :

Dans l’espace de travail Azure Databricks, cliquez sur Travaux et pipelines.
Sélectionnez le pipeline que vous souhaitez actualiser dans la liste.
Cliquez sur le bouton Démarrer.

À mesure que le pipeline s’actualise, vous verrez les mises à jour dans l’interface utilisateur.

Déclencheur lors de la mise à jour

La TRIGGER ON UPDATE clause actualise automatiquement une vue matérialisée lorsque les données sources en amont changent. Cela élimine la nécessité de coordonner les planifications entre les pipelines. La vue matérialisée reste à jour sans que l'utilisateur ait besoin de savoir quand les tâches en amont sont terminées ou de gérer une logique de planification complexe.

Il s’agit de l’approche recommandée pour les charges de travail de production, en particulier lorsque les dépendances en amont ne s’exécutent pas selon des planifications prévisibles. Une fois configuré, la vue matérialisée surveille ses tables sources et s’actualise automatiquement lorsque les modifications apportées à l’une des sources en amont sont détectées.

Limitations

Limites de dépendance en amont : une vue matérialisée peut surveiller un maximum de 10 tables en amont et 30 vues en amont. Pour plus de dépendances, fractionnez la logique entre plusieurs vues matérialisées.
Limites de l’espace de travail : un maximum de 1 000 vues TRIGGER ON UPDATE matérialisées pouvant exister par espace de travail. Contactez le support Databricks si plus de 1 000 vues matérialisées sont nécessaires.
Intervalle minimal : l’intervalle de déclencheur minimal est de 1 minute.

Les exemples suivants montrent comment définir un déclencheur lors de la mise à jour lors de la définition d’une vue matérialisée.

Créer une vue matérialisée avec déclencheur lors de la mise à jour

Pour créer une vue matérialisée qui s’actualise automatiquement lorsque les données sources changent, incluez la TRIGGER ON UPDATE clause dans l’instruction CREATE MATERIALIZED VIEW .

L’exemple suivant crée une vue matérialisée qui agrège les commandes des clients et les actualise chaque fois que la source customers ou orders les tables sont mises à jour :

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.customer_orders
  TRIGGER ON UPDATE
AS SELECT
    c.customer_id,
    c.name,
    count(o.order_id) AS order_count
FROM catalog.schema.customers c
JOIN catalog.schema.orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name;

Fréquence de rafraîchissement de l'étranglement

Si les données en amont sont actualisées fréquemment, utilisez cette option AT MOST EVERY pour limiter la fréquence d’actualisation de l’affichage et limiter les coûts de calcul. Cela 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 terme INTERVAL est requis avant la valeur temporelle.

L’exemple suivant limite l’affichage matérialisé à actualiser au maximum toutes les 5 minutes, même si les données sources changent plus fréquemment :

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.customer_orders
  TRIGGER ON UPDATE AT MOST EVERY INTERVAL 5 MINUTES
AS SELECT
    c.customer_id,
    c.name,
    count(o.order_id) AS order_count
FROM catalog.schema.customers c
JOIN catalog.schema.orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name;

Actualisation planifiée

Les planifications d’actualisation peuvent être définies directement dans la définition de vue matérialisée pour actualiser la vue à intervalles de temps fixes. Cette approche est utile lorsque la cadence de mise à jour des données est connue et que le minutage d’actualisation prévisible est souhaité.

Lorsqu’il existe une planification d’actualisation, vous pouvez toujours exécuter une actualisation manuelle à tout moment si vous avez besoin de données mises à jour.

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

Pour plus d’informations sur la syntaxe et l’utilisation de la SCHEDULE clause, consultez CREATE MATERIALIZED VIEW la clause SCHEDULE.

Lorsqu’une planification est créée, un nouveau travail Databricks est automatiquement configuré pour traiter la mise à jour.

Pour afficher la planification, effectuez l’une des opérations suivantes :

Exécutez l’instruction DESCRIBE EXTENDED à partir de l’éditeur SQL dans l’interface utilisateur Azure Databricks. Voir DESCRIBE TABLE.
Utilisez l’Explorateur de catalogues pour afficher la vue matérialisée. La planification est listée sous l’onglet Vue d’ensemble, sous État d’actualisation. Consultez Qu’est-ce que Catalog Explorer ?.

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

Planifier chaque intervalle de temps

Cet exemple planifie une actualisation une fois par heure :

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 une actualisation toutes les 15 minutes, au quart d’heure du fuseau horaire UTC :

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 travail

Les actualisations de vues matérialisées peuvent être orchestrées avec les Jobs Databricks en créant des tâches SQL qui incluent REFRESH MATERIALIZED VIEW commandes. Cette approche intègre l'actualisation des vues matérialisées dans les workflows d’orchestration de travaux existants.

Il existe deux façons de créer une tâche pour actualiser les vues matérialisées :

À partir de l’Éditeur SQL : écrivez la REFRESH MATERIALIZED VIEW commande et cliquez sur le bouton Planifier pour créer un travail directement à partir de la requête.
À partir de l'UI des travaux : créez un nouveau travail, ajoutez un type de tâche SQL et joignez une requête SQL ou un notebook avec la commande REFRESH MATERIALIZED VIEW.

L’exemple suivant montre l’instruction SQL dans une tâche SQL qui actualise une vue matérialisée :

REFRESH MATERIALIZED VIEW catalog.schema.daily_sales_summary;

Cette approche est appropriée lorsque :

Les pipelines à plusieurs étapes complexes ont des dépendances entre les systèmes.
L’intégration à l’orchestration des tâches existante est requise.
Les alertes et la surveillance au niveau du travail sont nécessaires.

Les tâches SQL utilisent à la fois l’entrepôt SQL attaché au travail et le calcul serverless qui exécute l’actualisation. Si l’utilisation de la planification basée sur la définition de vue matérialisée répond aux exigences, basculez vers TRIGGER ON UPDATE ou SCHEDULE pour simplifier le flux de travail.

Ajouter une planification à une vue matérialisée existante

Pour définir la planification après la création, utilisez l’instruction ALTER MATERIALIZED VIEW :

-- Alters the schedule to refresh the materialized view when its upstream data
-- gets updated.
ALTER MATERIALIZED VIEW sales
  ADD TRIGGER ON UPDATE;

Modifier une planification ou un déclencheur existant

Si une vue matérialisée a déjà une planification ou un déclencheur associé, utilisez ALTER SCHEDULE ou ALTER TRIGGER ON UPDATE pour modifier la configuration d’actualisation. Cela s’applique que vous changiez d’une planification à une autre, d’un déclencheur à un autre ou d’un basculement entre une planification et un déclencheur.

L’exemple suivant modifie une planification existante pour qu’elle s’actualise toutes les 4 heures :

ALTER MATERIALIZED VIEW catalog.schema.my_view
  ALTER SCHEDULE EVERY 4 HOURS;

Supprimer une planification ou un déclencheur

Pour supprimer une planification, utilisez ALTER ... DROP:

ALTER MATERIALIZED VIEW catalog.schema.my_view
  DROP SCHEDULE;

Arrêter une actualisation active

Pour arrêter une actualisation active dans l’interface utilisateur Azure Databricks, dans la page des détails du pipeline, cliquez sur Arrêter pour arrêter la mise à jour du pipeline. Vous pouvez également arrêter l’actualisation avec l’interface CLI Databricks ou l’opération POST /api/2.0/pipelines/{pipeline_id}/stop dans l’API Pipelines.

Délais d’expiration des actualisations

Les actualisations de vue matérialisées sont exécutées avec un délai d’expiration qui limite la durée pendant laquelle elles peuvent s’exécuter. Pour les vues matérialisées créées ou mises à jour le 14 août 2025 ou après, le délai d’expiration est capturé lorsque vous la mettez à jour en exécutant CREATE OR REFRESH:

Si une STATEMENT_TIMEOUT valeur est définie, cette valeur est utilisée. Voir STATEMENT_TIMEOUT.
Sinon, le délai d’expiration de l’entrepôt SQL utilisé pour exécuter la commande est utilisé.
Si l’entrepôt n’a pas de délai d’expiration configuré, une valeur par défaut de 2 jours s’applique.

Le délai d’attente est utilisé sur la création initiale, mais également sur les actualisations planifiées qui suivent.

Pour les vues matérialisées qui ont été mises à jour 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 une actualisation de la vue matérialisée Vous pouvez contrôler explicitement la durée pendant laquelle une actualisation de vue matérialisée est autorisée à 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 de la vue :

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;

Cette opération configure l'affichage matérialisé pour qu'il soit actualisé toutes les 12 heures. Si une actualisation prend plus de 6 heures, elle est abandonnée et attend l'actualisation planifiée suivante.

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

Les délais d’expiration sont synchronisés uniquement lorsque vous exécutez CREATE OR REFRESHexplicitement .

Les actualisations planifiées continuent d'utiliser le temps d'attente enregistré lors du plus récent CREATE OR REFRESH.
La seule modification du délai d’expiration de l’entrepôt n’affecte pas les rafraîchissements programmés existants.

Important

Après avoir modifié un délai d’expiration de l’entrepôt, réexécutez la commande CREATE OR REFRESH pour appliquer le nouveau délai d’expiration aux actualisations planifiées ultérieures.

Effacer définitivement les enregistrements d’une vue matérialisée avec activation des vecteurs de suppression

Important

La prise en charge de l’instruction REORG avec des vues matérialisées est en préversion publique.

Note

L’utilisation d’une instruction REORG avec une vue matérialisée nécessite Databricks Runtime 15.4 et versions ultérieures.
Bien que vous puissiez utiliser l’instruction REORG avec n’importe quelle vue matérialisée, elle n’est nécessaire que lors de la suppression d’enregistrements d’une vue matérialisée avec des vecteurs de suppression activés . La commande n’a aucun effet lorsqu’elle est utilisée avec une vue matérialisée sans vecteurs de suppression activés.

Pour supprimer physiquement les enregistrements du stockage sous-jacent pour une vue matérialisée avec des vecteurs de suppression activés, comme pour la conformité RGPD, des étapes supplémentaires doivent être prises pour s’assurer qu’une VACUUM opération s’exécute sur les données de la vue matérialisée.

Pour supprimer physiquement des enregistrements :

Exécutez une instruction REORG sur la vue matérialisée, en spécifiant le paramètre APPLY (PURGE). Par exemple, REORG TABLE <materialized-view-name> APPLY (PURGE);. Voir REORG TABLE.
Attendez que la période de rétention des données de la vue matérialisée passe. La période de rétention des données par défaut est de sept jours, mais elle peut être configurée avec la propriété de table delta.deletedFileRetentionDuration. Voir Configurer la conservation des données pour des requêtes de voyage dans le temps.
Utilisez REFRESH sur la vue matérialisée. Consultez Actualiser une vue matérialisée. Dans les 24 heures de l’opération REFRESH , les tâches de maintenance du pipeline, y compris l’opération VACUUM requise pour s’assurer que les enregistrements sont supprimés définitivement, sont exécutées automatiquement.

Supprimer une vue matérialisée

Note

Pour soumettre la commande de suppression d’une vue matérialisée, vous devez être le propriétaire de cette vue matérialisée ou avoir le privilège MANAGE sur la vue matérialisée.

Pour supprimer une vue matérialisée, utilisez l’instruction DROP VIEW. Pour envoyer une instruction DROP, vous pouvez utiliser l’éditeur SQL dans l’interface utilisateur Azure Databricks, l’interface CLI Databricks SQL ou l’API Databricks SQL. L’exemple suivant supprime la vue matérialisée mv1 :

DROP MATERIALIZED VIEW mv1;

Vous pouvez également utiliser l’Explorateur de catalogues pour supprimer une vue matérialisée.

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 vue matérialisée.
Ouvrez l’élément Tables sous le schéma que vous avez sélectionné, puis cliquez sur la vue matérialisée.
Dans sélectionnez Supprimer.

Comprendre les coûts d’une vue matérialisée

Étant donné qu’une vue matérialisée s’exécute dans un calcul sans serveur, en dehors du calcul que vous avez configuré pour un notebook ou une tâche, vous pouvez vous demander comment comprendre les coûts associés à celui-ci. L’utilisation de la vue matérialisée est suivie par la consommation de DBU. Pour en savoir plus, consultez Quelle est la consommation de DBU d’une vue matérialisée ou d’une table de diffusion en continu ?

Activation du suivi des lignes

Pour prendre en charge les actualisations incrémentielles des tables Delta, le suivi des lignes doit être activé pour ces tables sources. Si vous recréez une table source, vous devez réactiver le suivi des lignes.

L’exemple suivant montre comment activer le suivi des lignes sur une table :

ALTER TABLE source_table SET TBLPROPERTIES (delta.enableRowTracking = true);

Pour plus d’informations, consultez Suivi de lignes avec Databricks

Limites

Pour connaître les besoins en matière de calcul et d’espace de travail, consultez Configuration requise.
Pour connaître les exigences d’actualisation incrémentielle, consultez Actualisation incrémentielle pour les vues matérialisées.
Les vues matérialisées ne prennent pas en charge les colonnes d’identité ou les clés de substitution.
Si une vue matérialisée utilise un agrégat de somme sur une colonne pouvant accepter la valeur NULL et qu’il ne reste que des valeurs NULL dans cette colonne, la valeur d’agrégation résultante de la vue matérialisée est zéro au lieu de NULL.
Vous ne pouvez pas lire le flux des changements de données depuis une vue matérialisée.
Les requêtes de voyage dans le temps ne sont pas prises en charge sur les vues matérialisées.
Les fichiers sous-jacents prenant en charge les vues matérialisées peuvent inclure des données provenant de tables en amont (y compris d’éventuelles informations d’identification personnelle) qui n’apparaissent pas dans la définition de la vue matérialisée. Ces données sont automatiquement ajoutées au stockage sous-jacent pour prendre en charge l’actualisation incrémentielle des vues matérialisées. Étant donné que les fichiers sous-jacents d’une vue matérialisée peuvent risquer d’exposer des données provenant de tables en amont qui ne font pas partie du schéma de vue matérialisée, Databricks recommande de ne pas partager le stockage sous-jacent avec des consommateurs en aval non approuvés. Par exemple, supposez que la définition d’une vue matérialisée inclut une clause COUNT(DISTINCT field_a). Même si la définition de vue matérialisée inclut uniquement la clause d’agrégation COUNT DISTINCT, les fichiers sous-jacents contiennent une liste des valeurs réelles de field_a.
Vous pourriez encourir des frais de calcul sans serveur, même si vous utilisez ces fonctionnalités sur un calcul dédié.

Si vous devez utiliser une connexion Azure Private Link avec votre vue matérialisée, contactez votre représentant Databricks.

Accéder aux vues matérialisées à partir de clients externes

Pour accéder aux vues matérialisées à partir de clients Delta Lake ou Iceberg externes qui ne prennent pas en charge les API ouvertes, vous pouvez utiliser le mode de compatibilité. Le mode de compatibilité crée une version en lecture seule de votre vue matérialisée accessible par n’importe quel client Delta Lake ou Iceberg.

Rétroaction

Cette page a-t-elle été utile ?

Last updated on 2026-02-04