Datastream mit einer vorhandenen BigQuery-Tabelle verwenden
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite werden Best Practices für Anwendungsfälle beschrieben, in denen:
Nutzer haben eine vorhandene Tabelle in BigQuery und müssen ihre Daten mithilfe von Change Data Capture (CDC) in dieselbe BigQuery-Tabelle replizieren.
Nutzer müssen Daten in eine vorhandene BigQuery-Tabelle kopieren, ohne die Backfill-Funktion von Datastream zu verwenden, entweder aufgrund der Zeit, die dafür erforderlich wäre, oder aufgrund von Produkteinschränkungen.
Problem
Für eine BigQuery-Tabelle, die mit der BigQuery Storage Write API ausgefüllt wird, sind keine regulären DML-Vorgänge (Data Manipulation Language) zulässig. Das bedeutet, dass nach dem Start des Schreibens eines CDC-Streams in eine BigQuery-Tabelle keine Verlaufsdaten hinzugefügt werden können, die nicht bereits in der Tabelle vorhanden waren.
Stellen Sie sich folgendes Szenario vor:
TIMESTAMP 1: Der Tabellenkopiervorgang wird gestartet.
TIMESTAMP 2: Während die Tabelle kopiert wird, führen DML-Vorgänge an der Quelle zu Änderungen an den Daten (Zeilen werden hinzugefügt, aktualisiert oder entfernt).
TIMESTAMP 3: CDC wird gestartet, Änderungen, die bei TIMESTAMP 2 stattgefunden haben, werden nicht erfasst, was zu Datenabweichungen führt.
Lösung
Um die Datenintegrität zu gewährleisten, muss der CDC-Prozess alle Änderungen an der Quelle erfassen, die seit dem letzten Update aufgetreten sind, das in die BigQuery-Tabelle kopiert wurde.
Mit der folgenden Lösung können Sie dafür sorgen, dass der CDC-Prozess alle Änderungen ab TIMESTAMP 2 erfasst, ohne dass der Kopiervorgang das Schreiben von Daten in die BigQuery-Tabelle blockiert.
Vorbereitung
Die Zieltabelle in BigQuery muss genau dasselbe Schema und dieselbe Konfiguration haben, als wäre die Tabelle von Datastream erstellt worden. Dazu können Sie das Datastream BigQuery Migration Toolkit verwenden.
Bei MySQL- und Oracle-Quellen muss der Nutzer die Protokollposition zum Zeitpunkt des Startens des Kopiervorgangs ermitteln können.
Die Datenbank muss genügend Speicherplatz und eine ausreichende Aufbewahrungsrichtlinie für Protokolle haben, damit das Kopieren der Tabelle abgeschlossen werden kann.
MySQL- und Oracle-Quellen
Erstellen Sie den Stream, den Sie für die laufende CDC-Replikation verwenden möchten, aber starten Sie ihn nicht. Der Stream muss den Status ERSTELLT haben.
Wenn Sie mit dem Kopiervorgang der Tabelle beginnen möchten, ermitteln Sie die aktuelle Protokollposition der Datenbank:
Informationen zum Abrufen der binären Protokollkoordinaten für die Replikation unter MySQL finden Sie in der MySQL-Dokumentation. Nachdem Sie die Protokollposition ermittelt haben, schließen Sie die Sitzung, um alle Sperren für die Datenbank aufzuheben.
Führen Sie für Oracle die folgende Abfrage aus: SELECT current_scn FROM V$DATABASE
Kopieren Sie die Tabelle aus der Quelldatenbank in BigQuery.
Sobald der Kopiervorgang abgeschlossen ist, folge der Anleitung auf der Seite Streams verwalten, um den Stream an der zuvor ermittelten Protokollposition zu starten.
PostgreSQL-Quellen
Wenn Sie mit dem Kopieren der Tabelle beginnen möchten, erstellen Sie den Replikationsslot.
Weitere Informationen finden Sie unter PostgreSQL-Quelldatenbank konfigurieren.
Kopieren Sie die Tabelle aus der Quelldatenbank in BigQuery.
Sobald der Kopiervorgang abgeschlossen ist, erstellen und starten Sie den Stream.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eThis guide provides solutions for replicating data from existing tables into BigQuery using change data capture (CDC) without using Datastream's backfill feature.\u003c/p\u003e\n"],["\u003cp\u003eThe primary challenge addressed is ensuring data integrity when using BigQuery's Storage Write API for CDC, which does not allow adding historical data after the CDC stream begins, leading to potential data discrepancies.\u003c/p\u003e\n"],["\u003cp\u003eTo prevent data loss during table copy operations, the CDC process must capture all changes made to the source table from the moment after the last copied update.\u003c/p\u003e\n"],["\u003cp\u003eThe solution involves identifying the log position in MySQL and Oracle sources at the start of the copy operation, and using this position to start the CDC stream after the copy is completed, or using a replication slot for PostgreSQL sources.\u003c/p\u003e\n"],["\u003cp\u003eTarget tables must be using the correct schema, and the database must have the correct storage and log retention policy.\u003c/p\u003e\n"]]],[],null,["# Use Datastream with an existing BigQuery table\n\nThis page describes best practices for use cases where:\n\n- Users have an existing table in BigQuery and need to replicate their data using change data capture (CDC) into the same BigQuery table.\n- Users need to copy data into an existing BigQuery table without using the Datastream backfill capability, either because of the time it would take or because of product limitations.\n\nProblem\n-------\n\nA BigQuery table that's populated using the [BigQuery Storage\nWrite API](/bigquery/docs/change-data-capture) doesn't allow regular data\nmanipulation language (DML) operations. This means that once a CDC stream\nstarts writing to a BigQuery table, there's no way to add historical data\nthat wasn't already pre-populated in the table.\n\nConsider the following scenario:\n\n1. **TIMESTAMP 1**: the table copy operation is initiated.\n2. **TIMESTAMP 2**: while the table is being copied, DML operations at the source result in changes to the data (rows are added, updated or removed).\n3. **TIMESTAMP 3** : CDC is started, changes that happened in **TIMESTAMP 2** aren't captured, resulting in data discrepancy.\n\nSolution\n--------\n\nTo ensure data integrity, the CDC process must capture all the changes in the\nsource that occurred from the moment immediately following the last update made\nthat was copied into the BigQuery table.\n\nThe solution that follows lets you ensure that the CDC process captures all the\nchanges from **TIMESTAMP 2**, without blocking the copy operation from writing data\ninto the BigQuery table.\n\n### Prerequisites\n\n- The target table in BigQuery must have the exact same schema and configuration as if the table was created by Datastream. You can use the [Datastream BigQuery Migration Toolkit](/datastream/docs/best-practices-migration-toolkit) to accomplish this.\n- For MySQL and Oracle sources, the user must be able to identify the log position at the time when the copy operation is initiated.\n- The database must have sufficient storage and log retention policy to allow the table copy process to complete.\n\n### MySQL and Oracle sources\n\n1. Create, but don't start the stream that you intend to use for the ongoing CDC replication. The stream needs to be in the **CREATED** state.\n2. When you're ready to start the table copy operation, identify the database current log position:\n - For MySQL, see the [MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterstatus.html) to learn how to obtain the replication binary log coordinates. Once you've identified the log position, close the session to release any locks on the database.\n - For Oracle, run the following query: `SELECT current_scn FROM V$DATABASE`\n3. Copy the table from the source database into BigQuery.\n4. Once the copy operation is completed, follow the steps described in the [Manage streams](/datastream/docs/manage-streams#startastreamfromspecific) page to start the stream from the log position that you identified earlier.\n\n### PostgreSQL sources\n\n1. When you're ready to start copying the table, create the replication slot. For more information, see [Configure a source PostgreSQL database](/datastream/docs/configure-your-source-postgresql-database).\n2. Copy the table from the source database into BigQuery.\n3. Once the copy operation is completed, create and start the stream."]]
