Utiliser l'exécution avancée BigQuery

Le moteur d'exécution avancé BigQuery est un ensemble d'améliorations des performances conçu pour accélérer automatiquement les charges de travail analytiques sans nécessiter d'action de l'utilisateur ni de modification du code. Ce document décrit ces améliorations des performances, y compris la vectorisation améliorée et les optimisations des requêtes courtes.

Rôles et autorisations

Pour obtenir les autorisations nécessaires pour spécifier un paramètre de configuration, demandez à votre administrateur de vous accorder le rôle IAM Administrateur BigQuery (roles/bigquery.admin) sur votre projet ou votre organisation. Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Vectorisation améliorée

L'exécution vectorisée est un modèle de traitement des requêtes qui fonctionne sur des colonnes de données dans des blocs alignés sur la taille du cache du processeur et qui utilise des instructions SIMD (Single Instruction, Multiple Data). La vectorisation améliorée étend l'exécution vectorisée des requêtes dans BigQuery aux aspects suivants du traitement des requêtes :

  • En tirant parti des encodages de données spécialisés dans le format de stockage Capacitor, les opérations d'évaluation des filtres peuvent être exécutées sur les données encodées.
  • Les encodages spécialisés sont propagés dans le plan de requête, ce qui permet de traiter davantage de données lorsqu'elles sont encore encodées.
  • En implémentant le pliage d'expressions pour évaluer les fonctions déterministes et les expressions constantes, BigQuery peut simplifier les prédicats complexes en valeurs constantes.

Optimisations pour les requêtes courtes

BigQuery exécute généralement les requêtes dans un environnement distribué à l'aide d'une couche intermédiaire de redistribution. Les optimisations pour les requêtes courtes identifient de manière dynamique les requêtes qui peuvent être exécutées en une seule étape, ce qui réduit la latence et la consommation d'emplacements. Les encodages spécialisés peuvent être utilisés plus efficacement lorsqu'une requête est exécutée en une seule étape. Ces optimisations sont plus efficaces lorsqu'elles sont utilisées avec le mode de création de job facultatif, qui minimise la latence de démarrage, de maintenance et de récupération des résultats des jobs.

L'éligibilité aux optimisations pour les requêtes courtes est dynamique et dépend des facteurs suivants :

  • Taille prévue de l'analyse des données.
  • La quantité de données à transférer.
  • Sélectivité des filtres de requête.
  • Type et disposition physique des données stockées.
  • Structure globale de la requête.
  • Les statistiques historiques des exécutions de requêtes passées.

Activer l'environnement d'exécution avancé

Entre le 15 septembre 2025 et début 2026, BigQuery commencera à utiliser l'exécution avancée comme exécution par défaut pour tous les projets. Pour activer le runtime avancé dans un projet ou une organisation existants, utilisez l'instruction ALTER PROJECT ou ALTER ORGANIZATION pour modifier la configuration par défaut. Dans l'instruction, définissez l'argument query_runtime sur 'advanced'. Exemple :

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

Remplacez les éléments suivants :

  • PROJECT_NAME : nom du projet.
  • LOCATION : emplacement dans lequel les jobs doivent tenter d'utiliser le runtime avancé

La prise en compte de la modification peut prendre plusieurs minutes.

Une fois que vous avez activé l'environnement d'exécution avancé, les requêtes éligibles du projet ou de l'organisation utilisent l'environnement d'exécution avancé, quel que soit l'utilisateur qui a créé le job de requête.

Estimer l'impact du runtime avancé

Pour estimer l'impact de l'environnement d'exécution avancé, vous pouvez utiliser la requête SQL suivante afin d'identifier les requêtes de projet qui présentent l'amélioration de temps d'exécution estimée la plus grande :

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;

Remplacez les éléments suivants :

  • LOCATION : emplacement dans lequel les performances du job doivent être mesurées

Si le runtime avancé a été activé et appliqué, les résultats de cette requête peuvent ressembler à ce qui suit :

/*--------------+----------------------------+----------------+---------------------*
 |    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 |
 *--------------+----------------------------+----------------+---------------------*/

Les résultats de cette requête ne sont qu'une estimation de l'impact du runtime avancé. De nombreux facteurs peuvent influencer les performances des requêtes, y compris, mais sans s'y limiter, la disponibilité des emplacements, l'évolution des données au fil du temps, les définitions de vues ou de fonctions définies UDF;utilisateur, et les différences dans les valeurs des paramètres de requête.

Si les résultats de cette requête sont vides, cela signifie qu'aucun job n'a utilisé de runtime avancé ou que tous les jobs ont été optimisés il y a plus de 30 jours.

Cette requête peut être appliquée à d'autres métriques de performances des requêtes, telles que total_slot_ms et total_bytes_billed. Pour en savoir plus, consultez le schéma INFORMATION_SCHEMA.JOBS_BY_PROJECT.