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

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

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

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

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

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

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

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

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

התאמה אוטומטית לעומס בסטרימינג

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

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

Java

--autoscalingAlgorithm=THROUGHPUT_BASED
--maxNumWorkers=MAX_WORKERS

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

Python

--autoscaling_algorithm=THROUGHPUT_BASED
--max_num_workers=MAX_WORKERS

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

Go

--autoscaling_algorithm=THROUGHPUT_BASED
--max_num_workers=MAX_WORKERS

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

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

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

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

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

Java

--autoscalingAlgorithm=NONE

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

Python

--autoscaling_algorithm=NONE

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

Go

--autoscaling_algorithm=NONE

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

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

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

Java

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

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

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

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

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

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

Python

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

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

Go

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

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

מגבלות

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

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