Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Présentation des vues matérialisées

Les vues matérialisées BigQuery sont des tables précalculées qui optimisent les performances des requêtes et réduisent les coûts d'exécution pour les requêtes prévisibles et fréquemment exécutées. En stockant périodiquement les résultats d'une requête, les vues matérialisées résolvent les problèmes de latence des requêtes et de coûts d'analyse élevés lorsque vous interrogez de manière répétée de grands ensembles de données avec des modèles d'agrégation prévisibles. En fusionnant automatiquement les données précalculées avec les modifications récentes apportées aux tables de base, les vues matérialisées garantissent des résultats de requête actualisés sans nécessiter de pipelines de données manuels.

Ce document s'adresse aux ingénieurs de données, aux administrateurs de bases de données et aux développeurs d'informatique décisionnelle qui conçoivent des pipelines d'analyse hautes performances. Pour implémenter correctement les vues matérialisées, vous devez connaître les structures des ensembles de données BigQuery, les fonctions d'agrégation GoogleSQL et les structures de coûts des requêtes.

Avantages des vues matérialisées

Les cas d'utilisation suivants mettent en évidence la valeur des vues matérialisées :

Prétraiter les données Améliorez les performances des requêtes en préparant des agrégats, des filtres, des jointures et des clusters.
Accélération des tableaux de bord : Donnez aux outils de BI, comme Looker, qui interrogent fréquemment les mêmes métriques agrégées (par exemple, les utilisateurs actifs quotidiens), les moyens de le faire.
Analyses en temps réel sur les grands flux : Peut fournir des réponses plus rapides sur les tables qui reçoivent des données de streaming à grande vitesse.
Gestion des coûts. Réduisez le coût des requêtes coûteuses et répétitives sur de grands ensembles de données.

Principales caractéristiques

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

Aucune maintenance nécessaire BigQuery précalcule les vues matérialisées en arrière-plan lorsque les tables de base changent. BigQuery ajoute automatiquement les modifications incrémentielles apportées aux données depuis les tables de base aux vues matérialisées, sans aucune action de l'utilisateur.
Données à jour. 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, BigQuery lit les données directement à partir des tables de base. Si les modifications apportées aux tables de base n'invalident pas la vue matérialisée, BigQuery lit le reste des données à partir de la vue matérialisée et ne lit que les modifications à partir des tables de base.

Le schéma suivant illustre la logique utilisée pour fusionner les modifications des données en temps réel :
Réglage intelligent. Si une partie d'une requête sur une 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é. Pour savoir comment et quand le réglage intelligent peut améliorer les requêtes, consultez Utiliser des vues matérialisées.

Le schéma suivant illustre le workflow de réacheminement des requêtes de l'optimisation intelligente :

Types de vues matérialisées

Il existe deux types de base de vues matérialisées :

Les vues matérialisées incrémentielles sont compatibles avec un ensemble limité de fonctionnalités. Pour en savoir plus sur la syntaxe SQL acceptée pour les vues matérialisées, consultez Créer des vues matérialisées. Seules les vues matérialisées incrémentielles peuvent bénéficier du réglage intelligent.
Les vues matérialisées non incrémentielles sont compatibles avec la plupart des syntaxes que les vues matérialisées incrémentielles ne prennent pas en charge.

Lorsque vous créez des vues matérialisées, BigQuery ne vous permet par défaut de créer des vues que sur la base de requêtes incrémentielles. Pour créer une vue non incrémentielle, vous pouvez spécifier allow_non_incremental_definition = true dans la définition de la vue matérialisée.

Le type de vue matérialisée le plus adapté dépend de votre situation. Le tableau suivant compare les fonctionnalités des vues matérialisées incrémentielles et non incrémentielles :

Catégorie	Incrémental	Non incrémentiel
Requête compatible	Limitée	La plupart des requêtes
Coût de la maintenance	Peut réduire le coût des requêtes fréquemment utilisées. Pour savoir comment les vues matérialisées sont mises à jour, consultez la section Mises à jour incrémentielles.	Chaque actualisation exécute la requête complète.
Compatibilité avec le réglage intelligent	Prise en charge pour la plupart des requêtes de vues.	Non
Des résultats toujours actualisés	Compatible Les vues incrémentales renvoient des résultats de requête actualisés, même si les tables de base ont été modifiées depuis la dernière actualisation.	Non

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 avec une vue dans un ensemble de données secondaire. Vous pouvez ensuite partager cette vue avec des utilisateurs et des groupes (principaux) spécifiques. 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 des 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 vous spécifiez un nombre maximal d'octets facturés et qu'une requête lit des données au-delà de cette limite, elle échoue sans engendrer de frais, qu'elle utilise des vues matérialisées, les tables de base ou les deux.
Estimation des coûts à l'aide d'un dry run : Un dry run répète la logique de réécriture des requêtes en utilisant les vues matérialisées disponibles et fournit une estimation des coûts. Vous pouvez vous en servir pour vérifier si une requête spécifique utilise des vues matérialisées.
Réplication des données entre les régions Vous pouvez créer des vues matérialisées sur des tables BigQuery pour lesquelles la réplication multirégionale est activée, mais uniquement dans la région principale. Si vous utilisez la région secondaire, le message d'erreur suivant peut s'afficher : The dataset replica of the cross region dataset {PROJECT}:{DATASET} in region {REGION} is read-only because it's not the primary replica.

En plus de ces fonctionnalités, vous pouvez créer des vues matérialisées sur des tables avec des fonctionnalités spécifiques, comme décrit dans les sections suivantes.

Tables avec capture des données modifiées active

Vous pouvez créer des vues matérialisées sur des tables avec une capture des données modifiées (CDC) active, un modèle utilisé pour ingérer en continu les modifications apportées aux bases de données ou aux tables. Ces vues matérialisées fonctionnent comme les vues matérialisées sur des tables BigQuery, ce qui inclut les avantages de l'actualisation automatique. Les vues matérialisées ne peuvent pas exécuter de requêtes de fusion au moment de l'exécution. Vous devez donc configurer les vues matérialisées avec un max_staleness suffisant pour éviter les jobs de fusion au moment de l'exécution. Pour en savoir plus, consultez Limites des vues matérialisées sur les tables avec capture des données modifiées active.

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.

Limites

Les vues matérialisées BigQuery sont soumises aux limites fonctionnelles et opérationnelles décrites dans les sections suivantes.

Limites liées au SQL et à la syntaxe

Dialecte. Seul le dialecte GoogleSQL est accepté.
Syntaxe SQL. 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 Prise en charge des requêtes de vues matérialisées.
Variables système. Les vues matérialisées ne sont pas compatibles avec les variables système, par exemple la variable système @@session_id.
Types de données paramétrées. Les vues matérialisées ne peuvent pas hériter ni définir explicitement de types de données paramétrées, comme STRING(n), car ces types de données ne sont compatibles qu'avec les colonnes de tables de base et les variables de script.
Descriptions des colonnes Vous pouvez définir des descriptions pour les vues matérialisées, mais pas pour les colonnes individuelles de la vue matérialisée.
Modifications des requêtes. Vous ne pouvez pas mettre à jour la requête d'une vue matérialisée après l'avoir créée.
Modifications des données : Vous ne pouvez pas mettre à jour ni manipuler directement les données des vues matérialisées à l'aide d'opérations telles que COPY, EXPORT, LOAD, WRITE ou des instructions de langage de manipulation de données (LMD). Opérateurs gourmands en ressources de processeur. Les opérateurs gourmands en ressources processeur (comme UNPIVOT ou les transformations UNNEST lourdes) peuvent entraîner des échecs d'actualisation avec la facturation à la demande. Pour résoudre ce problème, vous pouvez passer à la tarification basée sur la capacité, matérialiser les données transformées dans la table de base avant de créer la vue ou utiliser des requêtes planifiées.

Limites concernant les tables de base et l'imbrication

Imbrication Vous ne pouvez pas imbriquer des vues matérialisées dans d'autres vues matérialisées.
Types de sources Les vues matérialisées ne peuvent pas interroger les tables externes (sauf les tables BigLake), les tables génériques, les vues logiques¹ ni les instantanés.
Comportement de suppression Si vous supprimez une 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.
Ensembles de données externes Spanner. Seules les vues matérialisées non incrémentielles peuvent comporter des tables de base de l'ensemble de données externe Spanner. Si la dernière actualisation d'une vue matérialisée non incrémentielle s'est produite en dehors de l'intervalle max_staleness, la requête lit les tables de l'ensemble de données externe Spanner de base. Pour en savoir plus, consultez Créer des vues matérialisées sur des ensembles de données externes Spanner.
Mise en cache avec Spanner BigQuery ne met pas en cache les résultats des requêtes si elles sont exécutées sur des vues matérialisées non incrémentielles qui référencent des tables de datasets externes Spanner.

Champ d'application et limites régionales

Limite de l'organisation : Une vue matérialisée doit résider dans le même projet ou bloc d'organisation que ses tables de base.
Paramètres d'obsolescence La valeur de l'option max_staleness doit être comprise entre 30 minutes et 3 jours (inclus).
Requêtes sur les ressources Des limites concernant les références de tables de base et d'autres restrictions peuvent s'appliquer. Pour en savoir plus, consultez la page Quotas et limites.

¹La 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 les tables avec CDC active

Les vues matérialisées avec des tables de base de capture des données modifiées (CDC) actives présentent les limites suivantes :

Si une vue matérialisée comporte une table de base avec une capture des données modifiées active, vous ne pouvez pas faire référence à cette table dans une requête qui fait également référence à la vue matérialisée.
Lorsque vous créez une vue matérialisée sur une table avec capture de données modifiées active, la vue matérialisée ne peut pas effectuer les jobs de fusion d'exécution de la table CDC sous-jacente. Définissez la valeur max_staleness de la vue matérialisée sur au moins le double de la valeur max_staleness de la table de base. Les requêtes sur une vue matérialisée échouent si la version actuelle de la table CDC sous-jacente est plus ancienne que la max_staleness de la vue matérialisée.
Vous ne pouvez pas utiliser le réglage intelligent pour les vues matérialisées sur des tables avec capture de données modifiées active.

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

Les vues matérialisées sur des tables BigLake présentent les limites suivantes :

Vous ne pouvez pas partitionner la vue matérialisée. Les tables de base peuvent utiliser le partitionnement Apache Hive, mais vous ne pouvez pas partitionner le stockage de vues matérialisées 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 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.
Vous ne pouvez pas effectuer de jointure entre les tables gérées BigQuery et les tables BigLake dans une définition de vue matérialisée unique.
BigQuery BI Engine (un service d'analyse en mémoire rapide) n'est pas compatible avec l'accélération des vues matérialisées sur les tables BigLake.

Tarification des vues matérialisées

Les vues matérialisées entraînent des coûts de différentes manières :

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

Le tableau suivant présente les composants de tarification des vues matérialisées :

Composant	Tarifs à la demande	Tarification basée sur la capacité
Requête	Octets traités par les vues matérialisées et toutes les parties nécessaires des tables de base.¹	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.

¹ 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

La façon dont BigQuery stocke certaines valeurs agrégées a une incidence sur le calcul de la taille de stockage. Pour les valeurs agrégées AVG, ARRAY_AGG et APPROX_COUNT_DISTINCT dans une vue matérialisée, la valeur finale n'est pas stockée directement. 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 s'affiche sous la forme NUMERIC ou FLOAT64, mais en interne, elle est stockée sous la forme 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).

Workflow de démarrage

La configuration des vues matérialisées implique le workflow suivant :

Concevez et vérifiez la requête. Rédigez votre requête d'agrégation en suivant les consignes GoogleSQL.
Créez une vue matérialisée. Exécutez l'instruction CREATE MATERIALIZED VIEW à l'aide de la console Google Cloud , de l'outil de ligne de commande bq ou de l'API BigQuery.
Laissez le réglage intelligent s'exécuter. BigQuery redirige automatiquement les requêtes adressées à la table de base pour qu'elles utilisent la vue matérialisée. Aucune requête ni application n'a besoin de réécrire les cibles.

Pour commencer à créer des vues matérialisées, consultez Créer des vues matérialisées.