הסבר על הזמנות

בדף הזה מוסבר איך להשתמש בהזמנות של משבצות כדי לנהל את עומסי העבודה ב-BigQuery.

הזמנות של יחידות קיבולת (Slot)

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

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

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

הקצאות של הזמנות

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

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

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

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

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

  • ‫QUERY: משתמשים במקום השמור הזה למשימות של שאילתות לא מתמשכות, כולל שאילתות SQL,‏ DDL,‏ DML ו-BigQuery ML (מודלים מובְנים).

  • ‫AUTOMATIC_MATERIALIZED_VIEW_REFRESH: שימוש במאגר הזה למשימות של רענון אוטומטי של תצוגות מהותיות.

  • ‫BACKGROUND_CHANGE_DATA_CAPTURE: משתמשים במקום השמור הזה כשבוחרים להשתמש במקום שמור משלכם כדי להריץ את משימות הרקע של הטמעת CDC ב-BigQuery. במהדורת Standard אי אפשר להזמין BACKGROUND_CHANGE_DATA_CAPTURE.

  • ‫BACKGROUND_COLUMN_METADATA_INDEX: משתמשים בהזמנה הזו כשבוחרים להשתמש בהזמנה משלכם כדי להריץ את המשימות ברקע של שמירת המטא-נתונים של BigLake במטמון. אפשר להשתמש בהזמנה הזו גם כשמשכפלים מסדי נתונים של מקורות ל-BigQuery באמצעות פעולות החלה ברקע של Datastream. במהדורת Standard אי אפשר להזמין BACKGROUND_COLUMN_METADATA_INDEX.

  • ‫BACKGROUND_SEARCH_INDEX_REFRESH: משתמשים במקום השמור הזה כשבוחרים להשתמש במקום שמור משלכם כדי להריץ את משימות הרקע לניהול האינדקס של חיפוש ב-BigQuery. במהדורת Standard אי אפשר להזמין BACKGROUND_SEARCH_INDEX_REFRESH.

  • ‫BACKGROUND: משתמשים במקום השמור הזה כשבוחרים להשתמש במקום שמור משלכם כדי לשכפל מסדי נתונים של מקורות ל-BigQuery באמצעות פעולות החלה ברקע של Datastream. המקום השמור הזה ישמש גם למשימות שמתוארות על ידי BACKGROUND_CHANGE_DATA_CAPTURE, ‏ BACKGROUND_COLUMN_METADATA_INDEX ו-BACKGROUND_SEARCH_INDEX_REFRESH כחלופה, אם לא קיים מקום שמור ספציפי יותר לסוגי העבודה האלה. הזמנות של BACKGROUND לא זמינות במהדורת Standard.

  • ‫CONTINUOUS: שימוש בהזמנה הזו למשימות של שאילתות מתמשכות.

  • ‫ML_EXTERNAL: משתמשים במקום השמור הזה לשאילתות של BigQuery ML CREATE MODEL שמשתמשות בשירותים חיצוניים ל-BigQuery. מידע נוסף מופיע במאמר הקצאת חריצים לעומסי עבודה של BigQuery ML. הזמנות של ML_EXTERNAL לא זמינות במהדורת Standard.

  • ‫PIPELINE: שימוש בהזמנה הזו למשימות טעינה וחילוץ.

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

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

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

הקצאת הזמנות בצורה גמישה

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

כדי להשתמש בהזמנה כשמריצים את השאילתה, צריך שתהיה לכם גישה להזמנה.

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

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

שילוב של מקומות שמורים עם חיוב על פי דרישה

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

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

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

ציון פרויקט ניהול

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

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

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

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

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

שימוש בכמה פרויקטים לניהול

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

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

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

בדף Workload management במסוף BigQuery Google Cloud , אתם יכולים לראות את ההתחייבויות וההזמנות רק של הפרויקט האדמיניסטרטיבי שנבחר.

מכסות לפרויקטים וכללי מדיניות לתזמון

כדי לבקש תמיכה או לשלוח משוב על התכונה הזו, אפשר לפנות לכתובת bigquery-wlm-feedback@google.com.

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

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

אלה סוגי המכסות לפרויקטים שנתמכים:

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

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

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

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

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

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

התאמת הגודל של הזמנות של יחידות קיבולת (Slot)

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

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

אתם יכולים להתנסות עם משבצות בסיסיות ומשבצות להתאמה לעומס (autoscaling) כדי לקבוע את ההגדרה הטובה ביותר של משבצות. לדוגמה, אתם יכולים לבדוק את עומס העבודה עם 500 משבצות בסיסיות, אחר כך עם 1,000, 1,500 ו-2,000, ולראות את ההשפעה על הביצועים.

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

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

אתם יכולים גם לבדוק את השימוש הנוכחי ב-slots בפרויקטים שלכם, יחד עם המחיר החודשי שבחרתם לשלם. לעומסי עבודה על פי דרישה יש מכסה גמישה של 2,000 חריצי עיבוד, אבל חשוב לבדוק כמה חריצי עיבוד נמצאים בשימוש בפועל בפרויקטים שלכם באמצעות תצוגות INFORMATION_SCHEMA.JOBS*, ‏Cloud Logging, ‏Jobs API או יומני הביקורת של BigQuery. מידע נוסף זמין במאמר מעקב אחרי הזמנות.

ציר הזמן של השימוש ביחידות ה-Slot.

ניהול עומסי עבודה באמצעות הזמנות

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

לדוגמה, נניח שיש לכם קיבולת כוללת של 1,000 חריצים בהתחייבות, ושלושה סוגים של עומסי עבודה: מדעי הנתונים, ELT ו-BI.

  • אתם יכולים ליצור הזמנה של ds עם 500 חריצים, ולהקצות את כל הפרויקטים הרלוונטיים של Google Cloud להזמנה של ds.
  • אתם יכולים ליצור הזמנה של elt עם 300 מיקומים, ולהקצות לה elt פרויקטים שאתם משתמשים בהם לעומסי עבודה של ELT.
  • אתם יכולים ליצור הזמנה של bi עם 200 משבצות, ולהקצות להbi פרויקטים שמחוברים לכלי ה-BI שלכם.

מחיקת התחייבויות.

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

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

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

  1. במסוף BigQuery, לוחצים על Reservations.
  2. לוחצים על בורר המיקום ובוחרים את האזור שבו רוצים לנהל את ההזמנות. צריך לבחור אזור אחר.
  3. אחרי שבוחרים אזור, אפשר לרכוש משבצות, ליצור הזמנות ולהקצות פרויקט להזמנה.

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

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

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

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

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

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

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

כדי לשנות את הקצאת ברירת המחדל של המשימה, או כדי לאלץ את המשימה לפעול על פי דרישה כשהקצאת המשאבים כבר קיימת בפרויקט, המשתמשים צריכים את ההרשאה reservations.use. התפקידים roles/bigquery.resourceAdmin ו-roles/bigquery.resourceEditor כוללים את ההרשאה הזו. אתם יכולים לתת גישה למשתמשים, לקבוצות או לחשבונות שירות ספציפיים. אתם יכולים גם להגדיר כללי מדיניות על סמך מאפייני הזמנה כמו שם, כי תנאי IAM תומכים בבקרת גישה שמבוססת על מאפיינים.

במאמר שליטה בגישה להזמנות מוסבר איך להעניק תנאי IAM בהזמנות.

התחייבויות ל-slots

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

  • התחייבות שנתית. אתם רוכשים התחייבות ל-365 ימים. אחרי 365 ימים, אתם יכולים לבחור אם לחדש את התוכנית או לעבור לסוג אחר של תוכנית מחויבות.

  • התחייבות ל-3 שנים. אתם רוכשים התחייבות לשלוש שנים. אחרי 3 שנים (1,095 ימים), אתם יכולים לבחור אם לחדש את התוכנית או לעבור לסוג אחר של תוכנית התחייבות.

בסוף תקופת ההתחייבות, ההתחייבות תתחדש בהתאם לתוכנית החידוש שנבחרה.

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

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

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

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

חידוש התחייבויות

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

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

במאמר יצירת התחייבות לקיבולת מוסבר איך רוכשים ומחדשים התחייבויות.

לדוגמה, אם רכשתם התחייבות שנתית ב-5 באוקטובר 2019 בשעה 18:00, החיוב התחיל באותו רגע. אפשר למחוק או לחדש את ההתחייבות אחרי השעה 18:00 ב-4 באוקטובר 2020, בהתחשב בכך ששנת 2020 היא שנה מעוברת. אפשר לשנות את תוכניות החידוש לפני 4 באוקטובר 2020 בשעה 18:00, באופן הבא:

  • אם תבחרו לחדש את ההתחייבות השנתית, היא תתחדש לשנה נוספת ב-4 באוקטובר 2020 בשעה 18:00.
  • אם תבחרו לחדש את ההתחייבות לשלוש שנים, ב-4 באוקטובר 2020 בשעה 18:00 ההתחייבות תתחדש לשלוש שנים.

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

תפוגת ההתחייבות

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

אם רכשתם התחייבות בטעות או ביצעתם טעות בהגדרת ההתחייבות, תוכלו לבקש עזרה מCloud Customer Care.

מגבלות על הזמנות

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

יכולת חיזוי של הזמנות

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

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

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

הערך של ignore_idle_slots חייב להתאים למצב ההתאמה לעומס. אם מצב ההתאמה לעומס הוא ALL_SLOTS או IDLE_SLOTS_ONLY, הערך של ignore_idle_slots חייב להיות false. אם מצב שינוי קנה המידה הוא AUTOSCALE_ONLY, הערך של ignore_idle_slots חייב להיות true.

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

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

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

  • משבצות בסיס + משבצות להתאמה לעומס (autoscaling): קיבולת המשבצות בהזמנה גדולה מאפס, ומצב ההתאמה לעומס הוא AUTOSCALE_ONLY. המקום השמור צורך קודם את יחידות הקיבולת של הבסיס שהוגדרו, ואז את יחידות הקיבולת להתאמה אוטומטית לעומס.

  • משבצות לא פעילות + משבצות להתאמה אוטומטית לעומס: קיבולת המשבצות בהזמנה היא אפס, ומצב ההתאמה לעומס הוא ALL_SLOTS. ההזמנה צורכת קודם את כל המשבצות הזמינות שלא בשימוש, ואז את המשבצות שנוספו בהתאמה אוטומטית לעומס.

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

הדיאגרמה הבאה מציגה את אפשרויות ההגדרה השונות:

אפשרויות הגדרה צפויות מראש של הזמנות.

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

מגבלות

היכולת לחזות את הזמינות של ההזמנות כפופה למגבלות הבאות:

  • האפשרות "חיזוי הזמנות" זמינה רק במהדורות Enterprise ו-Enterprise Plus, אלא אם בוחרים באפשרות AUTOSCALE_ONLY.

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

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

קבוצות של הזמנות

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

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

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

קבוצות של הזמנות.

שיתוף משבצות לא פעילות עם קבוצות הזמנות

משבצות לא פעילות מחולקות באופן שווה בין הזמנות שלא מקובצות וקבוצות של הזמנות, ואז באופן שווה בתוך קבוצות של הזמנות.

בדוגמה הבאה יש שלוש הזמנות ו-1,200 משבצות לא פעילות. בלי קבוצות של הזמנות, לכל הזמנה יש חלק הוגן של 400 משבצות לא פעילות. כשמאגדים את הזמנות 1 ו-2, חלוקת ה-slots שלא בשימוש משתנה. המשבצות הפנויות מחולקות קודם באופן שווה בין קבוצת ההזמנות לבין הזמנה 3 (600 משבצות פנויות לכל אחת). לאחר מכן, 600 המשבצות הלא פעילות של קבוצת ההזמנות מחולקות באופן שווה בין הזמנה 1 להזמנה 2.

שיתוף משבצות לא פעילות בקבוצות של הזמנות.

מגבלות

קבוצות של הזמנות כפופות למגבלות הבאות:

  • ההזמנות שמשתפות קבוצת הזמנות חייבות להיות שייכות לאותו פרויקט ולאותו אזור.

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

  • ההזמנות בקבוצה חייבות להיות מאותה מהדורה.

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

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

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

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

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

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

אם מופיעות שגיאות כמו Failed to allocate slots for reservation in the current system state או Failed to update reservation: Failed to allocate slots for reservation כשמנסים להוסיף עוד משבצות להזמנה, בדרך כלל מדובר בבעיה זמנית. כדי לפתור את הבעיה:

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

אם ניסיתם כמה פעמים וחיכיתם 30 דקות ועדיין מופיעה אותה הודעת שגיאה, פנו ל-Cloud Customer Care.

אין מספיק מכסה כדי להשלים את הבקשה הזו

אם הודעת השגיאה היא There is insufficient quota to complete this request, הבקשה חורגת ממגבלת המכסה שהוגדרה לפרויקט.

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

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

הזמנה שלא משמשת את BigQuery להרצת משימה

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

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

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

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

שליחת שאילתות לטבלאות BigQuery Omni

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

ההזמנה נוצרה, אבל הפרויקט לא הוקצה לה

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

אי-התאמה בסוג העבודה

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

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

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

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

כדי לוודא שהמשימה באמת השתמשה במקום שמור, בודקים את המטא-נתונים של משימת הצאצא.

אחזור תוצאות מהמטמון

כשמשימת שאילתה מאחזרת תוצאות שנשמרו במטמון, השדה reservation ריק כי BigQuery לא מבצע חישוב, אלא מאחזר את התוצאות ישירות מהטבלה הזמנית.

פעולות לשינוי שורות של סימון נתונים שהשתנו (CDC)

אם יש לכם טבלאות של סימון נתונים שהשתנו (CDC), המערכת של BigQuery מבצעת שינויים בשורות בהמתנה במרווח הזמן של max_staleness כמשימות ברקע שמשתמשות בסוג ההקצאה BACKGROUND. אם אין הקצאות של BACKGROUND, המשימות האלה מתומחרות לפי דרישה. כדי להימנע מעלויות בלתי צפויות על פי דרישה, כדאי ליצור הקצאה מסוג BACKGROUND לפרויקט. אפשר לזהות את המשימות האלה לפי המחרוזת queueworker_cdc_background_merge_coalesce במזהה המשימה.

סוגי מודלים של BigQuery ML שמשתמשים בשירותים חיצוניים

אם בפרויקט לא נמצאת הקצאת מקום שמור עם סוג העבודה ML_EXTERNAL, משימות ליצירת מודלים חיצוניים פועלות באמצעות תמחור על פי דרישה. הקצאת סוג העבודה QUERY חלה על מודלים סטנדרטיים של BigQuery ML ועל מודלים של פירוק לגורמים של מטריצות (שמחייבים הזמנה של מהדורת Enterprise או Enterprise Plus), ואילו מודלים חיצוניים מחייבים הקצאה של ML_EXTERNAL. מידע נוסף זמין במאמר הקצאת חריצים לעומסי עבודה ב-BigQuery.

זוהו בפרויקט הזמנות לא מזוהות

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

default-pipeline

כברירת מחדל, טעינה או ייצוא של נתונים באצוות ב-BigQuery מתבצעים באמצעות מאגר משבצות משותף בחינם. כשבודקים את משימות הטעינה או החילוץ האלה, בשדה reservation מופיע הערך default-pipeline.

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