Introduzione alle query continue

Questo documento descrive le query continue di BigQuery.

Le query continue di BigQuery sono istruzioni SQL eseguite ininterrottamente. Le query continue consentono di analizzare i dati in entrata in BigQuery in tempo reale. Puoi scrivere o esportare le righe di output prodotte da una query continua nelle seguenti destinazioni:

• Tabelle BigQuery
• Tabelle gestite Apache Iceberg
• Argomenti Pub/Sub
• Tabelle Bigtable
• Tabelle Spanner

Le query continue possono elaborare i dati scritti nelle tabelle BigQuery standard utilizzando uno dei seguenti metodi:

• L'API BigQuery Storage Write (gRPC)
• L'API BigQuery Storage Write (REST)
• Caricamento in batch
• L'istruzione DML INSERT
• I data manipulation language (DML) statements come DELETE, UPDATE e MERGE durante l'esportazione dei dati in Pub/Sub.
• Scrive i dati dai risultati di una query batch in una tabella permanente
• Scrive i risultati di una query continua BigQuery in una tabella permanente.
• Una sottoscrizione Pub/Sub BigQuery
• Scritture da Dataflow a BigQuery
• Scritture da Datastream a BigQuery utilizzando la modalità di scrittura solo accodamento

Puoi utilizzare le query continue per eseguire attività sensibili al tempo, ad esempio creare e agire immediatamente in base agli insight, applicare l'inferenza di machine learning (ML) in tempo reale e replicare i dati in altre piattaforme. In questo modo puoi utilizzare BigQuery come motore di elaborazione dei dati basato su eventi per la logica decisionale della tua applicazione.

Il seguente diagramma mostra i flussi di lavoro comuni delle query continue:

Casi d'uso

Ecco alcuni casi d'uso comuni in cui potresti voler utilizzare le query continue:

• Servizi di interazione con i clienti personalizzati: utilizza l'AI generativa per creare messaggi personalizzati per ogni interazione con i clienti.
• Rilevamento delle anomalie: crea soluzioni che ti consentono di eseguire il rilevamento di anomalie e minacce su dati complessi in tempo reale, in modo da poter reagire più rapidamente ai problemi.
• Pipeline basate su eventi personalizzabili: utilizza l'integrazione di query continue con Pub/Sub per attivare applicazioni downstream in base ai dati in entrata.
• Arricchimento dei dati ed estrazione delle entità: utilizza query continue per eseguire la trasformazione e l'arricchimento dei dati in tempo reale utilizzando funzioni SQL e modelli di machine learning.
• ETL inverso: esegui l'ETL inverso in tempo reale in altri sistemi di archiviazione più adatti alla pubblicazione di applicazioni a bassa latenza. Ad esempio, analizzare o migliorare i dati degli eventi scritti in BigQuery, e poi trasmetterli in streaming a Bigtable, Spanner o tabelle gestite Apache Iceberg per la pubblicazione di applicazioni.
• Attivazione autonoma degli agenti: attiva le pipeline di dati agentici in tempo reale in base a eventi complessi rilevati nei flussi di dati in tempo reale. Per un esempio, consulta il codelab Crea un agente di dati basato su eventi con BigQuery e Agent Development Kit (ADK).
• Monitoraggio degli agenti autonomi: sviluppa il monitoraggio e gli avvisi automatizzati in tempo reale per le interazioni agentiche in tempo reale utilizzando il plug-in di analisi degli agenti BigQuery, che trasmette in streaming tutti i dati di traccia degli agenti, l'utilizzo degli strumenti e i log operativi direttamente in BigQuery per una visibilità approfondita della tua forza lavoro AI.

Funzionalità supportate

Le seguenti operazioni sono supportate nelle query continue:

• Esecuzione di istruzioni INSERT per scrivere i dati di una query continua in una tabella BigQuery o in una tabella gestita Iceberg.

• Esecuzione di istruzioni EXPORT DATA per pubblicare l'output della query continua negli argomenti Pub/Sub.

  Le query continue che esportano dati in Pub/Sub devono essere eseguite utilizzando un service account. Per saperne di più, consulta Esportare dati in Pub/Sub.

  Da un argomento Pub/Sub, puoi utilizzare i dati con altri servizi, ad esempio eseguire l'analisi dei flussi di dati utilizzando Dataflow o utilizzare i dati in un flusso di lavoro di integrazione delle applicazioni.

• Esecuzione di istruzioni EXPORT DATA per esportare i dati da BigQuery alle tabelle Bigtable. Per saperne di più, consulta Esportare dati in Bigtable.

• Esecuzione di istruzioni EXPORT DATA per esportare i dati da BigQuery alle tabelle Spanner. Per saperne di più, vedi Esportare i dati in Spanner (ETL inversa).

• Chiamata delle seguenti funzioni di AI generativa:

  • AI.GENERATE

  • AI.GENERATE_TEXT

    • Questa funzione richiede un modello remoto BigQuery ML su un modello Gemini Enterprise Agent Platform.

• Chiamata delle seguenti funzioni AI:

  • ML.UNDERSTAND_TEXT
  • ML.TRANSLATE

  Queste funzioni richiedono un modello remoto BigQuery ML su un'API Cloud AI.

• Normalizza i dati numerici utilizzando la funzione ML.NORMALIZER.

• Analisi ed elaborazione dei dati JSON, incluso il supporto per le funzioni JSON e l'estrazione JSON.

• Utilizzo di funzioni GoogleSQL stateless, ad esempio funzioni di conversione. Nelle funzioni stateless, ogni riga viene elaborata indipendentemente dalle altre righe della tabella.

• Utilizzo di operazioni con stato, ad esempio JOIN, aggregazioni e aggregazioni a finestra. Nelle operazioni con stato, lo stato dei dati importati viene mantenuto su più righe o intervalli di tempo per calcolare un risultato accurato.

• Utilizzo della funzione APPENDS della cronologia delle modifiche per elaborare i dati aggiunti da un momento specifico.

• Utilizzo della funzione di cronologia delle modifiche CHANGES per elaborare i dati modificati, inclusi gli accodamenti e le modifiche, da un momento specifico durante l'esportazione dei dati in Pub/Sub. Tuttavia, CHANGES non è supportato quando si utilizza un'operazione con stato.

• Eseguire query sulle viste, a condizione che la query SQL sottostante della vista sia una query continua valida.

Operazioni stateful supportate

Anteprima

Questa funzionalità è soggetta ai "Termini dell'offerta pre-GA" nella sezione dei Termini di servizio generali dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

Per richiedere assistenza o fornire un feedback su questa funzionalità, invia un'email all'indirizzo [e-mail].

Le operazioni con stato consentono alle query continue di eseguire analisi complesse che richiedono la conservazione delle informazioni in più righe o intervalli di tempo. Mentre le funzioni senza stato elaborano ogni riga in modo indipendente, le operazioni con stato mantengono lo stato dei dati inseriti per supportare funzioni come JOIN, aggregazioni e aggregazioni a finestra. Questa funzionalità ti consente di correlare eventi di stream diversi o calcolare metriche nel tempo, ad esempio una media di 30 minuti, memorizzando i dati necessari nella memoria durante l'esecuzione della query.

Le query continue supportano le seguenti operazioni stateful:

• JOIN
• Aggregazioni e finestre

Autorizzazione

I token di accessoGoogle Cloud utilizzati durante l'esecuzione dei job di query continua hanno un durata (TTL) di due giorni quando vengono generati da un account utente. Pertanto, questi job smettono di essere eseguiti dopo due giorni. I token di accesso generati dagli account di servizio possono essere eseguiti più a lungo, ma devono comunque rispettare il runtime massimo della query. Per saperne di più, consulta Eseguire una query continua utilizzando un service account.

Località

Per un elenco delle regioni supportate, vedi Località delle query continue di BigQuery.

Limitazioni

Le query continue sono soggette alle seguenti limitazioni:

• Lo stato dei dati importati viene mantenuto solo per le operazioni con stato specifico in anteprima. Sebbene le query continue ora supportino alcuni tipi di JOIN, aggregazioni e aggregazioni finestra, questi sono limitati a operazioni stateful specifiche. Non tutti i tipi di operazioni stateful sono supportati.

• Non puoi utilizzare le seguenti funzionalità SQL in una query continua, a meno che non siano elencate come operazione stateful supportata:

  • I seguenti operatori di query:

    • PIVOT
    • UNPIVOT
    • TABLESAMPLE

  • Operatori di insiemi di query

  • La dichiarazione SELECT DISTINCT

  • EXISTS o NOT EXISTS

  • CTE ricorsive

  • Funzioni definite dall'utente

  • Chiamate di funzioni finestra

  • Funzioni BigQuery ML diverse da quelle elencate in Funzionalità supportata

  • Istruzioni DDL (Data Definition Language)

  • Istruzioni Data Manipulation Language (DML) ad eccezione di INSERT.

  • Istruzioni Data Control Language (DCL)

  • Istruzioni EXPORT DATA che non hanno come target Bigtable, Pub/Sub o Spanner.

  • Linguaggio procedurale

  • Istruzioni di debug

• Le query continue non supportano le seguenti origini dati:

  • Tabelle esterne.
  • Viste dello schema delle informazioni.
  • Tabelle gestite Apache Iceberg. Tieni presente che le tabelle gestite Iceberg non sono supportate come origini dati, ma sono supportate come destinazioni per l'output delle query continue.
  • Tabelle con caratteri jolly.
  • Upsert Change Data Capture (CDC) dei dati.
  • Viste materializzate.
  • Viste in cui la query SQL sottostante utilizza funzionalità non supportate, come funzioni definite dall'utente, tabelle esterne o tabelle abilitate per CDC.

• Le query continue non supportano le funzionalità di sicurezza column- e a livello di riga.

• L'output di una query continua è soggetto alle quote e ai limiti intrinseci del servizio di destinazione in cui viene esportato.

• Quando esporti i dati in Bigtable, Spanner o endpoint Pub/Sub puoi scegliere come target solo le risorse Bigtable, Spanner o Pub/Sub che rientrano nello stesso confine regionale di Google Cloud del set di dati BigQuery che contiene la tabella su cui stai eseguendo la query. Questa limitazione non si applica quando esporti i dati negli endpoint globali Pub/Sub. Per saperne di più sull'esportazione in una policy di routing del profilo app Bigtable, consulta Considerazioni sulla località.

• Non puoi eseguire una query continua da un data canvas.

• Non puoi modificare l'SQL utilizzato in una query continua mentre è in esecuzione il relativo job. Per ulteriori informazioni, consulta Modificare l'SQL di una query continua.

• Se un job di query continua è in ritardo nell'elaborazione dei dati in arrivo e ha un ritardo della filigrana di output di più di 48 ore, il job non va a buon fine. Puoi eseguire di nuovo la query e utilizzare la funzione APPENDS o CHANGES della cronologia delle modifiche per riprendere l'elaborazione dal momento in cui hai interrotto il precedente job di query continua. Per saperne di più, consulta Avvia una query continua da un momento specifico.

• Una query continua configurata con un account utente può essere eseguita per un massimo di due giorni. Una query continua configurata con un account di servizio può essere eseguita per un massimo di 150 giorni. Quando viene raggiunto il runtime massimo della query, la query non va a buon fine e l'elaborazione dei dati in arrivo si interrompe.

• Sebbene le query continue siano create utilizzando le funzionalità di affidabilità di BigQuery, possono verificarsi problemi temporanei occasionali. I problemi potrebbero comportare una certa quantità di rielaborazione automatica della query continua, il che potrebbe comportare la duplicazione dei dati nell'output della query continua. Progetta i sistemi downstream in modo che gestiscano questi scenari.

Limitazioni delle prenotazioni

• Per eseguire query continue, devi creare una prenotazione della versione Enterprise o Enterprise Plus con un tipo di assegnazione CONTINUOUS. Le query continue non supportano il modello di fatturazione di calcolo on demand.
• Quando crei un CONTINUOUS assegnazione di prenotazione, la prenotazione associata è limitata a un massimo di 500 slot. Puoi richiedere un aumento di questo limite contattando [e-mail].
• Non puoi creare un'assegnazione di prenotazione che utilizzi un tipo di prestazione diverso nella stessa prenotazione di un'assegnazione di prenotazione di query continua.

• BigQuery determina il numero di query continue che possono essere eseguite contemporaneamente per progetto in base alle dimensioni configurate dell'assegnazione della prenotazione che utilizza il tipo di prestazione CONTINUOUS. Per accettare nuovi job, BigQuery richiede una soglia di 10 slot per job di query continua. La query non utilizza necessariamente tutti i 10 slot durante la normale esecuzione. Questa soglia garantisce che ogni query continua in esecuzione mantenga una capacità di calcolo di base sufficiente per gestire picchi improvvisi nel volume dei dati in entrata senza rimanere indietro o compromettere l'elaborazione a bassa latenza.

  Per assicurarti che le query vengano accettate correttamente senza raggiungere i limiti di concorrenza, ti consigliamo di utilizzare lo scaling automatico degli slot. Con la scalabilità automatica, l'utilizzo complessivo degli slot viene scalato dinamicamente in base alla domanda effettiva di risorse. Puoi configurare una prenotazione di base più piccola e impostare un limite massimo di scalabilità automatica che copra comodamente la soglia di 10 slot per query per le query simultanee previste.

• Quando esegui più query continue utilizzando la stessa prenotazione, i singoli job potrebbero non dividere equamente le risorse disponibili, come definito da BigQuery fairness.

Scalabilità automatica degli slot

Le query continue possono utilizzare la scalabilità automatica degli slot per scalare dinamicamente la capacità allocata in base al tuo workload. Man mano che il workload delle query continue aumenta o diminuisce, BigQuery regola dinamicamente gli slot.

Una volta avviata l'esecuzione, una query continua ascolta attivamente i dati in arrivo, che consumano risorse slot. Mentre una prenotazione con una query continua in esecuzione non viene fare lo scale down a zero slot, una query continua inattiva che ascolta principalmente i dati in arrivo dovrebbe consumare una quantità minima di slot, in genere circa uno.

Condivisione di slot inattivi

Le query continue possono utilizzare la condivisione degli slot inattivi per condividere le risorse degli slot inutilizzati con altre prenotazioni e tipi di job.

• Per eseguire una query continua è ancora necessario un CONTINUOUS assegnazione di prenotazione e non è possibile fare affidamento esclusivamente sugli slot inattivi di altre prenotazioni. Pertanto, un'assegnazione di prenotazione CONTINUOUS richiede una base di riferimento di slot diversa da zero o una configurazione di scalabilità automatica di slot diversa da zero.
• Sono condivisibili solo gli slot di riferimento inattivi o gli slot impegnati di un'assegnazione di prenotazione CONTINUOUS. Gli slot con scalabilità automatica non sono condivisibili come slot inattivi per altre prenotazioni.

Prezzi

Le query continue possono utilizzare la scalabilità fluida di BigQuery.

Le query continue utilizzano i prezzi di computing della capacità BigQuery, che viene misurata in slot. Per eseguire query continue, devi disporre di una prenotazione che utilizzi Enterprise o Enterprise Plus, e di un assegnazione di prenotazione che utilizzi il tipo di prestazione CONTINUOUS.

L'utilizzo di altre risorse BigQuery, come l'importazione e l'archiviazione dei dati, viene addebitato alle tariffe indicate nei prezzi di BigQuery.

L'utilizzo di altri servizi che ricevono risultati di query continua o che vengono chiamati durante l'elaborazione di query continua viene addebitato alle tariffe pubblicate per questi servizi. Per i prezzi di altri servizi Google Cloud utilizzati dalle query continue, consulta i seguenti argomenti:

• Prezzi di Bigtable
• Prezzi di Pub/Sub
• Prezzi di Spanner
• Prezzi di Agent Platform

Stima dei requisiti di capacità dello slot

Poiché ogni carico di lavoro è diverso, spesso non è possibile stimare in anticipo uno slot esatto per le query continue. Il numero di slot richiesti dalle query continue dipende da una combinazione di diversi fattori:

• Il numero di query continue in esecuzione contemporaneamente.
• La complessità dell'istruzione SQL.
• L'utilizzo di funzioni di elaborazione stateful, tra cui durate delle finestre, JOIN e aggregazioni.
• Il tasso o la velocità dei dati in entrata.
• La struttura e le dimensioni dei dati importati.

A livello concettuale, puoi stimare il requisito totale di slot in funzione del tuo workload di query continua:

Slot stimati ≈ Numero di query continue x ∑ (velocità di trasferimento dei dati x complessità della query)

Poiché il consumo effettivo di slot dipende in larga misura dal tuo workload e dai pattern di dati unici, il metodo più accurato per stimare il costo è monitorare un job in esecuzione. Puoi misurare l'utilizzo massimo degli slot di un'esecuzione di query continua isolata utilizzando le visualizzazioni INFORMATION_SCHEMA. Per istruzioni dettagliate ed esempi di query per monitorare l'utilizzo degli slot nel tempo, vedi Visualizzare le informazioni sul consumo degli slot.

Passaggi successivi

Prova a creare una query continua.