Diese Seite wurde von der Cloud Translation API übersetzt.

Änderungsstreams – Übersicht

Bigtable bietet Change Data Capture (CDC) mit der Funktion Änderungsstreams. Ein Änderungsstream erfasst Datenänderungen in einer Bigtable-Tabelle, während die Änderungen erfolgen, und können sie zur Verarbeitung oder Analyse streamen.

Dieses Dokument bietet einen Überblick über Bigtable-Änderungsstreams. Bevor Sie dieses Dokument lesen, sollten Sie mit der Bigtable-Übersicht vertraut sein.

Änderungsstreams sind für CDC-Anwendungsfälle wertvoll, darunter:

Nachgelagerte Anwendungslogik auslösen, wenn angegebene Änderungen auftreten
In eine Datenanalysepipeline einbinden
Anforderungen an Audits und Archivierung erfüllen

Was ist ein Veränderungsstream?

Ein Änderungsstream verfolgt Änderungen auf Tabellenebene, die von einem Nutzer oder einer Anwendung vorgenommen werden, in der Regel mit einer der Cloud Bigtable-Clientbibliotheken. Änderungen der automatischen Speicherbereinigung werden ebenfalls erfasst.

Alle Änderungen, die auf eine Tabelle mit aktiviertem Änderungsstream angewendet werden, werden als Datenänderungseinträge gespeichert. Datensätze zu Datenänderungen enthalten Datenänderungen, die durch Folgendes angewendet 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 Sie an eine Bigtable-Tabelle senden können, finden Sie unter Lesevorgänge, Schreibvorgänge, Löschungen und Übersicht über die automatische Speicherbereinigung.

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

Datenänderungseinträge für jeden Zeilenschlüssel und jeden Cluster befinden sich in der Commit-Zeitstempelreihenfolge. Es gibt jedoch keine Garantie für die Reihenfolge von Datenänderungseinträgen für einen anderen Zeilenschlüssel oder Cluster.

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

Inhalt eines Änderungsprotokolls

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

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

Ein Datenänderungseintrag erhält seinen Zeitstempel, der als Commit-Zeitstempel bezeichnet wird, gleichzeitig mit der Änderung auf den ersten Cluster, 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 des Datenänderungseintrags zugewiesen, wenn der Schreibvorgang von Cluster A empfangen wird. Der Datenänderungseintrag in Cluster B für diesen Schreibvorgang hat denselben Commit-Zeitstempel.

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

Einträge: Änderungen an der Zeile, darunter mindestens eines der folgenden Elemente:
- Schreiben
  - Spaltenfamilie
  - Spaltenqualifizierer
  - Zeitstempel
  - Wert
- Löschen von Zellen
  - Spaltenfamilie
  - Spaltenqualifizierer
  - Zeitstempelbereich
- Löschen einer Spaltenfamilie
  - Spaltenfamilie
  - Löschung aus einer Zeile: Das Löschen aus einer Zeile wird in eine Liste von Löschungen aus Spaltenfamilien für jede Spaltenfamilie umgewandelt, in der die Zeile Daten enthält.
Zeilenschlüssel: die Kennung der geänderten Zeile
Art der Änderung – entweder vom Nutzer initiiert oder durch automatische Speicherbereinigung
ID des Clusters, der die Änderung erhalten hat
Commit-Zeitstempel: serverseitige Zeit, zu der die Änderung per Commit an die Tabelle übergeben wurde
Tiebreaker: Ein Wert, mit dem die Anwendung, die den Stream liest, die integrierte Konfliktlösungsrichtlinie von Bigtable verwenden kann.
Token – wird von der verarbeitenden Anwendung verwendet, um den Stream fortzusetzen, falls er unterbrochen wird
Geschätztes niedriges Wasserzeichen: die geschätzte Zeit, seit die Partition des Eintrags die Replikation in allen Clustern abgeschlossen hat. Weitere Informationen finden Sie unter Partitionen und Wasserzeichen.

Weitere Informationen zu den Feldern in einem Datensatz für Datenänderungen finden Sie in der API-Referenz zu DataChange.

Streamspeicher ändern

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

Der für die Änderungsstreamdaten verwendete Speicher wird nicht auf die gesamte Speicherauslastung (max. %) angerechnet. Folglich müssen Sie keine Knoten hinzufügen, um den zusätzlichen Speicher zu bewältigen, der durch Änderungsstreamdaten verbraucht wird (obwohl Sie möglicherweise Knoten hinzufügen müssen, um zusätzliche Rechenleistung zu erhalten). Ihnen wird jedoch der Speicher 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. Wenn Sie mit Dataflow streamen, müssen Sie Transaktionen für einzelne Zeilen aktivieren.

Weitere Informationen zu Routingrichtlinien finden Sie unter Routingoptionen.

Weitere Informationen zu Transaktionen für einzelne Zeilen finden Sie unter Transaktionen für einzelne Zeilen.

Änderungsstreammethoden werden von der Cloud Bigtable API (Data API) bereitgestellt. Wir empfehlen, eine der folgenden Optionen zu verwenden, anstatt die API ohne Verwendung einer Clientbibliothek oder eines Connectors aufzurufen:

Dataflow-Vorlagen
Bigtable Beam-Connector
Java-Clientbibliothek aktualisiert

Mit allen Optionen können Sie vermeiden, dass Sie Partitionsänderungen aufgrund von Aufteilungen und Zusammenführungen verfolgen und verarbeiten müssen.

Weitere Informationen finden Sie unter ReadChangeStream.

Dataflow-Vorlagen

Sie können eine der folgenden Dataflow-Vorlagen von Google 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 aktualisiert

Cloud Bigtable-Client für Java

Partitionen

Um einen hohen Lesedurchsatz zu erhalten, der einer hohen Schreib- oder Änderungsrate entspricht, teilt Bigtable einen Änderungsstream in mehrere Partitionen auf, die zum parallelen Lesen des Änderungsstreams verwendet werden können. Jede Änderungsstreampartition ist mit einem Tablet verknüpft. Tablets 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. Sie stellt die Informationen bereit, die zum Verwalten von Änderungen in Partitionen aufgrund von Aufteilungen und Zusammenführungen erforderlich sind.

Wasserzeichen

Ein Wasserzeichen ist ein Zeitstempel, der angibt, wann eine Partition die Replikation in allen Clustern bereits abgeschlossen hat. Das Wasserzeichen für die Partition wird fortlaufend aktualisiert, wenn die Replikation stattfindet.

Jedes ChangeStreamMutation (Datenänderungseintrag) enthält ein estimatedLowWatermark-Feld. Es ist das Wasserzeichen für die Partition, die dem Datenänderungseintrag zugeordnet ist. estimatedLowWatermark ist eine Schätzung und keine Garantie dafür, dass noch keine Daten im Stream ankommen.

Wasserzeichen für replizierte Tabellen

Der estimatedLowWatermark (niedriges Wasserzeichen) einer Partition wird nicht vorangetrieben, wenn die Replikation nicht vollständig von der Partition abgedeckt wird. Das im Stream verlaufende niedrige Wasserzeichen – die niedrigste aller geschätzten niedrigen Wasserzeichen auf Partitionsebene – wird nicht mehr weiterbewegt, wenn sich das Wasserzeichen einer Partition nicht weiter bewegt. Ein Wasserzeichen, das nicht weiterläuft, gilt als verzögert. Wenn Sie in diesem Fall Ihren Änderungsstream in einer Pipeline streamen, stürzt die Pipeline ins Stocken.

Es gibt verschiedene Faktoren, die dazu führen können, dass ein oder mehrere Wasserzeichen auf Partitionsebene für einen bestimmten Zeitraum angehalten werden. Dazu gehören:

Überlastung eines Clusters mit Traffic, der dazu führt, dass die Replikation für eine oder mehrere Partitionen in Verzug ist
Netzwerkverzögerungen
Cluster-Nichtverfügbarkeit

Zu diesem Zweck 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 verstehen, wie sich das Aktivieren eines Änderungsstreams auf die CPU- und Speicherauslastung einer Instanz mit für den Änderungsstream aktivierten Tabellen auswirkt, stellen wir zwei Messwerte für den Änderungsstream zur Verfügung. Sie können sich die Messwerte auf der Bigtable Monitoring-Seite oder mithilfe der Cloud Monitoring-Tools ansehen.

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 höheren Kosten für Knoten und Speicher. Konkret fallen höhere Speicherkosten an.

Knoten

In der Regel 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 durch das Aktivieren und Verarbeiten der Datenänderungseinträge zu verarbeiten.

Durch das Aktivieren eines Änderungsstreams kann die CPU-Nutzung schon vor der Verarbeitung um etwa 10 % erhöht werden. Die Verarbeitung eines Änderungsstreams, z. B. das Lesen mit einer Dataflow-Pipeline, kann die CPU-Auslastung um etwa 20 bis 30 % erhöhen, je nachdem, wie stark die Änderungsaktivität ist und wie die Streamdaten gelesen werden.

Speicher

Ihnen werden die standardmäßigen Bigtable-Speicherpreise für das Speichern der Datenänderungseinträge Ihrer Tabelle in Rechnung gestellt. Außerdem fallen Kosten für das Speichern der Tabelle an, die erstellt wurde, um die Metadaten des Änderungsstreams zu verfolgen. Die von Ihnen angegebene Aufbewahrungsdauer wirkt sich direkt auf die Speicherkosten aus.

Im Allgemeinen benötigen die Datenänderungseinträge eines Tages, die nur die an diesem Tag aufgetretenen Mutationen widerspiegeln, etwa 1,5-mal so viel Speicherplatz wie die an diesem Tag geschriebenen Daten auf der Festplatte.

Netzwerk-Datenübertragung

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

Verarbeitungskosten

Je nachdem, wie Sie die Datensätze zu Datenänderungen 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 es nach Möglichkeit, einen Zeilenbereich aus einer Tabelle mit aktiviertem Änderungsstream zu löschen. Wenn Sie einen Zeilenbereich löschen müssen, denken Sie daran, dass es lange dauern kann, bis Bigtable den Vorgang abgeschlossen hat, und dass die CPU-Auslastung während des Vorgangs zunimmt.