Erweiterte BigQuery-Laufzeit verwenden

Die erweiterte BigQuery-Laufzeit umfasst eine Reihe von Leistungsverbesserungen, die darauf ausgelegt sind, Analysearbeitslasten automatisch zu beschleunigen, ohne dass Nutzeraktionen oder Codeänderungen erforderlich sind. In diesem Dokument werden diese Leistungsverbesserungen beschrieben, darunter die verbesserte Vektorisierung und Optimierungen für kurze Anfragen.

Rollen und Berechtigungen

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle BigQuery-Administrator (roles/bigquery.admin) für Ihr Projekt oder Ihre Organisation zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Angeben 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.

Verbesserte Vektorisierung

Die vektorisierte Ausführung ist ein Modell zur Verarbeitung von Abfragen, bei dem Spalten von Daten in Blöcken verarbeitet werden, die mit der CPU-Cachegröße übereinstimmen. Außerdem werden SIMD-Befehle (Single Instruction, Multiple Data) verwendet. Die erweiterte Vektorisierung erweitert die vektorisierte Abfrageausführung in BigQuery auf die folgenden Aspekte der Abfrageverarbeitung:

  • Durch die Verwendung spezieller Datenkodierungen im Capacitor-Speicherformat können Filterauswertungsvorgänge für die codierten Daten ausgeführt werden.
  • Spezialisierte Codierungen werden im Abfrageplan weitergegeben, sodass mehr Daten verarbeitet werden können, während sie noch codiert sind.
  • Durch die Implementierung von Expression Folding zum Auswerten 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-Zwischenschicht aus. Bei der Optimierung kurzer Abfragen werden dynamisch Abfragen identifiziert, die als einzelne Phase ausgeführt werden können. Dadurch werden Latenz und Slot-Verbrauch reduziert. Spezialisierte 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 für die Job-Erstellung verwendet werden, der die Latenz beim Starten, Warten und Abrufen von Ergebnissen minimiert.

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

  • Die geschätzte Größe des Daten-Scans.
  • Die erforderliche Datenverschiebung.
  • Die Selektivität von Abfragefiltern.
  • Der Typ und das physische Layout der Daten im Speicher.
  • Die allgemeine Abfragestruktur.
  • Die Verlaufsstatistiken der bisherigen Abfrageausführungen.

Erweiterte Laufzeit aktivieren

Zwischen dem 15. September 2025 und Anfang 2026 wird die erweiterte Laufzeit zur Standardlaufzeit für alle Projekte in BigQuery. Wenn Sie die erweiterte Laufzeit jetzt in einem vorhandenen Projekt oder einer vorhandenen Organisation aktivieren möchten, verwenden Sie die Anweisung ALTER PROJECT oder ALTER ORGANIZATION, um die Standardkonfiguration zu ändern. Legen Sie in der Anweisung das Argument query_runtime auf 'advanced' fest. Beispiel:

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

Ersetzen Sie Folgendes:

  • PROJECT_NAME ist der Name des Projekts.
  • LOCATION: der Ort, an dem Jobs versuchen sollen, die erweiterte Laufzeit zu verwenden

Es kann einige Minuten dauern, bis die Änderung wirksam wird.

Nachdem Sie die erweiterte Laufzeit aktiviert haben, verwenden entsprechende Abfragen im Projekt oder in der Organisation die erweiterte Laufzeit, unabhängig davon, welcher Nutzer den Abfragejob erstellt hat.

Auswirkungen der erweiterten Laufzeit schätzen

Um die Auswirkungen der erweiterten Laufzeit zu schätzen, können Sie die folgende SQL-Abfrage verwenden, um Projektanfragen mit der größten geschätzten Verbesserung der Ausführungszeit zu 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)
  ),
  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;

Ersetzen Sie Folgendes:

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

Wenn die erweiterte Laufzeit aktiviert und angewendet wurde, sehen die Ergebnisse dieser Abfrage möglicherweise so aus:

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