Menggunakan runtime lanjutan BigQuery

Runtime lanjutan BigQuery adalah serangkaian peningkatan performa yang dirancang untuk mempercepat workload analisis secara otomatis tanpa memerlukan tindakan pengguna atau perubahan kode. Dokumen ini menjelaskan peningkatan performa ini, termasuk vektorisasi yang ditingkatkan dan pengoptimalan kueri pendek.

Peran dan izin

Untuk mendapatkan izin yang diperlukan guna menentukan setelan konfigurasi, minta administrator untuk memberi Anda peran IAM BigQuery Admin (roles/bigquery.admin) di project atau organisasi Anda. Untuk mengetahui informasi selengkapnya tentang cara memberikan peran, lihat Mengelola akses ke project, folder, dan organisasi.

Anda mungkin juga bisa mendapatkan izin yang diperlukan melalui peran khusus atau peran bawaan lainnya.

Vektorisasi yang ditingkatkan

Eksekusi vektor adalah model pemrosesan kueri yang beroperasi pada kolom data dalam blok yang selaras dengan ukuran cache CPU dan menggunakan satu instruksi, beberapa instruksi data (SIMD). Vektorisasi yang ditingkatkan memperluas eksekusi kueri vektor di BigQuery ke aspek pemrosesan kueri berikut:

  • Dengan memanfaatkan encoding data khusus dalam format penyimpanan Capacitor, operasi evaluasi filter dapat dijalankan pada data yang dienkode.
  • Encoding khusus disebarkan melalui rencana kueri, yang memungkinkan lebih banyak data diproses saat masih dienkode.
  • Dengan menerapkan pelipatan ekspresi untuk mengevaluasi fungsi deterministik dan ekspresi konstanta, BigQuery dapat menyederhanakan predikat kompleks menjadi nilai konstanta.

Pengoptimalan kueri pendek

BigQuery biasanya menjalankan kueri di lingkungan terdistribusi menggunakan lapisan perantara shuffle. Pengoptimalan kueri pendek secara dinamis mengidentifikasi kueri yang dapat dijalankan sebagai satu tahap, sehingga mengurangi latensi dan konsumsi slot. Encoding khusus dapat digunakan secara lebih efektif saat kueri dijalankan dalam satu tahap. Pengoptimalan ini paling efektif jika digunakan dengan mode pembuatan tugas opsional, yang meminimalkan latensi startup, pemeliharaan, dan pengambilan hasil tugas.

Kelayakan untuk pengoptimalan kueri pendek bersifat dinamis dan dipengaruhi oleh faktor-faktor berikut:

  • Perkiraan ukuran pemindaian data.
  • Jumlah pergerakan data yang diperlukan.
  • Selektivitas filter kueri.
  • Jenis dan tata letak fisik data dalam penyimpanan.
  • Struktur kueri secara keseluruhan.
  • Statistik historis eksekusi kueri sebelumnya.

Memperkirakan dampak runtime lanjutan

Untuk memperkirakan dampak runtime lanjutan, Anda dapat menggunakan kueri SQL berikut untuk mengidentifikasi kueri project dengan perkiraan peningkatan terbesar pada waktu eksekusi:

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;

Ganti kode berikut:

  • LOCATION: lokasi tempat performa tugas harus diukur

Jika runtime lanjutan diterapkan, hasil kueri ini mungkin mirip dengan hasil berikut:

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

Hasil kueri ini hanya perkiraan dampak runtime lanjutan. Banyak faktor yang dapat memengaruhi performa kueri, termasuk, tetapi tidak terbatas pada ketersediaan slot, perubahan data dari waktu ke waktu, definisi tampilan atau UDF, dan perbedaan nilai parameter kueri.

Jika hasil kueri ini kosong, berarti tidak ada tugas yang menggunakan runtime lanjutan, atau semua tugas dioptimalkan lebih dari 30 hari yang lalu.

Kueri ini dapat diterapkan ke metrik performa kueri lainnya seperti total_slot_ms dan total_bytes_billed. Untuk mengetahui informasi selengkapnya, lihat skema untuk INFORMATION_SCHEMA.JOBS_BY_PROJECT.