Utiliser des vues matérialisées autonomes
Les vues matérialisées autonomes précalculent et mettent en cache les résultats des query pour améliorer les performances et réduire le coût de vos charges de travail de traitement et d'analyse de données.
Vous pouvez créer et refresh des vues matérialisées autonomes à partir d’un warehouse Databricks SQL, ou d’un Notebook exécuté sur le compute général serverless. Pour plus de détails sur les différences entre les deux options de compute, consultez Exigences relatives aux pipelines autonomes.
Pour créer et refresh des vues matérialisées autonomes avec Python à partir d’un Notebook, voir Utiliser Python avec des pipelines autonomes.
Que sont les vues matérialisées autonomes ?
Une vue matérialisée autonome est une table gérée par Unity Catalog qui stocke physiquement les résultats d’une query, définis en dehors d’un pipeline Lakeflow. Contrairement aux vues standard qui compute les résultats à la demande, les vues matérialisées mettent en cache les résultats et les actualisent à mesure que les tables sources sous-jacentes sont modifiées, que ce soit selon un calendrier ou automatiquement.
Les vues matérialisées sont particulièrement adaptées pour fournir des résultats précalculés aux tableaux de bord et aux rapports, ainsi que pour les transformations qui nettoient, enrichissent et dénormalisent les tables de base. En précalculant des query coûteuses ou fréquemment utilisées, les vues matérialisées réduisent la latence des query et la consommation des Ressources. Dans de nombreux cas, elles peuvent compute les modifications de manière incrémentielle à partir des tables sources, améliorant ainsi l'efficacité et l'expérience de l'utilisateur final.
Pour les charges de travail ETL (extraction, transformation et chargement) par batch qui écrasent périodiquement une fenêtre de temps ou une partition, comme les corrections, les données arrivant en retard et les suppressions pour conformité, utilisez plutôt un flux REPLACE WHERE. Consultez Quand utiliser REPLACE WHERE plutôt que des vues matérialisées.
Voici quelques cas d’utilisation courants des vues matérialisées :
- Garder un tableau de bord de BI à jour avec une latence de query utilisateur final minimale.
- Construction de transformations complexes en couches.
- Tous les cas d’usage qui exigent des performances cohérentes avec des insights à jour.
Lorsque vous créez une vue matérialisée dans un warehouse Databricks SQL, un pipeline Serverless est créé pour traiter la création et les refresh de la vue matérialisée. Vous pouvez surveiller l’état des opérations de refresh dans l’explorateur de catalogue. Voir Afficher les détails avec DESCRIBE EXTENDED.
Exigences
Pour les options de compute, les autorisations et les autres exigences relatives à la création, à l’actualisation et à l’interrogation de vues matérialisées autonomes, consultez Configuration requise pour les pipelines autonomes.
Pour en savoir plus sur les autres restrictions liées à l’utilisation des vues matérialisées, consultez Limitations.
Créer une vue matérialisée
Les opérations sur les vues matérialisées autonomes CREATE utilisent un Databricks SQL warehouse 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. Cela signifie que la commande CREATE MATERIALIZED VIEW 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 autonome. Lorsque la vue matérialisée est refresh, le pipeline traite le refresh.
Pour créer une vue matérialisée, utilisez l'instruction CREATE MATERIALIZED VIEW. Pour soumettre une instruction de création, utilisez l'éditeur SQL dans l'interface utilisateur de Databricks, la CLI Databricks SQL ou l' API Databricks SQL.
L’utilisateur qui crée une vue matérialisée en est le propriétaire.
Vue matérialisée ad hoc
L’exemple suivant montre comment créer 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;
Vue matérialisée Trigger
L'exemple suivant crée une vue matérialisée qui refresh automatiquement chaque fois que les données sources en amont changent à l'aide de TRIGGER ON UPDATE. Utilisez cette approche pour les workloads de production, en particulier lorsque les dépendances en amont ne s'exécutent pas selon des plannings prévisibles.
-- Refresh automatically when the source table is updated.
CREATE OR REPLACE MATERIALIZED VIEW mv_trigger
TRIGGER ON UPDATE
AS SELECT
date,
sum(sales) AS sum_of_sales
FROM
base_table1
GROUP BY
date;
Vue matérialisée planifiée
L’exemple suivant crée une vue matérialisée avec un calendrier de refresh CRON quotidien à 3h30 UTC. Les expressions et les agrégats de la clause SELECT doivent utiliser des alias. GROUP BY références de colonne ne nécessitent pas d'alias.
-- Refresh nightly at 3:30 AM UTC.
-- The cron expression uses six space-separated fields: seconds minutes hours day-of-month month day-of-week
-- Use '?' for either day-of-month or day-of-week to leave it unspecified.
CREATE OR REPLACE MATERIALIZED VIEW daily_revenue_by_region
SCHEDULE CRON '0 30 3 * * ?' AT TIME ZONE 'UTC'
AS SELECT
date_trunc('day', order_time) AS sales_date,
region,
sum(revenue) AS total_revenue,
count(*) AS order_count
FROM
orders
GROUP BY sales_date, region;
Pour plus d'options de planification, y compris la syntaxe SCHEDULE EVERY et d'autres exemples CRON, consultez Planifier les refresh.
Lorsque vous créez une vue matérialisée à l'aide de l'instruction CREATE OR REPLACE MATERIALIZED VIEW, le refresh initial et le remplissage des données commencent immédiatement. Cela ne consomme pas de compute SQL Warehouse. Au lieu de cela, un pipeline Serverless est utilisé pour la création et les refresh ultérieurs. Consultez Comment sont actualisées les vues matérialisées autonomes ?.
Les commentaires de colonne sur une table de base sont automatiquement propagés à la nouvelle vue matérialisée uniquement lors de la création. Pour ajouter une planification, des contraintes de table ou d'autres propriétés, modifiez la définition de la vue matérialisée (la query SQL).
La même instruction SQL effectue le refresh d’une vue matérialisée si elle est appelée ultérieurement, ou selon un calendrier. Un refresh effectué de cette manière agit comme n’importe quel autre refresh. Pour plus de détails, consultez refresh 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 autonomes. Pour en savoir plus sur la syntaxe complète de création d'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 la section Charger des données dans les 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 des informations générales sur le chargement des données, y compris 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 des données sensibles aux utilisateurs qui accèdent à la table. Une solution consiste à créer la query de manière à ce qu'elle n'inclue pas ces données dès le départ. Mais vous pouvez aussi masquer des colonnes ou filtrer des lignes selon les permissions de l'utilisateur qui lance la requête. Par exemple, vous pouvez masquer la colonne tax_id aux utilisateurs qui ne font pas partie du 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 ligne et masques de colonne.
Effectuer le refresh d’une vue matérialisée
refresh une vue matérialisée met à jour la vue pour refléter les derniers changements apportés à la table de base au moment de l’refresh.
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 le refresh lors de tout refresh planifié. Vous pouvez également utiliser l’instruction REFRESH MATERIALIZED VIEW pour refresh la vue matérialisée sans avoir à fournir à nouveau la query. Voir REFRESH (MATERIALIZED VIEW or STREAMING TABLE) pour plus de détails sur la syntaxe SQL et les parameter de cette commande. Pour en savoir plus sur les types de vues matérialisées qui peuvent être refresh de manière incrémentielle, consultez refresh incrémentielle pour les vues matérialisées.
Pour soumettre une instruction de refresh, utilisez l’éditeur SQL de l’interface Databricks, un notebook associé à un SQL warehouse, la CLI Databricks SQL ou l’ API Databricks SQL.
Le propriétaire et tout utilisateur auquel le privilège REFRESH a été accordé sur la table peuvent effectuer le refresh de la vue matérialisée.
L’exemple suivant effectue un refresh de la vue matérialisée mv1 :
REFRESH MATERIALIZED VIEW mv1;
L'opération est synchrone par default, ce qui signifie que la commande se bloque jusqu'à ce que l'opération de refresh soit terminée. Pour effectuer un refresh de manière asynchrone, vous pouvez ajouter le mot-clé ASYNC :
REFRESH MATERIALIZED VIEW mv1 ASYNC;
Pour savoir comment planifier un refresh, consultez Planifier les refresh.
Comment les vues matérialisées autonomes sont-elles rafraîchies ?
Les vues matérialisées créent et utilisent automatiquement des pipelines Serverless pour traiter les opérations de refresh. Le refresh est géré par le pipeline et la mise à jour est surveillée par le warehouse Databricks SQL 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 une planification. Les vues matérialisées autonomes ne s’exécutent qu’en mode Trigger. Voir Mode de pipeline Trigger ou continu.
Les refresh programmés peuvent être accompagnés de notifications de mise à jour, et vous pouvez définir le mode de performance pour le refresh.
Actualisation refresh
Les vues matérialisées sont actualisées selon l’une des deux méthodes suivantes.
- Actualisation refresh - Le système évalue la query de la vue pour identifier les changements qui ont eu lieu après la dernière mise à jour et fusionne uniquement les données nouvelles ou modifiées.
- Full refresh : si une actualisation incrémentielle ne peut pas être effectuée ou n’est pas rentable, le système exécute la query entière et remplace les données existantes dans la vue matérialisée par les nouveaux résultats.
La structure de la query et le type de données source déterminent si l'refresh incrémentielle est prise en charge. Pour prendre en charge l'refresh incrémentielle, les données source doivent être stockées dans des tables Delta avec le suivi des lignes activé. Il est recommandé d'activer l'alimentation en données de modification pour améliorer les performances d'refresh incrémentielle. Pour savoir si une query est incrémentielle, utilisez l'instruction EXPLAIN CREATE MATERIALIZED VIEW de Databricks SQL. Une fois que vous avez créé une vue matérialisée, vous pouvez surveiller son comportement de refresh pour vérifier si elle est mise à jour de manière incrémentielle ou par une refresh complète.
Par default, Databricks utilise un modèle de coût pour choisir l'option la plus rentable entre une refresh complète et une refresh incrémentielle. Vous pouvez outrepasser ce comportement pour préférer des refresh incrémentiels ou complets en définissant un REFRESH POLICY dans votre définition SQL de la vue matérialisée.
Pour plus de détails sur les types de refresh et pour savoir comment optimiser les refresh incrémentiels, consultez Refresh incrémentiel pour les vues matérialisées.
refresh asynchrones
default, les Opérations de refresh sont effectuées de manière synchrone. Vous pouvez également définir une opération de refresh pour qu’elle se produise de manière asynchrone. Cela peut être défini à l'aide de la commande refresh avec le mot-clé ASYNC. Voir REFRESH (MATERIALIZED VIEW or STREAMING TABLE). Le comportement associé à chaque approche est le suivant :
- Synchrone : une refresh synchrone empêche les autres Opérations de se poursuivre jusqu'à ce que l'refresh soit terminée. Si le résultat est nécessaire pour l'étape suivante, par exemple lors du séquençage d'opérations de refresh dans des outils d'orchestration tels que Lakeflow Jobs, utilisez une refresh synchrone. Pour orchestrer des vues matérialisées avec un job, utilisez le type de tâche SQL . Voir Lakeflow Jobs.
- Asynchrone : une refresh asynchrone start une Job en arrière-plan sur le compute Serverless lorsqu’une refresh de vue matérialisée start, ce qui permet à la commande de revenir avant la fin du chargement des données. Ce type de refresh permet de réduire les coûts, car l'opération ne monopolise pas nécessairement la capacité de compute du warehouse à partir duquel la commande est initiée. Si le refresh devient inactive et qu'aucune autre tâche n'est en cours d'exécution, le warehouse peut s'arrêter tandis que le refresh utilise d'autres ressources de compute disponibles. En outre, les refresh asynchrones prennent en charge le lancement de plusieurs opérations en parallèle.
Supprimer définitivement les enregistrements d’une vue matérialisée avec des vecteurs de suppression activés
Aperçu
La prise en charge de l'instruction REORG avec des vues matérialisées est disponible en Prévisualisation publique.
- L'utilisation d'une instruction
REORGavec une vue matérialisée nécessite Databricks Runtime 15.4 et versions ultérieures. - Bien que vous puissiez utiliser l'instruction
REORGavec n'importe quelle vue matérialisée, elle n'est nécessaire que pour supprimer des 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 des enregistrements du stockage sous-jacent d'une vue matérialisée pour laquelle les vecteurs de suppression sont activés, par exemple dans le cadre de la conformité au GDPR, des étapes supplémentaires doivent être effectuées pour garantir qu'une opération VACUUM est exécutée sur les données de la vue matérialisée.
Pour supprimer physiquement des enregistrements :
- Exécutez une instruction
REORGsur la vue matérialisée en spécifiant le parameterAPPLY (PURGE). Par exempleREORG 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 soit écoulée. La période de conservation des données default 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 les queries time travel. REFRESHla vue matérialisée. Voir Refresh une vue matérialisée. Dans les 24 heures suivant l’opérationREFRESH, des tâches de maintenance de pipeline, notamment l’opérationVACUUMqui est nécessaire pour garantir la suppression définitive des enregistrements, sont exécutées automatiquement.
Supprimer une vue matérialisée
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 disposer du privilège MANAGE sur cette dernière.
Pour supprimer une vue matérialisée, utilisez l'instruction DROP VIEW. Pour soumettre une instruction DROP, vous pouvez utiliser l’éditeur SQL dans l’interface utilisateur de Databricks, le CLI Databricks SQL ou l’ API Databricks SQL. L’exemple suivant montre comment supprimer la vue matérialisée mv1 :
DROP MATERIALIZED VIEW mv1;
Vous pouvez également utiliser l'Explorateur de catalogue 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 le menu kebab
, sélectionnez Supprimer .
Comprendre les coûts d'une vue matérialisée
Lorsque vous exécutez CREATE MATERIALIZED VIEW ou REFRESH MATERIALIZED VIEW, Databricks crée et exécute automatiquement un pipeline serverless pour traiter l’opération. Ce pipeline est indépendant du Databricks SQL warehouse ou de la ressource de compute à partir de laquelle vous avez soumis la commande. La taille du cluster de votre warehouse ne limite pas le compute ou le coût utilisé par le refresh.
- Le pipeline de refresh s’exécute sur un compute Serverless, facturé en tant que DBU de LakeFlow Pipelines Serverless.
- Le pipeline serverless est séparé de votre warehouse. Le compute de votre warehouse est uniquement utilisé pour coordonner l’opération, pas pour effectuer le traitement des données.
- Le coût est proportionnel au volume de données traitées, pas à la taille de votre SQL warehouse.
- Pour surveiller les coûts de refresh de la vue matérialisée, utilisez des tables système. Voir Quelle est la consommation DBU d'une vue matérialisée ou d'une table de streaming ?.
- Pour afficher le pipeline sous-jacent qui gère votre vue matérialisée :
- Cliquez sur Jobs et pipelines dans la barre latérale gauche de votre Databricks workspace.
- Cliquez sur Type de pipeline . Ensuite, sélectionnez MV/ST pour voir les vues matérialisées autonomes.
Vous pouvez encourir des frais de compute Serverless même lorsque le warehouse d'origine utilise un compute dédié.
Activer le suivi des lignes
Pour prendre en charge les refresh 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 de détails, consultez Suivi des lignes dans Databricks
Limites
-
Pour les options de compute et les prérequis de workspace, voir Prérequis pour les pipelines autonomes.
-
Pour les besoins en refresh incrémentiel, voir refresh incrémentiel pour les vues matérialisées.
-
Les vues matérialisées ne prennent pas en charge les colonnes d'identité ni les clés de substitution.
-
Si une vue matérialisée utilise une agrégation de somme sur une colonne
NULL-able et qu'il ne reste que des valeursNULLdans cette colonne, la valeur d'agrégation résultante des vues matérialisées est zéro au lieu deNULL. -
Vous ne pouvez pas lire un flux de données de modification à partir d’une vue matérialisée, à moins d’activer le flux de données de modification sur chaque vue matérialisée pour laquelle vous en avez besoin. Voir Lire un flux de données de modification à partir d’une vue matérialisée (Bêta).
-
Les query time travel ne sont pas prises en charge sur les vues matérialisées.
-
Les fichiers sous-jacents qui prennent en charge les vues matérialisées peuvent inclure des données provenant de tables en amont (incluant d'éventuelles informations personnellement identifiables) 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. Comme les fichiers sous-jacents d'une vue matérialisée peuvent exposer des données provenant de tables en amont qui ne font pas partie du schéma de la vue matérialisée, Databricks recommande de ne pas partager le stockage sous-jacent avec des consommateurs en aval non approuvés. Supposons, par exemple, que la définition d’une vue matérialisée inclue une clause
COUNT(DISTINCT field_a). Bien que la définition de la vue matérialisée ne comporte que la clause d'agrégationCOUNT DISTINCT, les fichiers sous-jacents contiennent une liste des valeurs réelles defield_a. -
Des frais de compute Serverless peuvent vous être facturés, même si vous utilisez ces fonctionnalités sur un compute dédié.
-
Si vous devez utiliser une connexion AWS PrivateLink 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 APIs 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 à laquelle n'importe quel client Delta Lake ou Iceberg peut accéder.