התכונה 'איזון מחדש דינמי של עומס העבודה' בשירות Dataflow מאפשרת לשירות לבצע חלוקה מחדש דינמית של עומס העבודה על סמך תנאי זמן הריצה. התנאים האלה עשויים לכלול:
- חוסר איזון במטלות העבודה
- העובדים מסיימים את העבודה יותר לאט מהצפוי
- העובדים מסיימים מהר יותר מהצפוי
שירות Dataflow מזהה את התנאים האלה באופן אוטומטי ויכול להקצות באופן דינמי עבודה לעובדים שלא נמצאים בשימוש או שנמצאים בשימוש חלקי, כדי לקצר את זמן העיבוד הכולל של העבודה. מידע נוסף על האופן שבו Dataflow מפזרת את הביצוע ומשנה את קנה המידה שלו זמין במאמר הסבר על מקביליות ב-Dataflow.
מגבלות
איזון מחדש דינמי של עבודה מתבצע רק כששירות Dataflow מעבד נתוני קלט מסוימים במקביל: כשקוראים נתונים ממקור קלט חיצוני, כשעובדים עם PCollection מגובש או כשעובדים עם תוצאה של צבירה כמו GroupByKey. אם מספר גדול של שלבים בעבודה מוזגו, יש בעבודה פחות PCollections ביניים, ואיזון מחדש דינמי של העבודה מוגבל למספר הרכיבים ב-PCollection המקור שנוצר. אם רוצים לוודא שאפשר להחיל איזון מחדש דינמי של עבודה על PCollection מסוים בצינור, אפשר למנוע מיזוג בכמה דרכים שונות כדי להבטיח מקביליות דינמית.
אי אפשר להשתמש באיזון דינמי של עומסי עבודה כדי לבצע מחדש את ההקבלה של נתונים ברמת דיוק גבוהה יותר מרשומה אחת. אם הנתונים מכילים רשומות נפרדות שגורמות לעיכובים גדולים בזמן העיבוד, יכול להיות שהן עדיין יעכבו את העבודה. Dataflow לא יכול לחלק מחדש רשומה 'פעילה' ספציפית לכמה עובדים.
Java
אם מגדירים מספר קבוע של רסיסים לפלט הסופי של צינור הנתונים (לדוגמה, על ידי כתיבת נתונים באמצעות TextIO.Write.withNumShards), Dataflow מגביל את ההפעלה המקבילית על סמך מספר הרסיסים שבוחרים.
Python
אם מגדירים מספר קבוע של רסיסים לפלט הסופי של צינור הנתונים (לדוגמה, על ידי כתיבת נתונים באמצעות beam.io.WriteToText(..., num_shards=...)), Dataflow מגביל את ההפעלה המקבילית על סמך מספר הרסיסים שבוחרים.
המשך
אם מגדירים מספר קבוע של רסיסים לפלט הסופי של צינור עיבוד הנתונים, Dataflow מגביל את ההפעלה המקבילית על סמך מספר הרסיסים שבוחרים.
איך עובדים עם מקורות נתונים מותאמים אישית
Java
אם הצינור שלכם משתמש במקור נתונים מותאם אישית שאתם מספקים, אתם צריכים להטמיע את השיטה splitAtFraction כדי לאפשר למקור לעבוד עם התכונה של איזון מחדש דינמי של העבודה.
אם תטמיעו את splitAtFraction בצורה שגויה, יכול להיות שרשומות מהמקור שלכם יופיעו ככפולות או יימחקו. למידע נוסף על הטמעה של splitAtFraction, אפשר לעיין במאמרי העזרה של ה-API בנושא RangeTracker לקבלת עזרה וטיפים.
Python
אם צינור הנתונים משתמש במקור נתונים בהתאמה אישית שאתם מספקים, RangeTracker צריך להטמיע את try_claim, try_split, position_at_fraction ו-fraction_consumed כדי לאפשר למקור הנתונים לפעול עם התכונה של איזון מחדש דינמי של העבודה.
מידע נוסף זמין במאמר API reference information on RangeTracker.
המשך
אם בצינור שלכם נעשה שימוש במקור נתונים מותאם אישית שאתם מספקים, אתם צריכים להטמיע RTracker תקין כדי לאפשר למקור לעבוד עם התכונה של איזון מחדש דינמי של עומס העבודה.
מידע נוסף זמין במאמר RTracker API reference information.
האיזון הדינמי של העבודה משתמש בערך ההחזרה של getProgress()השיטה של המקור המותאם אישית כדי להפעיל. ההטמעה שמוגדרת כברירת מחדל של getProgress() מחזירה null. כדי לוודא שהשינוי האוטומטי של גודל הקבוצה יופעל, צריך לוודא שההגדרות של מקור מותאם אישית יחליפו את ההגדרות של getProgress() ויחזירו ערך מתאים.