Vues matérialisées continues

Ce document présente les vues matérialisées continues et leurs cas d'utilisation courants. Avant de lire cette page, vous devez avoir lu la présentation de Bigtable.

Dans Bigtable, une vue matérialisée continue est le résultat d'un processus en arrière-plan continu et entièrement géré. Ce processus utilise une requête SQL que vous fournissez pour créer et gérer une table précalculée que Bigtable met à jour de manière incrémentielle à mesure que les données sources changent. La requête SQL peut inclure des agrégations et des transformations sur la table Bigtable sous-jacente.

Les données d'une vue matérialisée continue incluent les éléments suivants :

  • Valeurs agrégées ou transformées dérivées des données de la table source
  • Valeurs non agrégées qui définissent la clé de regroupement

Les vues matérialisées continues vous permettent de pré-agréger vos données au fur et à mesure de leur ingestion. De plus, une vue matérialisée continue possède un schéma différent de celui de sa table source. Elle présente les données de la table source dans une structure optimisée pour les requêtes avec des modèles de recherche différents de ceux utilisés sur la table source.

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

  • Aucune maintenance : une vue matérialisée continue est précalculée en arrière-plan. Les modifications apportées aux données de la table source, y compris les mises à jour et les suppressions, sont automatiquement propagées en arrière-plan à la vue matérialisée continue, sans aucune action de l'utilisateur.
  • Modèles de développement SQL : les vues matérialisées continues sont basées sur des requêtes GoogleSQL pour Bigtable, y compris des fonctions, des filtres et des agrégations SQL. Bien que les fonctions soient déterministes par défaut, vous pouvez choisir d'utiliser un ensemble de fonctions non déterministes pour des cas d'utilisation limités.
  • Synchronisation avec la récupération de mémoire : une vue matérialisée continue reste synchronisée avec les règles de récupération de mémoire de sa table source, et se met à jour automatiquement lorsque les données de la table expirent ou sont supprimées.
  • La latence de lecture et d'écriture n'est pas affectée : une vue matérialisée continue a un impact minimal sur les performances de la table source lorsque les clusters de l'instance sont provisionnés de manière adéquate ou utilisent l'autoscaling.
  • Cohérence à terme : les vues matérialisées continues sont calculées en arrière-plan. Les mises à jour d'une vue matérialisée continue peuvent être retardées, mais les résultats matérialisés continus sont toujours cohérents au fil du temps.

La clé de ligne, le qualificatif de colonne et les valeurs de colonne que vous utilisez pour définir une vue matérialisée continue sont traités comme des données de service. Pour cette raison, ne créez pas de vue matérialisée continue à l'aide d'une clé de ligne, d'un qualificatif de colonne ou de valeurs de colonne contenant des informations sensibles. Pour en savoir plus sur le traitement des données de service, consultez l'Avis de confidentialité deGoogle Cloud .

Vous pouvez créer une vue matérialisée continue à l'aide de la Google Cloud CLI, de l'éditeur de requêtes Bigtable Studio dans la console Google Cloud ou des bibliothèques clientes Bigtable pour Java et Go.

Vous pouvez lire une vue matérialisée continue en procédant comme suit :

Pour en savoir plus, consultez Lire à partir d'une vue matérialisée continue.

Quand utiliser des vues matérialisées continues

Les vues matérialisées continues vous permettent de définir une nouvelle représentation de vos données Bigtable à l'aide de SQL. Une fois créée, une vue matérialisée continue restructure automatiquement et en continu les données de la table source au format défini par la requête SQL. Ensuite, au lieu d'interroger votre table et de transformer ou d'agréger les données après les avoir lues, vous pouvez interroger la vue matérialisée continue.

Les vues matérialisées continues peuvent améliorer les performances des requêtes pour les cas d'utilisation suivants :

  • Pré-agrégation des données : vous pouvez utiliser une vue matérialisée continue pour agréger les données entrantes sur plusieurs lignes. Cela vous permet de récupérer rapidement des données résumées et agrégées, telles que des métriques pour les tableaux de bord.
  • Automatisation des architectures lambda et kappa : si votre application nécessite un mélange de données de pipeline de streaming en temps réel et de données de pipeline par lot contenant des données historiques, utilisez des vues matérialisées continues. Ces vues fournissent une vue de toutes les sources de données qui est mise à jour au fil du temps pour refléter les modifications apportées aux données sous-jacentes, sans qu'il soit nécessaire d'utiliser des outils de traitement par flux supplémentaires ou des jobs ETL personnalisés.
  • Modèles d'accès secondaires : les vues matérialisées continues créent une représentation alternative de vos données. Cette représentation peut être optimisée pour les requêtes avec des modèles de recherche différents de ceux que vous utilisez dans les requêtes sur la table source. Les vues matérialisées continues sont donc un outil puissant pour créer ce qui est en fait un index secondaire asynchrone sur vos données. Pour en savoir plus sur ces modèles, consultez Créer un index secondaire asynchrone.

Pour comparer les vues matérialisées continues avec d'autres types de vues Bigtable, consultez Tables et vues.

Quand utiliser des compteurs ?

Une autre façon de pré-agréger vos données consiste à créer des compteurs distribués à l'aide de cellules d'agrégation.

Les écritures dans les cellules d'agrégation sont immédiatement lisibles à partir du cluster dans lequel elles sont écrites. Les vues matérialisées continues sont traitées après l'écriture des données et finissent par devenir cohérentes avec la table source.

Utilisez des compteurs au lieu de vues matérialisées continues pour les éléments suivants :

  • Agrégations ne nécessitant pas de filtres et ne devant pas être effectuées sur plusieurs lignes.
  • Si vous devez lire immédiatement vos écritures à partir du cluster sur lequel elles sont écrites.

Utilisez des vues matérialisées continues lorsque vous souhaitez effectuer les opérations suivantes :

  • Générez une clé différente pour les requêtes sur vos agrégations.
  • Les modifications apportées à la table de base sont reflétées dans vos agrégations.
  • Combinez automatiquement les données de plusieurs lignes.

Utilisez une combinaison de compteurs et de vues matérialisées continues pour des cas d'utilisation tels que les suivants :

  • Capturer de nouvelles métriques dans une cellule d'agrégation, mais conserver les cumuls historiques de ces métriques.
  • Combiner des métriques dans une vue matérialisée continue.

Provisionnement et performances des ressources

Le traitement continu des vues matérialisées continues s'effectue en tant que job en arrière-plan de faible priorité. Par conséquent, elle a un impact minimal sur les performances de l'application et sur la latence de lecture et d'écriture sur la table source, à condition que vos clusters soient correctement dimensionnés.

Pour vous assurer que les données de la vue matérialisée continue restent à jour, nous vous recommandons d'activer l'autoscaling pour les clusters de l'instance qui contient votre vue matérialisée continue. L'autoscaling ajoute automatiquement suffisamment de nœuds pour gérer la surcharge de traitement, puis les supprime lorsqu'ils ne sont plus nécessaires. Cela permet de s'assurer qu'une capacité de calcul suffisante est disponible pendant l'exécution de la requête SQL en continu. L'autoscaling peut également vous assurer que vous disposez de suffisamment de nœuds pour gérer les besoins de stockage de vos vues matérialisées continues.

Les vues matérialisées continues sont comptabilisées dans la limite de 1 000 tables par instance.

Créer des vues matérialisées continues sur des tables existantes

Lorsque vous créez une vue matérialisée continue pour une table existante, Bigtable lance un processus ponctuel qui remplit la vue avec les données de la table existante. Ce processus est appelé remplissage initial. Le temps nécessaire au remplissage initial dépend de la taille de la table et de la complexité de la requête. Par défaut, vous ne pouvez pas interroger la vue pendant le remplissage initial. Toutefois, si votre cas d'utilisation peut tolérer des données incomplètes, par exemple lors du développement d'une application, vous pouvez utiliser l'indice de requête allow_incomplete_view pour interroger la vue avant la fin du remplissage. Pendant ce temps, si la vue effectue une agrégation, les agrégats renvoyés peuvent ne refléter qu'une partie des données. Pour en savoir plus, consultez Lire les données lors du remplissage initial.

Cette population initiale s'exécute en tant que tâche en arrière-plan de faible priorité afin de minimiser l'impact sur les performances de votre cluster. Pour les tables volumineuses, vous pouvez ajouter temporairement des nœuds à votre cluster afin d'accélérer la création de vues.

Le schéma suivant illustre le processus de création de vues matérialisées continues :

Processus de création de vues matérialisées continues dans Bigtable.
Figure 1. Processus de création de vues matérialisées continues dans Bigtable (cliquez pour agrandir).

Par exemple, supposons que votre table source contienne des lignes avec des clés qui suivent le modèle advertiser_id#region#ad_id et une famille de colonnes, data, qui inclut un qualificatif de colonne spend_usd avec des données numériques représentant les dépenses publicitaires :

Clé de ligne data:spend_usd
adv1#us-east#ad1 100
adv1#us-west#ad2 150
adv2#us-east#ad3 200

Si vous utilisez la requête suivante pour définir une vue matérialisée continue de cette table, le remplissage initial de 1 To de données s'effectue en environ trois heures sur un cluster de 175 nœuds.

SELECT
          SPLIT(_key, "#")[SAFE_OFFSET(0)] AS advertiser_id,
          count(*) AS count,
          sum(cast(cast(data['spend_usd'] as string) as int64)) as sum_spend
        FROM `$0`
        GROUP BY advertiser_id

Étant donné que Bigtable évolue de manière linéaire, un cluster de 175 nœuds traite 2 To de données en environ six heures et 10 To en environ 30 heures, en supposant que les données ont une forme similaire. Pour réduire le temps nécessaire au remplissage initial, vous pouvez temporairement ajouter des nœuds à votre cluster ou, si vous utilisez l'autoscaling, augmenter temporairement le nombre maximal de nœuds.

Fonctions SQL non déterministes

Par défaut, les vues matérialisées continues n'acceptent que les fonctions déterministes pour garantir des résultats cohérents sur tous les clusters d'une instance. Toutefois, vous pouvez activer l'utilisation de fonctions non déterministes, telles que CLUSTER_ATTRIBUTE(), pour filtrer les données par cluster qui les traite. Pour en savoir plus, consultez Requêtes non déterministes.

Pour utiliser ces fonctions, vous devez accepter les différences sémantiques potentielles lorsque vous créez la vue matérialisée continue. Pour en savoir plus, consultez Créer une vue matérialisée continue.

Stockage

Pour chaque vue matérialisée continue, Bigtable stocke les éléments suivants :

  • Les données de la vue matérialisée continue
  • Stockage intermédiaire

Comme toute table Bigtable, une vue matérialisée continue existe sur tous les clusters de l'instance qui la contient. Les clusters de votre instance doivent disposer de suffisamment de nœuds pour stocker la table source et toutes les vues matérialisées continues basées sur la table. L'autoscaling permet à vos clusters d'augmenter ou de réduire leur taille en fonction de l'évolution des besoins de stockage.

Une vue matérialisée continue doit être créée dans la même instance que la table source, même si le stockage de la vue matérialisée continue est distinct de celui de la table source.

Stockage des vues matérialisées continues

Une vue matérialisée continue contient les données résultant de la requête SQL sur laquelle elle est basée. Cela signifie qu'elle contient des valeurs agrégées définies par des clauses d'agrégation dans la requête SQL et des valeurs non agrégées qui définissent la clé de regroupement.

Stockage intermédiaire

Pour permettre la synchronisation d'une vue matérialisée continue avec sa table source, Bigtable utilise un espace de stockage intermédiaire pour stocker des copies des données dont il a besoin pour mettre à jour de manière incrémentielle la vue matérialisée continue.

La quantité de données dans l'espace de stockage intermédiaire est à peu près équivalente à la quantité de données analysées dans la table source pour générer le résultat de la requête SQL qui définit la vue matérialisée continue. Par exemple, si votre requête agrège les données de l'ensemble de la table, Bigtable conserve l'équivalent de l'ensemble de la table dans un espace de stockage intermédiaire. Une vue matérialisée continue basée sur une requête de plages de clés de ligne ou de colonnes spécifiques ne conserve que ces lignes ou colonnes dans le stockage intermédiaire.

Le stockage intermédiaire persiste pendant toute la durée de vie de la vue matérialisée continue afin de prendre en charge efficacement les mises à jour incrémentielles de la vue et de propager les suppressions de la table source vers la vue matérialisée continue. Vous ne pouvez pas lire les données dans l'espace de stockage intermédiaire. Pour en savoir plus sur l'utilisation de votre espace de stockage intermédiaire, consultez Métriques des vues matérialisées continues.

Réplication

Dans les instances qui utilisent la réplication, les vues matérialisées continues ne sont pas répliquées de la même manière que les tables. Au lieu de cela, chaque cluster d'une instance traite la vue matérialisée continue indépendamment, en utilisant sa propre copie de la table source. Cela signifie, par exemple, que les données écrites dans une table source sur le cluster A sont répliquées dans la table sur le cluster B, puis dans la vue matérialisée continue sur le cluster B.

Coûts

L'utilisation de vues matérialisées continues n'entraîne aucun coût par ressource. Toutefois, la création et la synchronisation de vues matérialisées continues nécessitent un traitement et un stockage, et vous êtes facturé aux tarifs standards. Lorsque vous créez une vue matérialisée continue, vous pouvez vous attendre à une augmentation des éléments suivants :

  • Stockage : le stockage des données dans la vue matérialisée continue et le stockage intermédiaire vous sont facturés. Pour en savoir plus, consultez la section Stockage.
  • Calcul : la synchronisation continue de la table source et de la vue matérialisée continue nécessite un traitement CPU, et vos clusters peuvent avoir besoin de plus de nœuds pour gérer le travail en arrière-plan supplémentaire.

En même temps, vous constaterez peut-être une diminution du traitement sur la table source, par exemple lorsque vous n'effectuez plus d'analyses de plage des données pour effectuer des calculs répétés et d'autres requêtes moins efficaces. Vous pouvez également éliminer la nécessité d'exécuter des jobs de pipeline, tels que Dataflow ou Spark, pour agréger les données sources et les réécrire dans Bigtable.

Pour en savoir plus sur les tarifs, consultez Tarifs de Bigtable. Pour connaître les métriques qui peuvent vous aider à surveiller l'utilisation de vos vues matérialisées continues, consultez Métriques.

Métriques

Une vue matérialisée continue transmet plusieurs métriques clés à Cloud Logging, que vous pouvez utiliser pour surveiller vos vues matérialisées continues.

Métrique Description
materialized_view/max_delay Limite supérieure du délai de traitement de la vue matérialisée continue
materialized_view/storage Quantité de données utilisées pour le stockage de la vue matérialisée continue, en octets
materialized_view/intermediate_storage Quantité de données utilisées par le traitement intermédiaire pour la vue matérialisée continue, en octets
table/materialized_view_intermediate_storage Quantité de données utilisées par le traitement intermédiaire pour les vues matérialisées continues définies sur cette table
materialized_view/user_errors Nombre d'erreurs provenant des données utilisateur pour la vue matérialisée continue. Les erreurs utilisateur empêchent la propagation des données vers la vue.
materialized_view/system_errors Nombre d'erreurs du système pour la vue matérialisée continue

Vous pouvez également utiliser de nombreuses métriques de table Bigtable pour surveiller une vue matérialisée continue, en utilisant l'ID de la vue matérialisée continue à la place de l'ID de la table. En particulier, les vues matérialisées continues sont incluses dans la répartition des métriques de processeur, ce qui peut vous aider à comprendre leur impact. Les métriques Bigtable pour les requêtes par seconde, la latence et le débit sont générées lorsque vous lisez une vue matérialisée continue à l'aide de la méthode ReadRows de l'API Data. Pour en savoir plus, consultez Métriques.

Pour faire vos premiers pas avec Cloud Logging, consultez Présentation de l'interrogation et de l'affichage des journaux.

Limites

  • Vous pouvez créer jusqu'à 50 vues matérialisées continues par instance.
  • Vous pouvez créer jusqu'à cinq vues matérialisées continues par table. Si nécessaire, vous pouvez demander une augmentation de cette limite en contactant Cloud Customer Care.
  • Lorsque vous créez une vue sans spécifier de _key, les colonnes sélectionnées dans la table source ne doivent pas être NULL. Pour en savoir plus, consultez Clés de ligne définies par la clause GROUP BY ou ORDER BY.
  • Vous ne pouvez pas modifier la requête SQL qui définit une vue matérialisée continue. Vous devez supprimer la vue matérialisée continue et en créer une autre avec vos modifications.
  • Vous ne pouvez pas créer de vue matérialisée continue d'une autre vue matérialisée continue ou d'une vue logique.
  • La requête qui définit une vue matérialisée continue ne peut pas utiliser SELECT *.
  • Vous ne pouvez pas configurer de règles de récupération de mémoire pour une vue matérialisée continue. La conservation des données est régie par les règles de récupération de mémoire de la table source, et la récupération de mémoire de la source est automatiquement reflétée dans la vue matérialisée continue.
  • Vous ne pouvez pas créer de vues matérialisées continues sur des tables avec une précision de code temporel en microsecondes.

Étapes suivantes