Änderungsstreams – Übersicht

Bigtable bietet mit der Funktion Änderungsstreams die Möglichkeit zur Datenerfassung (Change Data Capture, CDC). Ein Änderungsstream erfasst Datenänderungen an einer Bigtable-Tabelle in Echtzeit, 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 der Bigtable-Übersicht vertraut gemacht haben.

Änderungsstreams sind für die folgenden Anwendungsfälle der kontinuierlichen Datenübertragung nützlich:

  • Auslösen der Downstream-Anwendungslogik bei bestimmten Änderungen
  • Einbindung in eine Datenanalysepipeline
  • Anforderungen an Audits und Archivierung erfüllen

Was ist ein Änderungsstream?

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

Alle Änderungen, die auf eine Tabelle mit aktiviertem Änderungsstream angewendet werden, werden als Datenänderungseinträge gespeichert. Datenänderungseinträge umfassen Datenänderungen, die durch Folgendes angewendet wurden:

  • Schreib-, Lösch- und Aktualisierungsvorgänge, die mit den Cloud Bigtable API-Methoden MutateRow, MutateRows, CheckAndMutateRow und ReadModifyWriteRow gesendet werden
  • Löschungen aufgrund der automatischen Speicherbereinigung
  • Zeilen, die mit der Methode DropRowRange der Admin API gelöscht wurden

Weitere Informationen zu den Arten von Änderungen, die Sie an eine Bigtable-Tabelle senden können, finden Sie unter Lesungen, Schreibvorgänge, Löschvorgänge und Übersicht über die Garbage Collection.

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

Datenänderungseinträge für jeden Zeilenschlüssel und jeden Cluster sind nach dem Commit-Zeitstempel sortiert. 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 Datenänderungsdatensatzes

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

Wenn ein Wert überschrieben wird, wird der neu geschriebene Wert im Datenänderungseintrag erfasst. Der Datenänderungsdatensatz enthält keinen alten Wert.

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

Jeder Datenänderungseintrag enthält Folgendes:

  • Einträge: Änderungen an der Zeile, einschließlich einer oder mehrerer der folgenden Optionen:
    • 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öschvorgängen aus Spaltenfamilien für jede Spaltenfamilie umgewandelt, in der die Zeile Daten enthält.
  • Zeilenschlüssel: Die Kennung für die geänderte Zeile
  • Typ ändern – entweder vom Nutzer initiiert oder automatische Speicherbereinigung
  • ID des Clusters, in dem die Änderung empfangen wurde
  • Commit-Zeitstempel: Die serverseitige Zeit, zu der die Änderung in der Tabelle verbindlich wurde.
  • Entscheidungsfaktor: Ein Wert, mit dem die Anwendung, die den Stream liest, die vordefinierte Bigtable-Richtlinie zur Konfliktlösung verwenden kann.
  • Token: Wird von der nutzenden Anwendung verwendet, um den Stream fortzusetzen, wenn er unterbrochen wird.
  • Geschätzter niedriger Wasserstand: Die geschätzte Zeit, seit die Partition des Datensatzes mit der Replikation in allen Clustern auf dem neuesten Stand ist. Weitere Informationen finden Sie unter Partitionen und Wasserzeichen.

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

Speicher für Änderungsstream ändern

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

Der für Ihre Änderungsstreamdaten verwendete Speicherplatz wird nicht auf die Gesamtspeicherauslastung (max. %) angerechnet. Daher müssen Sie keine Knoten hinzufügen, um den erhöhten Speicherplatz zu bewältigen, den Änderungsstream-Daten verbrauchen. Möglicherweise müssen Sie jedoch Knoten für zusätzliche Rechenleistung hinzufügen. Ihnen wird jedoch der Speicherplatz in Rechnung gestellt, der von Ihren Änderungsstream-Daten belegt wird. Weitere Informationen finden Sie unter Kosten.

Änderungsstream lesen

Wenn Sie einen Änderungsstream lesen (streamen) möchten, 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 mit einer Zeile finden Sie unter Transaktionen mit einer Zeile.

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

  • Dataflow-Vorlagen
  • Bigtable Beam-Connector
  • Java-Clientbibliothek

Mit allen Optionen müssen Sie keine Partitionsänderungen aufgrund von Aufteilungen und Zusammenführungen verfolgen und bearbeiten.

Weitere Informationen finden Sie unter ReadChangeStream.

Dataflow-Vorlagen

Sie können eine der folgenden von Google bereitgestellten Dataflow-Vorlagen verwenden:

Bigtable Beam-Connector

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

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

Java-Clientbibliothek

Partitionen

Um einen hohen Lesedurchsatz zu gewährleisten, 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 Änderungsstream-Partition ist einer Tabletreihe zugeordnet. Tabellenzeilen sind Teilbereiche einer Tabelle, die bei Bedarf neu verteilt werden, um die Anfragelast der Tabelle auszugleichen. Weitere Informationen finden Sie unter Load Balancing.

Mit der Java-Clientbibliothek können Sie jede Partition auf Änderungen abfragen. Außerdem enthält sie die Informationen, die zum Verwalten von Änderungen in Partitionen aufgrund von Spaltungen und Zusammenführungen erforderlich sind.

Wasserzeichen

Ein Wasserzeichen ist ein Zeitstempel, der angibt, wie lange es her ist, dass eine Partition mit der Replikation in allen Clustern auf dem neuesten Stand ist. Das Wasserzeichen für die Partition wird während der Replikation kontinuierlich aktualisiert und geht dabei in Richtung Zukunft.

Jeder ChangeStreamMutation-Datenänderungseintrag (ChangeStreamMutation) enthält ein estimatedLowWatermark-Feld, das das Wasserzeichen für die Partition ist, die mit dem Datenänderungseintrag verknüpft ist. Dieser Wert ist eine Schätzung und es kann nicht garantiert werden, dass keine Daten im Stream fehlen.estimatedLowWatermark

Wasserzeichen für replizierte Tabellen

Der estimatedLowWatermark (Low Watermark) einer Partition wird nicht erhöht, wenn die Replikation für die Partition noch nicht vollständig abgeschlossen ist. Der streamweite niedrige Wasserzeichenwert – der niedrigste aller geschätzten niedrigen Wasserzeichenwerte auf Partitionsebene – wird nicht mehr erhöht, wenn das Wasserzeichen einer Partition nicht weitergeht. Ein Wasserzeichen, das nicht mehr fortschreitet, gilt als eingefroren. Wenn Sie in diesem Fall Ihren Änderungsstream in einer Pipeline streamen, kommt die Pipeline zum Stillstand.

Es gibt viele Faktoren, die dazu führen können, dass ein oder mehrere Markierungen auf Partitionsebene für einige Zeit stecken bleiben. Dazu gehören:

  • Überlastung eines Clusters durch Traffic, der dazu führt, dass die Replikation für eine oder mehrere Partitionen ins Hintertreffen gerät
  • Netzwerkverzögerungen
  • Nicht verfügbarer Cluster

Der Bigtable Beam-Connector löst dieses Problem, indem er den Ausgabezeitstempel für alle Daten auf null setzt. Weitere Informationen finden Sie unter Daten ohne Ereigniszeiten gruppieren.

Monitoring

Damit Sie besser nachvollziehen können, wie sich die Aktivierung eines Änderungsstreams auf die CPU- und Speichernutzung einer Instanz mit Tabellen auswirkt, die für Änderungsstreams aktiviert sind, stellen wir zwei änderungsstreamspezifische Messwerte bereit. Sie können die Messwerte auf der Seite „Bigtable Monitoring“ oder mithilfe der Cloud Monitoring-Tools aufrufen.

Weitere Informationen zu diesen Messwerten finden Sie unter Monitoring.

Kostengesichtspunkte

Wenn Sie einen Änderungsstream für eine Tabelle aktivieren, steigen die Kosten für Knoten und Speicherplatz. Insbesondere können höhere Speicherkosten anfallen.

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 durch das Aktivieren und Verarbeiten der Datenänderungssätze zu bewältigen.

Wenn Sie einen Änderungsstream aktivieren, kann die CPU-Auslastung um etwa 10 % steigen, noch bevor Sie mit der Verarbeitung beginnen. Die Verarbeitung eines Änderungsstreams, z. B. das Lesen mit einer Dataflow-Pipeline, kann die CPU-Auslastung je nach Umfang der Änderungsaktivitäten und der Art und Weise, wie die Streamdaten gelesen werden, um etwa 20 bis 30 % erhöhen.

Speicher

Für das Speichern der Datenänderungseinträge Ihrer Tabelle werden Ihnen die standardmäßigen Bigtable-Speicherpreise in Rechnung gestellt. Außerdem werden Ihnen die Kosten für die Speicherung der Tabelle in Rechnung gestellt, die zum Erfassen von Änderungsstream-Metadaten erstellt wird. Die von Ihnen angegebene Aufbewahrungsdauer wirkt sich direkt auf die Speicherkosten aus.

Generell belegen die Datenänderungssätze eines Tages, die nur die an diesem Tag erfolgten Mutationen widerspiegeln, etwa 1,5-mal so viel Speicherplatz wie die Daten, die an diesem Tag auf die Festplatte geschrieben wurden.

Netzwerk-Datenübertragung

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

Bearbeitungskosten

Je nachdem, wie Sie die Datenänderungssätze 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, auf denen der Job verarbeitet wird. Weitere Informationen finden Sie unter Dataflow-Preise.

Zeilenbereiche löschen

Vermeiden Sie nach Möglichkeit das Löschen eines Zeilenbereichs aus einer Tabelle, für die ein Änderungsstream aktiviert ist. Falls Sie trotzdem 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 ansteigt.

Nächste Schritte