Utilizzare il runtime avanzato di BigQuery

BigQuery advanced runtime è un insieme di miglioramenti delle prestazioni progettati per accelerare automaticamente i carichi di lavoro analitici senza richiedere l'intervento dell'utente o modifiche al codice. Questo documento descrive questi miglioramenti delle prestazioni, tra cui una migliore vettorizzazione e ottimizzazioni delle query brevi.

Ruoli e autorizzazioni

Per ottenere le autorizzazioni necessarie per specificare un'impostazione di configurazione, chiedi all'amministratore di concederti il ruolo IAM BigQuery Admin (roles/bigquery.admin) nel progetto o nell'organizzazione. Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Vettorializzazione avanzata

L'esecuzione vettoriale è un modello di elaborazione delle query che opera su colonne di dati in blocchi allineati alle dimensioni della cache della CPU e utilizza istruzioni SIMD (Single Instruction, Multiple Data). La vettorizzazione avanzata estende l'esecuzione vettorizzata delle query in BigQuery ai seguenti aspetti dell'elaborazione delle query:

  • Sfruttando codifiche dei dati specializzate all'interno del formato di archiviazione Capacitor, le operazioni di valutazione dei filtri possono essere eseguite sui dati codificati.
  • Le codifiche specializzate vengono propagate tramite il piano di query, il che consente di elaborare più dati mentre sono ancora codificati.
  • Implementando il folding delle espressioni per valutare le funzioni deterministiche e le espressioni costanti, BigQuery può semplificare i predicati complessi in valori costanti.

Ottimizzazioni delle query a breve termine

BigQuery in genere esegue le query in un ambiente distribuito utilizzando un livello intermedio di shuffle. Le ottimizzazioni delle query brevi identificano dinamicamente le query che possono essere eseguite come singola fase, riducendo la latenza e il consumo di slot. Le codifiche specializzate possono essere utilizzate in modo più efficace quando una query viene eseguita in una singola fase. Queste ottimizzazioni sono più efficaci se utilizzate con la modalità di creazione dei job facoltativa, che riduce al minimo la latenza di avvio, manutenzione e recupero dei risultati dei job.

L'idoneità alle ottimizzazioni delle query brevi è dinamica e influenzata dai seguenti fattori:

  • La dimensione prevista della scansione dei dati.
  • La quantità di spostamento dei dati richiesta.
  • La selettività dei filtri delle query.
  • Il tipo e il layout fisico dei dati nell'archivio.
  • La struttura generale della query.
  • Le statistiche storiche delle esecuzioni di query precedenti.

Abilitare il runtime avanzato

Tra il 15 settembre 2025 e l'inizio del 2026, BigQuery inizierà a utilizzare il runtime avanzato come runtime predefinito per tutti i progetti. Per abilitare l'ambiente di runtime avanzato in un progetto o un'organizzazione esistente, utilizza l'istruzione ALTER PROJECT o ALTER ORGANIZATION per modificare la configurazione predefinita. Nell'istruzione, imposta l'argomento query_runtime su 'advanced'. Ad esempio:

ALTER PROJECT PROJECT_NAME
SET OPTIONS (
  `region-LOCATION.query_runtime` = 'advanced'
);

Sostituisci quanto segue:

  • PROJECT_NAME: il nome del progetto
  • LOCATION: la posizione in cui i job devono tentare di utilizzare il runtime avanzato

Potrebbero essere necessari diversi minuti prima che la modifica diventi effettiva.

Una volta abilitato l'ambiente di esecuzione avanzato, le query idonee nel progetto o nell'organizzazione utilizzano l'ambiente di esecuzione avanzato indipendentemente dall'utente che ha creato il job di query.

Stima l'impatto dell'ambiente di runtime avanzato

Per stimare l'impatto dell'ambiente di runtime avanzato, puoi utilizzare la seguente query SQL per identificare le query del progetto con il maggiore miglioramento stimato del tempo di esecuzione:

WITH
  jobs AS (
    SELECT
      *,
      query_info.query_hashes.normalized_literals AS query_hash,
      TIMESTAMP_DIFF(end_time, start_time, MILLISECOND) AS elapsed_ms,
      EXISTS(
        SELECT 1
        FROM UNNEST(JSON_QUERY_ARRAY(query_info.optimization_details.optimizations)) AS o
        WHERE JSON_VALUE(o, '$.enhanced_vectorization') = 'applied'
      ) AS has_advanced_runtime
    FROM region-LOCATION.INFORMATION_SCHEMA.JOBS_BY_PROJECT
    WHERE EXTRACT(DATE FROM creation_time) > DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
  ),
  most_recent_jobs_without_advanced_runtime AS (
    SELECT *
    FROM jobs
    WHERE NOT has_advanced_runtime
    QUALIFY ROW_NUMBER() OVER (PARTITION BY query_hash ORDER BY end_time DESC) = 1
  )
SELECT
  job.job_id,
  100 * SAFE_DIVIDE(
    original_job.elapsed_ms - job.elapsed_ms,
    original_job.elapsed_ms) AS percent_execution_time_saved,
  job.elapsed_ms AS new_elapsed_ms,
  original_job.elapsed_ms AS original_elapsed_ms,
FROM jobs AS job
INNER JOIN most_recent_jobs_without_advanced_runtime AS original_job
  USING (query_hash)
WHERE
  job.has_advanced_runtime
  AND original_job.end_time < job.start_time
ORDER BY percent_execution_time_saved DESC
LIMIT 10;

Sostituisci quanto segue:

  • LOCATION: la località in cui devono essere misurate le prestazioni del lavoro

Se l'ambiente di runtime avanzato è stato abilitato e applicato, i risultati di questa query potrebbero essere simili ai seguenti:

/*--------------+----------------------------+----------------+---------------------*
 |    job_id    | percent_elapsed_time_saved | new_elapsed_ms | original_elapsed_ms |
 +--------------+----------------------------+----------------+---------------------+
 | sample_job1  |         45.38834951456311  |            225 |                 412 |
 | sample_job2  |         45.19480519480519  |            211 |                 385 |
 | sample_job3  |         33.246753246753244 |            257 |                 385 |
 | sample_job4  |         29.28802588996764  |           1311 |                1854 |
 | sample_job5  |         28.18181818181818  |           1027 |                1430 |
 | sample_job6  |         25.804195804195807 |           1061 |                1430 |
 | sample_job7  |         25.734265734265733 |           1062 |                1430 |
 | sample_job8  |         25.454545454545453 |           1066 |                1430 |
 | sample_job9  |         25.384615384615383 |           1067 |                1430 |
 | sample_job10 |         25.034965034965033 |           1072 |                1430 |
 *--------------+----------------------------+----------------+---------------------*/

I risultati di questa query sono solo una stima dell'impatto dell'ambiente di runtime avanzato. Molti fattori possono influire sulle prestazioni delle query, tra cui, a titolo esemplificativo, la disponibilità di slot, la variazione dei dati nel tempo, le definizioni di viste o UDF e le differenze nei valori dei parametri di query.

Se i risultati di questa query sono vuoti, significa che nessun job ha utilizzato l'ambiente di runtime avanzato oppure che tutti i job sono stati ottimizzati più di 30 giorni fa.

Questa query può essere applicata ad altre metriche sul rendimento delle query, ad esempio total_slot_ms e total_bytes_billed. Per saperne di più, consulta lo schema per INFORMATION_SCHEMA.JOBS_BY_PROJECT.