שיטות מומלצות לאופטימיזציה של העלויות ב-Dataflow

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

מידע נוסף על אופן חישוב העלויות של משימות Dataflow זמין במאמר תמחור Dataflow.

יש כמה גורמים שיכולים להשפיע באופן משמעותי על עלות העבודה:

  • הגדרות זמן ריצה
  • ביצועים של צינורות עיבוד נתונים
  • דרישות לגבי קצב העברת הנתונים בצינור

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

הגדרת יעדים למדידת רמת השירות (SLO)

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

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

מעקב אחרי משימות

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

מעקב אחרי העלויות

כדי לחזות את העלויות ולעקוב אחריהן, כדאי להשתמש בשיטות הבאות.

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

מעקב אחר משרות

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

  • אפשר להשתמש בממשק למעקב אחרי משימות ב-Dataflow כדי לזהות בעיות בצינורות עיבוד הנתונים. בממשק המעקב מוצג תרשים של העבודה ופרטי הביצוע של כל צינור. שני הכלים האלה יכולים לעזור לכם להבין את הפייפליין ולזהות שלבים איטיים, שלבים תקועים או שלבים עם זמן בפועל ארוך מדי.
  • אפשר להשתמש ב-Metrics Explorer כדי לראות מדדים מפורטים של משימות Dataflow. אפשר להשתמש במדדים מותאמים אישית כדי לתעד נתוני ביצועים. מדד Distribution שימושי במיוחד לאיסוף נתוני ביצועים.
  • בצינורות עיבוד נתונים שדורשים הרבה משאבי CPU, כדאי להשתמש ב-Cloud Profiler כדי לזהות את החלקים בקוד של צינור עיבוד הנתונים שצורכים הכי הרבה משאבים.
  • כדאי להשתמש בדגימת נתונים כדי לזהות בעיות בנתונים. דגימת נתונים מאפשרת לכם לבחון את הנתונים בכל שלב של צינור Dataflow. המידע הזה יכול לעזור לכם לנפות באגים בצינור הנתונים, כי הוא מציג את הקלט והפלט בפועל של משימה שפועלת או שהושלמה.
  • אפשר להתאים אישית את לוח הבקרה למעקב אחרי פרויקטים כדי להציג משימות שעלולות להיות יקרות. מידע נוסף זמין במאמר בנושא התאמה אישית של לוח הבקרה של Dataflow Monitoring.

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

אופטימיזציה של הגדרות זמן הריצה

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

  • אם מריצים משימת סטרימינג או משימת אצווה
  • באיזה שירות אתם משתמשים כדי להריץ את המשימה, כמו Streaming Engine או FlexRS
  • סוג המכונה, גודל הדיסק ומספר יחידות ה-GPU במכונות הווירטואליות של העובדים
  • מצב שינוי הגודל האוטומטי
  • מספר העובדים ההתחלתי ומספר העובדים המקסימלי
  • מצב הסטרימינג (מצב של העברה בדיוק פעם אחת או מצב של העברה לפחות פעם אחת)

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

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

מיקום המשרה

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

  • מריצים את העבודה באותו אזור שבו נמצאים המשאבים שבהם העבודה משתמשת.
  • יוצרים קטגוריה של Cloud Storage לאחסון קבצים זמניים וקבצים של משימות בהמתנה באותו אזור שבו נמצאת המשימה. מידע נוסף זמין במאמרים בנושא gcpTempLocation וtemp_location אפשרויות של צינורות.

שינוי סוגי המכונות

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

  • מריצים את העבודה עם סוג המכונה הקטן ביותר שנדרש. משנים את סוג המכונה לפי הצורך בהתאם לדרישות של צינור העיבוד. לדוגמה, לפעמים כדאי לשנות את סוג המכונה מברירת המחדל במשימות סטרימינג עם צינורות (pipelines) שדורשים הרבה משאבי CPU. מידע נוסף זמין במאמר בנושא סוגי מכונות.
  • לעומסי עבודה שדורשים הרבה זיכרון או כוח מחשוב, צריך להשתמש בסוגי מכונות מתאימים. מידע נוסף זמין במאמר ציוני CoreMark של מכונות וירטואליות לפי משפחה.
  • מגדירים את המספר ההתחלתי של העובדים. כשמשימה עוברת התאמה כלפי מעלה, צריך לחלק מחדש את העבודה למכונות הווירטואליות החדשות. אם אתם יודעים כמה עובדים נדרשים לעבודות שלכם, תוכלו להימנע מהעלות הזו על ידי הגדרת המספר הראשוני של העובדים. כדי להגדיר את מספר העובדים ההתחלתי, משתמשים בnumWorkers או בnum_workers pipeline option.
  • מגדירים את המספר המקסימלי של העובדים. הגדרת ערך לפרמטר הזה עשויה להגביל את העלות הכוללת של העבודה. כשבודקים את הצינור בפעם הראשונה, כדאי להתחיל עם ערך מקסימלי נמוך יחסית. לאחר מכן מגדילים את הערך עד שהוא גבוה מספיק להרצת עומס עבודה של ייצור. כדאי לבדוק את יעדי ה-SLO של צינורות האספקה לפני שמגדירים ערך מקסימלי. מידע נוסף זמין במאמר בנושא שינוי גודל אוטומטי אופקי.
  • אפשר להשתמש בהתאמה נכונה כדי להתאים אישית את דרישות המשאבים לשלבים ספציפיים בצינור עיבוד הנתונים.
  • חלק מצינורות העיבוד נהנים משימוש במעבדים גרפיים. מידע נוסף זמין במאמר בנושא מעבדים גרפיים (GPU) ב-Dataflow. באמצעות התאמה נכונה, אפשר להגדיר מעבדי GPU לשלבים ספציפיים בצינור עיבוד הנתונים.
  • חשוב לוודא שיש לכם מספיק רוחב פס ברשת כדי לגשת לנתונים ממכונות וירטואליות של עובדים, במיוחד כשאתם צריכים לגשת לנתונים מקומיים.

אופטימיזציה של ההגדרות לעבודות אצווה

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

שימוש בתזמון משאבים גמיש

אם משימה באצווה לא רגישה לזמן, כדאי להשתמש בתזמון גמיש של משאבים (FlexRS). ‫FlexRS מפחית את עלויות העיבוד באצווה על ידי מציאת הזמן הטוב ביותר להתחלת העבודה, ולאחר מכן שימוש בשילוב של מופעי VM זמני ו-VM רגילים. העלות של מכונות Preemptible VM נמוכה בהרבה מזו של מכונות וירטואליות רגילות, מה שיכול להוזיל את העלות הכוללת. באמצעות שילוב של מכונות וירטואליות רגילות ומכונות וירטואליות שניתנות להפסקת פעולה, ‏ FlexRS עוזר לוודא שהצינור יתקדם גם אם Compute Engine יפסיק את הפעולה של המכונות הווירטואליות שניתנות להפסקת פעולה.

הימנעות מהרצת משימות קטנות מאוד

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

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

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

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

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

הפסקת עבודות לטווח ארוך

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

אופטימיזציה של ההגדרות למשרות סטרימינג

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

שימוש במנוע סטרימינג

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

מומלץ להשתמש במצב 'לפחות פעם אחת'

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

בחירת מודל תמחור

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

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

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

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

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

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

הפסקת עבודות לטווח ארוך

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

ביצועים של צינורות עיבוד נתונים

יכול להיות שהעלות של צינורות שפועלים מהר יותר תהיה נמוכה יותר. הגורמים הבאים יכולים להשפיע על הביצועים של צינורות הנתונים:

  • המקביליות שזמינה לעבודה
  • היעילות של הטרנספורמציות, מחברי הקלט/פלט והמקודדים שמשמשים בצינור
  • מיקום הנתונים

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

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

רישום ביומן

כדאי לפעול לפי השיטות המומלצות הבאות כשמתעדים פעולות ביומן:

בדיקה

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

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

מידע נוסף על יצירת בדיקות יחידה, בדיקות שילוב ובדיקות מקצה לקצה זמין במאמר בדיקת צינור העברת הנתונים. דוגמאות לבדיקות אפשר לראות במאגר GitHub‏ dataflow-ordered-processing.

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