שימוש בתורים של שאילתות

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

סקירה כללית

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

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

התנהגות התור

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

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

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

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

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

שליטה בזמן הקצוב לתפוגה של התור

כדי לשלוט בפרק הזמן הקצוב לתפוגה של תורים לשאילתות אינטראקטיביות או לשאילתות באצווה, משתמשים בהצהרת ALTER PROJECT SET OPTIONS או בהצהרת ALTER ORGANIZATION SET OPTIONS כדי להגדיר את השדות default_interactive_query_queue_timeout_ms או default_batch_query_queue_timeout_ms בתצורת ברירת המחדל של הפרויקט או הארגון.

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

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

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

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

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

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

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

התפקיד המוגדר מראש הזה כולל את ההרשאה bigquery.reservations.create, שנדרשת כדי להגדיר את הבו-זמניות (concurrency) במקום שמור חדש.

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

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

הגדרת יעד מקסימלי של שיחות בו-זמניות להזמנה

בוחרים באחת מהאפשרויות הבאות:

bq mk \
    --project_id=ADMIN_PROJECT_ID \
    --location=LOCATION \
    --target_job_concurrency=CONCURRENCY \
    --reservation \
    RESERVATION_NAME

עדכון היעד של מספר החיבורים המקסימלי בו-זמנית

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

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

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

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

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

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

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

עדכון יעד המקסימום של מספר המשתמשים בו-זמנית בהזמנה

בוחרים באחת מהאפשרויות הבאות:

bq update \
    --project_id=ADMIN_PROJECT_ID \
    --location=LOCATION \
    --target_job_concurrency=CONCURRENCY \
    --reservation \
    RESERVATION_NAME

מעקב

כדי לראות אילו שאילתות פועלות ואילו נמצאות בתור, אפשר לעיין בתצוגות INFORMATION_SCHEMA.JOBS_BY_* ו-INFORMATION_SCHEMA.JOBS_TIMELINE_BY_*. השדה state מוגדר לערך RUNNING עבור שאילתות שמופעלות באופן פעיל, ולערך PENDING עבור שאילתות שנמצאות בתור.

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

SELECT
  t1.period_start,
  t1.job_count AS dynamic_concurrency_threshold
FROM (
  SELECT
    period_start,
    state,
    COUNT(DISTINCT job_id) AS job_count
  FROM
    `PROJECT_ID.REGION_ID`.INFORMATION_SCHEMA.JOBS_TIMELINE
  WHERE
    period_start BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
    AND CURRENT_TIMESTAMP()
    AND reservation_id = "RESERVATION_ID"
  GROUP BY
    period_start,
    state) AS t1
JOIN (
  SELECT
    period_start,
    state,
    COUNT(DISTINCT job_id) AS job_count
  FROM
    `PROJECT_ID.REGION_ID`.INFORMATION_SCHEMA.JOBS_TIMELINE
  WHERE
    state = "PENDING"
    AND period_start BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
    AND CURRENT_TIMESTAMP()
    AND reservation_id = "RESERVATION_ID"
  GROUP BY
    period_start,
    state
  HAVING
    COUNT(DISTINCT job_id) > 0 ) AS t2
ON
  t1.period_start = t2.period_start
WHERE
  t1.state = "RUNNING";

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

• ‫PROJECT_ID: שם הפרויקט שבו הפעלתם את השאילתות
• REGION_ID: המיקום שבו העיבוד של השאילתות בוצע
• ‫RESERVATION_ID: השם של ההזמנה שבה השאילתות פועלות

אתם יכולים לעקוב אחרי אורך תור השאילתות בהזמנה באמצעות תרשימים של משאבי ניהול ב-BigQuery ולבחור בתרשים Job Concurrency עם המדד Pending.

אפשר גם לעקוב אחרי אורך התור ב-Cloud Monitoring על ידי הצגת המדד job count וסינון לפי מספר המשימות במצב pending.

פתרון בעיות שקשורות לזמני המתנה ארוכים בתור

יכול להיות שייראה ששאילתה פועלת לאט כי היא מבלה הרבה זמן בהמתנה בתור לפני שהיא מתחילה לפעול. משך הזמן הזה הוא זמן ההמתנה בתור. משרות שנמצאות בתור מוצגות במצב PENDING.

זיהוי של זמני המתנה ארוכים בתור

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

• ‫INFORMATION_SCHEMA: התצוגה INFORMATION_SCHEMA.JOBS* views יכולה לספק תובנות לגבי זמני ההמתנה בתור של השאילתות. לדוגמה, אפשר לחשב את זמן ההמתנה בתור למשימות ספציפיות על ידי חיסור creation_time מ-start_time, או לזהות משימות שבהן state="PENDING" למשך זמן ממושך. שאילתת הדוגמה יכולה לשמש כנקודת התחלה כדי לבחון את עומס השאילתות ולזהות מתי מגיעים לסף הדינמי של מספר הבקשות המקבילות.
• מעקב: כדי לעקוב אחרי אורך התור לאורך זמן, אפשר להשתמש במדד bigquery.googleapis.com/job/num_in_flight ב-Monitoring, עם סינון לפי state=pending.
• אפשר גם להשתמש בתרשימים של משאבים אדמיניסטרטיביים ב-BigQuery, כמו שמתואר בקטע מעקב.

גורמים נפוצים

ריכזנו כאן כמה מהסיבות הנפוצות לזמני המתנה ארוכים בתור:

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

פתרון בעיות שקשורות לזמני המתנה ארוכים בתור

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

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

מגבלות

• בכל פרויקט על פי דרישה אפשר להוסיף לתור עד 1,000 שאילתות אינטראקטיביות ו-20,000 שאילתות אצווה בכל פעם. אם שאילתות חורגות מהמגבלה הזו, מוחזרת שגיאת מכסה. אי אפשר לבקש להגדיל את המגבלות האלה.
• במסגרת הזמנה, כל פרויקט שמוקצה להזמנה יכול להוסיף לתור עד 1,000 שאילתות אינטראקטיביות ו-20,000 שאילתות אצווה בכל פעם. אם שאילתות חורגות מהמגבלה הזו, מוחזרת שגיאת מכסה. אי אפשר לבקש להגדיל את המגבלות האלה.
• כברירת מחדל, שאילתות שלא התחילו את ההרצה שלהן יפסיקו לפעול אחרי 6 שעות לשאילתות אינטראקטיביות ו-24 שעות לשאילתות אצווה.
• אי אפשר להגדיר את יעד המקבילות המקסימלי לשאילתות שמופעלות בפרויקט לפי דרישה.
• אי אפשר להגדיר את יעד המקסימום של מספר השאילתות המקבילות בשאילתות שמופעלות עם הזמנה במהדורה רגילה. מידע נוסף על מהדורות זמין במאמר מבוא למהדורות של BigQuery.

המאמרים הבאים

• מידע נוסף על אבחון ופתרון של שגיאות שקשורות למגבלות על תור השאילתות