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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

לדוגמה, נניח שיש לכם קיבולת כוללת של 1,000 חריצי זמן (slots) ושלושה סוגים של עומסי עבודה: מדעי הנתונים, 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, אין ערובה לכך שהרכישה תצליח. עם זאת, אחרי שרכישת ההתחייבות בוצעה בהצלחה, הקיבולת זמינה עד שתוקף ההתחייבות פג.

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

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

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

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

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

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

לדוגמה, אם רכשתם התחייבות שנתית ב-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 יש יחידות קיבולת בסיסיות, יחידות קיבולת לא פעילות ויחידות קיבולת בהתאמה אוטומטית. כשיוצרים מקום שמור עם גודל מקסימלי, צריך לאשר את מספר יחידות ה-baseline ואת ההגדרה המתאימה של התאמה אוטומטית לעומס ויחידות קיבולת לא פעילות, על סמך עומסי העבודה הקודמים.

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

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

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

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

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

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

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

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

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

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

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

מגבלות

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

לדוגמה, אם בוחרים באפשרות 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 יש מקומות שמורים שמייצגים מאגר משותף של יחידות קיבולת (slots) בחינם לפעולות מסוימות ב-BigQuery.

default-pipeline

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

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