מכסות ומגבלות

במאמר הזה מוסבר על מכסות ומגבלות המערכת של Dataflow.

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

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

מערכת המכסות ב-Cloud:

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

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

לסקירה כללית על מכסות ב-Cloud

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

למשאבי Dataflow יש גם מגבלות מערכת. שאי אפשר לשנות.

לשירות מנוהל של Dataflow יש את המכסות והמגבלות הבאות:

  • כל פרויקט ב-Google Cloud Platform יכול לשלוח עד 3,000,000 בקשות בדקה.
  • כל משימת Dataflow יכולה להשתמש בעד 2,000 מכונות של Compute Engine. אם לא מציינים אזור של עובדים, כל משימת סטרימינג באמצעות Streaming Engine או משימה באצווה באמצעות ארגון נתונים של Dataflow מבוסס-שירות יכולה להשתמש ב-4,000 מכונות לכל היותר של Compute Engine.
  • בכל פרויקט של Google Cloud Platform אפשר להריץ לכל היותר 25 עבודות Dataflow בו-זמנית כברירת מחדל.
  • לכל תהליך עבודה של Dataflow יש מגבלה מקסימלית של יומנים שהוא יכול להפיק במרווח זמן מסוים. הגבול המדויק מופיע במסמכי התיעוד בנושא רישום ביומן.
  • אם תפעילו את האפשרות להגדרת מכסות ברמת הארגון, כל ארגון יוכל להריץ לכל היותר 125 משימות Dataflow בו-זמנית כברירת מחדל.
  • כל משתמש יכול לשלוח עד 15,000 בקשות מעקב בדקה.
  • כל משתמש יכול לשלוח עד 60 בקשות ליצירת משימות בדקה.
  • כל משתמש יכול לשלוח עד 60 בקשות לתבניות משרות בדקה.
  • כל משתמש יכול לשלוח עד 60 בקשות לעדכון על משרה בדקה.
  • לכל פרויקט ב-Google Cloud Platform יש את חריצי הערבוב הבאים בכל אזור:
    • ‫asia-east1: 48 משבצות
    • ‫asia-northeast1: 24 משבצות
    • ‫asia-northeast3: 32 משבצות
    • ‫asia-south1: ‏ 64 משבצות
    • ‫asia-southeast1: 64 משבצות
    • ‫australia-southeast1: ‏ 24 משבצות
    • ‫europe-west1: 640 משבצות
    • ‫europe-west2: 32 משבצות
    • ‫europe-west3: 40 חריצים
    • ‫europe-west4: 640 משבצות
    • ‫northamerica-northeast1: 512 משבצות
    • ‫us-central1: 640 משבצות
    • ‫us-east1: 640 משבצות
    • ‫us-east4: 64 משבצות
    • ‫us-west1: 384 חריצים
    • ‫us-west2: 24 חריצים
    • ‫us-west3: 24 חריצים
    • אחרים: 16 משבצות
    16 משבצות מספיקות כדי לערבב בו-זמנית כ-10 TB של נתונים.
  • משימות אצווה של Dataflow יבוטלו אחרי 10 ימים.

מכסות ב-Compute Engine

כשמריצים את צינור הנתונים בשירות Dataflow,‏ Dataflow יוצר מכונות של Compute Engine כדי להריץ את קוד צינור הנתונים.

המכסה של Compute Engine מוגדרת לכל אזור. בודקים את המכסה של Compute Engine בפרויקט ומבקשים את השינויים הבאים אם צריך:

  • ‫CPUs: באזורים הבאים, סוגי המכונות שמוגדרים כברירת מחדל ל-Dataflow הם n1-standard-1 לעיבוד באצווה, n1-standard-2 לעבודות שמשתמשות ב-Streaming Engine,‏ n1-standard-4 לעבודות סטרימינג שלא משתמשות ב-Streaming Engine ו-n1-standard-2 לעבודות שמשתמשות בתזמון גמיש של משאבים (FlexRS). ‫FlexRS משתמש ב-90% מכונות וירטואליות שניתנות להפסקת פעולה וב-10% מכונות וירטואליות רגילות.
    • asia-east1
    • asia-east2
    • asia-northeast1
    • asia-northeast2
    • asia-northeast3
    • asia-south1
    • asia-south2
    • asia-southeast1
    • asia-southeast2
    • australia-southeast1
    • australia-southeast2
    • europe-central2
    • europe-north1
    • europe-west1
    • europe-west2
    • europe-west3
    • europe-west4
    • europe-west5
    • europe-west6
    • northamerica-northeast1
    • northamerica-northeast2
    • southamerica-east1
    • us-central1
    • us-central2
    • us-east1
    • us-east4
    • us-west1
    • us-west2
    • us-west3
    • us-west4

    באזורים אחרים, סוגי המכונות שמוגדרים כברירת מחדל הם e2-standard-2 לעיבוד באצווה, e2-standard-2 לעבודות שמשתמשות ב-Streaming Engine,‏ e2-standard-4 לעבודות סטרימינג שלא משתמשות ב-Streaming Engine ו-e2-standard-2 לעבודות שמשתמשות ב-FlexRS.

    ‫Compute Engine מחשב את מספר המעבדים על ידי סיכום של ספירת המעבדים הכוללת של כל מופע. לדוגמה, הפעלת 10 מכונות וירטואליות מסוג n1-standard-4 נחשבת כ-40 ליבות CPU. במאמר סוגי מכונות ב-Compute Engine מפורט מיפוי של סוגי מכונות למספר ליבות ה-CPU.

  • כתובות IP בשימוש: מספר כתובות ה-IP בשימוש בפרויקט צריך להיות מספיק כדי להכיל את מספר המכונות הרצוי. כדי להשתמש ב-10 מכונות Compute Engine, תצטרכו 10 כתובות IP בשימוש.
  • דיסק אחסון מתמיד:‏ Dataflow מצרף דיסק אחסון מתמיד לכל מופע.
    • גודל ברירת המחדל של הדיסק הוא 250GB עבור אצוות ו-400GB עבור צינורות להזרמת נתונים. ל-10 מופעים, כברירת מחדל צריך 2,500GB של Persistent Disk למשימת אצווה.
    • גודל ברירת המחדל של הדיסק הוא 25 GB עבור צינורות ארגון נתונים של Dataflow batch.
    • גודל ברירת המחדל של הדיסק הוא 30 GB לצינורות סטרימינג של Streaming Engine.
    • השירות Dataflow מוגבל כרגע ל-15 דיסקים קבועים לכל מופע Worker כשמריצים משימת סטרימינג. כל דיסק אחסון מתמיד הוא מקומי למכונה וירטואלית ספציפית ב-Compute Engine. הקצאת המשאבים המינימלית היא יחס של 1:1 בין העובדים לדיסקים.
    • השימוש ב-Compute Engine מבוסס על המספר הממוצע של העובדים, ואילו השימוש ב-Persistent Disk מבוסס על הערך המדויק של --maxNumWorkers. דיסקים של אחסון מתמיד מוקצים מחדש כך שלכל worker יש מספר שווה של דיסקים מצורפים.
  • קבוצות מופעי מכונה מנוהלים אזוריות:‏ Dataflow פורס את המכונות ב-Compute Engine כקבוצת מופעי מכונה מנוהלים אזורית. תצטרכו לוודא שיש לכם מכסה זמין שקשור לדברים הבאים:
    • קבוצת מופעים אחת לכל משימת Dataflow
    • תבנית מכונה אחת לכל משימת Dataflow
    • קבוצת מופעי מכונה מנוהלים אזורית אחת לכל משימת Dataflow
  • אם קבוצות של מופעים מנוהלים חסרות למשימת סטרימינג במשך יותר מ-7 ימים, המשימה מבוטלת.
  • אם קבוצות של מופעים מנוהלים חסרות לעבודת אצווה במשך יותר משעה, העבודה מבוטלת.

מכסות נוספות

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

  1. ‫Pub/Sub: אם אתם משתמשים ב-Pub/Sub, יכול להיות שתצטרכו מכסה נוספת. כשמתכננים את המכסה, חשוב לזכור שעיבוד של הודעה אחת מ-Pub/Sub כולל 3 פעולות. אם אתם משתמשים בחותמות זמן מותאמות אישית, כדאי להכפיל את מספר הפעולות הצפוי, כי Dataflow ייצור מינוי נפרד כדי לעקוב אחרי חותמות זמן מותאמות אישית.
  2. ‫BigQuery: אם אתם משתמשים ב-Streaming API ל-BigQuery, חלים מגבלות מכסה והגבלות אחרות.

חיפוש והגדלה של מכסות

אפשר לבדוק את השימוש הנוכחי במכסה שספציפית ל-Dataflow:

  1. במסוף Google Cloud , נכנסים אל APIs & services.
    עוברים אל API & Services
  2. כדי לבדוק את ניצול המכסה הנוכחי של ערוצים אקראיים, בכרטיסייה Quotas, מוצאים את השורה Shuffle slots בטבלה ובעמודה Usage Chart לוחצים על Show usage chart.

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

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

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

שירות Dataflow גם מפעיל רכיבים שונים של Google Cloud, כמו BigQuery,‏ Cloud Storage,‏ Pub/Sub ו-Compute Engine. השירותים האלה (ושירותים אחרים של Google Cloud ) משתמשים במכסות כדי להגביל את המספר המקסימלי של משאבים שאפשר להשתמש בהם בפרויקט. כשמשתמשים ב-Dataflow, יכול להיות שיהיה צורך לשנות את הגדרות המכסה בשירותים האלה.

‫Dataflow Prime

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

מגבלות

בקטע הזה מתוארות מגבלות מעשיות בייצור של Dataflow.

הגבלה סכום
מספר העובדים המקסימלי לכל צינור. 2,000
הגודל המקסימלי של בקשה ליצירת משימה. יכול להיות שתיאורי צינורות עם הרבה שלבים ושמות ארוכים מאוד יגיעו למגבלה הזו. ‫10 MB
הגודל המקסימלי של בקשה להפעלת תבנית. ‫1 MB
המספר המקסימלי של רסיסי קלט צדדי. 20,000
הגודל המקסימלי של רכיב בודד (אלא אם חלים תנאים מחמירים יותר, למשל ב-Streaming Engine). ‫2 GB
הגודל המקסימלי של מפתח בצינורות להעברת נתונים באצווה. ‫1.5 MB
המספר המקסימלי של רשומות ביומן בתקופת זמן מסוימת, לכל עובד. ‫15,000 הודעות כל 30 שניות
המספר המקסימלי של מדדים מותאמים אישית לכל פרויקט. 100
משך הזמן שבו ההמלצות יישמרו. 30 ימים
מגבלות של מנוע סטרימינג סכום
הגודל המקסימלי בבייטים של הודעות Pub/Sub. ‫7 MB
הגודל המקסימלי של ערך של רכיב יחיד. ‫80 MB
הגודל המקסימלי של מקש גדול. מפתחות בגודל של יותר מ-64 KB גורמים לירידה בביצועים. ‫2 MB
הגודל המקסימלי של קלט צדדי. ‫80 MB
האורך המקסימלי של תגי מצב שמשמשים את TagValue ואת TagBag. ‫64 KB