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

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

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

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

• טווח של שינוי גודל אוטומטי: מספר העובדים המינימלי והמקסימלי להקצאה.
• הצעה לניצול העובדים: ניצול המעבד הממוקד לעובדים.
• הצעה לשימוש במקביל ב-workers: מספר היעד של מקביליות ל-workers.
• רמת זמן האחזור: רמת הסף של ה-backlog להגדרת הרגישות של קנה המידה האוטומטי למשך ה-backlog.

הגדרת טווח של שינוי גודל אוטומטי

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

Java

• ‫--numWorkers: המספר הראשוני של העובדים שזמינים כשהצינור מתחיל לפעול
• ‫--maxNumWorkers: המספר המקסימלי של העובדים שזמינים לצנרת

Python

• ‫--num_workers: המספר הראשוני של העובדים שזמינים כשהצינור מתחיל לפעול
• ‫--max_num_workers: המספר המקסימלי של העובדים שזמינים לצינור שלך

המשך

• ‫--num_workers: המספר הראשוני של העובדים שזמינים כשהצינור מתחיל לפעול
• ‫--max_num_workers: המספר המקסימלי של העובדים שזמינים לצינור שלך

לגבי משימות סטרימינג שמשתמשות ב-Streaming Engine, הדגל --maxNumWorkers הוא אופציונלי. ערך ברירת המחדל הוא 100. במשימות סטרימינג שלא משתמשות ב-Streaming Engine, --maxNumWorkers נדרש כשמופעלת התכונה 'שינוי גודל אוטומטי אופקי'.

הערך ההתחלתי של --maxNumWorkers קובע גם כמה Persistent Disks מוקצים לעבודה. צינורות (pipelines) נפרסים עם מאגר קבוע של אחסון מתמיד (persistent disk), ששווה למספר --maxNumWorkers. במהלך הסטרימינג, מתבצעת חלוקה מחדש של דיסקים קשיחים כך שלכל worker יש מספר שווה של דיסקים מצורפים.

אם מגדירים את --maxNumWorkers, צריך לוודא שהערך מספק מספיק דיסקים לצורך הצינור. כדאי לקחת בחשבון את הצמיחה העתידית כשמגדירים את הערך ההתחלתי. מידע על הביצועים של דיסק אחסון מתמיד (persistent disk) מופיע במאמר הגדרת דיסק אחסון מתמיד (persistent disk) ומכונות וירטואליות. ב-Dataflow החיוב הוא על שימוש בדיסקים לאחסון מתמיד ויש מכסות של Compute Engine, כולל מכסות של דיסקים לאחסון מתמיד.

כברירת מחדל, המספר המינימלי של עובדים הוא 1 למשימות סטרימינג שמשתמשות ב-Streaming Engine, ו-(maxNumWorkers/15), מעוגל כלפי מעלה, למשימות שלא משתמשות ב-Streaming Engine.

עדכון טווח ההרחבה האוטומטית

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

• ‫--min-num-workers: מספר העובדים המינימלי.

• ‫--max-num-workers: המספר המקסימלי של העובדים.

gcloud

משתמשים בפקודה gcloud dataflow jobs update-options:

gcloud dataflow jobs update-options \
  --region=REGION \
  --min-num-workers=MINIMUM_WORKERS \
  --max-num-workers=MAXIMUM_WORKERS \
  JOB_ID

מחליפים את מה שכתוב בשדות הבאים:

• ‫REGION: מזהה האזור של נקודת הקצה האזורית של העבודה
• ‫MINIMUM_WORKERS: המספר המינימלי של מכונות Compute Engine
• ‫MAXIMUM_WORKERS: המספר המקסימלי של מכונות Compute Engine
• ‫JOB_ID: המזהה של העבודה שרוצים לעדכן

אפשר גם לעדכן את --min-num-workers ואת --max-num-workers בנפרד.

REST

משתמשים בשיטה projects.locations.jobs.update:

PUT https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID?updateMask=runtime_updatable_params.max_num_workers,runtime_updatable_params.min_num_workers
{
  "runtime_updatable_params": {
    "min_num_workers": MINIMUM_WORKERS,
    "max_num_workers": MAXIMUM_WORKERS
  }
}

מחליפים את מה שכתוב בשדות הבאים:

• ‫PROJECT_ID: מזהה הפרויקט Google Cloud של משימת Dataflow
• ‫REGION: מזהה האזור של נקודת הקצה האזורית של העבודה
• ‫JOB_ID: המזהה של העבודה שרוצים לעדכן
• ‫MINIMUM_WORKERS: המספר המינימלי של מכונות Compute Engine
• ‫MAXIMUM_WORKERS: המספר המקסימלי של מכונות Compute Engine

אפשר גם לעדכן את min_num_workers ואת max_num_workers בנפרד. מציינים אילו פרמטרים לעדכן בפרמטר השאילתה updateMask, וכוללים את הערכים המעודכנים בשדה runtimeUpdatableParams של גוף הבקשה. בדוגמה הבאה מופיעים עדכונים של min_num_workers:

PUT https://dataflow.googleapis.com/v1b3/projects/my_project/locations/us-central1/jobs/job1?updateMask=runtime_updatable_params.min_num_workers
{
  "runtime_updatable_params": {
    "min_num_workers": 5
  }
}

בג'ובים שלא משתמשים ב-Streaming Engine, אפשר להחליף את הג'וב הקיים בערך מעודכן של maxNumWorkers.

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

הגדרת רמז לניצול העובדים

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

כדי לקבל שליטה טובה יותר בהתנהגות של שינוי הגודל האוטומטי, אפשר להגדיר את יעד השימוש במעבד לערך בטווח [0.1, 0.9].

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

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

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

בדוגמה הבאה אפשר לראות איך משתמשים בפונקציה worker_utilization_hint:

Java

--dataflowServiceOptions=worker_utilization_hint=TARGET_UTILIZATION

מחליפים את TARGET_UTILIZATION בערך בטווח [0.1, 0.9].

Python

--dataflow_service_options=worker_utilization_hint=TARGET_UTILIZATION

מחליפים את TARGET_UTILIZATION בערך בטווח [0.1, 0.9].

המשך

--dataflow_service_options=worker_utilization_hint=TARGET_UTILIZATION

מחליפים את TARGET_UTILIZATION בערך בטווח [0.1, 0.9].

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

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

עדכון רמז הניצול

כדי לעדכן את רמז הניצול בזמן שהעבודה פועלת, מבצעים עדכון בזמן הריצה באופן הבא:

gcloud

משתמשים בפקודה gcloud dataflow jobs update-options:

gcloud dataflow jobs update-options \
  --region=REGION \
  --worker-utilization-hint=TARGET_UTILIZATION \
  JOB_ID

מחליפים את מה שכתוב בשדות הבאים:

• ‫REGION: מזהה האזור של נקודת הקצה האזורית של העבודה
• ‫JOB_ID: המזהה של העבודה שרוצים לעדכן
• ‫TARGET_UTILIZATION: ערך בטווח [0.1, 0.9]

כדי לאפס את רמז הניצול לערך ברירת המחדל, משתמשים בפקודת gcloud הבאה:

gcloud dataflow jobs update-options \
  --unset-worker-utilization-hint \
  --region=REGION \
  --project=PROJECT_ID \
  JOB_ID

REST

משתמשים בשיטה projects.locations.jobs.update:

PUT https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID?updateMask=runtime_updatable_params.worker_utilization_hint
{
  "runtime_updatable_params": {
    "worker_utilization_hint": TARGET_UTILIZATION
  }
}

מחליפים את מה שכתוב בשדות הבאים:

• ‫PROJECT_ID: Google Cloud מזהה הפרויקט של משימת Dataflow.
• ‫REGION: מזהה האזור של נקודת הקצה האזורית של העבודה.
• ‫JOB_ID: המזהה של העבודה שרוצים לעדכן.
• ‫TARGET_UTILIZATION: ערך בטווח [0.1, 0.9]

הגדרת רמז לגבי מקביליות של עובדים

כדי לטפל בשינוי גודל אוטומטי עם פעולות ארוכות שלא מסתמכות על מעבדים, כמו עומסי עבודה אינטנסיביים של למידת מכונה, אפשר להגדיר את רמז המקביליות של העובד באמצעות רמזי משאבים של Apache Beam. ההצעות האלה מעבירות את קנה המידה האוטומטי למצב אחר שממוטב לעומסי עבודה (workloads) שדורשים שימוש אינטנסיבי ב-GPU או לטרנספורמציות עם זמן עיבוד ארוך.

בדוגמה הבאה אפשר לראות איך לצרף רמז מקביליות לטרנספורמציה:

Java

pcoll.apply(MyCompositeTransform.of(...)
  .setResourceHints(
      ResourceHints.create()
          .withMaxActiveBundlesPerWorker(TARGET_PARALLELISM_PER_WORKER)))

מחליפים את TARGET_PARALLELISM_PER_WORKER בערך שמתאים לתרחיש לדוגמה. הנחיות כלליות זמינות במאמר איך בוחרים ערך התחלתי טוב.

Python

pcoll | MyPTransform().with_resource_hints(
  max_active_bundles_per_worker="TARGET_PARALLELISM_PER_WORKER")

מחליפים את TARGET_PARALLELISM_PER_WORKER בערך שמתאים לתרחיש לדוגמה. הנחיות כלליות זמינות במאמר איך בוחרים ערך התחלתי טוב.

בחירת ערך לרמז על מקביליות העובדים

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

בתרחישי שימוש אחרים, צינור הנתונים מוגבל על ידי הזיכרון או על ידי המעבד. בצינורות שמוגבלים על ידי הזיכרון, משתמשים במגבלת הזיכרון כדי לחשב את העיבוד המקביל המקסימלי. בצינורות (pipelines) שמוגבלים על ידי CPU, מומלץ להשתמש במדיניות ברירת המחדל של שינוי הגודל האוטומטי, במקום לספק רמז לגבי מקביליות.

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

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

היוריסטיקות של התאמה אוטומטית לעומס שדורשת שימוש אינטנסיבי ב-GPU

בהגדרה שדורשת שימוש אינטנסיבי במעבד גרפי, שמצוינת באמצעות setting parallelism hint,‏ Dataflow לוקח בחשבון כמה גורמים כשמבצעים שינוי אוטומטי של קנה המידה. הגורמים האלה כוללים:

• המקשים הזמינים. מפתחות הם יחידת הבסיס של מקביליות ב-Dataflow.
• מספר חבילות התכנים הפעילות המקסימלי לכל עובד. הערך הזה מציין את המספר המקסימלי האידיאלי של מקביליות העיבוד בתהליך העבודה.

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

אם צינור הנתונים מורכב וכולל עומס עבודה כבד שדורש שימוש רב ב-GPU וגם המרות רבות שדורשות שימוש רב במעבד, מומלץ להפעיל התאמה נכונה. כך השירות יכול להבדיל בין עבודה שדורשת הרבה משאבי CPU לבין עבודה שדורשת הרבה משאבי GPU, ואז לשנות את הגודל של כל מאגר עובדים בהתאם.

הגדרת רמת זמן האחזור

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

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

בטבלה הבאה מתוארות רמות השהייה הזמינות:

רמת זמן האחזור	הזמן המשוער המקסימלי של עומס העבודה	תרחיש השימוש המיועד
low_latency	פחות מ-15 שניות	העדיפות היא להרחבה מהירה כדי לצמצם את כמות הפריטים שממתינים לטיפול. ערך ברירת המחדל שנבחר אם לא צוינה רמה
medium_latency	פחות מ-2 דקות	איזון בין זמן האחזור לעלויות המשאבים.
high_latency	פחות מ-10 דקות	העדיפות היא לחיסכון בעלויות, ולכן המערכת מאפשרת להצטברות של בקשות להגיע למצב של צוואר בקבוק. מיועד לעומסי עבודה (workloads) שסובלים השהיה.

כדי להגדיר את רמת השהייה כשמריצים עבודה, מגדירים את enable_latency_tier_lightweight_update experiment flag:

--experiments=enable_latency_tier_lightweight_update=TIER

מחליפים את TIER באחת מרמות השהייה הזמינות (לדוגמה, medium_latency).

עדכון רמת זמן האחזור

כדי לעדכן את רמת השהייה בזמן שהעבודה פועלת, מבצעים עדכון בזמן הריצה באמצעות הפקודה gcloud dataflow jobs update-options:

gcloud dataflow jobs update-options \
  --region=REGION \
  --latency-tier=TIER \
  JOB_ID

מחליפים את מה שכתוב בשדות הבאים:

• ‫REGION: מזהה האזור של נקודת הקצה האזורית של העבודה
• ‫JOB_ID: המזהה של העבודה שרוצים לעדכן
• ‫TIER: רמת זמן האחזור של היעד. אחד מהערכים הבאים: low_latency,‏ medium_latency או high_latency

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

gcloud dataflow jobs update-options \
  --unset-latency-tier \
  --region=REGION \
  JOB_ID

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

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

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

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

• יעד לניצול המעבד. יעד ברירת המחדל לניצול ממוצע של המעבד הוא 0.8. אפשר לשנות את הערך הזה.

• המקשים הזמינים. מפתחות הם יחידת הבסיס של מקביליות ב-Dataflow.

במקרים מסוימים, מערכת Dataflow משתמשת בגורמים הבאים כדי לקבל החלטות לגבי שינוי גודל אוטומטי. אם הגורמים האלה משמשים בעבודה שלכם, תוכלו לראות את המידע הזה בכרטיסיית המדדים Autoscaling.

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

• הפחתת תנודות בשינוי גודל. אם Dataflow מזהה שהתקבלו החלטות לא יציבות לגבי שינוי גודל אוטומטי, הוא מאט את קצב ההקטנה כדי לשפר את היציבות.

• הגדלה על בסיס CPU משתמשת בניצול גבוה של CPU כקריטריון להגדלה.

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

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

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

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

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

מדדים

כדי למצוא את המגבלות הנוכחיות של שינוי הגודל האוטומטי של משימה, שולחים שאילתה למדדים הבאים:

• ‫job/max_worker_instances_limit: מספר העובדים המקסימלי.
• ‫job/min_worker_instances_limit: המספר המינימלי של העובדים.

כדי לקבל מידע על ניצול העובדים, שולחים שאילתה לגבי המדדים הבאים:

• ‫job/aggregated_worker_utilization: ניצול העובדים המצטבר.
• ‫job/worker_utilization_hint: רמז לגבי ניצול העובדים הנוכחי.

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

• ‫job.worker_utilization_hint_is_actively_used: מציין אם המערכת להגדלת נפח העבודה משתמשת באופן פעיל ברמז לניצול העובדים. אם גורמים אחרים מבטלים את הרמז כשדוגמים את המדד הזה, הערך הוא false.
• ‫job/horizontal_worker_scaling: תיאור של ההחלטות שהתקבלו על ידי הכלי להתאמת קנה מידה אוטומטית. המדד הזה מכיל את התוויות הבאות:
  • ‫direction: מציין אם בוצעה הגדלה או הקטנה של הקיבולת על ידי הכלי לשינוי גודל אוטומטי, או שלא בוצעה פעולה.
  • ‫rationale: מציין את ההצדקה להחלטה של הכלי לשינוי גודל אוטומטי.

מידע נוסף זמין במאמר בנושא מדדים של Cloud Monitoring. המדדים האלה מוצגים גם בתרשימי המעקב של שינוי הגודל האוטומטי.

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

• מעקב אחרי שינוי גודל אוטומטי של Dataflow
• פתרון בעיות בהתאמת גודל אוטומטית ב-Dataflow