Présentation des vues matérialisées

Les vues matérialisées sont des vues précalculées qui stockent régulièrement les résultats d'une requête SQL. Les vues matérialisées peuvent réduire le temps de traitement total et les frais liés aux requêtes en stockant les résultats des requêtes, ce qui réduit la quantité de données à analyser pour chaque requête. BigQuery vérifie que les vues matérialisées fournissent des données actualisées en calculant les mises à jour en arrière-plan. Ce processus est effectué de manière incrémentielle en n'utilisant que les données modifiées dans la table de base, sous réserve d'un certain nombre de considérations. Les vues matérialisées peuvent être interrogées directement ou utilisées par BigQuery pour optimiser les requêtes sur leurs tables de base.

Voici les principales caractéristiques des vues matérialisées :

  • Aucune maintenance nécessaire Les vues matérialisées sont précalculées en arrière-plan lorsque les tables de base changent. Toutes les modifications incrémentielles apportées aux données depuis les tables de base sont automatiquement ajoutées aux vues matérialisées, sans aucune action de l'utilisateur.
  • Données actualisées Les vues matérialisées renvoient des données actualisées. Si les modifications apportées aux tables de base peuvent invalider la vue matérialisée, les données sont lues directement à partir des tables de base. Si les modifications apportées aux tables de base n'invalident pas la vue matérialisée, les autres données sont lues à partir de la vue matérialisée, et seules les modifications sont lues à partir des tables de base.
  • Réglage intelligent. Si une partie d'une requête sur la table de base peut être résolue en interrogeant la vue matérialisée, BigQuery redirige la requête pour utiliser la vue matérialisée afin d'améliorer les performances et l'efficacité.

Cas d'utilisation

Les vues matérialisées peuvent optimiser les requêtes avec des coûts de calcul élevés et des résultats de petite taille. Les processus bénéficiant de vues matérialisées incluent les opérations de traitement analytique en ligne (OLAP) qui nécessitent un traitement important à l'aide de requêtes prévisibles et répétées, telles que celles provenant de processus d'extraction, de transformation et de chargement (ETL), ou de l'informatique décisionnelle.

Les cas d'utilisation suivants mettent en évidence la valeur des vues matérialisées. Les vues matérialisées peuvent améliorer les performances des requêtes si vous avez fréquemment besoin des éléments suivants :

  • Pré-agréger des données Agrégation de données en flux continu.
  • Préfiltrer les données Exécution des requêtes qui ne lisent qu'un sous-ensemble particulier de la table.
  • Pré-joindre des données Jointures de requêtes, en particulier entre les grandes et les petites tables.
  • Regrouper les données Exécution des requêtes pouvant tirer parti d'un schéma de clustering différent des tables de base.

Réglage intelligent

Les vues matérialisées peuvent être utilisées pour améliorer de manière transparente les performances des requêtes sans les modifier. Vous pouvez utiliser une vue matérialisée pour optimiser des ensembles de requêtes avec des schémas communs, comme celles générées par un outil de BI. Pour en savoir plus, consultez Utiliser des vues matérialisées.

Comparaison avec d'autres techniques BigQuery

Le tableau suivant récapitule les similitudes et les différences entre la mise en cache, les requêtes programmées, les vues logiques et les vues matérialisées de BigQuery.

Composant Mise en cache Requêtes programmées Vues logiques Vues matérialisées
Optimiser le calcul Oui Non Non Oui
Compatibilité des requêtes Tous Toutes Tous Limitée1
Partitionnement et filtrage par cluster Non Oui N/A Oui
Actualisation incrémentielle Non Non Non Oui
Stockage supplémentaire Non Oui Non Oui
Réécriture de requêtes Non Non Non Oui
Frais de maintenance Non Oui N/A Oui
Obsolescence des données Jamais Oui Jamais Facultatif 2

1 L'option --allow_non_incremental_definition est compatible avec une gamme étendue de requêtes SQL permettant de créer des vues matérialisées.

2 L'option --max_staleness offre des performances élevées et constantes avec des coûts contrôlés lors du traitement de grands ensembles de données qui changent fréquemment.

Vues matérialisées autorisées

Vous pouvez créer une vue matérialisée autorisée pour partager un sous-ensemble de données d'un ensemble de données source vers une vue dans un ensemble de données secondaire. Vous pouvez ensuite partager cette vue avec des utilisateurs et des groupes (comptes principaux) spécifiques qui pourront consulter les données que vous partagez. Les principaux peuvent interroger les données que vous fournissez dans une vue, mais ils ne peuvent pas accéder directement à l'ensemble de données source.

Les vues autorisées et les vues matérialisées autorisées sont autorisées de la même manière. Pour en savoir plus, consultez Vues autorisées.

Interaction avec d'autres fonctionnalités BigQuery

Les fonctionnalités BigQuery suivantes fonctionnent de manière transparente avec les vues matérialisées :

  • Explication du plan de requête : le plan de requête indique les vues matérialisées analysées (le cas échéant) et le nombre d'octets lus à partir de la vue matérialisée et des tables de base.

  • Mise en cache de requêtes : les résultats d'une requête que BigQuery réécrit à l'aide d'une vue matérialisée peuvent être mis en cache sous réserve des limites habituelles (utilisation de fonctions déterministes, aucun flux dans les tables de base, etc.).

  • Restriction de coût : si la requête lit un nombre d'octets qui dépasse la limite que vous avez définie, elle échoue sans engendrer de frais, qu'elle ait utilisé les vues matérialisées, les tables de base ou les deux.

  • Estimation des coûts par simulation : une simulation répète la logique de réécriture des requêtes à l'aide des vues matérialisées disponibles et doit fournir une estimation précise des coûts. Vous pouvez vous en servir pour vérifier si une requête spécifique utilise des vues matérialisées.

Tables compatibles avec le cache de métadonnées BigLake

Les vues matérialisées sur les tables compatibles avec le cache de métadonnées BigLake peuvent référencer des données structurées stockées dans Cloud Storage et Amazon Simple Storage Service (Amazon S3). Ces vues matérialisées fonctionnent comme les vues matérialisées sur des tables de stockage gérées par BigQuery, ce qui inclut les avantages de l'actualisation automatique et du réglage intelligent. Les autres avantages incluent la pré-agrégation, le préfiltrage et la préjointure des données stockées en dehors de BigQuery. Les vues matérialisées sur des tables BigLake sont stockées dans et présentent toutes les caractéristiques du stockage géré BigQuery.

Lorsque vous créez une vue matérialisée sur une table BigLake Amazon S3, les données de la vue matérialisée ne sont pas disponibles pour les jointures avec les données BigQuery. Pour rendre les données Amazon S3 d'une vue matérialisée disponibles pour les jointures, créez une instance répliquée de la vue matérialisée. Vous ne pouvez créer des instances répliquées de vues matérialisées que pour les vues matérialisées autorisées.

Instances dupliquées de vues matérialisées

BigQuery vous permet de créer des vues matérialisées sur des tables compatibles avec le cache des métadonnées BigLake sur les données Amazon Simple Storage Service (Amazon S3), Apache Iceberg ou Salesforce Data Cloud.

Une instance dupliquée avec vue matérialisée vous permet d'utiliser les données de la vue matérialisée Amazon S3, Iceberg ou Data Cloud dans les requêtes tout en évitant les coûts de sortie des données et en améliorant leurs performances. Pour ce faire, une instance dupliquée avec vue matérialisée réplique les données Amazon S3, Iceberg ou Data Cloud vers un ensemble de données situé dans une région BigQuery compatible, afin que les données soient disponibles localement dans BigQuery.

Apprenez à créer des instances dupliquées de vues matérialisées.

Fraîcheur des données

Une fois que vous avez créé l'instance dupliquée de la vue matérialisée, le processus de réplication interroge la vue matérialisée source pour rechercher les modifications et réplique les données sur l'instance dupliquée de la vue matérialisée. Les données sont répliquées à l'intervalle que vous avez spécifié dans l'option replication_interval_seconds de l'instruction CREATE MATERIALIZED VIEW AS REPLICA OF.

Outre l'intervalle de réplication, l'actualisation des données répliquées de la vue matérialisée est également affectée par la fréquence d'actualisation de la vue matérialisée source et la fréquence d'actualisation du cache de métadonnées de la table Amazon S3, Iceberg ou Data Clous utilisée par les actualisations de la vue matérialisée.

Vous pouvez vérifier la fraîcheur des données de l'instance dupliquée de la vue matérialisée et des ressources sur lesquelles elle repose à l'aide de la console Trusted Cloud  :

  • Pour connaître la fraîcheur de l'instance dupliquée de la vue matérialisée, consultez le champ Dernière modification dans le volet Détails de l'instance dupliquée de la vue matérialisée.
  • Pour connaître la fraîcheur de la vue matérialisée source, consultez le champ Dernière modification dans le volet Détails de la vue matérialisée.
  • Pour connaître la fraîcheur du cache des métadonnées de la table Amazon S3, Iceberg ou Data Cloud source, consultez le champ Obsolescence maximale dans le volet Détails de la vue matérialisée.

Régions où le service est disponible

Utilisez les mappages d'emplacement dans le tableau suivant lorsque vous créez des instances dupliquées de vue matérialisée :

Emplacement de la vue matérialisée source Emplacement de l'instance répliquée de la vue matérialisée
aws-us-east-1 Emplacement multirégional US ou l'une des régions suivantes :
  • northamerica-northeast1
  • northamerica-northeast2
  • us-central1
  • us-east1
  • us-east4
  • us-east5
  • us-south1
  • us-west1
  • us-west2
  • us-west3
  • us-west4
aws-us-west-2 Emplacement multirégional US ou l'une des régions suivantes :
  • northamerica-northeast1
  • northamerica-northeast2
  • us-central1
  • us-east1
  • us-east4
  • us-east5
  • us-south1
  • us-west1
  • us-west2
  • us-west3
  • us-west4
aws-eu-west-1 Emplacement multirégional EU ou l'une des régions suivantes :
  • europe-central2
  • europe-north1
  • europe-southwest1
  • europe-west1
  • europe-west2
  • europe-west3
  • europe-west4
  • europe-west6
  • europe-west8
  • europe-west9
  • europe-west10
aws-ap-northeast-2 L'une des régions suivantes :
  • asia-east1
  • asia-east2
  • asia-northeast1
  • asia-northeast2
  • asia-northeast3
  • asia-south1
  • asia-south2
  • asia-southeast1
aws-ap-southeast-2 L'une des régions suivantes :
  • australia-southeast1
  • australia-southeast2

Limites

  • Des limites concernant les références de tables de base et d'autres restrictions peuvent s'appliquer. Pour en savoir plus sur les limites s'appliquant aux vues matérialisées, consultez la section Quotas et limites.
  • Les données d'une vue matérialisée ne peuvent pas être mises à jour ou manipulées directement à l'aide d'opérations telles que COPY, EXPORT, LOAD, WRITE ou des instructions de langage de manipulation de données (LMD).
  • Vous ne pouvez pas remplacer une vue matérialisée existante par une vue matérialisée du même nom.
  • La vue SQL ne peut pas être mise à jour après la création de la vue matérialisée.
  • Une vue matérialisée doit résider dans la même organisation que les tables de base ou dans le même projet si celui-ci n'appartient pas à une organisation.
  • Les vues matérialisées utilisent une syntaxe SQL limitée et un ensemble limité de fonctions d'agrégation. Pour en savoir plus, consultez la page Vues matérialisées compatibles.
  • Les vues matérialisées ne peuvent pas être imbriquées dans d'autres vues matérialisées.
  • Les vues matérialisées ne peuvent pas interroger les tables externes ou génériques, les vues logiques1 ni les instantanés.
  • Seul le dialecte GoogleSQL est compatible avec les vues matérialisées.
  • Vous pouvez définir des descriptions pour les vues matérialisées, mais vous ne pouvez pas définir de descriptions pour les colonnes individuelles de la vue matérialisée.
  • Si vous supprimez la table de base sans d'abord supprimer la vue matérialisée, les requêtes et les actualisations de la vue matérialisée échouent. Si vous recréez la table de base, vous devez également recréer la vue matérialisée.
  • Si une vue matérialisée possède une table de base activée pour la capture des données modifiées, cette table ne peut pas être référencée dans la même requête que la vue matérialisée.

1La compatibilité de référence concernant les vues logiques est disponible en preview. Pour en savoir plus, consultez la page Référencer les vues logiques.

Limites des vues matérialisées sur des tables BigLake

  • Le partitionnement de la vue matérialisée n'est pas possile. Les tables de base peuvent utiliser le partitionnement Hive, mais le stockage de vues matérialisées ne peut pas être partitionné dans des tables BigLake. Cela signifie que toute suppression dans une table de base entraîne une actualisation complète de la vue matérialisée. Pour en savoir plus, consultez la section Mises à jour incrémentielles.
  • La valeur de l'option -max_staleness de la vue matérialisée doit être supérieure à celle de la table de base BigLake.
  • Les jointures entre les tables gérées BigQuery et les tables BigLake ne sont pas compatibles avec une définition de vue matérialisée unique.
  • BigQuery BI Engine n'est pas compatible avec l'accélération des vues matérialisées sur les tables BigLake.

Limites des instances dupliquées avec vue matérialisée

Tarification des vues matérialisées

Les coûts sont associés aux aspects suivants des vues matérialisées :

  • Interrogation des vues matérialisées
  • Gestion des vues matérialisées, par exemple lorsqu'elles sont actualisées Le coût de l'actualisation automatique est facturé dans le projet où se trouve la vue. Le coût de l'actualisation manuelle est facturé dans le projet dans lequel la tâche d'actualisation manuelle est exécutée. Pour en savoir plus sur le contrôle des coûts de maintenance, consultez la section Maintenance des tâches d'actualisation.
  • Stockage des tables de vues matérialisées
Composant Tarifs à la demande Tarifs en fonction de la capacité
Requête Octets traités par les vues matérialisées et toutes les parties nécessaires des tables de base.1 Les emplacements sont consommés lors de la requête.
Maintenance Octets traités pendant l'actualisation. Les emplacements sont consommés pendant l'actualisation.
Stockage Octets stockés dans les vues matérialisées. Octets stockés dans les vues matérialisées.

1 Dans la mesure du possible, BigQuery ne lit que les modifications depuis la dernière actualisation de la vue. Pour en savoir plus, consultez la section Mises à jour incrémentielles.

Détails des coûts de stockage

Pour les valeurs cumulées AVG, ARRAY_AGG et APPROX_COUNT_DISTINCT dans une vue matérialisée, la valeur finale n'est pas directement stockée. Au lieu de cela, BigQuery stocke une vue matérialisée en interne sous forme d'esquisse intermédiaire, qui est utilisée pour générer la valeur finale.

Prenons l'exemple d'une vue matérialisée créée à l'aide de la commande suivante :

CREATE MATERIALIZED VIEW project-id.my_dataset.my_mv_table AS
SELECT date, AVG(net_paid) AS avg_paid
FROM project-id.my_dataset.my_base_table
GROUP BY date

La colonne avg_paid est affichée en tant que NUMERIC ou FLOAT64 pour l'utilisateur, mais en interne elle est stockée en tant que BYTES, son contenu étant une esquisse intermédiaire au format propriétaire. Pour le calcul de la taille des données, la colonne est traitée comme des octets (BYTES).

Coûts des instances dupliquées de vues matérialisées

L'utilisation d'instances dupliquées de vues matérialisées entraîne des coûts de calcul, de transfert de données sortant et de stockage.

Étapes suivantes