Änderungsstreams

Bigtable bietet Change Data Capture (CDC) mit seinem Änderungsstream-Feature. Ein Änderungsstream erfasst Datenänderungen in einer Bigtable-Tabelle, sobald die Änderungen eintreten, sodass Sie sie zur Verarbeitung oder Analyse streamen können.

Dieses Dokument bietet einen Überblick über Bigtable-Änderungsstreams. Bevor Sie dieses Dokument lesen, sollten Sie sich mit den Informationen unter Bigtable vertraut machen.

Änderungsstreams sind für die folgenden Anwendungsfälle der CDC nützlich:

Nachgelagerte Anwendungslogik bei bestimmten Änderungen auslösen
In eine Data-Analytics-Pipeline einbinden
Audit- und Archivierungsanforderungen unterstützen

Was ist ein Änderungsstream?

Ein Änderungsstream verfolgt Änderungen auf Tabellenebene, die von einem Nutzer oder einer Anwendung vorgenommen werden, wobei normalerweise eine der Cloud Bigtable-Clientbibliotheken verwendet wird. Änderungen bei der automatischen Speicherbereinigung werden ebenfalls erfasst.

Alle Änderungen, die auf eine Tabelle mit aktiviertem Änderungsstream angewendet werden, werden als Datensätze zu Datenänderungen gespeichert. Datensätze zu Datenänderungen enthalten Datenänderungen, die von folgenden Elementen angewandt wurden:

Schreibvorgänge, Löschungen und Aktualisierungen, die mit den Cloud Bigtable API-Methoden MutateRow, MutateRows, CheckAndMutateRow und ReadModifyWriteRow gesendet werden
Löschungen, die aufgrund der automatischen Speicherbereinigung erfolgen
Mit der Methode DropRowRange der Admin API gelöschte Zeilen

Weitere Informationen zu den Arten von Änderungen, die an eine Bigtable-Tabelle gesendet werden können, finden Sie unter Lesevorgänge, Schreibvorgänge, Löschvorgänge und Speicherbereinigung – Übersicht.

Änderungsstreams verfolgen keine Schemaänderungen wie das Hinzufügen oder Ändern einer Spaltenfamilie oder die Replikationstopologie, z. B. das Hinzufügen oder Entfernen eines Clusters.

Sie aktivieren Änderungsstreams für eine Tabelle und geben eine Aufbewahrungsdauer von 1 bis 7 Tagen an.

Inhalt eines Datenänderungseintrags

Jeder Datenänderungseintrag enthält alle Änderungen für eine Zeile, die als Teil eines einzelnen RPC-Aufrufs einzeln angewendet wurden.

Beim Überschreiben eines Werts wird der neu geschriebene Wert im Datenänderungseintrag aufgezeichnet. Der Datenänderungseintrag enthält nicht den alten Wert.

Ein Datenänderungseintrag erhält seinen Zeitstempel, einen sogenannten Commit-Zeitstempel, zur selben Zeit, zu der die Änderung auf den ersten Cluster angewendet wird, der sie empfängt. Angenommen, Sie haben eine Instanz mit zwei Clustern. Wenn Sie eine Schreibanfrage an Tabelle 1 in Cluster A senden, wird der Commit-Zeitstempel für den Datenänderungseintrag zugewiesen, wenn der Schreibvorgang von Cluster A empfangen wird, und der Datenänderungseintrag in Cluster B für diesen Schreibvorgang hat denselben Commit-Zeitstempel.

Jeder Datensatz für die Datenänderung enthält Folgendes:

Einträge – Änderungen, die an der Zeile vorgenommen wurden, darunter eine oder mehrere der folgenden:
- Schreiben
  - Spaltenfamilie
  - Spaltenqualifizierer
  - Zeitstempel
  - Wert
- Löschen von Zellen
  - Spaltenfamilie
  - Spaltenqualifizierer
  - Zeitstempelbereich
- Löschen einer Spaltenfamilie
  - Spaltenfamilie
  - Löschen aus einer Zeile: Das Löschen aus einer Zeile wird in eine Liste von Löschungen aus Spaltenfamilien für jede Spaltenfamilie konvertiert, in der die Zeile Daten enthält.
Zeilenschlüssel: die Kennung für die geänderte Zeile
Änderungstyp – vom Nutzer initiiert oder durch automatische Speicherbereinigung
ID des Clusters, der die Änderung erhalten hat
Commit-Zeitstempel – serverseitige Zeit, zu der für die Änderung ein Commit für die Tabelle durchgeführt wurde
Tiebreaker: Dieser Wert ermöglicht es der Anwendung, die den Stream liest, die integrierte Konfliktlösungsrichtlinie von Bigtable zu verwenden.
Token: Wird von der nutzenden Anwendung verwendet, um den Stream fortzusetzen, falls er unterbrochen wird
Geschätztes geringes Wasserzeichen: die geschätzte Zeit, die seit der Partition des Eintrags mit der Replikation über alle Cluster hinweg erfasst wurde. Weitere Informationen finden Sie unter Partitionen und Wasserzeichen.

Weitere Informationen zu den Feldern in einem Datenänderungseintrag finden Sie in der API-Referenz für ReadChangeStream.

Stream-Speicher ändern

Eine Tabelle und ihr Änderungsstream teilen sich die gleichen Ressourcen auf Clusterebene, einschließlich Knoten und Speicher. Daher ist der Datenspeicher von Änderungsstreams Teil des Speichers einer Tabelle. In einer Instanz mit Replikation wird eine Kopie der Daten eines Änderungsstreams in jedem Cluster der Instanz gespeichert, die die für den Änderungsstream aktivierte Tabelle enthält.

Der für Ihre Änderungsstreamdaten verwendete Speicherplatz wird nicht auf die gesamte Speicherauslastung (max. %) angerechnet. Daher müssen Sie keine Knoten hinzufügen, um den erhöhten Speicher zu bewältigen, der von Änderungsstreamdaten verbraucht wird (obwohl Sie möglicherweise Knoten für zusätzliche Rechenleistung hinzufügen müssen). Es wird Ihnen jedoch der Speicherplatz in Rechnung gestellt, den Ihre Änderungsstreamdaten belegen. Weitere Informationen finden Sie unter Kostengesichtspunkte.

Änderungsstream lesen

Zum Lesen (Streamen) eines Änderungsstreams müssen Sie ein Anwendungsprofil verwenden, das für Single-Cluster-Routing konfiguriert ist. Weitere Informationen zu Routingrichtlinien finden Sie unter Anwendungsprofile.

Eine vollständige Liste der Parameter, die Sie zum Lesen eines Änderungsstreams übergeben, finden Sie unter ReadChangeStream.

Änderungsstreammethoden werden von der Cloud Bigtable API (Data API) bereitgestellt. Wir empfehlen, eine der folgenden Optionen zu verwenden, anstatt die API ohne eine Clientbibliothek oder einen Connector aufzurufen. So müssen Sie Partitionsänderungen aufgrund von Aufteilungen und Zusammenführungen nicht nachverfolgen und verarbeiten.

Dataflow-Vorlagen

Sie können eine von Google bereitgestellte Dataflow-Vorlage verwenden:

Bigtable Beam-Connector

Mit dem Bigtable Beam-Connector können Sie eine Pipeline erstellen:

Bigtable Beam-Connector

Wenn Sie keine eigene Pipeline erstellen möchten, können Sie die Codebeispiele aus der Bigtable-Anleitung oder der Bigtable-Kurzanleitung als Ausgangspunkt für Ihren Code verwenden:

Java-Clientbibliothek

Cloud Bigtable-Client für Java

Partitionen

Um einen hohen Lesedurchsatz, der einer hohen Schreib-/Änderungsrate entspricht, aufrechtzuerhalten, teilt Bigtable einen Änderungsstream in mehrere Partitionen auf, die zum parallelen Lesen des Änderungsstreams verwendet werden können. Jede Änderungsstreampartition ist einer Tablet zugeordnet. Tabellenreihen sind Unterabschnitte einer Tabelle, die nach Bedarf neu verteilt werden, um die Anfragearbeitslast der Tabelle auszugleichen. Weitere Informationen finden Sie unter Load-Balancing.

Mit der Java-Clientbibliothek können Sie jede Partition auf Änderungen abfragen und stellt die Informationen bereit, die erforderlich sind, um Änderungen in Partitionen aufgrund von Aufteilungen und Zusammenführungen zu verwalten.

Wasserzeichen

Ein Wasserzeichen ist ein Zeitstempel, der angibt, wie lange eine Partition zuletzt die Replikation über alle Cluster hinweg eingeholt hat. Das Wasserzeichen für die Partition wird bei der Replikation kontinuierlich aktualisiert und kommt mit der Zeit voran.

Jeder ChangeStreamMutation (Datensatz für Datenänderung) enthält ein Feld estimatedLowWatermark. Dies ist das Wasserzeichen für die Partition, die mit dem Datenänderungseintrag verknüpft ist. estimatedLowWatermark ist eine Schätzung und keine Garantie dafür, dass noch keine Daten im Stream eingehen.

Wasserzeichen für replizierte Tabellen

Der estimatedLowWatermark (niedriges Wasserzeichen) einer Partition wird nicht fortgesetzt, wenn die Replikation nicht vollständig von der Partition abgedeckt ist. Das niedrigste Wasserzeichen im Stream – das niedrigste unter allen geschätzten niedrigen Wasserzeichen auf Partitionsebene – stoppt den Fortschritt, wenn das Wasserzeichen einer Partition nicht vorankommt. Ein Wasserzeichen, das nicht mehr vorankommt, gilt als angehalten. Wenn Sie den Änderungsstream in einer Pipeline streamen, wird die Pipeline in diesem Fall angehalten.

Viele Faktoren können dazu führen, dass ein oder mehrere Wasserzeichen auf Partitionsebene für einen bestimmten Zeitraum verzögert werden. Dazu gehören:

Die Überlastung eines Clusters mit Traffic führt dazu, dass die Replikation bei einer oder mehreren Partitionen in Rückstand gerät
Netzwerkverzögerungen
Nichtverfügbarkeit von Clustern

Hierzu setzt der Bigtable Beam-Connector den Ausgabezeitstempel für alle Daten auf null. Weitere Informationen finden Sie unter Daten ohne Ereigniszeiten gruppieren.

Monitoring

Damit Sie besser verstehen, wie sich das Aktivieren eines Änderungsstreams auf die CPU- und Speicherauslastung für eine Instanz auswirkt, die Tabellen mit aktivierten Änderungsstreams enthält, stellen wir zwei Änderungsstream-spezifische Messwerte bereit. Sie können die Messwerte auf der Monitoring-Seite von Bigtable oder mithilfe der Cloud Monitoring-Tools einsehen.

Von den Änderungsstreameinträgen verwendete Byte (change_stream_log_used_bytes)
CPU-Auslastung nach Änderungsstreams ( verwendet cpu_load_by_app_profile_by_method_by_table)

Weitere Informationen zu diesen Messwerten finden Sie unter Monitoring.

Kostengesichtspunkte

Das Aktivieren eines Änderungsstreams für eine Tabelle führt zu erhöhten Kosten für Knoten und Speicher. Insbesondere sind mehr Speicherkosten zu erwarten.

Knoten

Normalerweise müssen Sie einem Cluster Knoten hinzufügen (oder die maximale Anzahl von Knoten erhöhen, wenn Sie Autoscaling verwenden), um den zusätzlichen Traffic zum Aktivieren und Verarbeiten der Datenänderungseinträge zu verarbeiten.

Durch das Aktivieren eines Änderungsstreams kann die CPU-Auslastung um etwa 10 % erhöht werden, noch bevor Sie mit der Verarbeitung beginnen. Die Verarbeitung eines Änderungsstreams, z. B. das Lesen mit einer Dataflow-Pipeline, kann die CPU-Auslastung um etwa 20 bis 30 % erhöhen, abhängig vom Grad der Änderungsaktivität und davon, wie die Streamdaten gelesen werden.

Speicher

Für das Speichern der Datenänderungseinträge Ihrer Tabelle fallen die üblichen Bigtable-Speicherpreise an. Außerdem fallen für das Speichern der Tabelle, die zum Verfolgen von Änderungsstream-Metadaten erstellt wird, Gebühren an. Die von Ihnen angegebene Aufbewahrungsdauer wirkt sich direkt auf die Speicherkosten aus.

In der Regel belegen die Datenänderungseinträge eines Tages, die nur die an diesem Tag aufgetretenen Mutationen wiedergeben, etwa 1,5-mal so viel Speicherplatz wie die an diesem Tag geschriebenen Daten auf der Festplatte.

Netzwerkdatenübertragung

Wenn Sie einen Änderungsstream regionsübergreifend lesen, können Kosten für diesen Traffic anfallen. Eine vollständige Liste der Netzwerkdatenübertragungsraten finden Sie im Abschnitt "Netzwerk" in der Preisübersicht für Bigtable.

Bearbeitungskosten

Je nachdem, wie Sie die Datenänderungseinträge lesen, fallen zusätzliche Kosten für andere Dienste als Bigtable an. Wenn Sie beispielsweise Dataflow verwenden, zahlen Sie für die verarbeiteten Byte und die Worker-Maschinen, die den Job verarbeiten. Weitere Informationen finden Sie unter Dataflow-Preise.

Zeilenbereiche löschen

Vermeiden Sie das Löschen eines Zeilenbereichs aus einer Tabelle mit aktiviertem Änderungsstream nach Möglichkeit. Wenn Sie einen Zeilenbereich löschen müssen, beachten Sie, dass es lange dauern kann, bis Bigtable den Vorgang abgeschlossen hat, und dass die CPU-Auslastung während des Vorgangs zunimmt.