Utilisez des vues matérialisées autonomes

Les vues matérialisées autonomes pré-calculent et mettent en cache les résultats de query afin d'améliorer les performances et de réduire le coût de vos charges de travail de traitement de données et d'analyse.

Vous pouvez créer et refresh des vues matérialisées autonomes à partir d'un warehouse Databricks SQL, ou à partir d'un Notebook exécuté sur un compute serverless général. Pour plus de détails sur les différences entre les deux options de compute, consultez Exigences pour les pipelines autonomes.

Pour créer et refresh des vues matérialisées autonomes avec Python à partir d'un Notebook, consultez 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éfinie en dehors d'une LakeFlow Pipelines. 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 lorsque les tables sources sous-jacentes changent, soit selon un calendrier, soit automatiquement.

Les vues matérialisées sont bien adaptées aux charges de travail de traitement de données telles que le traitement d'extraction, de transformation et de chargement (ETL). Les vues matérialisées offrent un moyen simple et déclaratif de traiter les données pour la conformité, les corrections, les agrégations ou la Change Data Capture (CDC) générale. Les vues matérialisées permettent également des transformations faciles à utiliser en nettoyant, enrichissant et dénormalisant les tables de base. En précalculant les queries coûteuses ou fréquemment utilisées, les vues matérialisées réduisent la latence des queries et la consommation de ressources. Dans de nombreux cas, elles peuvent calculer les changements de manière incrémentielle à partir des tables source, améliorant ainsi l'efficacité et l'expérience utilisateur finale.

Voici les cas d'utilisation courants des vues matérialisées :

• Maintenir un tableau de bord de BI à jour avec une latence de query minimale pour l'utilisateur final.
• Réduire l'orchestration ETL complexe avec une logique SQL simple.
• Élaboration de Transformations complexes et superposées.
• Tous les cas d'utilisation qui exigent des performances constantes 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 Catalog Explorer. Voir Afficher les détails avec DESCRIBE EXTENDED.

Exigences

Pour les options de compute, les autorisations et les autres exigences pour la création, l'actualisation et l'interrogation de vues matérialisées autonomes, consultez Exigences pour les pipelines autonomes.

Pour en savoir plus sur d'autres restrictions concernant l'utilisation des vues matérialisées, consultez Limitations.

Créer une vue matérialisée

Les opérations CREATE de la vue matérialisée autonome utilisent un warehouse 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 autonome. Lorsque la vue matérialisée est actualisée, 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, le 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.

Vue matérialisée ad hoc

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

SQL

-- 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 On-Trigger

L’exemple suivant crée une vue matérialisée qui se refresh automatiquement chaque fois que les données sources en amont changent à l’aide de TRIGGER ON UPDATE. Utilisez cette approche pour les charges de travail de production, en particulier lorsque les dépendances en amont ne s'exécutent pas selon des plannings prévisibles.

SQL

-- 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 refresh CRON quotidien planifié à 3 h 30 UTC. Les expressions et agrégats de la clause SELECT doivent utiliser des alias. Les références de colonne GROUP BY ne nécessitent pas d'alias.

SQL

-- 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 des exemples CRON supplémentaires, consultez Schedule refresh.

Lorsque vous créez une vue matérialisée à l'aide de l'instruction CREATE OR REPLACE MATERIALIZED VIEW, le refresh et le remplissage initiaux des données commencent immédiatement. Cela ne consomme pas de compute de SQL Warehouse. Au lieu de cela, un pipeline serverless est utilisé pour la création et les actualisations ultérieures. Consultez Comment les vues matérialisées autonomes sont-elles actualisées ?.

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 un calendrier, 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 actualise une vue matérialisée si elle est appelée une fois de plus, ou selon une planification. Un refresh effectué de cette manière agit comme tout 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 pour la 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érentes sources, consultez Charger des données dans les pipelines.

Charger les données de systèmes externes

Des vues matérialisées peuvent être créées sur des données externes en utilisant 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 les pipelines.

Masquer les données sensibles

Vous pouvez utiliser des vues matérialisées pour masquer les données sensibles aux utilisateurs qui accèdent à la table. Une façon de le faire est de créer la query de manière à ce qu'elle n'inclue pas ces données dès le départ. Mais vous pouvez également masquer des colonnes ou filtrer des lignes en fonction des autorisations de l'utilisateur qui effectue la query. Par exemple, vous pourriez masquer la colonne tax_id pour les 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 en savoir plus, consultez Filtres de ligne et masques de colonne.

Refresh une vue matérialisée

Le refresh d'une vue matérialisée met à jour la vue pour refléter les dernières modifications de la table de base au moment du 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 la refresh pour toute refresh planifiée. Vous pouvez également utiliser l'instruction REFRESH MATERIALIZED VIEW pour refresh la vue matérialisée sans avoir à fournir à nouveau la query. Consultez REFRESH (MATERIALIZED VIEW ou STREAMING TABLE) pour plus de détails sur la syntaxe SQL et les parameters 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 refresh incrémentielle des vues matérialisées.

Pour soumettre une instruction de refresh, utilisez l'éditeur SQL de l'interface utilisateur de Databricks, un Notebook attaché à un SQL Warehouse, la CLI Databricks SQL, ou l'API Databricks SQL.

Le propriétaire, et tout utilisateur ayant obtenu le privilège REFRESH sur la table, peut refresh la vue matérialisée.

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

SQL

REFRESH MATERIALIZED VIEW mv1;

L'Opérations est synchrone par default, ce qui signifie que la commande bloque jusqu'à ce que l'Opérations de refresh soit terminée. Pour refresh de manière asynchrone, vous pouvez ajouter le mot-clé ASYNC :

SQL

REFRESH MATERIALIZED VIEW mv1 ASYNC;

Pour savoir comment planifier un refresh, consultez Planifier les refreshes.

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. The refresh is managed by the pipeline and the update is monitored by the Databricks SQL warehouse used to create the materialized view. 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 s'exécutent toujours en mode Trigger. Voir Trigger vs. continu pipeline mode.

Les actualisations programmées peuvent avoir des notifications de mise à jour, et vous pouvez définir le mode de performance pour le refresh.

refresh incrémentielle

Les vues matérialisées sont actualisées selon l'une des deux méthodes.

• **Incremental refresh** — Le système évalue la query de la vue pour identifier les changements survenus après la dernière mise à jour et Merge uniquement les données nouvelles ou modifiées.
• Full refresh — Si une refresh incrémentielle ne peut pas être effectuée ou n’est pas rentable, le système exécute l’intégralité de la query 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 le refresh incrémentiel est pris en charge. Pour prendre en charge le refresh incrémentiel, les données source doivent être stockées dans des tables Delta avec le suivi des lignes activé. L'activation du flux de données de modification est recommandée pour une meilleure performance de refresh incrémentiel. Pour voir si une query est incrémentable, utilisez l'instruction Databricks SQL EXPLAIN CREATE MATERIALIZED VIEW. Après avoir 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 via un refresh complet.

Par défaut, Databricks utilise un modèle de coût pour choisir l'option la plus rentable entre une refresh complète et refresh incrémentielle. Vous pouvez remplacer ce comportement pour privilégier des refresh incrémentielles ou complètes en définissant un REFRESH POLICY dans la définition SQL de votre vue matérialisée.

Pour plus de détails sur les types de refresh et sur la façon d'optimiser les refreshs incrémentiels, consultez Refresh incrémentiel des vues matérialisées.

Actualisations asynchrones

Par default, les opérations de refresh sont effectuées de manière synchrone. Vous pouvez également configurer une opération de refresh pour qu'elle s'exécute de manière asynchrone. Ceci peut être défini à l'aide de la commande refresh avec le mot-clé ASYNC. Consultez REFRESH (MATERIALIZED VIEW ou STREAMING TABLE). Le comportement associé à chaque approche est le suivant :

• Synchrone : Un refresh synchrone empêche les autres opérations de se poursuivre jusqu’à ce que le refresh soit terminé. Si le résultat est nécessaire pour l'étape suivante, par exemple lors du séquençage des opérations de refresh dans des outils d'orchestration comme Lakeflow Jobs, utilisez un refresh synchrone. Pour orchestrer des vues matérialisées avec un Job, utilisez le type de tâche SQL . See Lakeflow Jobs.
• Asynchrone : Une actualisation asynchrone start un Job en arrière-plan sur le compute Serverless lorsqu’une actualisation de vue matérialisée commence, permettant à la commande de revenir avant la fin du chargement des données. Ce type de refresh permet d'économiser des coûts car l'opération ne retient pas nécessairement la capacité de compute dans le warehouse où la commande est initiée. Si le refresh devient inactif et qu'aucune autre tâche n'est en cours d'exécution, le warehouse peut s'arrêter pendant que le refresh utilise d'autres ressources de compute disponibles. De plus, les refreshes asynchrones supportent le démarrage de plusieurs opérations en parallèle.

Supprimer définitivement les enregistrements d'une vue matérialisée avec les vecteurs de suppression activés

info

Aperçu

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

remarque

• 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 requise 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 des enregistrements du stockage sous-jacent pour une vue matérialisée avec des vecteurs de suppression activés, par exemple pour la conformité au GDPR, des étapes supplémentaires doivent être suivies pour s'assurer qu'une opération VACUUM s'exécute sur les données de la vue matérialisée.

Pour supprimer physiquement des enregistrements :

1. 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);. See REORG TABLE.
2. Attendez que la période de rétention des données de la vue matérialisée soit écoulée. La période de rétention des données par default est de sept jours, mais elle peut être configurée avec la propriété de table delta.deletedFileRetentionDuration. Consultez Configurer la rétention des données pour les query Time Travel.
3. REFRESH la vue matérialisée. Voir refresh une vue matérialisée. Dans les 24 heures suivant l’opération REFRESH, les tâches de maintenance du pipeline, y compris l’opération VACUUM requise pour garantir la suppression permanente des enregistrements, sont exécutées automatiquement.

Supprimer une vue matérialisée

remarque

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

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

SQL

DROP MATERIALIZED VIEW mv1;

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

1. Cliquez sur Catalogue dans la barre latérale.
2. 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.
3. Ouvrez l'élément Tables sous le schéma que vous avez sélectionné, et cliquez sur la vue matérialisée.
4. Dans le menu kebab , sélectionnez Supprimer .

Comprenez 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 desquels vous avez soumis la commande. La taille de cluster de votre warehouse ne limite pas le compute ou le coût utilisé par la refresh.

• Le pipeline de refresh s’exécute sur un compute Serverless, facturé comme des 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, et non pour effectuer le traitement des données.
• Le coût augmente avec le volume de données traitées, et non avec la taille de votre SQL Warehouse.
• Pour surveiller les coûts de refresh des vues matérialisées, utilisez les tables système. Voir Quelle est la consommation de 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 :
  1. Cliquez sur Tâches et pipelines dans la barre latérale gauche de votre workspace Databricks.
  2. Cliquez sur Type de pipeline . Ensuite, sélectionnez MV/ST pour afficher les vues matérialisées autonomes.

remarque

Vous pourriez encourir des frais de compute serverless même lorsque l'entrepôt d'origine utilise du compute dédié.

Activation du suivi des lignes

Pour prendre en charge les refresh incrémentiels à partir des tables Delta, le suivi des lignes doit être activé pour ces tables source. 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 :

SQL

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

Pour plus de détails, consultez le suivi des lignes dans Databricks

Limitations

• Pour les options de compute et les exigences du Workspace, voir Exigences pour les pipelines autonomes.

• Pour les exigences d'actualisation incrémentielle, consultez le refresh incrémentiel 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 NULLet que seules NULL valeurs subsistent dans cette colonne, la valeur agrégée résultante des vues matérialisées est zéro au lieu de NULL.

• Vous ne pouvez pas lire un flux de données de modification à partir d'une vue matérialisée.

• Les requêtes Time Travel ne sont pas prises en charge sur les vues matérialisées.

• Les fichiers sous-jacents qui supportent les vues matérialisées peuvent inclure des données provenant de tables en amont (y compris des informations personnelles identifiables possibles) 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 ne faisant 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 fiables. Par exemple, supposons que la définition d'une vue matérialisée inclue une clause COUNT(DISTINCT field_a). Même si la définition de la vue matérialisée n'inclut que la clause d'agrégation COUNT DISTINCT, les fichiers sous-jacents contiennent une liste des valeurs réelles de field_a.

• Vous pourriez encourir certains frais de compute Serverless, même en utilisant ces fonctionnalités sur un compute dédié.

• Si vous avez besoin d'utiliser une connexion AWS PrivateLink avec votre vue matérialisée, contactez votre représentant Databricks.

Accédez aux vues matérialisées depuis des clients externes

Pour accéder aux vues matérialisées à partir de clients externes Delta Lake ou Iceberg 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, accessible par n'importe quel client Delta Lake ou Iceberg.

Ressources supplémentaires

• Configurer les vues matérialisées autonomes
• Surveiller les vues matérialisées autonomes
• Utiliser des tables de streaming autonomes