Flusso di aggiornamenti delle tabelle con Change Data Capture

La tecnologia Change Data Capture (CDC) di BigQuery aggiorna BigQuery mediante l'elaborazione e l'applicazione di modifiche in modalità flusso ai dati esistenti. Questo la sincronizzazione avviene mediante operazioni di upsert ed eliminazione delle righe, vengono trasmessi in streaming in tempo reale API BigQuery StorageWrite, che dovresti essere prima di procedere.

Prima di iniziare

Concede ruoli IAM (Identity and Access Management) che concedono agli utenti le autorizzazioni necessarie eseguire ogni attività descritta in questo documento e assicurarti che il flusso di lavoro soddisfi ogni prerequisito.

Autorizzazioni obbligatorie

Per ottenere l'autorizzazione necessaria per usare l'API StorageWrite, chiedi all'amministratore di concederti Ruolo IAM Editor dati BigQuery (roles/bigquery.dataEditor). Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.

Questo ruolo predefinito contiene bigquery.tables.updateData, che è richiesta per usare l'API StorageWrite.

Potresti anche riuscire a ottenere questa autorizzazione con ruoli personalizzati e altri ruoli predefiniti.

Per ulteriori informazioni su ruoli e autorizzazioni IAM in per BigQuery, consulta Introduzione a IAM.

Prerequisiti

Per utilizzare BigQuery CDC, il flusso di lavoro deve soddisfare quanto segue condizioni:

  • Devi utilizzare l'API StorageWrite nella streaming predefinito.
  • Devi dichiarare chiavi primarie di destinazione in BigQuery. Chiavi primarie composte sono supportate fino a un massimo di 16 colonne.
  • Devono essere disponibili risorse di calcolo BigQuery sufficienti eseguire le operazioni sulle righe CDC. Tieni presente che, se la modifica delle righe CDC potrebbero non funzionare correttamente, potresti involontariamente conservare i dati che intendevi eliminare. Per ulteriori informazioni, vedi Considerazioni sui dati eliminati.

Specifica le modifiche ai record esistenti

In CDC di BigQuery, la pseudocolonna _CHANGE_TYPE indica la tipo di modifica da elaborare per ogni riga. Per utilizzare CDC, imposta _CHANGE_TYPE quando puoi trasmettere le modifiche alle righe utilizzando l'API StorageWrite. La La pseudocolonna _CHANGE_TYPE accetta solo i valori UPSERT e DELETE. Una tabella è considerata abilitata per la CDC, mentre l'API StorageWrite è flussi di modifiche delle righe alla tabella in questo modo.

Esempio con valori UPSERT e DELETE

Considera la seguente tabella in BigQuery:

ID Nome Retribuzione
100 Fattura 2000
101 Lucia 3000
102 Roberto 5000

Le seguenti modifiche alle righe vengono trasmesse in flusso API StorageWrite:

ID Nome Retribuzione _CHANGE_TYPE
100 ELIMINA
101 Lucia 8000 UPSERT
105 Max 6000 UPSERT

La tabella aggiornata è ora la seguente:

ID Nome Retribuzione
101 Lucia 8000
102 Roberto 5000
105 Max 6000

Gestisci l'inattività della tabella

Per impostazione predefinita, ogni volta che esegui una query, BigQuery restituisce e i risultati aggiornati. per fornire i risultati più recenti quando si esegue una query su una piattaforma CDC abilitata tabella, BigQuery deve applicare ogni modifica di righe in modalità flusso fino al l'ora di inizio della query, in modo che la versione più aggiornata della tabella con cui viene eseguita la query. L'applicazione di queste modifiche alle righe durante il tempo di esecuzione della query aumenta la query latenza e costi. Tuttavia, se non hai bisogno di risultati delle query completamente aggiornati, puoi ridurre i costi e la latenza delle query impostando il max_staleness nella tabella. Se questa opzione è impostata, BigQuery applica le modifiche di riga almeno una volta nell'intervallo definito max_staleness, che ti consente di eseguire query senza attendere gli aggiornamenti applicati, a scapito dell'inattività dei dati.

Questo comportamento è particolarmente utile per le dashboard e i report per i quali l'aggiornamento non è essenziale. È utile anche per la gestione dei costi, in quanto offre maggiore controllo sulla frequenza di applicazione delle righe da parte di BigQuery modifiche.

Esegui query sulle tabelle con l'opzione max_staleness impostata

Quando esegui una query su una tabella con l'opzione max_staleness impostata, BigQuery restituisce il risultato in base al valore di max_staleness. e l'ora in cui si è verificato l'ultimo job di candidature, rappresentato da il timestamp upsert_stream_apply_watermark della tabella.

Considera l'esempio seguente, in cui una tabella ha l'opzione max_staleness impostata su 10 minuti e il job di candidatura più recente si è verificato al livello T20:

Il tempo di esecuzione della query rientra nell'intervallo di tempo massimo per l'inattività dei dati.

Se esegui una query sulla tabella T25, la versione corrente della tabella è 5 minuti, ossia meno dell'intervallo max_staleness di 10 minuti. Nel in questo caso, BigQuery restituisce la versione della tabella al T20, il che significa che anche i dati restituiti sono inattivi per 5 minuti.

Quando imposti l'opzione max_staleness nella tabella, BigQuery applica le modifiche alle righe in sospeso almeno una volta all'interno di max_staleness intervallo di tempo. In alcuni casi, tuttavia, BigQuery potrebbe non completare processo di applicazione di queste modifiche di riga in sospeso all'interno dell'intervallo.

Ad esempio, se esegui una query sulla tabella al T35 e il processo di applicazione le modifiche alle righe non sono state completate, la versione corrente della tabella è 15 minuti di inattività, superiore all'intervallo max_staleness di 10 minuti. In questo caso, al momento dell'esecuzione della query, BigQuery applica tutte le righe modifiche tra T20 e T35 per la query corrente, ovvero i dati sono completamente aggiornati, a scapito di una latenza aggiuntiva delle query. Questo è considerato un job di unione di runtime.

Il tempo di esecuzione della query non rientra nell'intervallo di tempo massimo per l'inattività dei dati.

Il valore max_staleness di una tabella in genere deve essere il più alto tra i seguenti: due valori:

  • L'inattività massima tollerabile dei dati per il tuo flusso di lavoro.
  • Il doppio del tempo massimo necessario per applicare modifiche con upserted nella tua e un buffer aggiuntivo.

Per calcolare il tempo necessario per applicare le modifiche con upserted a una tabella esistente, usa la seguente query SQL per determinare il 95° percentile dei job di applicazione in background, più un buffer di sette minuti per consentire Conversione dello spazio di archiviazione ottimizzato per la scrittura (buffer di flusso) BigQuery.

SELECT
  project_id,
  destination_table.dataset_id,
  destination_table.table_id,
  APPROX_QUANTILES((TIMESTAMP_DIFF(end_time, creation_time,MILLISECOND)/1000), 100)[OFFSET(95)] AS p95_background_apply_duration_in_seconds,
  CEILING(APPROX_QUANTILES((TIMESTAMP_DIFF(end_time, creation_time,MILLISECOND)/1000), 100)[OFFSET(95)]*2/60)+7 AS recommended_max_staleness_with_buffer_in_minutes
FROM `region-us`.INFORMATION_SCHEMA.JOBS AS job
WHERE
  project_id = 'PROJECT_ID'
  AND DATE(creation_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) AND CURRENT_DATE()
  AND job_id LIKE "%cdc_background%"
GROUP BY 1,2,3;

Sostituisci PROJECT_ID con l'ID del progetto contenente le tabelle BigQuery modificate CDC di BigQuery.

La durata dei job di applicazione in background è influenzata da diversi fattori, tra cui il numero e la complessità delle operazioni CDC eseguite in stato di inattività intervallo, le dimensioni della tabella e la disponibilità delle risorse BigQuery. Per saperne di più sulla disponibilità delle risorse, consulta Dimensioni e monitoraggio delle prenotazioni BACKGROUND.

Crea una tabella con l'opzione max_staleness

Per creare una tabella con l'opzione max_staleness, utilizza la proprietà Dichiarazione CREATE TABLE. L'esempio seguente crea la tabella employees con un limite di max_staleness di 10 minuti:

CREATE TABLE employees (
  id INT64 PRIMARY KEY NOT ENFORCED,
  name STRING)
  CLUSTER BY
    id
  OPTIONS (
    max_staleness = INTERVAL 10 MINUTE);

Modifica l'opzione max_staleness per una tabella esistente

Per aggiungere o modificare un limite di max_staleness in una tabella esistente, utilizza la Dichiarazione ALTER TABLE. L'esempio seguente modifica il limite max_staleness della tabella employees ai 15 minuti:

ALTER TABLE employees
SET OPTIONS (
  max_staleness = INTERVAL 15 MINUTE);

Determina il valore max_staleness attuale di una tabella

Per determinare l'attuale valore max_staleness di una tabella, esegui una query su INFORMATION_SCHEMA.TABLE_OPTIONS visualizzazione. L'esempio seguente controlla il valore attuale di max_staleness della tabella mytable:

SELECT
  option_name,
  option_value
FROM
  DATASET_NAME.INFORMATION_SCHEMA.TABLE_OPTIONS
WHERE
  option_name = 'max_staleness'
  AND table_name = 'TABLE_NAME';

Sostituisci quanto segue:

  • DATASET_NAME: il nome del set di dati in cui della tabella abilitata per CDC.
  • TABLE_NAME: il nome della tabella abilitata per CDC.

I risultati mostrano che il valore max_staleness è 10 minuti:

+---------------------+--------------+
| Row |  option_name  | option_value |
+---------------------+--------------+
|  1  | max_staleness | 0-0 0 0:10:0 |
+---------------------+--------------+

Monitora l'avanzamento dell'operazione di upsert della tabella

Per monitorare lo stato di una tabella e controllare quando sono state apportate le modifiche alle righe applicata per l'ultima volta, esegui una query INFORMATION_SCHEMA.TABLES visualizzazione per ottenere il timestamp upsert_stream_apply_watermark.

L'esempio seguente verifica il valore upsert_stream_apply_watermark di la tabella mytable:

SELECT upsert_stream_apply_watermark
FROM DATASET_NAME.INFORMATION_SCHEMA.TABLES
WHERE table_name = 'TABLE_NAME';

Sostituisci quanto segue:

  • DATASET_NAME: il nome del set di dati in cui della tabella abilitata per CDC.
  • TABLE_NAME: il nome della tabella abilitata per CDC.

Il risultato è simile al seguente:

[{
 "upsert_stream_apply_watermark": "2022-09-15T04:17:19.909Z"
}]

Le operazioni di upsert vengono eseguite dall'bigquery-adminbot@system.gserviceaccount.com l'account di servizio e vengono visualizzati nella cronologia dei job del progetto Tabella abilitata per CDC.

Gestisci gli ordini personalizzati

Quando si esegue un flusso di upsert in BigQuery, il comportamento predefinito l'ordinamento di record con chiavi primarie identiche è determinato Ora del sistema BigQuery in cui il record è stato importato in BigQuery. In altre parole, il record importato più di recente con il timestamp più recente ha la precedenza sul record precedentemente importato con un timestamp precedente. Per alcuni casi d'uso, come quelli in cui sono Gli upsert possono verificarsi per la stessa chiave primaria in una finestra di tempo molto breve, oppure dove l'ordine dell'upsert non è garantito, poiché potrebbe non essere sufficiente. Per questi potrebbe essere necessaria una chiave di ordinamento fornita dall'utente.

Per configurare le chiavi di ordinamento fornite dall'utente, la pseudocolonna _CHANGE_SEQUENCE_NUMBER viene utilizzato per indicare l'ordine in cui BigQuery deve applicare i record, in base alle _CHANGE_SEQUENCE_NUMBER tra due record corrispondenti con lo stesso stato principale chiave. La pseudocolonna _CHANGE_SEQUENCE_NUMBER è facoltativa e può essere accetta valori in un formato fisso STRING.

Formato _CHANGE_SEQUENCE_NUMBER

La pseudocolonna _CHANGE_SEQUENCE_NUMBER accetta solo valori STRING, scritte in formato fisso. Questo formato fisso utilizza valori STRING scritti in esadecimale, separato in sezioni da una barra /. Ogni sezione può essere espressi in al massimo 16 caratteri esadecimali e fino a quattro sezioni consentito per _CHANGE_SEQUENCE_NUMBER. L'intervallo consentito _CHANGE_SEQUENCE_NUMBER supporta valori compresi tra 0/0/0/0 e FFFFFFFFFFFFFFFF/FFFFFFFFFFFFFFFF/FFFFFFFFFFFFFFFF/FFFFFFFFFFFFFFFF. I valori _CHANGE_SEQUENCE_NUMBER supportano lettere maiuscole e minuscole caratteri.

È possibile esprimere le chiavi di ordinamento di base utilizzando un'unica sezione. Per Ad esempio, per ordinare le chiavi esclusivamente in base al timestamp di elaborazione di un record server applicazioni, potresti utilizzare una sezione: '2024-04-30 11:19:44 UTC', espresso come esadecimale convertendo il timestamp in millisecondi da Epoca, '18F2EBB6480' in questo caso. La logica per convertire i dati in esadecimale è responsabilità del client che invia la scrittura a BigQuery. utilizzando l'API StorageWrite.

Il supporto di più sezioni consente di combinare diversi valori logici di elaborazione in un'unica chiave per casi d'uso più complessi. Ad esempio, per ordinare le chiavi in base a il timestamp di elaborazione di un record da un server applicazioni, una sequenza di log numero e lo stato del record, puoi utilizzare tre sezioni: '2024-04-30 11:19:44 UTC' / '123' / 'complete', ciascuno espresso in formato esadecimale. L'ordine delle sezioni è importante per il ranking logica di elaborazione. BigQuery confronta _CHANGE_SEQUENCE_NUMBER mettendo a confronto la prima sezione e poi la sezione successiva solo se le sezioni precedenti erano uguali.

BigQuery utilizza _CHANGE_SEQUENCE_NUMBER per eseguire l'ordinamento confrontando due o più campi _CHANGE_SEQUENCE_NUMBER come valori numerici non firmati e i relativi valori. Considera i seguenti esempi di confronto per _CHANGE_SEQUENCE_NUMBER i loro risultati di precedenza:

  • Esempio 1:

    • Record 1: _CHANGE_SEQUENCE_NUMBER = "77"
    • Record 2: _CHANGE_SEQUENCE_NUMBER = "7B"

    Risultato: il record 2 è considerato l'ultimo record perché "7B" > "77" (ad es. "123" > "119").

  • Esempio 2:

    • Record 1: _CHANGE_SEQUENCE_NUMBER = "FFF/B"
    • Record 2: _CHANGE_SEQUENCE_NUMBER = "FFF/ABC"

    Risultato: il record 2 è considerato il record più recente perché "FFF/ABC" > "FFF/B" (ad es. "4095/2748" > "4095/11").

  • Esempio 3:

    • Record 1: _CHANGE_SEQUENCE_NUMBER = "BA/FFFFFFFF"
    • Record 2: _CHANGE_SEQUENCE_NUMBER = "ABC"

    Risultato: il record 2 è considerato il record più recente perché "ABC" > "BA/FFFFFFFF" (ad es. "2748" > "186/4294967295")

  • Esempio 4:

    • Record 1: _CHANGE_SEQUENCE_NUMBER = "FFF/ABC"
    • Record 2: _CHANGE_SEQUENCE_NUMBER = "ABC"

    Risultato: il record 1 è considerato il record più recente perché "FFF/ABC" > "ABC" (ad es. "4095/2748" > "2748")

Se due valori _CHANGE_SEQUENCE_NUMBER sono identici, il record con il valore la data/ora di importazione del sistema BigQuery più recente ha la precedenza sulle precedentemente importati.

Configura una prenotazione BigQuery da utilizzare con CDC

Puoi utilizzare Prenotazioni BigQuery per allocare risorse di computing BigQuery dedicate per la riga CDC e le operazioni di modifica. Le prenotazioni ti consentono di impostare un limite per il costo eseguendo queste operazioni. Questo approccio è particolarmente utile per i flussi di lavoro con frequenti operazioni CDC su tabelle di grandi dimensioni, che altrimenti sarebbero costi on demand elevati a causa dell'elevato numero di byte elaborati durante ogni operazione.

Job CDC di BigQuery che applicano modifiche alle righe in attesa all'interno l'intervallo max_staleness sono considerati job in background e utilizzano Tipo di assegnazione BACKGROUND, anziché QUERY. Al contrario, le query al di fuori dell'intervallo max_staleness che richiedono una riga le modifiche da applicare durante l'esecuzione della query Tipo di assegnazione QUERY. Job in background CDC di BigQuery eseguiti senza un BACKGROUND l'assegnazione utilizza i prezzi on demand. Questa considerazione è importante durante la progettazione della gestione dei carichi di lavoro per la CDC di BigQuery.

Per configurare una prenotazione BigQuery da utilizzare con CDC, inizia con l'acquisto di un impegno in termini di capacità e configurare una prenotazione nella regione in cui in cui si trovano. Per indicazioni sulle dimensioni della prenotazione, consulta Dimensioni e monitoraggio di BACKGROUND prenotazioni. Dopo aver creato una prenotazione, assegna l'account BigQuery progetto alla prenotazione e imposta l'opzione job_type su BACKGROUND eseguendo i seguenti comandi Dichiarazione CREATE ASSIGNMENT:

CREATE ASSIGNMENT
  `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME.ASSIGNMENT_ID`
OPTIONS (
  assignee = 'projects/PROJECT_ID',
  job_type = 'BACKGROUND');

Sostituisci quanto segue:

  • ADMIN_PROJECT_ID: l'ID del progetto di amministrazione proprietario della prenotazione.
  • LOCATION: il valore località della prenotazione.
  • RESERVATION_NAME: il nome della prenotazione.
  • ASSIGNMENT_ID: l'ID del compito. L'ID deve Deve essere univoco per il progetto e la località, iniziare e terminare con una lettera minuscola o un numero e contenere solo lettere minuscole, numeri e trattini.
  • PROJECT_ID: l'ID del progetto contenente la Le tabelle BigQuery che vengono modificate da CDC di BigQuery. Questo progetto è assegnato alla prenotazione.

Dimensione e monitoraggio delle prenotazioni BACKGROUND

Le prenotazioni determinano la quantità di risorse di computing disponibili per l'esecuzione le operazioni di computing di BigQuery. Il dimensionamento insufficiente di una prenotazione può Aumentare il tempo di elaborazione delle operazioni di modifica delle righe CDC. Per scegliere una dimensione la prenotazione in modo accurato, monitora il consumo storico di slot per il progetto esegue le operazioni CDC eseguendo una query INFORMATION_SCHEMA.JOBS_TIMELINE vista:

SELECT
  period_start,
  SUM(period_slot_ms) / (1000 * 60) AS slots_used
FROM
  REGION.INFORMATION_SCHEMA.JOBS_TIMELINE_BY_PROJECT
WHERE
  DATE(job_creation_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
  AND CURRENT_DATE()
  AND job_id LIKE '%cdc_background%'
GROUP BY
  period_start
ORDER BY
  period_start DESC;

Sostituisci REGION con nome della regione in cui si trova il progetto. Ad esempio, region-us.

Considerazioni sull'eliminazione dei dati

  • Le operazioni CDC di BigQuery sfruttano BigQuery di risorse di computing. Se le operazioni CDC sono configurate per utilizzare fatturazione on demand, le operazioni CDC vengono vengono eseguite regolarmente utilizzando risorse di BigQuery interne. Se Le operazioni CDC sono configurate con una prenotazione BACKGROUND, operazioni CDC sono invece soggette alla disponibilità delle risorse della prenotazione configurata. Se non sono disponibili risorse sufficienti nella prenotazione configurata, l'elaborazione delle operazioni CDC, inclusa l'eliminazione, potrebbe richiedere più tempo di previsto.
  • Un'operazione CDC DELETE viene considerata applicata solo quando Il timestamp upsert_stream_apply_watermark ha superato il timestamp in cui l'API StorageWrite ha trasmesso in streaming l'operazione. Per ulteriori informazioni sul timestamp upsert_stream_apply_watermark, consulta Monitorare l'avanzamento dell'operazione di upsert della tabella.
  • Per applicare le operazioni CDC DELETE che non arrivano in ordine, BigQuery mantiene un periodo di conservazione di due giorni. Le operazioni della tabella DELETE sono archiviati per questo periodo prima Procedura di eliminazione dei dati di Google Cloud inizia. DELETE operazioni all'interno del periodo di conservazione dell'eliminazione utilizzano lo standard Prezzi di archiviazione di BigQuery.

Limitazioni

  • BigQuery CDC non esegue l'applicazione forzata delle chiavi, quindi è essenziale che le chiavi primarie siano univoche.
  • Le chiavi primarie non possono superare le 16 colonne.
  • Le tabelle abilitate per CDC non possono avere più di 2000 colonne di primo livello definite da lo schema della tabella.
  • Le tabelle abilitate per CDC non supportano quanto segue:
  • Le tabelle abilitate per CDC che eseguono job di unione del runtime perché Il valore di max_staleness è troppo basso non può supportare quanto segue:
  • Esportazione in BigQuery le operazioni sulle tabelle abilitate per CDC non esportano la riga trasmessa di recente modifiche che devono ancora essere applicate da un job in background. Per esportare utilizza un'istruzione EXPORT DATA.
  • Se la query attiva un'unione del runtime in una tabella partizionata, l'intero la tabella viene analizzata indipendentemente dal fatto che la query sia limitata o meno a un sottoinsieme del partizioni di Compute Engine.
  • Se utilizzi la versione Standard, Le prenotazioni BACKGROUND non sono disponibili, perciò è in corso l'applicazione della riga in attesa modifiche utilizza modello di prezzi on demand. Tuttavia, può eseguire query su tabelle abilitate per CDC indipendentemente dalla versione.
  • Non è possibile eseguire query sulle pseudocolonne _CHANGE_TYPE e _CHANGE_SEQUENCE_NUMBER durante la lettura di una tabella.

Prezzi CDC di BigQuery

La CDC di BigQuery utilizza l'API StorageWrite per i dati Importazione, archiviazione BigQuery per l'archiviazione dei dati Computing BigQuery per le operazioni di modifica delle righe, tutte incluse comporta dei costi. Per informazioni sui prezzi, vedi Prezzi di BigQuery.

Stima i costi CDC di BigQuery

Oltre a best practice generali per la stima dei costi di BigQuery, la stima dei costi di CDC di BigQuery potrebbe essere importante flussi di lavoro con grandi quantità di dati, Configurazione di max_staleness o che vengono modificate di frequente e i dati di Google Cloud.

Prezzi di importazione dati di BigQuery e i prezzi di archiviazione di BigQuery calcolati direttamente in base alla quantità di dati importati e archiviati, inclusi pseudocolonne. Tuttavia, i prezzi di calcolo di BigQuery può essere più difficile da stimare, poiché si riferisce al consumo di risorse di calcolo utilizzati per eseguire job CDC di BigQuery.

I job CDC di BigQuery sono suddivisi in tre categorie:

  • Job di applicazione in background: job eseguiti in background a intervalli regolari intervalli definiti dal valore max_staleness della tabella. Questi job applicare modifiche di righe trasmesse di recente alla tabella abilitata per CDC.
  • Query job: query GoogleSQL eseguite all'interno max_staleness e legge solo dalla tabella di riferimento CDC.
  • Job di unione runtime:job attivati da query GoogleSQL ad hoc eseguite al di fuori della finestra max_staleness. Questi job devono eseguire un'unione immediata della tabella di riferimento CDC e della riga riprodotta di recente le modifiche al runtime della query.

Tutti e tre i tipi di job CDC di BigQuery sfruttano clustering BigQuery, ma solo i job di query sfruttano Partizionamento di BigQuery. I job di applicazione in background e i job di unione del runtime non possono utilizzare il partizionamento perché quando si applicano modifiche alle righe trasmesse di recente, non vi è alcuna garanzia a quale partizione di tabella vengono applicati gli upsert trasmessi di recente. In altre parole, la tabella di riferimento completa viene letta durante il job di applicazione in background e il runtime di unione Comprendere la quantità di dati che vengono letti per eseguire la CDC è utile per stimare il costo totale.

Se la quantità di dati letti dalla base di riferimento della tabella è elevata, valuta la possibilità di utilizzare BigQuery modello di determinazione del prezzo della capacità, che non si basa sulla quantità di dati elaborati.

Best practice per i costi di CDC di BigQuery

Oltre a best practice generali sui costi di BigQuery, utilizza le seguenti tecniche per ottimizzare i costi di BigQuery Operazioni CDC:

Passaggi successivi