Aggiornare le tabelle in tempo reale con il rilevamento delle modifiche

BigQuery Change Data Capture (CDC) aggiorna le tue tabelle BigQuery elaborando e applicando le modifiche in streaming ai dati esistenti. Questa sincronizzazione viene eseguita tramite operazioni di inserimento e eliminazione delle righe che vengono trasmesse in streaming in tempo reale dall'API BigQuery Storage Write, che devi conoscere prima di procedere.

Prima di iniziare

Concedi i ruoli IAM (Identity and Access Management) che concedono agli utenti le autorizzazioni necessarie per eseguire ogni attività in questo documento e assicurati che il flusso di lavoro soddisfi tutti i prerequisiti.

Autorizzazioni obbligatorie

Per ottenere l'autorizzazione necessaria per utilizzare l'API Storage Write, chiedi all'amministratore di concederti il ruolo IAM Editor dati BigQuery (roles/bigquery.dataEditor). Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.

Questo ruolo predefinito contiene l'autorizzazione bigquery.tables.updateData necessaria per utilizzare l'API Storage Write.

Potresti anche ottenere questa autorizzazione con ruoli personalizzati o altri ruoli predefiniti.

Per saperne di più sui ruoli e sulle autorizzazioni IAM in BigQuery, consulta Introduzione a IAM.

Prerequisiti

Per utilizzare la copia dei dati di BigQuery, il flusso di lavoro deve soddisfare le seguenti condizioni:

  • Devi utilizzare l'API Storage Write nello stream predefinito.
  • Devi dichiarare le chiavi principali per la tabella di destinazione in BigQuery. Sono supportate le chiavi principali composite contenenti fino a 16 colonne.
  • Devono essere disponibili risorse di calcolo BigQuery sufficienti per eseguire le operazioni sulle righe CDC. Tieni presente che se le operazioni di modifica delle righe del CDC non riescono, potresti conservare involontariamente i dati che intendevi eliminare. Per ulteriori informazioni, consulta Considerazioni sui dati eliminati.

Specifica le modifiche ai record esistenti

In BigQuery CDC, la pseudocolonna _CHANGE_TYPE indica il tipo di modifica da elaborare per ogni riga. Per utilizzare la CDC, imposta _CHANGE_TYPE quando scorri le modifiche alle righe utilizzando l'API Storage Write. La pseudocolonna _CHANGE_TYPE accetta solo i valori UPSERT e DELETE. Una tabella è considerata abilitata al CDC mentre l'API Storage Write carica in streaming le modifiche alle righe nella tabella in questo modo.

Esempio con valori UPSERT e DELETE

Prendi in considerazione la seguente tabella in BigQuery:

ID Nome Stipendio
100 Charlie 2000
101 Tal 3000
102 Lee 5000

Le seguenti modifiche alle righe vengono trasmesse in streaming dall'API Storage Write:

ID Nome Stipendio _CHANGE_TYPE
100 ELIMINA
101 Tal 8000 UPSERT
105 Izumi 6000 UPSERT

La tabella aggiornata è la seguente:

ID Nome Stipendio
101 Tal 8000
102 Lee 5000
105 Izumi 6000

Gestire l'obsolescenza delle tabelle

Per impostazione predefinita, ogni volta che esegui una query, BigQuery restituisce i risultati più aggiornati. Per fornire i risultati più recenti quando esegui una query su una tabella abilitata per il CDC, BigQuery deve applicare ogni modifica delle righe sottoposte a streaming fino all'ora di inizio della query, in modo da eseguire la query sulla versione più aggiornata della tabella. L'applicazione di queste modifiche alle righe al momento dell'esecuzione della query aumenta la latenza e il costo della query. Tuttavia, se non hai bisogno di risultati delle query completamente aggiornati, puoi ridurre i costi e la latenza delle query impostando l'opzione max_staleness nella tabella. Quando questa opzione è impostata, BigQuery applica le modifiche alle righe almeno una volta nell'intervallo definito dal valore max_staleness, consentendoti di eseguire query senza attendere l'applicazione degli aggiornamenti, a costo di una certa inattività dei dati.

Questo comportamento è particolarmente utile per le dashboard e i report per i quali l'aggiornamento dei dati non è essenziale. È utile anche per la gestione dei costi perché ti offre un maggiore controllo sulla frequenza con cui BigQuery applica le modifiche alle righe.

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 all'ora in cui si è verificato l'ultimo job di applicazione, rappresentato dal timestamp upsert_stream_apply_watermark della tabella.

Considera l'esempio seguente, in cui per una tabella l'opzione max_staleness è impostata su 10 minuti e l'ultimo job di applicazione si è verificato in T20:

Il tempo di esecuzione della query avviene nell'intervallo di tempo massimo per l'obsolescenza dei dati.

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

Quando imposti l'opzione max_staleness nella tabella, BigQuery applica le modifiche in attesa delle righe almeno una volta nell'intervallo max_staleness. In alcuni casi, tuttavia, BigQuery potrebbe non completare il processo di applicazione di queste modifiche alle righe in attesa entro l'intervallo.

Ad esempio, se esegui una query sulla tabella in T35 e il processo di applicazione delle modifiche in sospeso delle righe non è stato completato, la versione corrente della tabella è obsoleta di 15 minuti, ovvero più dell'intervallo di 10 minuti di max_staleness. In questo caso, al momento dell'esecuzione della query, BigQuery applica tutte le modifiche alle righe tra T20 e T35 per la query corrente, il che significa che i dati sottoposti a query sono completamente aggiornati, a costo di una maggiore latenza della query. Si tratta di un job di unione in fase di esecuzione.

Il tempo di esecuzione della query avviene al di fuori dell'intervallo di tempo massimo per l'obsolescenza dei dati.

In genere, il valore max_staleness di una tabella deve essere il più alto dei seguenti due valori:

  • L'obsolescenza massima dei dati tollerabile per il flusso di lavoro.
  • Il doppio del tempo massimo necessario per applicare le modifiche upsert alla tabella, oltre a un buffer aggiuntivo.

Per calcolare il tempo necessario per applicare le modifiche upsert a una tabella esistente, utilizza la seguente query SQL per determinare la durata mediana del 95% dei job di applicazione in background, più un buffer di sette minuti per consentire la conversione dello spazio di archiviazione ottimizzato per la scrittura di BigQuery (buffer di streaming).

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-REGION`.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 quanto segue:

  • REGION: il nome della regione in cui si trova il progetto. Ad esempio, us.
  • PROJECT_ID: l'ID del progetto contenente le tabelle BigQuery che vengono modificate da BigQuery CDC.

La durata dei job di applicazione in background è influenzata da diversi fattori, tra cui il numero e la complessità delle operazioni CDC emesse nell'intervallo di inattività, le dimensioni della tabella e la disponibilità delle risorse BigQuery. Per ulteriori informazioni sulla disponibilità delle risorse, vedi Dimensionare e monitorare le prenotazioni BACKGROUND.

Crea una tabella con l'opzione max_staleness

Per creare una tabella con l'opzione max_staleness, utilizza l'istruzione 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);

Modificare l'opzione max_staleness per una tabella esistente

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

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

Determinare il valore max_staleness corrente di una tabella

Per determinare il valore max_staleness corrente di una tabella, esegui una query sulla vista INFORMATION_SCHEMA.TABLE_OPTIONS. L'esempio seguente controlla il valore corrente 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 risiede la tabella abilitata per la CDC.
  • TABLE_NAME: il nome della tabella abilitata per la 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 |
+---------------------+--------------+

Monitorare l'avanzamento dell'operazione di upsert della tabella

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

L'esempio seguente controlla il valore upsert_stream_apply_watermark della 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 risiede la tabella abilitata per la CDC.
  • TABLE_NAME: il nome della tabella abilitata per la CDC.

Il risultato è simile al seguente:

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

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

Gestire l'ordinamento personalizzato

Quando esegui l'upsert in streaming in BigQuery, il comportamento predefinito per l'ordinamento dei record con chiavi principali identiche è determinato dall'ora di 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 importato in precedenza con un timestamp precedente. Per alcuni casi d'uso, ad esempio quelli in cui possono verificarsi upsert molto frequenti nella stessa chiave primaria in un intervallo di tempo molto breve o in cui l'ordine di upsert non è garantito, questa operazione potrebbe non essere sufficiente. Per questi scenari, 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 utilizzata per indicare l'ordine in cui BigQuery deve applicare i record, in base al valore più grande _CHANGE_SEQUENCE_NUMBER tra due record corrispondenti con la stessa chiave primaria. La pseudocolonna _CHANGE_SEQUENCE_NUMBER è facoltativa e accetta solo valori in un formato fisso STRING.

Formato _CHANGE_SEQUENCE_NUMBER

La pseudocolonna _CHANGE_SEQUENCE_NUMBER accetta solo valori STRING, scritti in un formato fisso. Questo formato fisso utilizza valori STRING scritti in esadecimale, separati in sezioni da una barra /. Ogni sezione può essere expressed in at most 16 hexadecimal characters, and up to four sections are permitted per _CHANGE_SEQUENCE_NUMBER. L'intervallo consentito di _CHANGE_SEQUENCE_NUMBER supporta valori compresi tra 0/0/0/0 e FFFFFFFFFFFFFFFF/FFFFFFFFFFFFFFFF/FFFFFFFFFFFFFFFF/FFFFFFFFFFFFFFFF. I valori _CHANGE_SEQUENCE_NUMBER supportano i caratteri sia maiuscoli che minuscoli.

Puoi esprimere le chiavi di ordinamento di base utilizzando una singola sezione. Ad esempio, per ordinare le chiavi in base al timestamp di elaborazione di un record da un server di applicazioni, puoi utilizzare una sezione: '2024-04-30 11:19:44 UTC', espressa in esadecimale mediante la conversione del timestamp in millisecondi dall'Epoch, in questo caso '18F2EBB6480'. La logica per convertire i dati in esadecimale è responsabilità del client che esegue la scrittura in BigQuery utilizzando l'API Storage Write.

Il supporto di più sezioni ti consente di combinare diversi valori di logica di elaborazione in un'unica chiave per casi d'uso più complessi. Ad esempio, per ordinare le chiavi in base al timestamp di elaborazione di un record da un server di applicazioni, a un numero di sequenza del log e allo stato del record, puoi utilizzare tre sezioni:'2024-04-30 11:19:44 UTC' / '123' / 'complete', ciascuna espressa in esadecimale. L'ordine delle sezioni è un aspetto importante per il ranking della logica di elaborazione. BigQuery confronta i valori _CHANGE_SEQUENCE_NUMBER confrontando la prima sezione, quindi 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. Considera i seguenti esempi di confronto _CHANGE_SEQUENCE_NUMBER e i relativi risultati di precedenza:

  • Esempio 1:

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

    Risultato: il record 2 è considerato il record più recente 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 l'ultimo 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 l'ultimo orario di importazione del sistema BigQuery ha la precedenza sui record importati in precedenza.

Configurare una prenotazione BigQuery per l'utilizzo con CDC

Puoi utilizzare le prenotazioni BigQuery per allocare risorse di calcolo BigQuery dedicate per le operazioni di modifica delle righe CDC. Le prenotazioni ti consentono di impostare un limite per il costo dell'esecuzione di queste operazioni. Questo approccio è particolarmente utile per i flussi di lavoro con operazioni CDC frequenti su tabelle di grandi dimensioni, che altrimenti avrebbero costi on demand elevati a causa del numero elevato di byte elaborati durante l'esecuzione di ogni operazione.

I job CDC BigQuery che applicano modifiche alle righe in attesa nell'intervallo max_staleness sono considerati job in background e utilizzano il tipo di assegnazione BACKGROUND anziché il tipo di assegnazione QUERY. Al contrario, le query al di fuori dell'intervallo max_staleness che richiedono modifiche alle righe da applicare al momento dell'esecuzione della query utilizzano il tipo di assegnazione QUERY. I job in background di BigQuery CDC eseguiti senza un BACKGROUND assegnamento utilizzano i prezzi on demand. Questa considerazione è importante quando si progetta la strategia di gestione del carico di lavoro per la CDC BigQuery.

Per configurare una prenotazione BigQuery da utilizzare con CDC, inizia con l'acquisto di un impegno di capacità e configura una prenotazione nella regione in cui si trovano le tue tabelle BigQuery. Per indicazioni sulle dimensioni della prenotazione, consulta Definire le dimensioni e monitorare le prenotazioni BACKGROUND. Dopo aver creato una prenotazione, assegna il progetto BigQuery alla prenotazione e imposta l'opzione job_type su BACKGROUND eseguendo il seguente statement CREATE ASSIGNMENT:

CREATE ASSIGNMENT
  `ADMIN_PROJECT_ID.region-REGION.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.
  • REGION: il nome della regione in cui si trova il progetto. Ad esempio, us.
  • RESERVATION_NAME: il nome della prenotazione.
  • ASSIGNMENT_ID: l'ID del compito. L'ID 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 le tabelle BigQuery che vengono modificate da BigQuery CDC. Questo progetto è assegnato alla prenotazione.

Gestire le dimensioni e monitorare le prenotazioni di BACKGROUND

Le prenotazioni determinano la quantità di risorse di calcolo disponibili per eseguire operazioni di calcolo BigQuery. Una prenotazione di dimensioni ridotte può aumentare il tempo di elaborazione delle operazioni di modifica delle righe CDC. Per determinare con precisione le dimensioni di una prenotazione, monitora il consumo storico degli slot per il progetto che esegue le operazioni di CDC eseguendo una query sulla visualizzazione INFORMATION_SCHEMA.JOBS_TIMELINE:

SELECT
  period_start,
  SUM(period_slot_ms) / (1000 * 60) AS slots_used
FROM
  region-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 il nome della regione in cui si trova il tuo progetto. Ad esempio, us.

Considerazioni sui dati eliminati

  • Le operazioni CDC di BigQuery utilizzano le risorse di calcolo di BigQuery. Se le operazioni CDC sono configurate per utilizzare la fatturazione on demand, vengono eseguite regolarmente utilizzando le risorse BigQuery interne. Se le operazioni CDC sono configurate con una prenotazione BACKGROUND, sono invece soggette alla disponibilità delle risorse della prenotazione configurata. Se non sono disponibili risorse sufficienti all'interno della prenotazione configurata, l'elaborazione delle operazioni CDC, inclusa l'eliminazione, potrebbe richiedere più tempo del previsto.
  • Un'operazione DELETE CDC è considerata applicata solo quando il timestamp upsert_stream_apply_watermark ha superato il timestamp in cui l'API Storage Write ha eseguito lo streaming dell'operazione. Per ulteriori informazioni sul timestamp upsert_stream_apply_watermark, consulta Monitorare l'avanzamento dell'operazione di upsert della tabella.
  • Per applicare le operazioni DELETE CDC che arrivano fuori sequenza, BigQuery mantiene una finestra di conservazione dell'eliminazione di due giorni. Le operazioni della tabella DELETE vengono memorizzate per questo periodo prima dell'inizio della procedura standard di eliminazione dei dati di Google Cloud. Le operazioni DELETE all'interno della finestra di conservazione dell'eliminazione utilizzano i prezzi di archiviazione di BigQuery standard.

Limitazioni

  • La copia dei dati di BigQuery non esegue l'applicazione delle chiavi, pertanto è essenziale che le chiavi primarie siano univoche.
  • Le chiavi primarie non possono superare le 16 colonne.
  • Le tabelle con la funzionalità CDC abilitata non possono avere più di 2000 colonne di primo livello definite dall'schema della tabella.
  • Le tabelle con la CDC abilitata non supportano quanto segue:
  • Le tabelle abilitate per la CDC che eseguono job di unione in fase di runtime perché il valore max_staleness della tabella è troppo basso non supportano quanto segue:
  • Le operazioni di esportazione di BigQuery sulle tabelle con il CDC abilitato non esportano le modifiche delle righe di recente sottoposte a streaming che devono ancora essere applicate da un job in background. Per esportare la tabella completa, utilizza un'istruzione EXPORT DATA.
  • Se la query attiva un'unione dinamica in una tabella partizionata, l'intera tabella viene analizzata indipendentemente dal fatto che la query sia limitata o meno a un sottoinsieme delle partizioni.
  • Se utilizzi la versione Standard, le prenotazioniBACKGROUND non sono disponibili, pertanto l'applicazione delle modifiche alle righe in attesa utilizza il modello di prezzo on demand. Tuttavia, puoi eseguire query sulle tabelle con la funzionalità CDC abilitata indipendentemente dalla tua versione.
  • Le pseudocolonne _CHANGE_TYPE e _CHANGE_SEQUENCE_NUMBER non sono colonne su cui è possibile eseguire query quando viene eseguita una lettura della tabella.
  • La combinazione di righe con valori UPSERT o DELETE per _CHANGE_TYPE con righe con valori INSERT o non specificati per _CHANGE_TYPE nella stessa connessione non è supportata e genera il seguente errore di convalida:The given value is not a valid CHANGE_TYPE.

Prezzi di BigQuery CDC

BigQuery CDC utilizza l'API Storage Write per l'importazione dei dati, lo spazio di archiviazione BigQuery per l'archiviazione dei dati e il calcolo BigQuery per le operazioni di modifica delle righe, tutte le quali comportano costi. Per informazioni sui prezzi, consulta Prezzi di BigQuery.

Stimare i costi di BigQuery CDC

Oltre alle best practice generali per la stima dei costi di BigQuery, la stima dei costi del CDC di BigQuery potrebbe essere importante per i flussi di lavoro con grandi quantità di dati, una configurazione max_staleness bassa o dati in continua evoluzione.

I prezzi di importazione dati di BigQuery e i prezzi di archiviazione di BigQuery vengono calcolati direttamente in base alla quantità di dati che importi e archivi, incluse le pseudocolonne. Tuttavia, i prezzi di calcolo di BigQuery possono essere più difficili da stimare, in quanto si riferiscono al consumo di risorse di calcolo utilizzate per eseguire i job CDC di BigQuery.

I job CDC BigQuery sono suddivisi in tre categorie:

  • Job di applicazione in background:job eseguiti in background a intervalli regolari definiti dal valore max_staleness della tabella. Questi job applicano le modifiche alle righe sottoposte a streaming di recente alla tabella abilitata per la CDC.
  • Job di query: query GoogleSQL eseguite all'interno della finestramax_staleness e che leggono solo dalla tabella di riferimento del CDC.
  • Job di unione di runtime:job attivati da query GoogleSQL ad hoc eseguite al di fuori della finestra max_staleness. Questi job devono eseguire un'unione dinamica della tabella di riferimento della CDC e delle modifiche delle righe in streaming di recente durante l'esecuzione della query.

Tutti e tre i tipi di job CDC BigQuery sfruttano il clustering BigQuery, ma solo i job di query sfruttano il partizionamento BigQuery. I job di applicazione in background e i job di unione in fase di esecuzione non possono utilizzare la partizione perché, quando vengono applicate le modifiche alle righe sottoposte a streaming di recente, non è possibile garantire a quale partizione della tabella vengono applicati gli upsert sottoposti a streaming di recente. In altre parole, la tabella di riferimento completa viene letta durante i job di applicazione in background e i job di unione in fase di runtime. Comprendere la quantità di dati che viene letta per eseguire le operazioni di CDC è utile per stimare il costo totale.

Se la quantità di dati letti dal valore di riferimento della tabella è elevata, valuta la possibilità di utilizzare il modello di determinazione dei prezzi in base alla capacità di BigQuery, che non si basa sulla quantità di dati elaborati.

Best practice per i costi di BigQuery CDC

Oltre alle best practice generali per i costi di BigQuery, utilizza le seguenti tecniche per ottimizzare i costi delle operazioni di CDC di BigQuery:

Passaggi successivi