Présentation des flux de modifications

Bigtable offre la capture de données modifiées (CDC, Change Data Capture) grâce à sa fonctionnalité de flux de modifications. Un flux de modifications capture les modifications de données dans une table Bigtable en temps réel, ce qui vous permet de les diffuser en flux continu pour traitement ou analyse.

Ce document présente les flux de modifications Bigtable. Avant de lire ce document, vous devez avoir pris connaissance de la présentation de Bigtable.

Les flux de modifications sont utiles pour les cas d'utilisation des CDC, y compris les suivants:

  • Déclencher la logique d'application en aval lorsque des modifications spécifiées se produisent
  • Intégration à un pipeline d'analyse de données
  • Répondre aux exigences d'audit et d'archivage

Qu'est-ce qu'un flux de modifications ?

Un flux de modifications suit les modifications au niveau de la table apportées par un utilisateur ou une application, généralement à l'aide de l'une des bibliothèques clientes Cloud Bigtable. Les modifications apportées à la récupération de mémoire sont également capturées.

Toutes les modifications appliquées à une table pour laquelle les flux de modifications sont activés sont stockées en tant qu'enregistrements de modifications de données. Les enregistrements de modifications de données incluent les modifications de données appliquées par les éléments suivants:

  • Écritures, suppressions et mises à jour envoyées à l'aide des méthodes MutateRow, MutateRows, CheckAndMutateRow et ReadModifyWriteRow de l'API Cloud Bigtable
  • les suppressions survenant en raison de la récupération de mémoire ;
  • Lignes supprimées à l'aide de la méthode DropRowRange de l'API Admin

Pour en savoir plus sur les types de modifications que vous pouvez envoyer à une table Bigtable, consultez les sections Lectures, Écritures, Suppressions et Présentation de la récupération de mémoire.

Les flux de modifications ne permettent pas de suivre les modifications de schéma, telles que l'ajout ou la modification d'une famille de colonnes, ni la topologie de réplication, comme l'ajout ou la suppression d'un cluster.

Vous activez les flux de modifications sur une table et spécifiez une durée de conservation comprise entre 1 et 7 jours.

Contenu d'un enregistrement de modification des données

Chaque enregistrement de modifications de données contient toutes les modifications apportées à une ligne qui ont été appliquées de manière atomique dans le cadre d'un seul appel RPC.

Si une valeur est écrasée, la nouvelle valeur écrite est enregistrée dans l'enregistrement de modification de données. L'enregistrement de modification des données ne contient pas l'ancienne valeur.

Un enregistrement de modification de données reçoit son horodatage, appelé horodatage de commit,en même temps que la modification est appliquée au premier cluster qui la reçoit. Prenons l'exemple d'une instance avec deux clusters. Si vous envoyez une requête d'écriture à la Table 1 du cluster A, l'horodatage de commit de l'enregistrement de modifications de données est attribué au moment de la réception de l'écriture par le cluster A, et l'enregistrement des modifications de données sur le cluster B pour cette écriture possède le même horodatage de commit.

Chaque enregistrement de modification des données contient les éléments suivants:

  • Entrées : modifications apportées à la ligne, y compris un ou plusieurs des éléments suivants :
    • Écriture
      • Famille de colonnes
      • Le qualificatif de colonne
      • Code temporel
      • Value (Valeur)
    • Suppression de cellules
      • Famille de colonnes
      • Le qualificatif de colonne
      • Plage d'horodatages
    • Suppression d'une famille de colonnes
      • Famille de colonnes
      • Suppression d'une ligne : la suppression d'une ligne est convertie en liste de suppressions dans les familles de colonnes pour chaque famille de colonnes contenant des données.
  • Clé de ligne : identifiant de la ligne modifiée.
  • Type de modification : déclenchée par l'utilisateur ou récupération de mémoire
  • ID du cluster ayant reçu la modification
  • Horodatage de commit : heure côté serveur du moment où la modification a été validée dans la table.
  • Point de rupture : valeur qui permet à l'application qui lit le flux d'utiliser la règle intégrée de résolution des conflits de Bigtable.
  • Jeton : utilisé par l'application consommatrice pour reprendre le flux s'il est interrompu
  • Filigrane faible estimé : temps estimé depuis que la partition de l'enregistrement a rattrapé la réplication sur tous les clusters. Pour en savoir plus, consultez Partitions et Filigranes.

Pour en savoir plus sur les champs d'un enregistrement de modification des données, consultez la documentation de référence de l'API pour ReadChangeStream.

Modifier le stockage du flux

Une table et son flux de modifications partagent les mêmes ressources au niveau du cluster, y compris les nœuds et l'espace de stockage. Le stockage des données du flux de modifications fait donc partie du stockage d'une table. Dans une instance qui utilise la réplication, une copie des données d'un flux de modifications est stockée dans chaque cluster de l'instance contenant la table pour laquelle le flux de modifications est activé.

L'espace de stockage utilisé pour les données de vos flux de modifications n'est pas comptabilisé dans votre utilisation totale du stockage (% max.). Par conséquent, vous n'avez pas besoin d'ajouter des nœuds pour gérer l'espace de stockage supplémentaire consommé par les données de flux de modifications (bien que vous deviez ajouter des nœuds pour augmenter la puissance de calcul). Toutefois, l'espace de stockage utilisé par les données de vos flux de modifications vous est facturé. Pour en savoir plus, consultez la section Considérations sur les coûts.

Lire un flux de modifications

Pour lire (diffuser) un flux de modifications, vous devez utiliser un profil d'application configuré pour le routage à cluster unique. Pour en savoir plus sur les règles de routage, consultez la section Présentation des profils d'application.

Pour obtenir la liste complète des paramètres que vous transmettez pour lire un flux de modifications, consultez ReadChangeStream.

Les méthodes de flux de modifications sont fournies par l'API Cloud Bigtable (API Data). Nous vous recommandons d'utiliser l'une des options suivantes plutôt que d'appeler l'API sans utiliser de bibliothèque cliente ni de connecteur, afin d'éviter de devoir suivre et gérer les modifications de partition dues aux divisions et aux fusions.

Modèles Dataflow

Vous pouvez utiliser un modèle Dataflow fourni par Google:

Connecteur Bigtable Beam

Vous pouvez utiliser le connecteur Bigtable Beam pour créer un pipeline:

Si vous ne souhaitez pas créer votre propre pipeline, vous pouvez utiliser les exemples de code du tutoriel ou du guide de démarrage rapide Bigtable comme point de départ:

Bibliothèque cliente Java

Partitions

Pour maintenir un débit de lecture élevé correspondant à un taux d'écriture/de modification élevé, Bigtable divise un flux de modifications en plusieurs partitions pouvant être utilisées pour lire le flux de modifications en parallèle. Chaque partition du flux de modifications est associée à une tablette. Les tablettes sont des sous-sections d'une table qui sont redistribuées en fonction des besoins pour équilibrer la charge de travail des requêtes de la table. Pour en savoir plus, consultez la page Équilibrage de charge.

La bibliothèque cliente Java vous permet d'interroger chaque partition pour rechercher des modifications et fournit les informations requises pour gérer les modifications apportées aux partitions dues aux divisions et fusions.

Filigranes

Un filigrane est un horodatage qui estime la date à laquelle une partition a rattrapé la réplication sur tous les clusters. Le filigrane de la partition est mis à jour en continu à mesure que la réplication se produit.

Chaque ChangeStreamMutation (enregistrement de modification de données) inclut un champ estimatedLowWatermark, qui correspond au filigrane de la partition associée à l'enregistrement de modification des données. Cette estimatedLowWatermark est une estimation et ne garantit pas qu'il n'y a pas encore de données dans le flux.

Filigranes pour les tables répliquées

Le estimatedLowWatermark (filigrane faible) d'une partition n'avance pas si la réplication n'est pas entièrement rattrapée par la partition. Le filigrane faible à l'échelle du flux (le plus bas de tous les filigranes estimés au niveau de la partition) cesse d'avancer si le filigrane d'une partition n'avance pas. Un filigrane qui ne progresse plus est considéré comme bloqué. Dans ce cas, si vous diffusez votre flux de modifications dans un pipeline, celui-ci se bloque.

De nombreux facteurs peuvent entraîner le blocage d'un ou plusieurs filigranes au niveau de la partition pendant un certain temps, y compris les suivants:

  • Surcharger un cluster avec du trafic entraînant le retard de la réplication pour une ou plusieurs partitions
  • Retards du réseau
  • Indisponibilité du cluster

Le connecteur Bigtable Beam gère cela en définissant l'horodatage de sortie sur zéro pour toutes les données. Pour en savoir plus, consultez la section Regrouper des données sans heure d'événement.

Surveillance

Pour vous aider à comprendre comment l'activation d'un flux de modifications affecte l'utilisation du processeur et de l'espace de stockage pour une instance contenant des tables compatibles avec les flux de modifications, nous fournissons deux métriques spécifiques aux flux de modifications. Vous pouvez afficher les métriques sur la page Bigtable Monitoring ou à l'aide de la suite d'outils Cloud Monitoring.

Pour en savoir plus sur ces métriques, consultez la page Surveillance.

Considérations liées au coût

L'activation d'un flux de modifications sur une table entraîne une augmentation des coûts liés aux nœuds et au stockage. C'est particulièrement vrai pour les coûts de stockage supplémentaires.

Nœuds

Vous devez généralement ajouter des nœuds à un cluster (ou augmenter le nombre maximal de nœuds si vous utilisez l'autoscaling) pour gérer le trafic supplémentaire lié à l'activation et au traitement des enregistrements de modifications de données.

L'activation d'un flux de modifications peut augmenter l'utilisation du processeur d'environ 10%, avant même de commencer à le traiter. Le traitement d'un flux de modifications, par exemple à l'aide d'un pipeline Dataflow, peut augmenter l'utilisation du processeur d'environ 20 à 30%, en fonction du niveau d'activité de modifications et de la manière dont les données du flux sont lues.

Stockage

Les tarifs de stockage Bigtable standards vous sont facturés pour le stockage des enregistrements de modifications de données de votre table. Le stockage de la table créée pour suivre les métadonnées des flux de modifications vous est également facturé. La durée de conservation que vous spécifiez affecte directement les coûts de stockage.

En règle générale, l'équivalent d'une journée d'enregistrements de modifications de données (ne reflétant que les mutations qui se sont produites ce jour-là) occupe environ 1,5 fois plus d'espace de stockage que les données écrites ce jour-là sur le disque.

Transfert de données réseau

La lecture d'un flux de modifications sur plusieurs régions peut entraîner des frais pour ce trafic. Consultez la section Réseau sur les tarifs de Bigtable pour obtenir la liste complète des taux de transfert de données réseau.

Frais de traitement

Selon la manière dont vous lisez les enregistrements de modification de données, des coûts supplémentaires s'appliquent pour les services autres que Bigtable. Par exemple, si vous utilisez Dataflow, vous payez pour les octets traités et pour les machines de calcul qui traitent la tâche. Pour en savoir plus, consultez la page Tarifs de Dataflow.

Supprimer des plages de lignes

Si possible, évitez de supprimer une plage de lignes d'une table dans laquelle un flux de modifications est activé. Si vous devez supprimer une plage de lignes, sachez que Bigtable peut mettre beaucoup de temps à effectuer l'opération et que l'utilisation du processeur augmente au cours de l'opération.

Étapes suivantes