מכסות בקשה

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

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

זהירות: שינוי ידני של משאבי Compute Engine שמנוהלים על ידי Dataflow ומשויכים למשימת Dataflow הוא פעולה שלא נתמכת. אל תנסו להפסיק, למחוק או לשלוט בדרך אחרת במכונות של Compute Engine שנוצרו על ידי Dataflow כדי להריץ את העבודה. בנוסף, אסור לשנות משאבי דיסק אחסון מתמיד (persistent disk) שמשויכים לעבודת Dataflow.

תעסוקה

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

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

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

Java

--dataflowJobFile=<path to output file>

Python

--dataflow_job_file=<path to output file>

Go

בשלב הזה, אי אפשר להשתמש ב-Go כדי להעריך את הגודל של מטען ה-JSON של משימה באמצעות דגל.

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

מידע נוסף זמין בדף פתרון הבעיות בנושא '413 Request Entity Too Large' / 'The size of serialized JSON representation of the pipeline exceeds the allowable limit'.

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

עובדים

נכון לעכשיו, שירות Dataflow מאפשר ליצור לכל היותר 1,000 מכונות של Compute Engine לכל משימה. למשימות באצווה, סוג ברירת המחדל של המכונה הוא n1-standard-1. במשימות סטרימינג, סוג המכונה שמוגדר כברירת מחדל למשימות עם Streaming Engine הוא n1-standard-2, וסוג המכונה שמוגדר כברירת מחדל למשימות ללא Streaming Engine הוא n1-standard-4. לכן, כשמשתמשים בסוגי המכונות שמוגדרים כברירת מחדל, שירות Dataflow יכול להקצות עד 4,000 ליבות לכל משימה. אם אתם צריכים יותר ליבות לעבודה, אתם יכולים לבחור סוג מכונה גדול יותר.

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

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

אפשר להשתמש בכל אחת ממשפחות סוגי המכונות הזמינות ב-Compute Engine, וגם בסוגי מכונות בהתאמה אישית. כדי לקבל את התוצאות הטובות ביותר, מומלץ להשתמש בn1 סוגי מכונות. סוגי מכונות ליבה משותפים, כמו workers מסדרות f1 ו-g1, לא נתמכים במסגרת הסכם רמת השירות של Dataflow.

כדי להקצות זיכרון נוסף לכל Thread עובד, משתמשים בסוג מכונה בהתאמה אישית עם זיכרון מורחב. לדוגמה, custom-2-15360-ext הוא סוג מכונה n1 עם 2 מעבדים ו-15 GB של זיכרון. מערכת Dataflow מתחשבת במספר המעבדים במכונה כדי לקבוע את מספר השרשורים של העובדים לכל worker VM. אם ה-pipeline שלכם מעבד עבודה שדורשת הרבה זיכרון, סוג מכונה בהתאמה אישית עם זיכרון מורחב יכול לספק יותר זיכרון לכל Thread עובד. מידע נוסף זמין במאמר בנושא יצירת מופע VM בהתאמה אישית.

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

שימו לב: סוגי מכונות ליבה משותפים כמו workers מסדרות f1 ו-g1 לא נתמכים במסגרת הסכם רמת השירות של Dataflow.

Java

כדי לשנות את סוג המכונה, מגדירים את האפשרות --workerMachineType.

Python

כדי לשנות את סוג המכונה, מגדירים את האפשרות --worker_machine_type.

Go

כדי לשנות את סוג המכונה, מגדירים את האפשרות ‑‑worker_machine_type.

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

מכסת משאבים

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

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

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

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

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

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

כתובות IP

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

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

• פרמטר של כתובת IP ציבורית
• גישה לאינטרנט ב-Dataflow

עובדים לא פעילים

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

• פתרון בעיות במאגרי תגים בהתאמה אישית ב-Dataflow
• שגיאה בסנכרון של ה-Pod… נכשלה הפעולה StartContainer

משאבים של Persistent Disk

שירות Dataflow מוגבל ל-15 דיסקים קבועים לכל מופע עובד כשמריצים משימת סטרימינג. כל דיסק אחסון מתמיד (persistent disk) הוא מקומי למכונה וירטואלית ספציפית של Compute Engine. במשימה לא יכולים להיות יותר עובדים מדיסקים קשיחים. הקצאת המשאבים המינימלית היא יחס של 1:1 בין עובדים לדיסקים.

משימות שמשתמשות ב-Streaming Engine משתמשות בדיסקים לאתחול בנפח 30GB. משימות שמשתמשות בארגון נתונים של Dataflow משתמשות בדיסקים לאתחול בנפח 25GB. במשימות שלא משתמשות בפתרונות האלה, גודל ברירת המחדל של כל דיסק אחסון מתמיד (persistent disk) הוא 250GB במצב אצווה ו-400GB במצב סטרימינג.

מיקומים

כברירת מחדל, שירות Dataflow פורס משאבי Compute Engine באזור us-central1-f בתחום us-central1. אפשר לציין את הפרמטר --region כדי לשנות את ההגדרה הזו. אם אתם צריכים להשתמש באזור ספציפי בשביל המשאבים, אתם יכולים להשתמש בפרמטר --zone כשאתם יוצרים את צינור הנתונים. עם זאת, מומלץ לציין רק את האזור ולא את האזור הספציפי. האפשרות הזו מאפשרת לשירות Dataflow לבחור באופן אוטומטי את האזור הטוב ביותר באזור על סמך קיבולת האזור הזמינה בזמן בקשת יצירת העבודה. מידע נוסף זמין במאמר בנושא אזורי Dataflow.