Questo documento descrive come trasmettere dati in streaming in BigQuery utilizzando il metodo legacy tabledata.insertAll.
Per i nuovi progetti, consigliamo di utilizzare l'API BigQuery Storage Write anziché il metodo tabledata.insertAll. L'API Storage Write offre prezzi inferiori e funzionalità più solide, tra cui la semantica di consegna "exactly-once". Se
stai eseguendo la migrazione di un progetto esistente dal metodo tabledata.insertAll
all'API Storage Write, ti consigliamo di selezionare lo
stream predefinito. Il metodo
tabledata.insertAll è ancora completamente supportato.
Prima di iniziare
Assicurati di disporre dell'accesso in scrittura al set di dati che contiene la tabella di destinazione. La tabella deve esistere prima di iniziare a scrivervi i dati, a meno che tu non stia utilizzando tabelle modello. Per saperne di più sulle tabelle modello, vedi Creare tabelle automaticamente utilizzando le tabelle modello.
Consulta le norme relative alle quote per i dati di streaming.
-
Verify that billing is enabled for your Google Cloud project.
Concedi ruoli Identity and Access Management (IAM) che forniscono agli utenti le autorizzazioni necessarie per eseguire ogni attività descritta in questo documento.
Lo streaming non è disponibile tramite il livello gratuito. Se tenti di utilizzare lo streaming senza attivare la fatturazione, ricevi il seguente errore: BigQuery: Streaming insert is not allowed in the free tier.
Autorizzazioni obbligatorie
Per trasmettere dati in streaming a BigQuery, devi disporre delle seguenti autorizzazioni IAM:
bigquery.tables.updateData(consente di inserire dati nella tabella)bigquery.tables.get(consente di ottenere i metadati della tabella)bigquery.datasets.get(consente di ottenere i metadati del set di dati)bigquery.tables.create(obbligatorio se utilizzi una tabella modello per creare automaticamente la tabella)
Ciascuno dei seguenti ruoli IAM predefiniti include le autorizzazioni necessarie per trasmettere dati in streaming in BigQuery:
roles/bigquery.dataEditorroles/bigquery.dataOwnerroles/bigquery.admin
Per saperne di più sui ruoli e sulle autorizzazioni IAM in BigQuery, consulta Ruoli e autorizzazioni predefiniti.
Trasmetti flussi di dati in BigQuery
C#
Prima di provare questo esempio, segui le istruzioni di configurazione di C# nella guida rapida di BigQuery per l'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API BigQuery C#.
Per eseguire l'autenticazione in BigQuery, configura le Credenziali predefinite dell'applicazione. Per saperne di più, vedi Configurare l'autenticazione per le librerie client.
Go
Prima di provare questo esempio, segui le istruzioni di configurazione di Go nella guida rapida di BigQuery per l'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API BigQuery Go.
Per eseguire l'autenticazione in BigQuery, configura le Credenziali predefinite dell'applicazione. Per saperne di più, vedi Configurare l'autenticazione per le librerie client.
Java
Prima di provare questo esempio, segui le istruzioni di configurazione di Java nella guida rapida di BigQuery per l'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API BigQuery Java.
Per eseguire l'autenticazione in BigQuery, configura le Credenziali predefinite dell'applicazione. Per saperne di più, vedi Configurare l'autenticazione per le librerie client.
Node.js
Prima di provare questo esempio, segui le istruzioni di configurazione di Node.js nella guida rapida di BigQuery per l'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API BigQuery Node.js.
Per eseguire l'autenticazione in BigQuery, configura le Credenziali predefinite dell'applicazione. Per saperne di più, vedi Configurare l'autenticazione per le librerie client.
PHP
Prima di provare questo esempio, segui le istruzioni di configurazione di PHP nella guida rapida di BigQuery per l'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API BigQuery PHP.
Per eseguire l'autenticazione in BigQuery, configura le Credenziali predefinite dell'applicazione. Per saperne di più, vedi Configurare l'autenticazione per le librerie client.
Python
Prima di provare questo esempio, segui le istruzioni di configurazione di Python nella guida rapida di BigQuery per l'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API BigQuery Python.
Per eseguire l'autenticazione in BigQuery, configura le Credenziali predefinite dell'applicazione. Per saperne di più, vedi Configurare l'autenticazione per le librerie client.
Ruby
Prima di provare questo esempio, segui le istruzioni di configurazione di Ruby nella guida rapida di BigQuery per l'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API BigQuery Ruby.
Per eseguire l'autenticazione in BigQuery, configura le Credenziali predefinite dell'applicazione. Per saperne di più, vedi Configurare l'autenticazione per le librerie client.
Non è necessario compilare il campo insertID quando inserisci le righe.
L'esempio seguente mostra come evitare di inviare un insertID per ogni riga
durante lo streaming.
Java
Prima di provare questo esempio, segui le istruzioni di configurazione di Java nella guida rapida di BigQuery per l'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API BigQuery Java.
Per eseguire l'autenticazione in BigQuery, configura le Credenziali predefinite dell'applicazione. Per saperne di più, vedi Configurare l'autenticazione per le librerie client.
Python
Prima di provare questo esempio, segui le istruzioni di configurazione di Python nella guida rapida di BigQuery per l'utilizzo delle librerie client. Per saperne di più, consulta la documentazione di riferimento dell'API BigQuery Python.
Per eseguire l'autenticazione in BigQuery, configura le Credenziali predefinite dell'applicazione. Per saperne di più, vedi Configurare l'autenticazione per le librerie client.
Inviare dati di data e ora
Per i campi data e ora, formatta i dati nel metodo tabledata.insertAll come segue:
| Tipo | Formato |
|---|---|
DATE |
Una stringa nel formato "YYYY-MM-DD" |
DATETIME |
Una stringa nel formato "YYYY-MM-DD [HH:MM:SS]" |
TIME |
Una stringa nel formato "HH:MM:SS" |
TIMESTAMP |
Il numero di secondi dal 1° gennaio 1970 (l'epoca Unix) o una stringa
nel formato "YYYY-MM-DD HH:MM[:SS]" |
Inviare i dati del raggio
Per i campi di tipo RANGE<T>, formatta i dati nel metodo tabledata.insertAll
come oggetto JSON con due campi, start e end.
I valori mancanti o NULL per i campi start e end rappresentano limiti illimitati.
Questi campi devono avere lo stesso formato JSON supportato di tipo T, dove
T può essere uno tra DATE, DATETIME e TIMESTAMP.
Nell'esempio seguente, il campo f_range_date rappresenta una colonna RANGE<DATE>
in una tabella. In questa colonna viene inserita una riga utilizzando l'API tabledata.insertAll.
{
"f_range_date": {
"start": "1970-01-02",
"end": null
}
}
Disponibilità dei dati di streaming
I dati sono disponibili per l'analisi in tempo reale utilizzando le query GoogleSQL immediatamente dopo che BigQuery ha riconosciuto correttamente una richiesta tabledata.insertAll. Quando esegui query sui dati nel buffer di streaming, non ti vengono addebitati i byte elaborati dal buffer di streaming se utilizzi i prezzi di calcolo on demand. Se utilizzi i prezzi basati sulla capacità, le tue
prenotazioni
consumano slot per l'elaborazione dei dati nel buffer di streaming.
Le righe trasmesse in streaming di recente a una tabella partizionata in base al tempo di importazione hanno temporaneamente un
valore NULL per la pseudocolonna _PARTITIONTIME. Per queste righe, BigQuery assegna in background il valore finale non NULL
della colonna PARTITIONTIME, in genere entro pochi
minuti. In rari casi, l'operazione può richiedere fino a 90 minuti.
Alcune righe trasmesse in streaming di recente potrebbero non essere disponibili per la copia della tabella in genere per
alcuni minuti. In rari casi, l'operazione può richiedere fino a 90 minuti. Per verificare se i dati
sono disponibili per la copia della tabella, controlla la risposta tables.get per una sezione denominata
streamingBuffer.
Se la sezione streamingBuffer non è presente, i tuoi dati sono disponibili per la copia.
Puoi anche utilizzare il campo streamingBuffer.oldestEntryTime per identificare l'età dei record nel buffer di streaming.
Deduplicazione best effort
Quando fornisci insertId per una riga inserita, BigQuery utilizza questo ID per supportare la deduplicazione con il massimo impegno per un massimo di un minuto. ovvero, se
trasmetti in streaming la stessa riga con lo stesso insertId più di una volta entro
questo periodo di tempo nella stessa tabella, BigQuery potrebbe rimuovere i duplicati
delle più occorrenze di quella riga, conservandone solo una.
Il sistema prevede che le righe fornite con insertId identici siano
identiche. Se due righe hanno insertId identici, non è deterministico
quale riga BigQuery conserva.
La deduplicazione è generalmente pensata per gli scenari di ripetizione in un sistema distribuito in cui non è possibile determinare lo stato di un inserimento di flussi di dati in determinate condizioni di errore, ad esempio errori di rete tra il sistema e BigQuery o errori interni a BigQuery.
Se riprovi un inserimento, utilizza lo stesso insertId per lo stesso insieme di righe in modo che
BigQuery possa tentare di deduplicare i dati. Per ulteriori
informazioni, consulta la sezione Risoluzione dei problemi relativi agli inserimenti di flussi di dati.
La deduplicazione offerta da BigQuery è il risultato di un impegno massimo e non deve essere considerata un meccanismo per garantire l'assenza di duplicati nei tuoi dati. Inoltre, BigQuery potrebbe ridurre la qualità della deduplicazione con il massimo impegno in qualsiasi momento per garantire una maggiore affidabilità e disponibilità dei dati.
Se hai requisiti di deduplicazione rigorosi per i tuoi dati, Google Cloud Datastore è un servizio alternativo che supporta le transazioni.
Disattivazione della deduplicazione basata sul "best effort"
Puoi disattivare la deduplicazione best effort non compilando il campo insertId
per ogni riga inserita. Questo è il modo consigliato per inserire i dati.
Apache Beam e Dataflow
Per disattivare la deduplicazione con il massimo impegno quando utilizzi il
connettore BigQuery I/O
di Apache Beam per Java, utilizza il
metodo ignoreInsertIds().
Rimozione manuale dei duplicati
Per assicurarti che non esistano righe duplicate al termine dello streaming, utilizza la seguente procedura manuale:
- Aggiungi
insertIdcome colonna nello schema della tabella e includi il valoreinsertIdnei dati per ogni riga. - Dopo l'interruzione dello streaming, esegui la seguente query per verificare la presenza di
duplicati:
Se il risultato è maggiore di 1, esistono duplicati.#standardSQL SELECT MAX(count) FROM( SELECT ID_COLUMN, count(*) as count FROM `TABLE_NAME` GROUP BY ID_COLUMN)
- Per rimuovere i duplicati, esegui la seguente query. Specifica
una tabella di destinazione, consenti risultati di grandi dimensioni e disattiva l'appiattimento dei risultati.
#standardSQL SELECT * EXCEPT(row_number) FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY ID_COLUMN) row_number FROM `TABLE_NAME`) WHERE row_number = 1
Note sulla query di rimozione dei duplicati:
- La strategia più sicura per la query di rimozione dei duplicati è quella di scegliere come target una nuova tabella.
In alternativa, puoi scegliere come target la tabella di origine con la disposizione di scrittura
WRITE_TRUNCATE. - La query di rimozione dei duplicati aggiunge una colonna
row_numbercon il valore1alla fine dello schema della tabella. La query utilizza un'istruzioneSELECT * EXCEPTdi GoogleSQL per escludere la colonnarow_numberdalla tabella di destinazione. Il prefisso#standardSQLattiva GoogleSQL per questa query. In alternativa, puoi selezionare in base a nomi di colonne specifici per omettere questa colonna. - Per eseguire query sui dati live con i duplicati rimossi, puoi anche creare una vista sulla tabella utilizzando la query di rimozione dei duplicati. Tieni presente che i costi delle query sulla vista vengono calcolati in base alle colonne selezionate nella vista, il che può comportare dimensioni di byte scansionati elevate.
Esegui lo streaming nelle tabelle partizionate in base al tempo
Quando trasmetti dati in streaming a una tabella partizionata in base al tempo, ogni partizione ha un buffer di streaming. Il buffer di streaming viene mantenuto quando esegui un job di caricamento, query o copia che sovrascrive una partizione impostando la proprietà writeDisposition su WRITE_TRUNCATE. Se vuoi rimuovere il buffer di streaming, verifica che sia vuoto chiamando
tables.get sulla partizione.
Partizionamento per data di importazione
Quando esegui lo streaming in una tabella partizionata per data di importazione, BigQuery deduce la partizione di destinazione dall'ora UTC corrente.
I dati appena arrivati vengono inseriti temporaneamente nella partizione __UNPARTITIONED__
mentre si trovano nel buffer dei flussi di dati. Quando ci sono dati non partizionati sufficienti,
BigQuery partiziona i dati nella partizione corretta. Tuttavia,
non esiste un SLA per il tempo necessario per spostare i dati dalla
partizione __UNPARTITIONED__. Una query
può escludere i dati nel buffer di streaming da una query filtrando i
valori NULL dalla partizione __UNPARTITIONED__ utilizzando una delle
pseudocolonne (_PARTITIONTIME
o _PARTITIONDATE
a seconda del tipo di dati preferito).
Se trasmetti dati in streaming in una tabella partizionata giornalmente, puoi ignorare
l'inferenza della data fornendo un decoratore di partizione come parte della richiesta insertAll. Includi il decoratore nel parametro tableId. Ad esempio, puoi
trasmettere in streaming alla partizione corrispondente a 2021-03-01 per la tabella table1 utilizzando il
decoratore di partizione:
table1$20210301
Quando esegui lo streaming utilizzando un decoratore di partizioni, puoi eseguire lo streaming nelle partizioni entro gli ultimi 31 giorni nel passato e 16 giorni nel futuro rispetto alla data corrente, in base all'ora UTC attuale. Per scrivere nelle partizioni per le date al di fuori di questi limiti consentiti, utilizza un job di caricamento o di query, come descritto in Aggiunta e sovrascrittura dei dati delle tabella partizionata partizionate.
Lo streaming che utilizza un decoratore di partizione è supportato solo per le tabelle partizionate giornalmente. Non è supportato per le tabelle partizionate orarie, mensili o annuali.
Per i test, puoi utilizzare lo strumento a riga di comando bq
bq insert.
Ad esempio, il seguente comando trasmette in streaming una singola riga a una partizione per la
data 1° gennaio 2017 ($20170101) in una tabella partizionata denominata
mydataset.mytable:
echo '{"a":1, "b":2}' | bq insert 'mydataset.mytable$20170101'
Partizionamento per colonne di unità di tempo
Puoi trasmettere dati in streaming in una tabella partizionata in base a una colonna DATE, DATETIME o
TIMESTAMP compresa tra 10 anni nel passato e 1 anno nel futuro.
I dati al di fuori di questo intervallo vengono rifiutati.
Quando i dati vengono trasmessi in streaming, vengono inizialmente inseriti nella partizione __UNPARTITIONED__. Quando ci sono dati non partizionati sufficienti, BigQuery
ripartiziona automaticamente i dati, inserendoli nella partizione appropriata.
Tuttavia, non esiste un SLA per il tempo necessario per spostare i dati dalla partizione
__UNPARTITIONED__.
- Nota: le partizioni giornaliere vengono elaborate in modo diverso rispetto a quelle orarie, mensili e annuali. Solo i dati al di fuori dell'intervallo di date (dagli ultimi 7 giorni ai 3 giorni futuri) vengono estratti nella partizione UNPARTITIONED, in attesa di essere ripartizionati. D'altra parte, per la tabella partizionata oraria, i dati vengono sempre estratti nella partizione UNPARTITIONED e ripartizionati in un secondo momento.
Creare tabelle automaticamente utilizzando le tabelle modello
Le tabelle modello forniscono un meccanismo per dividere una tabella logica in molte tabelle più piccole per creare set di dati più piccoli (ad esempio, per ID utente). Le tabelle dei modelli presentano una serie di limitazioni descritte di seguito. Al contrario, le tabelle partizionate e le tabelle raggruppate in cluster sono i modi consigliati per ottenere questo comportamento.
Per utilizzare una tabella modello tramite l'API BigQuery, aggiungi un parametro templateSuffix
alla richiesta insertAll. Per lo strumento a riga di comando bq, aggiungi il flag template_suffix
al comando insert. Se BigQuery rileva un parametro templateSuffix o il flag template_suffix, considera la tabella di destinazione come un modello di base. Crea una nuova tabella che condivide lo stesso schema della tabella di destinazione e ha un nome che include il suffisso specificato:
<targeted_table_name> + <templateSuffix>
Utilizzando una tabella modello, eviti il sovraccarico di creare ogni tabella singolarmente e specificare lo schema per ciascuna. Devi solo creare un singolo modello e fornire suffissi diversi in modo che BigQuery possa creare le nuove tabelle per te. BigQuery inserisce le tabelle nello stesso progetto e set di dati.
Le tabelle create utilizzando le tabelle modello sono in genere disponibili in pochi secondi. In rari casi, potrebbe essere necessario più tempo prima che diventino disponibili.
Modificare lo schema della tabella del modello
Se modifichi uno schema di tabella modello, tutte le tabelle generate successivamente utilizzano lo schema aggiornato. Le tabelle generate in precedenza non sono interessate, a meno che la tabella esistente non abbia ancora un buffer di streaming.
Per le tabelle esistenti che hanno ancora un buffer di streaming, se modifichi lo schema della tabella modello in modo compatibile con le versioni precedenti, viene aggiornato anche lo schema delle tabelle generate in streaming attivo. Tuttavia, se modifichi lo schema della tabella del modello in modo non compatibile con le versioni precedenti, i dati memorizzati nel buffer che utilizzano il vecchio schema vengono persi. Inoltre, non puoi trasmettere in streaming nuovi dati alle tabelle generate esistenti che utilizzano lo schema precedente, ora incompatibile.
Dopo aver modificato lo schema di una tabella modello, attendi che le modifiche siano state propagate prima di provare a inserire nuovi dati o a eseguire query sulle tabelle generate. Le richieste di inserimento di nuovi campi dovrebbero essere completate in pochi minuti. I tentativi di eseguire query sui nuovi campi potrebbero richiedere un'attesa più lunga, fino a 90 minuti.
Se vuoi modificare lo schema di una tabella generata, non farlo
finché lo streaming tramite la tabella modello non è terminato e la sezione delle statistiche di streaming della tabella generata non è presente nella risposta tables.get(),
il che indica che non sono presenti dati memorizzati nella tabella.
Le tabelle partizionate e le tabelle in cluster non sono soggette alle limitazioni precedenti e sono il meccanismo consigliato.
Dettagli della tabella del modello
- Valore del suffisso del modello
- Il valore di
templateSuffix(o--template_suffix) deve contenere solo lettere (a-z, A-Z), numeri (0-9) o trattini bassi (_). La lunghezza massima combinata del nome della tabella e del suffisso della tabella è di 1024 caratteri. - Quota
Le tabelle modello sono soggette a limitazioni della quota di streaming. Il tuo progetto può creare fino a 10 tabelle al secondo con tabelle modello, in modo simile all'API
tables.insert. Questa quota si applica solo alle tabelle in fase di creazione, non a quelle in fase di modifica.Se la tua applicazione deve creare più di 10 tabelle al secondo, ti consigliamo di utilizzare tabelle in cluster. Ad esempio, puoi inserire l'ID della tabella ad alta cardinalità nella colonna chiave di una singola tabella di clustering.
- Durata
La tabella generata eredita il tempo di scadenza dal set di dati. Come per i normali dati di streaming, le tabelle generate non possono essere copiate immediatamente.
- Deduplicazione
La deduplicazione avviene solo tra riferimenti uniformi a una tabella di destinazione. Ad esempio, se esegui lo streaming simultaneo in una tabella generata utilizzando sia le tabelle modello sia un normale comando
insertAll, non viene eseguita alcuna deduplicazione tra le righe inserite dalle tabelle modello e un normale comandoinsertAll.- Visualizzazioni
La tabella modello e le tabelle generate non devono essere visualizzazioni.
Risolvere i problemi relativi agli inserimenti di flussi di dati
Le sezioni seguenti descrivono come risolvere gli errori che si verificano quando inserisci flussi di dati in BigQuery utilizzando l'API Streaming precedente. Per ulteriori informazioni su come risolvere gli errori di quota per gli inserimenti di flussi di dati, consulta la sezione Errori di quota relativi agli inserimenti di flussi di dati.
Codici di risposta HTTP di errore
Se ricevi un codice di risposta HTTP di errore, ad esempio un errore di rete, non è possibile
determinare se l'inserimento dello streaming è andato a buon fine. Se provi a inviare di nuovo
la richiesta, potresti ritrovarti con righe duplicate nella tabella. Per proteggere la tabella dalla duplicazione, imposta la proprietà insertId quando invii la richiesta. BigQuery utilizza la proprietà insertId
per la deduplicazione.
Se ricevi un errore di autorizzazione, un errore di nome tabella non valido o un errore di quota superata, non vengono inserite righe e l'intera richiesta non va a buon fine.
Codici di risposta HTTP riusciti
Anche se ricevi un
codice di risposta HTTP riuscito, devi controllare la proprietà
insertErrors della risposta per determinare se gli inserimenti di righe
sono andati a buon fine, perché è possibile che BigQuery abbia inserito le righe
solo parzialmente. Potresti riscontrare uno dei seguenti scenari:
- Tutte le righe sono state inserite correttamente. Se la proprietà
insertErrorsè un elenco vuoto, tutte le righe sono state inserite correttamente. - Alcune righe sono state inserite correttamente. Ad eccezione dei casi in cui si verifica una mancata corrispondenza dello schema in una delle righe, le righe indicate nella proprietà
insertErrorsnon vengono inserite e tutte le altre righe vengono inserite correttamente. La proprietàerrorscontiene informazioni dettagliate sul motivo per cui ogni riga non è stata caricata. La proprietàindexindica l'indice di riga in base zero della richiesta a cui si applica l'errore. - Nessuna riga inserita correttamente. Se BigQuery rileva una mancata corrispondenza dello schema nelle singole righe della richiesta, nessuna riga viene inserita e viene restituita una voce
insertErrorsper ogni riga, anche per quelle che non presentavano una mancata corrispondenza dello schema. Le righe che non presentavano una mancata corrispondenza dello schema hanno un errore con la proprietàreasonimpostata sustoppede possono essere inviate nuovamente così come sono. Le righe non riuscite includono informazioni dettagliate sulla mancata corrispondenza dello schema. Per informazioni sui tipi di protocol buffer supportati per ogni tipo di dati BigQuery, consulta Tipi di dati Arrow e protocol buffer supportati.
Errori dei metadati per gli inserimenti di flussi di dati
Poiché l'API BigQuery Streaming è progettata per tassi di inserimento elevati, le modifiche ai metadati della tabella sottostante sono coerenti alla fine quando si interagisce con il sistema di streaming. Nella maggior parte dei casi, le modifiche ai metadati vengono propagate in pochi minuti, ma durante questo periodo le risposte API potrebbero riflettere lo stato incoerente della tabella.
Alcuni scenari includono:
- Modifiche allo schema. La modifica dello schema di una tabella che ha ricevuto di recente inserimenti di streaming può causare risposte con errori di mancata corrispondenza dello schema perché il sistema di streaming potrebbe non rilevare immediatamente la modifica dello schema.
- Creazione/eliminazione di tabelle. Lo streaming a una tabella inesistente restituisce una variante di una
risposta
notFound. Una tabella creata in una risposta potrebbe non essere riconosciuta immediatamente dai successivi inserimenti di streaming. Analogamente, l'eliminazione o la ricreazione di una tabella può creare un periodo di tempo in cui gli inserimenti streaming vengono effettivamente inviati alla vecchia tabella. Gli inserimenti di streaming potrebbero non essere presenti nella nuova tabella. - Troncamento della tabella. Il troncamento dei dati di una tabella (utilizzando un job di query che utilizza writeDisposition di WRITE_TRUNCATE) può causare in modo simile l'eliminazione degli inserimenti successivi durante il periodo di coerenza.
Dati mancanti/non disponibili
Gli inserimenti in streaming risiedono temporaneamente nell'archiviazione ottimizzata per la scrittura, che ha caratteristiche di disponibilità diverse rispetto all'archiviazione gestita. Alcune operazioni in BigQuery non interagiscono
con lo spazio di archiviazione ottimizzato per la scrittura, ad esempio i job di copia delle tabelle e i metodi API come tabledata.list.
I dati di streaming recenti non saranno presenti nella tabella di destinazione o nell'output.
Errori di quota relativi agli inserimenti di flussi di dati
Questa sezione fornisce suggerimenti per la risoluzione dei problemi relativi alle quote per i flussi di dati in BigQuery.
In alcune aree geografiche, gli inserimenti di flussi di dati hanno una quota maggiore se non immetti dati nel campo insertId per ogni riga. Per ulteriori informazioni sulle quote per gli inserimenti di flussi di dati, consulta la pagina relativa agli Inserimento di flussi di dati.
Gli errori relativi alle quote per i flussi di dati di BigQuery dipendono dalla presenza o dall'assenza di un valore nel campo insertId.
Messaggio di errore
Se il campo insertId è vuoto, si può verificare il seguente errore di quota:
| Limite quota | Messaggio di errore |
|---|---|
| Byte al secondo per progetto | La tua entità con ID GAIA GAIA_ID, progetto PROJECT_ID e area geografica REGION ha superato la quota di inserimento byte al secondo. |
Se il campo insertId è compilato, si possono verificare i seguenti errori di quota:
| Limite quota | Messaggio di errore |
|---|---|
| Righe al secondo per progetto | Il tuo progetto PROJECT_ID in REGION ha superato la quota per l'inserimento di righe di flussi di dati al secondo. |
| Righe al secondo per tabella | La tua tabella TABLE_ID ha superato la quota per l'inserimento di righe di flussi di dati al secondo. |
| Byte al secondo per tabella | La tua tabella TABLE_ID ha superato la quota per l'inserimento di byte di flussi di dati al secondo. |
Lo scopo del campo insertId è deduplicare le righe inserite. Se arrivano più inserimenti con lo stesso insertId nel giro di pochi minuti, BigQuery scrive un'unica versione del record. Tuttavia, questa deduplicazione automatica non è garantita. Per la massima velocità effettiva di trasmissione dei flussi di dati, ti consigliamo di non includere insertId e di usare invece la deduplicazione manuale.
Per ulteriori informazioni, consulta la pagina relativa a come garantire la coerenza dei dati.
Quando si verifica questo errore, diagnostica il problema e poi segui i passaggi consigliati per risolverlo.
Diagnosi
Usa le viste STREAMING_TIMELINE_BY_* per analizzare il traffico dei flussi di dati. Queste viste aggregano le statistiche relative ai flussi di dati in intervalli di un minuto, raggruppate per error_code. Gli errori di quota vengono visualizzati nei risultati con error_code uguale a RATE_LIMIT_EXCEEDED o QUOTA_EXCEEDED.
A seconda del limite di quota specifico raggiunto, fai riferimento a total_rows o total_input_bytes. Se l'errore riguarda una quota a livello di tabella, filtra per table_id.
Ad esempio, la seguente query mostra i byte totali importati al minuto e il numero totale di errori di quota:
SELECT start_timestamp, error_code, SUM(total_input_bytes) as sum_input_bytes, SUM(IF(error_code IN ('QUOTA_EXCEEDED', 'RATE_LIMIT_EXCEEDED'), total_requests, 0)) AS quota_error FROM `region-REGION_NAME`.INFORMATION_SCHEMA.STREAMING_TIMELINE_BY_PROJECT WHERE start_timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY) GROUP BY start_timestamp, error_code ORDER BY 1 DESC
Risoluzione
Per risolvere questo errore relativo alla quota, segui questi passaggi:
Se usi il campo
insertIdper la deduplicazione e il tuo progetto si trova in una regione che supporta una quota per i flussi di dati maggiore, ti consigliamo di rimuovere il campoinsertId. Questa soluzione potrebbe richiedere passaggi aggiuntivi per la deduplicazione manuale dei dati. Per ulteriori informazioni, vedi Rimozione manuale dei duplicati.Se non usi
insertId, oppure non è possibile rimuoverlo, monitora il traffico dei flussi di dati per un periodo di 24 ore e analizza gli errori di quota:Se risultano soprattutto errori
RATE_LIMIT_EXCEEDEDanziché erroriQUOTA_EXCEEDEDe il traffico complessivo è inferiore all'80% della quota, gli errori indicano probabilmente picchi temporanei. Per risolvere questi errori, puoi eseguire nuovamente l'operazione usando il backoff esponenziale tra tentativi successivi.Se utilizzi un job Dataflow per inserire dati, valuta la possibilità di utilizzare job di caricamento anziché inserimenti in streaming. Per saperne di più, vedi Impostare il metodo di inserimento. Se utilizzi Dataflow con un connettore I/O personalizzato, valuta la possibilità di utilizzare un connettore I/O integrato. Per saperne di più, consulta Pattern di I/O personalizzati.
Se risultano errori
QUOTA_EXCEEDEDo il traffico complessivo supera costantemente l'80% della quota, invia una richiesta di aumento della quota. Per saperne di più, consulta Richiedi un aggiustamento delle quote.Potresti anche prendere in considerazione la sostituzione degli inserimenti in streaming con la nuova API Storage Write, che offre una velocità effettiva superiore, un prezzo inferiore e molte funzionalità utili.