תצוגת JOBS

התצוגה INFORMATION_SCHEMA.JOBS מכילה מטא-נתונים כמעט בזמן אמת על כל המשימות ב-BigQuery בפרויקט הנוכחי.

הערה: שמות התצוגות INFORMATION_SCHEMA.JOBS ו-INFORMATION_SCHEMA.JOBS_BY_PROJECT הם שמות נרדפים ואפשר להשתמש בהם לסירוגין.

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות לשליחת שאילתות לתצוגה INFORMATION_SCHEMA.JOBS, בקשו מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:

• BigQuery User (roles/bigquery.user)
• צפייה במשאבים של BigQuery (roles/bigquery.resourceViewer)

להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

התפקידים המוגדרים מראש האלה כוללים את ההרשאות שנדרשות כדי לשלוח שאילתות לתצוגה INFORMATION_SCHEMA.JOBS. כדי לראות בדיוק אילו הרשאות נדרשות, אפשר להרחיב את הקטע ההרשאות הנדרשות:

ההרשאות הנדרשות

כדי לשלוח שאילתות לתצוגה INFORMATION_SCHEMA.JOBS, נדרשות ההרשאות הבאות:

• bigquery.jobs.listAll
• bigquery.jobs.create

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

במאמר בקרת גישה באמצעות IAM יש מידע נוסף על הרשאות ב-BigQuery.

סכימה

הנתונים הבסיסיים מחולקים למחיצות לפי העמודה creation_time ומקובצים לפי project_id ו-user_email. העמודה query_info מכילה מידע נוסף על משימות השאילתה.

הסכימה של התצוגה INFORMATION_SCHEMA.JOBS היא:

שם העמודה	סוג הנתונים	ערך
bi_engine_statistics	RECORD	אם הפרויקט מוגדר לשימוש ב-BI Engine, השדה הזה מכיל את BiEngineStatistics. אחרת NULL.
cache_hit	BOOLEAN	אם תוצאות השאילתה של המשימה הזו הגיעו מהמטמון. אם יש לכם משימה של הצהרה עם כמה שאילתות, הערך של cache_hit בשאילתת ההורה הוא NULL.
copy_job_statistics	RECORD	נתונים סטטיסטיים של משימת העתקה.
creation_time	TIMESTAMP	(עמודת חלוקה למחיצות) מועד היצירה של המשימה. החלוקה למחיצות מבוססת על זמן ה-UTC של חותמת הזמן הזו.
destination_table	RECORD	טבלת היעד לתוצאות, אם יש כאלה.
dml_statistics	RECORD	אם המשימה היא שאילתה עם פקודת DML, הערך הוא רשומה עם השדות הבאים: ‫inserted_row_count: מספר השורות שנוספו. ‫deleted_row_count: מספר השורות שנמחקו. ‫updated_row_count: מספר השורות שעודכנו. בכל שאר המשימות, הערך הוא NULL. העמודה הזו מופיעה בתצוגות INFORMATION_SCHEMA.JOBS_BY_USER ו-INFORMATION_SCHEMA.JOBS_BY_PROJECT.
end_time	TIMESTAMP	שעת הסיום של המשימה, באלפיות השנייה מאז ראשית זמן יוניקס (Unix epoch). השדה הזה מייצג את הזמן שבו המשימה נכנסת למצב DONE.
error_result	RECORD	פרטים על שגיאות כאובייקטים של ErrorProto.
global_query_info	RECORD	מידע על שאילתה עם אחזור נתונים גלובלי. מכיל את השדות הבאים: ‫parent_job_id: המזהה של משימת ההורה של השאילתה עם אחזור נתונים גלובלי באזור הראשי. ‫parent_job_location: המיקום של משימת ההורה של השאילתה עם אחזור נתונים גלובלי. ‫remote_regions: מערך של אזורים מרוחקים שהשאילתה עם אחזור הנתונים הגלובלי מפנה אליהם.
job_creation_reason.code	STRING	מציין את הסיבה הכללית ליצירת המשימה. הערכים האפשריים הם: ‫REQUESTED: נשלחה בקשה ליצירת משימה. ‫LONG_RUNNING: בקשת השאילתה חרגה מזמן הקצוב לתפוגה שמוגדר במערכת, שצוין בשדה timeoutMs ב-QueryRequest. לכן היא נחשבה לפעולה ממושכת שנוצרה בשבילה משימה. ‫LARGE_RESULTS: התוצאות מהשאילתה לא נכנסות בתשובה בשורה. ‫OTHER: המערכת קבעה שצריך להריץ את השאילתה כמשימה.
job_id	STRING	המזהה של המשימה, אם נוצרה משימה. אחרת, מזהה השאילתה של שאילתה שמשתמשת במצב יצירה אופציונלית של משימות. לדוגמה, bquxjob_1234.
job_stages	RECORD REPEATED	שלבי השאילתה של המשימה. הערה: הערכים בעמודה הזו ריקים בשאילתות שקוראות מטבלאות עם כללי מדיניות גישה ברמת השורה. מידע נוסף זמין במאמר שיטות מומלצות לאבטחה ברמת השורה ב-BigQuery.
job_type	STRING	סוג המשימה. הערכים האפשריים: QUERY, ‏LOAD, ‏EXTRACT, ‏COPY או NULL. הערך NULL מציין משימה ברקע.
labels	RECORD	מערך של תוויות שנוספו למשימה כצמדי מפתח/ערך.
object_storage_stats	RECORD REPEATED	נתונים סטטיסטיים על השימוש במאגר אובייקטים ובמטמון של משימת שאילתה. הערך הוא רשומה חוזרת עם השדות הבאים: ‫cloud_provider: ספק שירותי הענן שבו מאוחסן מאגר האובייקטים (לדוגמה, AWS). ‫object_storage_bytes_read: המספר הכולל של הבייטים שנקראו ישירות ממאגר האובייקטים. ‫cache_bytes_read: המספר הכולל של הבייטים שנקראו מהמטמון.
parent_job_id	STRING	המזהה של המשימה הראשית, אם יש כזו.
priority	STRING	העדיפות של המשימה הזו. הערכים התקינים כוללים את INTERACTIVE ו-BATCH.
project_id	STRING	(עמודת אשכול) מזהה הפרויקט.
project_number	INTEGER	מספר הפרויקט.
query	STRING	טקסט של שאילתת SQL.
referenced_tables	RECORD	מערך של ערכי STRUCT שמכילים את השדות הבאים של STRING לכל טבלה שהשאילתה מפנה אליה: project_id,‏ dataset_id ו-table_id. השדה הזה מאוכלס רק במשימות של שאילתות שלא נמצאו במטמון.
referenced_logical_views	RECORD	מערך של ערכי STRUCT שמכילים את השדות הבאים של STRING לכל תצוגה לוגית שהשאילתה מפנה אליה: project_id,‏ dataset_id ו-table_id. השדה הזה מאוכלס רק במשימות שאילתה שהן לא מציאות במטמון (cache hit).
reservation_id	STRING	שם ההקצאה הראשית שהוקצתה למשימה הזו, בפורמט RESERVATION_ADMIN_PROJECT:RESERVATION_LOCATION.RESERVATION_NAME. בפלט הזה: ‫RESERVATION_ADMIN_PROJECT: השם של הפרויקט בענן של Google שמנהל את ההזמנה ‫RESERVATION_LOCATION: המיקום של ההזמנה ‫RESERVATION_NAME: שם ההזמנה
reservation_group_path	ARRAY<STRING>	קבוצת ההזמנות שאליה מקושרת ההזמנה. לדוגמה, אם ההזמנה מקושרת לקבוצה my-group, השדה reservation_group_path מכיל רשימה כמו: [my-group].
edition	STRING	המהדורה שמשויכת להזמנה שהוקצתה למשימה הזו. מידע נוסף על המהדורות זמין במאמר מבוא למהדורות של BigQuery.
session_info	RECORD	פרטים על הסשן שבו המשימה הזו הופעלה, אם יש כאלה.
start_time	TIMESTAMP	שעת ההתחלה של המשימה, באלפיות השנייה מאז ראשית זמן יוניקס (Unix epoch). השדה הזה מייצג את הזמן שבו המשימה עוברת מהמצב PENDING למצב RUNNING או DONE.
state	STRING	מצב ההפעלה של המשימה. הסטטוסים התקינים הם PENDING,‏ RUNNING ו-DONE.
statement_type	STRING	סוג הצהרת השאילתה. לדוגמה, DELETE, INSERT, SCRIPT, SELECT או UPDATE. רשימה של ערכים תקינים מופיעה ב-QueryStatementType.
timeline	RECORD	ציר הזמן של השאילתה של המשימה. מכיל תמונות מצב של הפעלת השאילתה.
total_bytes_billed	INTEGER	אם הפרויקט מוגדר לשימוש בתמחור על פי דרישה, השדה הזה מכיל את סך כל הבייטים שחויבו עבור המשימה. אם הפרויקט מוגדר לשימוש בתמחור קבוע, לא תחויבו על בייטים והשדה הזה מיועד למטרות מידע בלבד. הערה: הערכים בעמודה הזו ריקים בשאילתות שקוראות מטבלאות עם כללי מדיניות גישה ברמת השורה. מידע נוסף זמין במאמר שיטות מומלצות לאבטחה ברמת השורה ב-BigQuery.
total_bytes_processed	INTEGER	מספר הבייטים הכולל שעובדו על ידי המשימה. הערה: הערכים בעמודה הזו ריקים בשאילתות שקוראות מטבלאות עם כללי מדיניות גישה ברמת השורה. מידע נוסף זמין במאמר שיטות מומלצות לאבטחה ברמת השורה ב-BigQuery.
total_modified_partitions	INTEGER	המספר הכולל של המחיצות שהמשימה שינתה. השדה הזה מאוכלס במשימות LOAD ו-QUERY.
total_slot_ms	INTEGER	מספר אלפיות השנייה של המשבצת שהוקצו למשימה במשך כל הזמן שהיא הייתה במצב RUNNING, כולל ניסיונות חוזרים.
total_services_sku_slot_ms	INTEGER	המספר הכולל של אלפיות השנייה של ה-slot למשימה שפועלת בשירותים חיצוניים ומחויבת במק"ט של השירותים. השדה הזה מאוכלס רק במשימות שיש להן עלויות של שירותים חיצוניים, והוא מייצג את סך כל השימוש בעלויות שאמצעי החיוב שלהן הוא "SERVICES_SKU".
transaction_id	STRING	המזהה של הטרנזקציה שבה המשימה הזו הופעלה, אם יש כזו.
user_email	STRING	(עמודת אשכול) כתובת האימייל או חשבון השירות של המשתמש שהריץ את המשימה.
principal_subject	STRING	ייצוג מחרוזת של זהות חשבון המשתמש שהפעיל את המשימה.
query_info.resource_warning	STRING	הודעת האזהרה שמופיעה אם השימוש במשאבים במהלך עיבוד השאילתה חורג מהסף הפנימי של המערכת. אם משימת השאילתה בוצעה בהצלחה, השדה resource_warning יכול להיות מאוכלס. בעזרת resource_warning, אתם מקבלים נקודות נוספות על הגרף כדי לבצע אופטימיזציה של השאילתות ולהגדיר מעקב אחרי מגמות בביצועים של קבוצת שאילתות מקבילה באמצעות query_hashes.
query_info.query_hashes.normalized_literals	STRING	מכיל את ערך ה-hash של השאילתה. ‫normalized_literals הוא גיבוב (hash) הקסדצימלי של STRING שמתעלם מהערות, מערכי פרמטרים, מפונקציות בהגדרת משתמש (UDF) ומליטרלים. ערך ה-hash יהיה שונה כשהתצוגות הבסיסיות ישתנו, או אם השאילתה מפנה באופן משתמע לעמודות, כמו SELECT *, וסכימת הטבלה משתנה. השדה הזה מופיע בשאילתות GoogleSQL שהסתיימו בהצלחה ולא נמצאו במטמון.
query_info.performance_insights	RECORD	תובנות לגבי הביצועים של המשרה.
query_info.optimization_details	STRUCT	האופטימיזציות מבוססות-ההיסטוריה של המשימה. העמודה הזו קיימת רק בתצוגה JOBS_BY_PROJECT.
transferred_bytes	INTEGER	סה"כ הבייטים שהועברו בשאילתות של BigQuery Omni, כמו משימות העברה של BigQuery Omni.
materialized_view_statistics	RECORD	נתונים סטטיסטיים של תצוגות מהותיות שנכללו במשימת שאילתה. (גרסת טרום-השקה (Preview))
metadata_cache_statistics	RECORD	נתונים סטטיסטיים על השימוש באינדקס של עמודות המטא-נתונים בטבלאות שאליהן מפנה משימת שאילתה.
search_statistics	RECORD	נתונים סטטיסטיים של שאילתת חיפוש.
query_dialect	STRING	השדה הזה יהיה זמין במהלך מאי 2025. הניב של השאילתה ששימש למשימה. הערכים התקינים כוללים: ‫GOOGLE_SQL: התקבלה בקשה להשתמש ב-GoogleSQL במשימה. ‫LEGACY_SQL: התקבלה בקשה להשתמש ב-LegacySQL במשימה. ‫DEFAULT_LEGACY_SQL: לא צוין ניב של שאילתה בבקשת המשימה. ‫BigQuery השתמש בערך ברירת המחדל של LegacySQL. ‫DEFAULT_GOOGLE_SQL: לא צוין ניב של שאילתה בבקשת המשימה. ב-BigQuery נעשה שימוש בערך ברירת המחדל של GoogleSQL. במשימות שנשלחו על ידי משתמשים, השדה הזה מאוכלס רק במשימות של שאילתות. אפשר לשלוט בבחירת ברירת המחדל של ניב השאילתה באמצעות הגדרות התצורה. במשימות ברקע, הערך של השדה הזה לא נשלט על ידי הגדרות ברירת המחדל של ניב השאילתה, ולא משפיע על משימות שנשלחות על ידי משתמשים. בחלק מהמשימות ברקע, הערך מושמט.
continuous	BOOLEAN	אם המשימה היא שאילתה מתמשכת.
continuous_query_info.output_watermark	TIMESTAMP	מייצג את הנקודה שעד אליה השאילתה המתמשכת עיבדה נתונים בהצלחה.
vector_search_statistics	RECORD	נתונים סטטיסטיים של שאילתת חיפוש וקטורי.
external_service_costs	RECORD	מערך של מידע על עלויות השירות החיצוני של משימת שאילתה.
ml_statistics.model_type	STRING	אם המשימה היא שאילתה ליצירת מודל BigQuery ML, השדה הזה מציין את סוג המודל שנוצר. בכל שאר המשימות, הערך הוא NULL.

כששולחים שאילתה ל-INFORMATION_SCHEMA.JOBS כדי למצוא סיכום של עלות משימות השאילתה, צריך להחריג את סוג ההצהרה SCRIPT, אחרת יכול להיות שחלק מהערכים ייספרו פעמיים. השורה SCRIPT כוללת ערכי סיכום של כל המשימות הצאצא שבוצעו כחלק מהמשימה הזו.

כדי לשמור על יציבות, מומלץ לציין במפורש את העמודות בשאילתות של סכימת המידע במקום להשתמש בתו כללי לחיפוש (SELECT *). ציון מפורש של העמודות מונע את קריסת השאילתות אם הסכימה הבסיסית משתנה.

משימות של שאילתות עם כמה הצהרות

משימת שאילתה עם כמה הצהרות היא משימת שאילתה שמשתמשת בשפה פרוצדורלית. משימות של שאילתות עם כמה הצהרות בדרך כלל מגדירות משתנים באמצעות DECLARE או כוללות הצהרות של בקרת זרימה כמו IF או WHILE. כששולחים שאילתה ל-INFORMATION_SCHEMA.JOBS, יכול להיות שתצטרכו לזהות את ההבדל בין משימת שאילתה עם כמה הצהרות לבין משימות אחרות. למשימת שאילתה עם כמה הצהרות יש את המאפיינים הבאים:

• ‫statement_type = SCRIPT
• ‫reservation_id = NULL

משימות צאצא

לכל משימת צאצא של משימת שאילתה עם כמה הצהרות יש parent_job_id שמצביע על משימת השאילתה עם כמה ההצהרות עצמה. הוא כולל ערכי סיכום של כל המשימות הצאצא שבוצעו כחלק מהמשימה הזו.

אם אתם שולחים שאילתה ל-INFORMATION_SCHEMA.JOBS כדי למצוא סיכום של עלויות משימות השאילתה, אתם צריכים להחריג את סוג ההצהרה SCRIPT. אחרת, יכול להיות שערכים מסוימים, כמו total_slot_ms, ייספרו פעמיים.

שמירת נתונים

בתצוגה הזו מופיעות משימות שפועלות, וגם היסטוריית המשימות מ-180 הימים האחרונים. אם פרויקט מועבר לארגון (ממצב שבו לא היה לו ארגון או מארגון אחר), אי אפשר לגשת למידע על משימות שנוצרו לפני תאריך ההעברה דרך התצוגה INFORMATION_SCHEMA.JOBS, כי בתצוגה נשמרים רק נתונים שנוצרו החל מתאריך ההעברה.

היקף ותחביר

שאילתות בתצוגה הזו חייבות לכלול מזהה אזור. בטבלה הבאה מוסבר היקף האזור של התצוגה הזו:

שם התצוגה המפורטת	היקף המשאבים	היקף האזור
[PROJECT_ID.]`region-REGION`.INFORMATION_SCHEMA.JOBS[_BY_PROJECT]	רמת הפרויקט	REGION

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

• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud (אופציונלי). אם לא מציינים פרויקט, המערכת משתמשת בפרויקט שמוגדר כברירת מחדל.
• ‫REGION: כל שם של אזור של מערך נתונים. לדוגמה, `region-us`.
  הערה: כדי לשלוח שאילתה לתצוגות של INFORMATION_SCHEMA, צריך להשתמש במזהה אזור. המיקום של הרצת השאילתה צריך להתאים לאזור של התצוגה INFORMATION_SCHEMA.

אומדני שאילתות של הרצה יבשה

כשמבצעים הרצה של שאילתה שמפנה לתצוגה INFORMATION_SCHEMA.JOBS, מספר הבייטים המשוערים שעובדו עשוי להיות גבוה משמעותית ממספר הבייטים שעובדו בפועל במהלך ביצוע השאילתה.

ההערכה המוגזמת הזו מתרחשת כי החישוב של ההרצה היבשה מביא בחשבון רק מסננים בעמודת החלוקה למחיצות creation_time של הנתונים הבסיסיים. הוא לא מביא בחשבון מסננים בעמודות אשכולות, כמו המסנן המשתמע project_id או המסנן user_email, אם הם צוינו במשפט WHERE. הנתונים שנסרקים בפועל יכולים להיות נמוכים משמעותית מהאומדן של ההרצה היבשה, במיוחד בפרויקטים או למשתמשים עם פחות משימות.

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

דוגמאות

כדי להריץ את השאילתה בפרויקט אחר, שהוא לא פרויקט ברירת המחדל, מוסיפים את מזהה הפרויקט בפורמט הבא:

`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS

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

• ‫PROJECT_ID: מזהה הפרויקט
• ‫REGION_NAME: האזור של הפרויקט.

לדוגמה, `myproject`.`region-us-central1`.INFORMATION_SCHEMA.JOBS.

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

חיוב ותמחור

בדוגמאות הבאות מוסבר איך להעריך עלויות, לעקוב אחרי בייטים שחויבו ולזהות שאילתות יקרות.

בייטים שעובדו לכל זהות משתמש

בדוגמה הבאה מוצג סך הבייטים שחויבו עבור משימות שאילתה לכל משתמש:

SELECT
  user_email,
  SUM(total_bytes_billed) AS bytes_billed
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
  job_type = 'QUERY'
  AND statement_type != 'SCRIPT'
GROUP BY
  user_email;

הערה: הערכים בעמודה הזו ריקים בשאילתות שקוראות מטבלאות עם כללי מדיניות גישה ברמת השורה. מידע נוסף זמין במאמר שיטות מומלצות לאבטחה ברמת השורה ב-BigQuery.

התוצאה אמורה להיראות כך:

+---------------------+--------------+
| user_email          | bytes_billed |
+---------------------+--------------+
| [e-mail]     | 2847932416   |
| [e-mail]   | 1184890880   |
| [e-mail] | 10485760     |
+---------------------+--------------+

פירוט לפי שעה של הבייטים שעובדו

בדוגמה הבאה מוצג סך הבייטים שחויבו עבור משימות שאילתה, במרווחים של שעה:

SELECT
  TIMESTAMP_TRUNC(end_time, HOUR) AS time_window,
  SUM(total_bytes_billed) AS bytes_billed
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
  job_type = 'QUERY'
  AND statement_type != 'SCRIPT'
GROUP BY
  time_window
ORDER BY
  time_window DESC;

התוצאה אמורה להיראות כך:

+-------------------------+--------------+
| time_window             | bytes_billed |
+-------------------------+--------------+
| 2022-05-17 20:00:00 UTC | 1967128576   |
| 2022-05-10 21:00:00 UTC | 0            |
| 2022-04-15 17:00:00 UTC | 41943040     |
+-------------------------+--------------+

השאילתות הכי יקרות לפי פרויקט

בדוגמה הבאה מוצגת רשימה של השאילתות היקרות ביותר ב-my_project לפי זמן השימוש ב-slot:

SELECT
 job_id,
 query,
 user_email,
 total_slot_ms
FROM `my_project`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE EXTRACT(DATE FROM  creation_time) = current_date()
ORDER BY total_slot_ms DESC
LIMIT 3

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

SELECT
 job_id,
 query,
 user_email,
 total_bytes_processed
FROM `my_project`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE EXTRACT(DATE FROM  creation_time) = current_date()
ORDER BY total_bytes_processed DESC
LIMIT 3

התוצאה של כל אחת מהדוגמאות דומה לתוצאה הבאה:

+-----------+---------------------------------+-----------------------+---------------+
| job_id    | query                           | user_email            | total_slot_ms |
+-----------+---------------------------------+-----------------------+---------------+
| bquxjob_1 | SELECT ... FROM dataset.table1  | [e-mail]       | 80,000        |
| bquxjob_2 | SELECT ... FROM dataset.table2  | [e-mail]     | 78,000        |
| bquxjob_3 | SELECT ... FROM dataset.table3  | [e-mail]   | 75,000        |
+-----------+---------------------------------+-----------------------+---------------+

הערכת השימוש ב-slots והעלות של שאילתות

בדוגמה הבאה, המערכת מחשבת את הממוצע והמקסימום של המשבצות לכל משימה באמצעות ערכי estimated_runnable_units.

אם אין לכם הזמנות, הערך של reservation_id הוא NULL.

SELECT
  project_id,
  job_id,
  reservation_id,
  EXTRACT(DATE FROM creation_time) AS creation_date,
  TIMESTAMP_DIFF(end_time, start_time, SECOND) AS job_duration_seconds,
  job_type,
  user_email,
  total_bytes_billed,

  -- Average slot utilization per job is calculated by dividing total_slot_ms by the millisecond duration of the job

  SAFE_DIVIDE(job.total_slot_ms,(TIMESTAMP_DIFF(job.end_time, job.start_time, MILLISECOND))) AS job_avg_slots,
  query,

  -- Determine the max number of slots used at ANY stage in the query.
  -- The average slots might be 55. But a single stage might spike to 2000 slots.
  -- This is important to know when estimating number of slots to purchase.

  MAX(SAFE_DIVIDE(unnest_job_stages.slot_ms,unnest_job_stages.end_ms - unnest_job_stages.start_ms)) AS jobstage_max_slots,

  -- Check if there's a job that requests more units of works (slots). If so, you need more slots.
  -- Estimated_runnable_units = Units of work that can be scheduled immediately.
  -- Providing additional slots for these units of work accelerates the query.
  -- If no other query in the reservation needs additional slots.

  MAX(unnest_timeline.estimated_runnable_units) AS estimated_runnable_units
FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS AS job
  CROSS JOIN UNNEST(job_stages) as unnest_job_stages
  CROSS JOIN UNNEST(timeline) AS unnest_timeline
WHERE
  DATE(creation_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) AND CURRENT_DATE()
  AND project_id = 'my_project'
  AND (statement_type != 'SCRIPT' OR statement_type IS NULL)
GROUP BY 1,2,3,4,5,6,7,8,9,10
ORDER BY job_id;

התוצאה אמורה להיראות כך:

+-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+
|project_id | job_id    | reservation_id | creation_date | job_duration_seconds | job_type | user_email      | total_bytes_billed | job_avg_slots| query                          | jobstage_max_slots | estimated_runnable_units |
+-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+
| project1  | bquxjob1  | reservation1   | 2020-10-10    | 160                  | LOAD     | [e-mail] | 161480704          | 2890         | SELECT ... FROM dataset.table1 | 2779.1534          | 1000                     |
| project1  | bquxjob2  | reservation2   | 2020-12-10    | 120                  | LOAD     | [e-mail] | 161480704          | 2890         | SELECT ... FROM dataset.table1 | 2779.1534          | 1000                     |
| project1  | bquxjob3  | reservation1   | 2020-12-10    | 120                  | LOAD     | [e-mail] | 161480704          | 2890         | SELECT ... FROM dataset.table1 | 1279.1534          | 998                     |
+-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+

השוואה בין השימוש במשימות על פי דרישה לבין נתוני החיוב

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

בפרויקטים שבהם משתמשים בתמחור מבוסס-קיבולת (משבצות), אתם יכולים להשתמש בINFORMATION_SCHEMA.RESERVATIONS_TIMELINE כדי לבדוק את חיובי המחשוב בתקופה נתונה.

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

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

• ‫START_DATE: התאריך המוקדם ביותר לצבירה (כולל).
• ‫END_DATE: התאריך האחרון לצבירה (כולל).
• ‫PRICE_PER_TIB: המחיר על פי דרישה לכל TiB שמשמש להערכות החיוב.

CREATE TEMP FUNCTION isBillable(error_result ANY TYPE)
AS (
  -- You aren't charged for queries that return an error.
  error_result IS NULL
  -- However, canceling a running query might incur charges.
  OR error_result.reason = 'stopped'
);

-- BigQuery hides the number of bytes billed on all queries against tables with
-- row-level security.
CREATE TEMP FUNCTION isMaybeUsingRowLevelSecurity(
  job_type STRING, tib_billed FLOAT64, error_result ANY TYPE)
AS (
  job_type = 'QUERY'
  AND tib_billed IS NULL
  AND isBillable(error_result)
);

-- Built-in BigQuery ML models apply a 50x billing multiplier to
-- total_bytes_billed for on-demand CREATE_MODEL queries.
CREATE TEMP FUNCTION isNativeBqmlModel(model_type STRING)
AS (
  model_type IN (
    'LINEAR_REGRESSION',
    'LOGISTIC_REGRESSION',
    'KMEANS',
    'MATRIX_FACTORIZATION',
    'PCA',
    'ARIMA',
    'ARIMA_PLUS',
    'ARIMA_PLUS_XREG',
    'CONTRIBUTION_ANALYSIS',
    'TRANSFORM_ONLY')
);

WITH
  query_params AS (
    SELECT
      date 'START_DATE' AS start_date,  -- inclusive
      date 'END_DATE' AS end_date,  -- inclusive
  ),
  usage_with_multiplier AS (
    SELECT
      job_type,
      error_result,
      creation_time,
      -- Jobs are billed by end_time in PST8PDT timezone, regardless of where
      -- the job ran.
      EXTRACT(date FROM end_time AT TIME ZONE 'PST8PDT') billing_date,
      total_bytes_billed / 1024 / 1024 / 1024 / 1024
        * IF(
          statement_type = 'CREATE_MODEL'
            AND isNativeBqmlModel(ml_statistics.model_type),
          50,
          1) AS total_tib_billed,
      CASE statement_type
        WHEN 'SCRIPT' THEN 0
        ELSE PRICE_PER_TIB
        END AS multiplier,
    FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
    WHERE statement_type <> 'SCRIPT'
  )
SELECT
  billing_date,
  sum(total_tib_billed * multiplier) estimated_charge,
  sum(total_tib_billed) estimated_usage_in_tib,
  countif(isMaybeUsingRowLevelSecurity(job_type, total_tib_billed, error_result))
    AS jobs_using_row_level_security,
FROM usage_with_multiplier, query_params
WHERE
  1 = 1
  -- Filter by creation_time for partition pruning.
  AND date(creation_time) BETWEEN date_sub(start_date, INTERVAL 2 day) AND date_add(end_date, INTERVAL 1 day)
  AND billing_date BETWEEN start_date AND end_date
  AND isBillable(error_result)
GROUP BY billing_date
ORDER BY billing_date;

מגבלות

• ב-BigQuery מוסתרים חלק מהנתונים הסטטיסטיים של שאילתות בטבלאות עם אבטחה ברמת השורה. השאילתה שסופקה סופרת את מספר המשימות שהושפעו בתור jobs_using_row_level_security, אבל אין לה גישה לשימוש שניתן לחיוב.

• התמחור של שאילתות על פי דרישה ב-BigQuery ML תלוי בסוג המודל שנוצר. הפונקציה isNativeBqmlModel בשאילתה לדוגמה בודקת את ml_statistics.model_type ומפעילה את המכפיל פי 50 רק על מודלים מובנים. במודלים חיצוניים של Vertex AI, העלות של total_bytes_billed כבר כוללת את עלויות האימון החיצוניות שהומרו, בשיעור של פי 1.

• בפרוצדורות של Apache Spark משתמשים במודל תמחור דומה, אבל החיובים מדווחים כמק"ט של תשלום לפי שימוש במהדורת BigQuery Enterprise. ‫INFORMATION_SCHEMA.JOBS עוקב אחרי השימוש הזה בתור total_bytes_billed, אבל לא יכול לקבוע איזה מק"ט מייצג את השימוש.

פתרון בעיות וביצועי שאילתות

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

‫Get the last few failed jobs (קבלת המשימות האחרונות שנכשלו)

בדוגמה הבאה מוצגות שלוש המשימות האחרונות שנכשלו:

SELECT
   job_id,
  creation_time,
  user_email,
   error_result
 FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  error_result.reason != "Null"
ORDER BY
  creation_time DESC
LIMIT 3;

התוצאה אמורה להיראות כך:

+------------+--------------------------+------------------+-------------------------------------+
| job_id     | creation_time            | user_email       | error_result                        |
+------------+--------------------------+------------------+-------------------------------------+
| bquxjob_1  | 2020-10-10 00:00:00 UTC  | [e-mail]  | Column 'col1' has mismatched type...|
| bquxjob_2  | 2020-10-11 00:00:00 UTC  | [e-mail]  | Column 'col1' has mismatched type...|
| bquxjob_3  | 2020-10-11 00:00:00 UTC  | [e-mail]  | Column 'col1' has mismatched type...|
+------------+--------------------------+------------------+-------------------------------------+

שליחת שאילתה על רשימת המשימות שפועלות במשך זמן רב

בדוגמה הבאה מוצגת רשימה של משימות ארוכות שנמצאות במצב RUNNING או PENDING במשך יותר מ-30 דקות:

SELECT
  job_id,
  job_type,
  state,
  creation_time,
  start_time,
  user_email
 FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
 WHERE
  state!="DONE" AND
  creation_time <= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 MINUTE)
ORDER BY
  creation_time ASC;

התוצאה אמורה להיראות כך:

+-----------+----------+---------+--------------------------------+--------------------------------+------------------+
| job_id    | job_type | state   | creation_time                  | start_time                     | user_email       |
+-----------+----------+---------+--------------------------------+--------------------------------+------------------+
| bquxjob_1 | QUERY    | RUNNING | 2023-05-03 05:07:22.818000 UTC | 2023-05-03 05:07:22.905000 UTC | [e-mail]  |
| bquxjob_2 | QUERY    | PENDING | 2023-05-01 02:05:47.925000 UTC | 2023-05-01 02:05:47.998000 UTC | [e-mail]  |
| bquxjob_3 | QUERY    | PENDING | 2023-05-01 02:05:47.925000 UTC | 2023-05-01 02:05:47.998000 UTC | [e-mail]  |
+-----------+----------+---------+--------------------------------+--------------------------------+------------------+

איך רואים פרטים על אזהרה לגבי משאב

אם מופיעה הודעת השגיאה Resources exceeded, אפשר לשלוח שאילתות לגבי השאילתות בחלון זמן מסוים:

SELECT
  query,
  query_info.resource_warning
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
 creation_time BETWEEN TIMESTAMP("2022-12-01")
 AND TIMESTAMP("2022-12-08")
 AND query_info.resource_warning IS NOT NULL
LIMIT 3;

מעקב אחרי אזהרות לגבי משאבים מקובצות לפי תאריך

אם קיבלתם הודעת שגיאה מסוג Resources exceeded, אתם יכולים לעקוב אחרי המספר הכולל של אזהרות המשאבים בקיבוץ לפי תאריך כדי לדעת אם יש שינויים בעומס העבודה:

WITH resource_warnings AS (
  SELECT
    EXTRACT(DATE FROM creation_time) AS creation_date
  FROM
    `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
  WHERE
    creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY)
    AND query_info.resource_warning IS NOT NULL
)
SELECT
  creation_date,
  COUNT(1) AS warning_counts
FROM
  resource_warnings
GROUP BY creation_date
ORDER BY creation_date DESC;

קבלת משימות עם אותו גיבוב (hash) של שאילתה

השאילתה הבאה מחזירה את מזהי המשימות עם אותו גיבוב שאילתה כמו משימה ספציפית:

SELECT
  j.job_id,
  j.creation_time,
  j.query
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS j
WHERE
  j.job_id != "JOB_IDENTIFIER"
  AND j.query_info.query_hashes.normalized_literals = (
    SELECT
      sub.query_info.query_hashes.normalized_literals
    FROM
      `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS sub
    WHERE
      sub.job_id = "JOB_IDENTIFIER"
    LIMIT 1
  )
ORDER BY
  j.creation_time DESC;

הערה: שמות התצוגות ב-INFORMATION_SCHEMA תלויים באותיות רישיות.

התוצאה אמורה להיראות כך:

+--------------+---------------------------+------------------------------------------------+
| job_id       |  creation_time            |  query                                         |
+--------------+---------------------------+------------------------------------------------+
| bquxjob_1    |  2019-10-10 00:00:00 UTC  |  SELECT ... FROM dataset.table1 WHERE x = "a"  |
| bquxjob_2    |  2019-10-10 00:00:01 UTC  |  SELECT ... FROM dataset.table1 WHERE x = "b"  |
| bquxjob_3    |  2019-10-10 00:00:02 UTC  |  SELECT ... FROM dataset.table1 WHERE x = "c"  |
+--------------+---------------------------+------------------------------------------------+

ניתוח הביצועים לאורך זמן של שאילתות זהות

בדוגמה הבאה מוצגות 10 המשימות האיטיות ביותר ב-7 הימים האחרונים, שהריצו את אותה שאילתה:

DECLARE querytext STRING DEFAULT(
  SELECT query
  FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
  WHERE job_id = 'JOB_ID'
  LIMIT 1
);

SELECT
  start_time,
  end_time,
  project_id,
  job_id,
  TIMESTAMP_DIFF(end_time, start_time, SECOND) AS run_secs,
  total_bytes_processed / POW(1024, 3) AS total_gigabytes_processed,
  query
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
  query = querytext
  AND total_bytes_processed > 0
  AND creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY 5 DESC
LIMIT 3;

מחליפים את JOB_ID בכל ערך של job_id שהריץ את השאילתה שאתם מנתחים.

הצגת תובנות לגבי הביצועים של שאילתות

בדוגמה הבאה מוצגות כל משימות השאילתה שיש להן תובנות לגבי הביצועים מהפרויקט שלכם ב-30 הימים האחרונים, וגם כתובת URL שמקשרת לתרשים של ביצוע השאילתה במסוף Google Cloud :

SELECT
  `bigquery-public-data`.persistent_udfs.job_url(
    project_id || ':us.' || job_id) AS job_url,
  query_info.performance_insights
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  DATE(creation_time) >= CURRENT_DATE - 30 -- scan 30 days of query history
  AND job_type = 'QUERY'
  AND state = 'DONE'
  AND error_result IS NULL
  AND statement_type != 'SCRIPT'
  AND EXISTS ( -- Only include queries which had performance insights
    SELECT 1
    FROM UNNEST(
      query_info.performance_insights.stage_performance_standalone_insights
    )
    WHERE
      slot_contention
      OR insufficient_shuffle_quota
      OR bi_engine_reasons IS NOT NULL
      OR high_cardinality_joins IS NOT NULL
      OR partition_skew IS NOT NULL
    UNION ALL
    SELECT 1
    FROM UNNEST(
      query_info.performance_insights.stage_performance_change_insights
    )
    WHERE input_data_change.records_read_diff_percentage IS NOT NULL
  );

הצגת הממוצע של משימות בו-זמניות שפועלות לצד משימה מסוימת באותו פרויקט

בדוגמה הבאה מוסבר איך לחשב את המספר הממוצע של משימות שפועלות במקביל למשימת שאילתה ספציפית באותו פרויקט.

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

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

WITH job_metadata AS (
 SELECT creation_time, end_time, job_type
 FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
 WHERE job_id = 'JOB_ID'
-- If you know the date the job was created, add the following line to speed up the query by providing the date in UTC:
-- AND DATE(creation_time) = 'YYYY-MM-DD'
),
intervals AS (
 SELECT TIMESTAMP_ADD(creation_time, INTERVAL (seconds_offset) SECOND) AS ts,
 job_type
 FROM job_metadata,
 UNNEST (GENERATE_ARRAY(0, IF(TIMESTAMP_DIFF(end_time, creation_time, SECOND) > 0, TIMESTAMP_DIFF(end_time, creation_time, SECOND), 1))) as seconds_offset
),
concurrent_jobs AS (
 SELECT int.ts, COUNT(*) as concurrent_jobs_count
 FROM intervals int JOIN
 `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT j
 ON int.ts BETWEEN j.creation_time and j.end_time
 WHERE job_id != 'JOB_ID'
 AND j.job_type = int.job_type
 GROUP BY int.ts)

SELECT ROUND(AVG(concurrent_jobs_count),1) as average_concurrent_jobs FROM concurrent_jobs

הערה: רמת הפירוט של צבירת המטא-נתונים מוגדרת לשניות. אם אתם צריכים רמת פירוט גבוהה יותר למשימות קצרות יותר, החליפו את SECOND ב-MILLISECOND בגוף השאילתה כדי לדגום אלפיות השנייה.

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

• ‫JOB_ID: מזהה המשימה של השאילתה שאתם מנתחים.

• ‫REGION_NAME: האזור של הפרויקט.

התוצאה אמורה להיראות כך:

+-------------------------+
| average_concurrent_jobs |
+-------------------------+
|                     2.8 |
+-------------------------+

ניצול של יחידות ה-SQL

הדוגמאות בקטעים הבאים מראות איך לחשב את ניצול ה-slots ולזהות תחרות על slots בפרויקט או בהזמנה.

חישוב הניצול הממוצע של חריצי עיבוד

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

כדי להריץ את השאילתה:

SELECT
  SUM(total_slot_ms) / (1000 * 60 * 60 * 24 * 7) AS avg_slots
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
  -- Filter by the partition column first to limit the amount of data scanned.
  -- Eight days allows for jobs created before the 7 day end_time filter.
  creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP()
  AND job_type = 'QUERY'
  AND statement_type != 'SCRIPT'
  AND end_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP();

הערה: שמות התצוגות ב-INFORMATION_SCHEMA תלויים באותיות רישיות.

התוצאה אמורה להיראות כך:

+------------+
| avg_slots  |
+------------+
| 3879.1534  |
+------------+

אפשר לבדוק את השימוש במקום שמור מסוים באמצעות WHERE reservation_id = "…". המידע הזה יכול לעזור לכם לקבוע את אחוז השימוש בהזמנה לאורך זמן. במשימות של סקריפטים, המשימה הראשית מדווחת גם על השימוש הכולל ב-slots של המשימות המשניות שלה. כדי למנוע ספירה כפולה, צריך להשתמש ב-WHERE statement_type != "SCRIPT" כדי להחריג את המשימה הראשית.

אם רוצים לבדוק את ניצול המשבצות הממוצע של משימות ספציפיות, משתמשים ב-total_slot_ms / TIMESTAMP_DIFF(end_time, start_time, MILLISECOND).

מספר ממוצע של משבצות לאלפית שנייה שבהן נעשה שימוש במשימה

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

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

SELECT ROUND(SAFE_DIVIDE(total_slot_ms,TIMESTAMP_DIFF(end_time, start_time, MILLISECOND)), 1) as avg_slots_per_ms
FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE job_id = 'JOB_ID'

מחליפים את JOB_ID בערך של job_id של המשימה שבודקים.

הערה: שמות התצוגות ב-INFORMATION_SCHEMA תלויים באותיות רישיות.

התוצאה אמורה להיראות כך:

+------------------+
| avg_slots_per_ms |
+------------------+
|             17.0 |
+------------------+

הצגת משימות עם תובנות לגבי תחרות על משבצות

כדי להציג משימות עם תובנות לגבי התחרות על משבצות, מריצים את השאילתה הבאה:

SELECT
  job_id,
  creation_time,
  query_info.performance_insights,
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS j,
  UNNEST(query_info.performance_insights.stage_performance_standalone_insights) i
WHERE
  (j.statement_type != "SCRIPT" OR j.statement_type IS NULL)
  AND i IS NOT NULL
  AND i.slot_contention

הפלט מציג תובנות שונות לגבי ביצועי המשימות, כולל תחרות על משבצות:

+------------+-------------------------+-------------------------------------------------+----------------------------------------------------------------------------+
| job_id     | creation_time           | performance_insights.avg_previous_execution_ms  | performance_insightsstage_performance_standalone_insights.slot_contention  |
+------------+-------------------------+-------------------------------------------------+----------------------------------------------------------------------------+
| bquxjob_1  | 2025-08-08 00:00:00 UTC | null                                            | true                                                                       |
| bquxjob_2  | 2025-08-08 00:00:00 UTC | 42689                                           | true                                                                       |
| bquxjob_3  | 2025-08-08 00:00:00 UTC | 42896                                           | true                                                                       |
+------------+-------------------------+-------------------------------------------------+----------------------------------------------------------------------------+

התאמה של אופן השימוש במשבצות לפי תרשימי המשאבים של האדמין

כדי לבדוק את אופן השימוש במשבצות, בדומה למידע שמוצג בתרשימי המשאבים של האדמין, אפשר לשלוח שאילתה לתצוגה INFORMATION_SCHEMA.JOBS_TIMELINE.

משימות טעינה, חילוץ והעתקה

בדוגמאות שבקטעים הבאים מוסבר איך לעקוב אחרי היסטוריית המשימות והשימוש במכסות של משימות טעינה, חילוץ והעתקה.

הצגת ההיסטוריה של משימות הטעינה

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

SELECT
  user_email AS user,
  COUNT(*) num_jobs
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
  job_type = 'LOAD'
GROUP BY
  user_email;

הערה: שמות התצוגות ב-INFORMATION_SCHEMA תלויים באותיות רישיות.

התוצאה אמורה להיראות כך:

+--------------+
| user         |
+--------------+
| [e-mail]  |
| [e-mail]  |
| [e-mail]  |
+--------------+

קבלת בייטים שעובדו על ידי משימות חילוץ

בדוגמה הבאה מחושב הערך של total_bytes_processed עבור EXTRACT סוגי עבודות. למידע על מכסות של משימות חילוץ, קראו את מדיניות המכסות של משימות חילוץ. אפשר להשתמש בערך total_bytes_processed כדי לעקוב אחרי השימוש המצטבר ולוודא שמשימות החילוץ לא חורגות מהמגבלה של 50TiB ליום:

SELECT
    DATE(creation_time) as day,
    project_id as source_project_id,
    SUM(total_bytes_processed) AS total_bytes_processed
 FROM
   `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
 WHERE
    creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP()
    AND job_type = "EXTRACT"
GROUP BY
    day,
    source_project_id
ORDER BY
    day DESC;

קבלת מספר משימות הטעינה כדי לקבוע את מכסת המשימות היומית שנוצלה

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

SELECT
    DATE(creation_time) as day,
    destination_table.project_id as project_id,
    destination_table.dataset_id as dataset_id,
    destination_table.table_id as table_id,
    COUNT(job_id) AS load_job_count
 FROM
   `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
 WHERE
    creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP()
    AND job_type = "LOAD"
GROUP BY
    day,
    project_id,
    dataset_id,
    table_id
ORDER BY
    day DESC;

הערה: שמות התצוגות ב-INFORMATION_SCHEMA תלויים באותיות רישיות.

התוצאה אמורה להיראות כך:

+-------------+------------+-------------+----------+-----------------+
|day          | project_id | dataset_id  | table_id | load_job_count  |
+-------------+------------+-------------+----------+-----------------+
| 2020-10-10  | my_project | dataset1    | orders   | 58              |
| 2020-10-10  | my_project | dataset1    | product  | 20              |
| 2020-10-10  | my_project | dataset1    | sales    | 11              |
+-------------+------------+-------------+----------+-----------------+

קבלת נתוני שימוש במשימות העתקה

מידע נוסף על משימות העתקה זמין במאמר העתקת טבלה. בדוגמה הבאה מוסבר איך להשתמש במשימות העתקה:

SELECT
    DATE(creation_time) as day,
    project_id as source_project_id,
CONCAT(destination_table.project_id,":",destination_table.dataset_id,".",destination_table.table_id) as destination_table,
    COUNT(job_id) AS copy_job_count
 FROM
   `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
 WHERE
    creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP()
    AND job_type = "COPY"
GROUP BY
    day,
    source_project_id,
    destination_table
ORDER BY
    day DESC;

פעילות בשאילתות ובטבלאות

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

ספירת השאילתות הפעילות מהזמן האחרון לפי עדיפות השאילתה

בדוגמה הבאה מוצג מספר השאילתות שהתחילו ב-7 השעות האחרונות, מקובצות לפי עדיפות (אינטראקטיבית או באצ'):

SELECT
  priority,
  COUNT(*) active_jobs
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 hour)
  AND job_type = 'QUERY'
GROUP BY priority;

התוצאה אמורה להיראות כך:

+-------------+-------------+
| priority    | active_jobs |
+-------------+-------------+
| INTERACTIVE |           2 |
| BATCH       |           3 |
+-------------+-------------+

השדה priority מציין אם השאילתה היא INTERACTIVE או BATCH.

מספר המחיצות ששונו על ידי שאילתות ומשימות טעינה בכל טבלה

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

SELECT
  destination_table.table_id,
  SUM(total_modified_partitions) AS total_modified_partitions
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
  DATE(creation_time, "America/Los_Angeles") = CURRENT_DATE()
GROUP BY
  table_id
ORDER BY
  total_modified_partitions DESC

משימות של שאילתות לכל טבלה

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

SELECT
  t.project_id,
  t.dataset_id,
  t.table_id,
  COUNT(*) AS num_references
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS, UNNEST(referenced_tables) AS t
GROUP BY
  t.project_id,
  t.dataset_id,
  t.table_id
ORDER BY
  num_references DESC;

התוצאה אמורה להיראות כך:

+------------+------------+----------+----------------+
| project_id | dataset_id | table_id | num_references |
+------------+------------+----------+----------------+
| my_project | dataset1   | orders   | 58             |
| my_project | dataset1   | products | 40             |
| other_proj | dataset1   | accounts | 12             |
+------------+------------+----------+----------------+

מספר המשימות של שאילתות SQL מדור קודם לכל פרויקט

השדה query_dialect ב-INFORMATION_SCHEMA זמין ממאי 2025. בדוגמה הבאה אפשר לראות כמה משימות של שאילתות SQL מדור קודם מופעלות על ידי פרויקטים.

SELECT
  project_id,
  -- Implicitly defaulted to Legacy SQL since the query dialect was not specified
  -- in the request.
  COUNTIF(query_dialect = 'DEFAULT_LEGACY_SQL') AS default_legacysql_query_jobs,
  -- Explicitly requested Legacy SQL.
  COUNTIF(query_dialect = 'LEGACY_SQL') AS legacysql_query_jobs,
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
  query_dialect = 'DEFAULT_LEGACY_SQL'
  OR query_dialect = 'LEGACY_SQL'
GROUP BY
  project_id
ORDER BY
  default_legacysql_query_jobs DESC,
  legacysql_query_jobs DESC;

שאילתות שמשתמשות במצב יצירה אופציונלית של משימות

בדוגמה הבאה מוצגת רשימה של שאילתות שהופעלו במצב יצירה אופציונלית של משימות, ש-BigQuery לא יצר בשבילן משימות.

SELECT
 job_id,
FROM
 `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
 TIMESTAMP_TRUNC(creation_time, DAY) = '2024-06-12'
 AND job_creation_reason.code IS NULL
LIMIT 3;

התוצאה אמורה להיראות כך:

+-----------+
| job_id    |                                          |
+-----------+
| bquxjob_1 |
| bquxjob_2 |
| bquxjob_3 |
+-----------+

בדוגמה הבאה מוצג מידע על שאילתה שהופעלה במצב יצירה אופציונלית של משימות, שבה BigQuery לא יצר משימה.

SELECT
 job_id,
 statement_type,
 priority,
 cache_hit,
 job_creation_reason.code AS job_creation_reason_code,
 total_bytes_billed,
 total_bytes_processed,
 total_slot_ms,
 state,
 error_result.message AS error_result_message,
FROM
 `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
 TIMESTAMP_TRUNC(creation_time, DAY) = '2024-06-12'
 AND job_id = '2Lm09bHxDEsoVK8zwzWJomLHU_Ud%1910479b151' -- queryId

הערה: השדה job_id מכיל את ה-queryId של השאילתה כשלא נוצר לה משימה.

התוצאה אמורה להיראות כך:

+-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+
| job_id    | statement_type | priority    | cache_hit | job_creation_reason_code | total_bytes_billed | total_bytes_processed | total_slot_ms | state | error_result_message |
+-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+
| bquxjob_1 | SELECT         | INTERACTIVE | false     | null                     | 161480704          | 161164718             | 3106          | DONE  | null                 |
+-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+

בדוגמה הבאה מוצגת רשימה של שאילתות שהופעלו במצב יצירה אופציונלית של משימות, שבהן BigQuery יצר משימות.

SELECT
 job_id,
 job_creation_reason.code AS job_creation_reason_code
FROM
 `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
 TIMESTAMP_TRUNC(creation_time, DAY) = '2024-06-12'
 AND job_creation_reason.code IS NOT NULL
 AND job_creation_reason.code != 'REQUESTED'
LIMIT 3

התוצאה אמורה להיראות כך:

+-----------+--------------------------+
| job_id    | job_creation_reason_code |
+-----------+--------------------------+
| bquxjob_1 | LARGE_RESULTS            |
| bquxjob_2 | LARGE_RESULTS            |
| bquxjob_3 | LARGE_RESULTS            |
+-----------+--------------------------+

#### צבירת נתוני השימוש בגיליונות מקושרים לפי משתמש ברמת הפרויקט

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

SELECT
  user_email,
  COUNT(*) AS total_queries,
  SUM(total_bytes_billed) AS total_bytes_billed,
  SUM(total_slot_ms) AS total_slot_ms
FROM
  -- This view queries the project you are currently running the query in.
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  -- Filter for jobs created in the last 30 days
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  -- Filter for jobs originating from Connected Sheets
  AND job_id LIKE 'sheets_dataconnector%'
  -- Filter for completed jobs
  AND state = 'DONE'
  AND (statement_type IS NULL OR statement_type <> 'SCRIPT')
GROUP BY
  user_email
ORDER BY
  total_bytes_billed DESC
LIMIT
  10;

מחליפים את REGION_NAME באזור של הפרויקט. לדוגמה, region-us.

הערה: צריך להשתמש במזהה אזור כדי לשלוח שאילתות לתצוגות של INFORMATION_SCHEMA. המיקום של הרצת השאילתה חייב להתאים לאזור של התצוגה INFORMATION_SCHEMA.

התוצאה אמורה להיראות כך:

+---------------------+---------------+--------------------+-----------------+
| user_email          | total_queries | total_bytes_billed | total_slot_ms   |
+---------------------+---------------+--------------------+-----------------+
| [e-mail]   | 152           | 12000000000        | 3500000         |
| [e-mail]     | 45            | 8500000000         | 2100000         |
| [e-mail] | 210           | 1100000000         | 1800000         |
+---------------------+---------------+--------------------+-----------------+

#### חיפוש יומני משימות של שאילתות בגיליונות מקושרים ברמת הפרויקט

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

SELECT
  job_id,
  creation_time,
  user_email,
  total_bytes_billed,
  total_slot_ms,
  query
FROM
  -- This view queries the project you are currently running the query in.
  `region-REGION_NAME.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_id LIKE 'sheets_dataconnector%'
  AND state = 'DONE'
  AND (statement_type IS NULL OR statement_type <> 'SCRIPT')
ORDER BY
  creation_time DESC;

מחליפים את REGION_NAME באזור של הפרויקט. לדוגמה, region-us.

הערה: צריך להשתמש במזהה אזור כדי לשלוח שאילתות לתצוגות של INFORMATION_SCHEMA. המיקום של הרצת השאילתה חייב להתאים לאזור של התצוגה INFORMATION_SCHEMA.

התוצאה אמורה להיראות כך:

+---------------------------------+---------------------------------+------------------+--------------------+-----------------+---------------------------------+
| job_id                          | creation_time                   | user_email       | total_bytes_billed | total_slot_ms   |  query                          |
+---------------------------------+---------------------------------+------------------+--------------------+-----------------+---------------------------------+
| sheets_dataconnector_bquxjob_1  | 2025-11-06 00:26:53.077000 UTC  | [e-mail]  | 12000000000        | 3500000         |  SELECT ... FROM dataset.table1 |
| sheets_dataconnector_bquxjob_2  | 2025-11-06 00:24:04.294000 UTC  | [e-mail]  | 8500000000         | 2100000         |  SELECT ... FROM dataset.table2 |
| sheets_dataconnector_bquxjob_3  | 2025-11-03 23:17:25.975000 UTC  | [e-mail]  | 1100000000         | 1800000         |  SELECT ... FROM dataset.table3 |
+---------------------------------+---------------------------------+------------------+--------------------+-----------------+---------------------------------+

משימות של אופטימיזציה של מטא-נתונים ואחסון

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

הצגת משימות לרענון מטא-נתונים

בדוגמה הבאה מפורטות משימות הרענון של המטא-נתונים בשש השעות האחרונות:

SELECT
 *
FROM
 `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
 job_id LIKE '%metadata_cache_refresh%'
 AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time desc
LIMIT 10;

מחליפים את REGION_NAME באזור שלכם.

איך בודקים את השימוש באופטימיזציה של האחסון בטבלאות מנוהלות של Apache Iceberg

בדוגמה הבאה מוסבר איך משתמשים באופטימיזציה של אחסון טבלאות מנוהלות ב-Iceberg.

SELECT
    job_id, reservation_id, edition,
    total_slot_ms, total_bytes_processed, state
FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
    AND user_email = "[e-mail]"
    AND query LIKE "CALL BQ.OPTIMIZE_STORAGE(%)";

קבלת נתוני השימוש במטא-נתונים של טבלת הייצוא של טבלה מנוהלת ב-Iceberg

בדוגמה הבאה מוצג השימוש ב-EXPORT TABLE METADATA FROM של Iceberg.

SELECT
   job_id,
   user_email,
   start_time,
   end_time,
   TIMESTAMP_DIFF(end_time, start_time, SECOND) AS duration_seconds,
   total_bytes_processed,
   reservation_id,
   CASE
     WHEN reservation_id IS NULL THEN 'PAYG (On-demand)'
     WHEN reservation_id != '' THEN 'Reservation'
     ELSE 'Unknown'
   END AS compute_type,
   query
 FROM
   `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
 WHERE
   job_type = 'QUERY'
   AND end_time IS NOT NULL
   -- Filter for queries containing the specified pattern (case-insensitive)
   AND REGEXP_CONTAINS(LOWER(query), r"export table metadata from")
 ORDER BY
   start_time DESC
 LIMIT 3;