Utilizzare Datastream con una tabella BigQuery esistente
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina descrive le best practice per i casi d'uso in cui:
Gli utenti hanno una tabella esistente in BigQuery e devono replicare i propri dati utilizzando Change Data Capture (CDC) nella stessa tabella BigQuery.
Gli utenti devono copiare i dati in una tabella BigQuery esistente senza utilizzare la funzionalità di backfill di Datastream, a causa del tempo necessario o delle limitazioni del prodotto.
Problema
Una tabella BigQuery compilata utilizzando l'API BigQuery Storage Write non consente operazioni di Data Manipulation Language (DML) standard. Ciò significa che, una volta che uno stream CDC inizia a scrivere in una tabella BigQuery, non è possibile aggiungere dati storici che non sono già stati precompilati nella tabella.
Considera il seguente scenario:
TIMESTAMP 1: viene avviata l'operazione di copia della tabella.
TIMESTAMP 2: durante la copia della tabella, le operazioni DML all'origine provocano modifiche ai dati (le righe vengono aggiunte, aggiornate o rimosse).
TIMESTAMP 3: il CDC è avviato, le modifiche apportate in TIMESTAMP 2 non vengono acquisite, con conseguente discrepanza nei dati.
Soluzione
Per garantire l'integrità dei dati, il processo CDC deve acquisire tutte le modifiche all'origine che si sono verificate dal momento immediatamente successivo all'ultimo aggiornamento eseguito e che è stato copiato nella tabella BigQuery.
La soluzione che segue ti consente di assicurarti che il processo CDC acquisisca tutte le modifiche a partire da TIMESTAMP 2, senza bloccare l'operazione di copia che scrive i dati nella tabella BigQuery.
Prerequisiti
La tabella di destinazione in BigQuery deve avere lo stesso schema e la stessa configurazione come se fosse stata creata da Datastream. Puoi utilizzare il Datastream BigQuery Migration Toolkit per farlo.
Per le origini MySQL e Oracle, l'utente deve essere in grado di identificare la posizione del log
al momento dell'avvio dell'operazione di copia.
Il database deve avere spazio di archiviazione e criteri di conservazione dei log sufficienti per consentire il completamento della procedura di copia delle tabelle.
Origini MySQL e Oracle
Crea, ma non avviare lo stream che intendi utilizzare per la replica del CDC in corso. Lo stream deve essere in stato CREATO.
Quando è tutto pronto per iniziare l'operazione di copia della tabella, identifica la posizione corrente del log del database:
Per MySQL, consulta la documentazione di MySQL per scoprire come ottenere le coordinate del log binario di replica. Una volta identificata la posizione del log, chiudi la sessione per rilasciare eventuali blocchi sul database.
Per Oracle, esegui la seguente query: SELECT current_scn FROM V$DATABASE
Copia la tabella dal database di origine in BigQuery.
Al termine dell'operazione di copia, segui i passaggi descritti nella pagina Gestisci stream per avviare lo stream dalla posizione del log identificata in precedenza.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
