Erweiterte BigQuery-Laufzeit verwenden

Die erweiterte BigQuery-Laufzeit umfasst eine Reihe von Leistungsverbesserungen, mit denen analytische Arbeitslasten automatisch beschleunigt werden, ohne dass Nutzeraktionen oder Codeänderungen erforderlich sind. In diesem Dokument werden diese Leistungsverbesserungen beschrieben, einschließlich der erweiterten Vektorisierung und Optimierungen für kurze Abfragen.

Rollen und Berechtigungen

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle BigQuery-Administrator (roles/bigquery.admin) für Ihr Projekt oder Ihre Organisation zu gewähren, um die Berechtigungen zu erhalten, die Sie zum Festlegen einer Konfigurationseinstellung benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Erweiterte Vektorisierung

Die vektorisierte Ausführung ist ein Abfrageverarbeitungsmodell, das Spalten von Daten in Blöcken verarbeitet, die der CPU-Cachegröße entsprechen, und SIMD-Anweisungen (Single Instruction, Multiple Data) verwendet. Die erweiterte Vektorisierung erweitert die vektorisierte Abfrageausführung in BigQuery auf die folgenden Aspekte der Abfrageverarbeitung:

• Durch die Nutzung spezieller Datencodierungen im Capacitor-Speicherformat können Filterauswertungen für die codierten Daten ausgeführt werden.
• Spezielle Codierungen werden über den Abfrageplan weitergegeben, sodass mehr Daten verarbeitet werden können, während sie noch codiert sind.
• Durch die Implementierung der Ausdrucksfaltung zur Auswertung deterministischer Funktionen und konstanter Ausdrücke kann BigQuery komplexe Prädikate in konstante Werte vereinfachen.

Optimierungen für kurze Abfragen

BigQuery führt Abfragen in der Regel in einer verteilten Umgebung mit einer Shuffle-Zwischenebene aus. Mit Optimierungen für kurze Abfragen werden dynamisch Abfragen identifiziert, die in einer einzigen Phase ausgeführt werden können, wodurch die Latenz und der Slotverbrauch reduziert werden. Spezielle Codierungen können effektiver verwendet werden, wenn eine Abfrage in einer einzigen Phase ausgeführt wird. Diese Optimierungen sind am effektivsten, wenn sie mit dem optionalen Modus zur Joberstellung, der die Latenz beim Jobstart, bei der Wartung und beim Abrufen von Ergebnissen minimiert, verwendet werden.

Die Berechtigung für Optimierungen für kurze Abfragen ist dynamisch und wird von den folgenden Faktoren beeinflusst:

• Die vorhergesagte Größe des Datenscans.
• Die Menge der erforderlichen Datenübertragung.
• Die Selektivität der Abfragefilter.
• Der Typ und das physische Layout der Daten im Speicher.
• Die allgemeine Abfragestruktur.
• Die Verlaufsstatistiken früherer Abfrageausführungen.

Auswirkungen der erweiterten Laufzeit schätzen

Um die Auswirkungen der erweiterten Laufzeit zu schätzen, können Sie mit der folgenden SQL-Abfrage Projektanfragen mit der größten geschätzten Verbesserung der Ausführungszeit ermitteln:

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)
      AND creation_time >= TIMESTAMP "2026-01-30"
  ),
  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;

Hinweis: Sie können nur Abfragen vergleichen, die am oder nach dem 30. Januar 2026 erstellt wurden. An diesem Datum wurden die Optimierungsindikatoren für die erweiterte Laufzeit (enhanced_vectorization und short_query_optimization) in der Ansicht INFORMATION_SCHEMA.JOBS konsistent verfügbar. Die vorherige Abfrage stellt dies sicher, indem sie den abgefragten Zeitraum einschränkt.

Ersetzen Sie Folgendes:

• LOCATION: der Standort, an dem die Jobleistung gemessen werden soll

Wenn die erweiterte Laufzeit angewendet wurde, können die Ergebnisse dieser Abfrage so aussehen:

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

Die Ergebnisse dieser Abfrage sind nur eine Schätzung der Auswirkungen der erweiterten Laufzeit. Viele Faktoren können die Abfrageleistung beeinflussen, darunter die Verfügbarkeit von Slots, Änderungen der Daten im Zeitverlauf, Definitionen von Ansichten oder UDFs und Unterschiede bei den Abfrageparameterwerten.

Wenn die Ergebnisse dieser Abfrage leer sind, haben entweder keine Jobs die erweiterte Laufzeit verwendet oder alle Jobs wurden vor mehr als 30 Tagen optimiert.

Diese Abfrage kann auf andere Messwerte zur Abfrageleistung wie total_slot_ms und total_bytes_billed angewendet werden. Weitere Informationen finden Sie im Schema für INFORMATION_SCHEMA.JOBS_BY_PROJECT.