שימוש בסביבת זמן הריצה המתקדמת של BigQuery

זמן הריצה המתקדם של BigQuery הוא אוסף של שיפורים בביצועים שנועדו להאיץ באופן אוטומטי עומסי עבודה אנליטיים, בלי שמשתמשים יצטרכו לבצע פעולות או לשנות קוד. במסמך הזה מתוארים שיפורים בביצועים, כולל וקטוריזציה משופרת ואופטימיזציות של שאילתות קצרות.

תפקידים והרשאות

כדי לקבל את ההרשאות שנדרשות לציון הגדרת תצורה, צריך לבקש מהאדמין להקצות לכם ב-IAM את התפקיד אדמין של BigQuery (roles/bigquery.admin) בפרויקט או בארגון. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.

וקטוריזציה משופרת

ביצוע וקטורי הוא מודל לעיבוד שאילתות שפועל על עמודות של נתונים בבלוקים שתואמים לגודל המטמון של המעבד, ומשתמש בהוראות SIMD (הוראה יחידה, נתונים מרובים). התכונה 'וקטוריזציה משופרת' מרחיבה את הביצוע הווקטורי של שאילתות ב-BigQuery להיבטים הבאים של עיבוד שאילתות:

• באמצעות קידודים מיוחדים של נתונים בפורמט האחסון של Capacitor, אפשר לבצע פעולות של הערכת מסננים על הנתונים המקודדים.
• קידודים מיוחדים מועברים דרך תוכנית השאילתה, מה שמאפשר לעבד יותר נתונים בזמן שהם עדיין מקודדים.
• באמצעות הטמעה של קיפול ביטויים להערכת פונקציות דטרמיניסטיות וביטויים קבועים, BigQuery יכול לפשט פרדיקטים מורכבים לערכים קבועים.

אופטימיזציות של שאילתות קצרות

בדרך כלל, BigQuery מריץ שאילתות בסביבה מבוזרת באמצעות שכבת ביניים של ערבוב. אופטימיזציות של שאילתות קצרות מזהות באופן דינמי שאילתות שאפשר להריץ בשלב אחד, וכך מקטינות את זמן האחזור ואת צריכת המשבצות. אפשר להשתמש בקידודים מיוחדים בצורה יעילה יותר כשמריצים שאילתה בשלב אחד. האופטימיזציות האלה יעילות במיוחד כשמשתמשים בהן עם מצב יצירה אופציונלית של משימות, שממזער את זמן האחזור של הפעלת המשימה, התחזוקה ואחזור התוצאות.

הזכאות לאופטימיזציות של שאילתות קצרות היא דינמית ומושפעת מהגורמים הבאים:

• הגודל הצפוי של סריקת הנתונים.
• כמות הנתונים שצריך להעביר.
• הסלקטיביות של מסנני השאילתה.
• הסוג והפריסה הפיזית של הנתונים באחסון.
• המבנה הכולל של השאילתה.
• הנתונים הסטטיסטיים ההיסטוריים של הרצות קודמות של שאילתות.

הערכת ההשפעה של זמן הריצה המתקדם

כדי להעריך את ההשפעה של זמן הריצה המתקדם, אפשר להשתמש בשאילתת ה-SQL הבאה כדי לזהות שאילתות של פרויקטים עם השיפור המשוער הגדול ביותר בזמן הביצוע:

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;

הערה: אפשר להשוות רק בין שאילתות שנוצרו ב-30 בינואר 2026 או אחרי התאריך הזה. זה התאריך שבו התחילו להופיע באופן עקבי בINFORMATION_SCHEMA.JOBS התצוגה המקדימה המדדים המתקדמים של אופטימיזציה בזמן ריצה (enhanced_vectorization ו-short_query_optimization). השאילתה הקודמת מבטיחה זאת על ידי הגבלת טווח הזמן של השאילתה.

מחליפים את מה שכתוב בשדות הבאים:

• ‫LOCATION: המיקום שבו צריך למדוד את ביצועי המשימה

אם הוחל זמן ריצה מתקדם, התוצאות של השאילתה הזו עשויות להיות דומות לתוצאות הבאות:

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

התוצאות של השאילתה הזו הן רק אומדן של ההשפעה של זמן הריצה המתקדם. יש הרבה גורמים שיכולים להשפיע על הביצועים של שאילתות, כולל, בין היתר, זמינות של משבצות, שינויים בנתונים לאורך זמן, הגדרות של תצוגות או של פונקציות מוגדרות על ידי המשתמש (UDF), והבדלים בערכים של פרמטרים של שאילתות.

אם התוצאות של השאילתה הזו ריקות, זה אומר שאף עבודה לא השתמשה בסביבת ריצה מתקדמת, או שכל העבודות עברו אופטימיזציה לפני יותר מ-30 ימים.

אפשר להחיל את השאילתה הזו על מדדי ביצועים אחרים של שאילתות, כמו total_slot_ms ו-total_bytes_billed. מידע נוסף זמין בסכימה של INFORMATION_SCHEMA.JOBS_BY_PROJECT.