שימוש בסביבת זמן הריצה המתקדמת של BigQuery
זמן הריצה המתקדם של BigQuery הוא אוסף של שיפורים בביצועים שנועדו להאיץ באופן אוטומטי עומסי עבודה אנליטיים, בלי שמשתמשים יצטרכו לבצע פעולות או לשנות קוד. במסמך הזה מתוארים שיפורים בביצועים, כולל וקטוריזציה משופרת ואופטימיזציות של שאילתות קצרות.
תפקידים והרשאות
כדי לקבל את ההרשאות שנדרשות לציון הגדרת תצורה, צריך לבקש מהאדמין להקצות לכם ב-IAM את התפקיד BigQuery Admin (roles/bigquery.admin) בפרויקט או בארגון.
להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.
יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.
וקטוריזציה משופרת
ביצוע וקטורי הוא מודל לעיבוד שאילתות שפועל על עמודות של נתונים בבלוקים שתואמים לגודל המטמון של המעבד, ומשתמש בהוראות SIMD (הוראה יחידה, נתונים מרובים). התכונה 'וקטוריזציה משופרת' מרחיבה את הביצוע הווקטורי של שאילתות ב-BigQuery להיבטים הבאים של עיבוד שאילתות:
- באמצעות קידודים מיוחדים של נתונים בפורמט האחסון של Capacitor, אפשר לבצע פעולות של הערכת מסננים על הנתונים המקודדים.
- קידודים מיוחדים מועברים דרך תוכנית השאילתה, מה שמאפשר לעבד יותר נתונים בזמן שהם עדיין מקודדים.
- באמצעות הטמעה של קיפול ביטויים להערכת פונקציות דטרמיניסטיות וביטויים קבועים, BigQuery יכול לפשט פרדיקטים מורכבים לערכים קבועים.
אופטימיזציות של שאילתות קצרות
בדרך כלל, BigQuery מריץ שאילתות בסביבה מבוזרת באמצעות שכבת ביניים של ערבוב. אופטימיזציות של שאילתות קצרות מזהות באופן דינמי שאילתות שאפשר להריץ בשלב אחד, וכך מקטינות את זמן האחזור ואת צריכת המשבצות. אפשר להשתמש בקידודים מיוחדים בצורה יעילה יותר כשמריצים שאילתה בשלב אחד. האופטימיזציות האלה יעילות במיוחד כשמשתמשים בהן עם מצב יצירה אופציונלית של משימות, שממזער את זמן האחזור של הפעלת המשימה, התחזוקה ואחזור התוצאות.
הזכאות לאופטימיזציות של שאילתות קצרות היא דינמית ומושפעת מהגורמים הבאים:
- הגודל הצפוי של סריקת הנתונים.
- כמות הנתונים שנדרשת להעברה.
- הסלקטיביות של מסנני השאילתה.
- הסוג והפריסה הפיזית של הנתונים באחסון.
- המבנה הכללי של השאילתה.
- הנתונים הסטטיסטיים ההיסטוריים של הרצות קודמות של שאילתות.
הפעלת זמן הריצה המתקדם
בין 15 בספטמבר 2025 לתחילת 2026, מערכת BigQuery תתחיל להשתמש בזמן הריצה המתקדם כזמן הריצה שמוגדר כברירת מחדל לכל הפרויקטים החדשים והקיימים. במהלך תקופת המעבר הזו, יכול להיות שחלק מהמשימות שמופעלות בפרויקטים שלכם יפעלו באזורים שעדיין לא משתמשים בסביבת ההרצה המתקדמת כברירת מחדל.
כדי להפעיל את זמן הריצה המתקדם בפרויקט או בארגון קיימים, משתמשים בהצהרה ALTER PROJECT או ALTER ORGANIZATION כדי לשנות את הגדרת ברירת המחדל. במשפט, מגדירים את הארגומנט query_runtime לערך 'advanced'. לדוגמה:
ALTER PROJECTPROJECT_NAMESET OPTIONS ( `region-LOCATION.query_runtime` = 'advanced' );
מחליפים את מה שכתוב בשדות הבאים:
-
PROJECT_NAME: שם הפרויקט -
LOCATION: המיקום שבו המשימות ינסו להשתמש בסביבת זמן הריצה המתקדמת
יכול להיות שיחלפו כמה דקות עד שהשינוי ייכנס לתוקף.
אחרי שמפעילים את זמן הריצה המתקדם, שאילתות שעומדות בדרישות בפרויקט או בארגון משתמשות בזמן הריצה המתקדם, בלי קשר למשתמש שיצר את משימת השאילתה.
הערכת ההשפעה של זמן הריצה המתקדם
כדי להעריך את ההשפעה של זמן הריצה המתקדם, אפשר להשתמש בשאילתת ה-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)
),
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;
מחליפים את מה שכתוב בשדות הבאים:
-
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.