התכונה 'איזון מחדש דינמי של עומס העבודה' בשירות 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 בנושא RangeTracker.
המשך
אם בצינור העיבוד שלכם נעשה שימוש במקור נתונים מותאם אישית שאתם מספקים, אתם צריכים להטמיע RTracker תקין כדי לאפשר למקור הנתונים לעבוד עם התכונה של איזון מחדש דינמי של עומס העבודה.
מידע נוסף זמין במאמר RTracker הפניית API.
האיזון הדינמי של העבודה משתמש בערך ההחזרה של getProgress()השיטה של המקור המותאם אישית כדי להפעיל. ההטמעה שמוגדרת כברירת מחדל של getProgress() מחזירה null. כדי לוודא שהתאמה אוטומטית לעומס תופעל, צריך לוודא שהשינויים מברירת המחדל של המקור המותאם אישית שלכם יחזירו ערך מתאים.getProgress()