התאמה אופקית אוטומטית לעומס

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

התאמה אוטומטית לעומס (autoscaling) אופקית נתמכת בצינורות נתונים של אצווה ושל סטרימינג.

התאמה אוטומטית לעומס (autoscaling) באצווה

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

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

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

  • ממוצע השימוש במעבד של העובד נמוך מ-5%.
  • המקביליות מוגבלת בגלל עבודה שלא ניתן להקביל, כמו נתונים שלא ניתן לפצל בגלל קבצים דחוסים או מודולים של קלט/פלט שלא מפצלים.
  • רמת המקביליות קבועה, למשל כשכותבים לקבצים קיימים ב-Cloud Storage.

כדי להגדיר גבול עליון למספר העובדים, מגדירים את --maxNumWorkers אפשרות הצינור. ערך ברירת המחדל הוא 2,000. כדי להגדיר את הגבול התחתון של מספר העובדים, מגדירים את אפשרות השירות --dataflow-service-options=min_num_workers. ההתראות האלה הן אופציונליות.

התאמה אוטומטית לעומס (autoscaling) של סטרימינג

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

כברירת מחדל, התאמה אוטומטית לעומס (autoscaling) אופקית מופעלת למשימות סטרימינג שמשתמשות ב-Streaming Engine. כדי להפעיל את ההתאמה האוטומטית לעומס האופקית לעבודות סטרימינג שלא משתמשות ב-Streaming Engine, צריך להגדיר את אפשרויות פייפליין הבאות כשמפעילים את הפייפליין:

Java

--autoscalingAlgorithm=THROUGHPUT_BASED
--maxNumWorkers=MAX_WORKERS

מחליפים את MAX_WORKERS במספר המקסימלי של מופעי worker.

Python

--autoscaling_algorithm=THROUGHPUT_BASED
--max_num_workers=MAX_WORKERS

מחליפים את MAX_WORKERS במספר המקסימלי של מופעי worker.

המשך

--autoscaling_algorithm=THROUGHPUT_BASED
--max_num_workers=MAX_WORKERS

מחליפים את MAX_WORKERS במספר המקסימלי של מופעי worker.

כדי להגדיר את הגבול התחתון של מספר העובדים, מגדירים את אפשרות השירות --dataflow-service-options=min_num_workers. כשמגדירים את הערך הזה, התאמה אוטומטית לעומס לרוחב לא תצמצם את מספר ה-workers מתחת למספר שצוין. הדגל הזה הוא אופציונלי.

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

השבתת שינוי הגודל האוטומטי האופקי

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

Java

--autoscalingAlgorithm=NONE

אם משביתים את התכונה 'שינוי גודל אוטומטי אופקי', Dataflow מגדיר את מספר העובדים על סמך האפשרות --numWorkers.

Python

--autoscaling_algorithm=NONE

אם משביתים את ההגדלה האוטומטית האופקית, Dataflow מגדיר את מספר העובדים על סמך האפשרות --num_workers.

המשך

--autoscaling_algorithm=NONE

אם משביתים את ההגדלה האוטומטית האופקית, Dataflow מגדיר את מספר העובדים על סמך האפשרות --num_workers.

מקורות בהתאמה אישית

אם יוצרים מקור נתונים בהתאמה אישית, אפשר לשפר את הביצועים באמצעות הטמעה של שיטות שמספקות יותר מידע לאלגוריתם של שינוי גודל אוטומטי אופקי:

Java

מקורות מוגבלים

  • ב-subclass‏ BoundedSource, מטמיעים את ה-method‏ getEstimatedSizeBytes. שירות Dataflow משתמש ב-getEstimatedSizeBytes כשהוא מחשב את מספר העובדים הראשוני שיידרשו לצינור.
  • ב-subclass‏ BoundedReader, מטמיעים את ה-method‏ getFractionConsumed. שירות Dataflow משתמש ב-getFractionConsumed כדי לעקוב אחרי התקדמות הקריאה ולהגיע למספר הנכון של עובדים לשימוש במהלך קריאה.

מקורות ללא הגבלה

מקור הנתונים צריך ליידע את שירות Dataflow לגבי ה-backlog. ה-Backlog הוא אומדן של הקלט בבייט שלא עבר עדיין עיבוד על ידי המקור. כדי לעדכן את השירות לגבי ה-backlog, מטמיעים אחת מהשיטות הבאות במחלקה UnboundedReader.

  • ‫getSplitBacklogBytes() – עיכוב בחלק הנוכחי של המקור. השירות צובר את העבודה שמצטברת בכל הפיצולים.
  • ‫getTotalBacklogBytes() – העומס הגלובלי בכל הפיצולים. במקרים מסוימים, ה-backlog לא זמין לכל פיצול ואפשר לחשב אותו רק בכל הפיצולים. רק בחלוקה הראשונה (מזהה החלוקה '0') צריך לספק את כמות ההזמנות המצטברות הכוללת.

מאגר Apache Beam מכיל כמה דוגמאות למקורות מותאמים אישית שמיישמים את המחלקה UnboundedReader.

Python

מקורות מוגבלים

  • ב-subclass‏ BoundedSource, מטמיעים את ה-method‏ estimate_size. שירות Dataflow משתמש בערך estimate_size כשהוא מחשב את מספר העובדים הראשוני שיידרש לשימוש בצינור עיבוד הנתונים.
  • ב-subclass‏ RangeTracker, מטמיעים את ה-method‏ fraction_consumed. שירות Dataflow משתמש ב-fraction_consumed כדי לעקוב אחרי התקדמות הקריאה ולהגיע למספר הנכון של עובדים לשימוש במהלך קריאה.

המשך

מקורות מוגבלים

  • ב-RangeTracker, מטמיעים את ה-method‏ GetProgress(). שירות Dataflow משתמש ב-GetProgress כדי לעקוב אחרי התקדמות הקריאה ולהגיע למספר הנכון של עובדים לשימוש במהלך קריאה.

מגבלות

  • במשימות שמופעלות ב-Dataflow Prime, התאמה אופקית לעומס מושבתת במהלך התאמה אנכית לעומס ועד 10 דקות אחרי. מידע נוסף זמין במאמר ההשפעה על שינוי גודל אוטומטי אופקי.
  • בפייפליינים שלא נעשה בהם שימוש ב-ארגון נתונים של Dataflow, יכול להיות ש-Dataflow לא יוכל להקטין את מספר ה-workers בצורה יעילה, כי יכול להיות שה-workers ערבבו נתונים שמאוחסנים בדיסקים מקומיים.
  • הטרנספורמציה PeriodicImpulse נתמכת בשינוי גודל אוטומטי של סטרימינג בגרסאות 2.60.0 ואילך של Apache Beam SDK. אם צינור הנתונים שלכם משתמש ב-PeriodicImpulse עם גרסת SDK קודמת, העובדים של Dataflow לא מצטמצמים כמו שציפיתם.

המאמרים הבאים