בקשת מכסות

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

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

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

תעסוקה

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

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

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

Java

--dataflowJobFile=<path to output file>

Python

--dataflow_job_file=<path to output file>

המשך

בשלב הזה, אין תמיכה ב-Go בהערכת הגודל של מטען ייעודי (payload) בפורמט 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 לכל משימה. לגבי עבודות באצווה, סוג המכונה שמוגדר כברירת מחדל הוא סוג מכונה עם vCPU אחד. במשימות של סטרימינג, סוג המכונה שמוגדר כברירת מחדל למשימות עם Streaming Engine הוא סוג מכונה עם 2 ליבות vCPU, וסוג המכונה שמוגדר כברירת מחדל למשימות ללא Streaming Engine הוא סוג מכונה עם 4 ליבות vCPU. אם אתם צריכים יותר ליבות לעבודה, אתם יכולים לבחור סוג מכונה גדול יותר.

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

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

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

כדי להקצות זיכרון נוסף לכל שרשור של עובד, משתמשים בסוג מכונה מותאם אישית עם זיכרון מורחב. לדוגמה, סוג מכונה בהתאמה אישית עם 2 ליבות vCPU ו-15GB של זיכרון יכול לספק יותר זיכרון לכל Thread עובד. ‫Dataflow מתחשב במספר המעבדים במכונה כדי לקבוע את מספר השרשורים של העובדים לכל מכונה וירטואלית של עובד. אם צינור העיבוד שלכם מבצע עבודה שדורשת הרבה זיכרון, סוג מכונה בהתאמה אישית עם זיכרון מורחב יכול לספק יותר זיכרון לכל Thread עובד. מידע נוסף זמין במאמר יצירת מופע של מכונה וירטואלית בהתאמה אישית.

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

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

Java

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

Python

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

המשך

כדי לשנות את סוג המכונה, מגדירים את האפשרות ‑‑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

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

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

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

משאבים של דיסק אחסון מתמיד (persistent disk)

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

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

מיקומים

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