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

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

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

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

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

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

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

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

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

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

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

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

  • בכל פרויקט Google Cloud אפשר לשלוח עד 3,000,000 בקשות לדקה.
  • בכל משימת Dataflow אפשר להשתמש ב-2,000 מכונות של Compute Engine לכל היותר. בלי לציין אזור של Worker, כל משימת סטרימינג שמשתמשת ב-Streaming Engine או כל משימה באצווה שמשתמשת ב-Dataflow Shuffle מבוסס-שירות יכולה להשתמש ב-4,000 מכונות Compute Engine לכל היותר.
  • בכל פרויקט ב- Google Cloud אפשר להריץ כברירת מחדל עד 25 משימות Dataflow בו-זמנית.
  • לכל worker של Dataflow יש מגבלה מקסימלית של יומנים שהוא יכול להפיק במרווח זמן מסוים. לעיון במסמכי התיעוד של רישום ביומן לגבי המגבלה המדויקת
  • אם תבחרו להשתמש במכסות ברמת הארגון, כל ארגון יוכל להריץ כברירת מחדל עד 125 משימות Dataflow בו-זמנית.
  • כל משתמש יכול לשלוח עד 15,000 בקשות מעקב בדקה.
  • כל משתמש יכול לשלוח עד 60 בקשות ליצירת משימות בדקה.
  • כל משתמש יכול לשלוח עד 60 בקשות לתבניות של משרות בדקה.
  • כל משתמש יכול לשלוח עד 60 בקשות לעדכון משרות בדקה.
  • כל פרויקט ב- Google Cloud מקבל את משבצות ה-Shuffle הבאות בכל אזור:
    • ‫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 משבצות מספיקות כדי לערבב בערך 10TB של נתונים בו-זמנית.
  • משימות באצ' ב-Dataflow יבוטלו אחרי 10 ימים.

מכסות ב-Compute Engine

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

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

  • ‫מעבדי CPU: באזורים הבאים, סוגי המכונות שמוגדרים כברירת מחדל ל-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.

  • כתובות IP בשימוש: מספר כתובות ה-IP שבשימוש בפרויקט צריך להספיק למספר המכונות הרצוי. כדי להשתמש ב-10 מכונות של Compute Engine, תצטרכו 10 כתובות IP בשימוש.
  • ‫Persistent Disk: שירות Dataflow מחבר Persistent Disk לכל מכונה.
    • גודל הדיסק שמוגדר כברירת מחדל הוא 250GB לפייפליינים של אצווה ו-400GB לפייפליינים זורמים. כברירת מחדל, ל-10 מכונות צריך 2,500GB של Persistent Disk למשימה באצווה.
    • גודל ברירת המחדל של הדיסק הוא 25GB לצינורות עיבוד נתונים באצווה של Dataflow Shuffle.
    • גודל ברירת המחדל של הדיסק הוא 30GB לפייפליינים זורמים של Streaming Engine.
    • נכון לעכשיו, שירות Dataflow מוגבל ל-15 דיסקים קבועים לכל מכונה של Worker כשמריצים משימת סטרימינג. כל דיסק אחסון מתמיד הוא מקומי למכונה וירטואלית ספציפית של Compute Engine. הקצאת המשאבים המינימלית היא יחס של 1:1 בין ה-workers לדיסקים.
    • השימוש ב-Compute Engine מבוסס על המספר הממוצע של ה-workers, ואילו השימוש ב-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 ונגדיל את המגבלה לערך שמתאים יותר לצרכים שלכם. מכסת ברירת המחדל היא 25 משימות Dataflow בו-זמניות לפרויקט, או 125 משימות Dataflow בו-זמניות לארגון.

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

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

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