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

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

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

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

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

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

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

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

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

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

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

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

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

  • לפני שמריצים את צינור העברת הנתונים בסביבת הייצור, מריצים משימה אחת או יותר על קבוצת משנה של הנתונים. בצינורות רבים, הטכניקה הזו יכולה לספק הערכת עלויות.
  • אפשר להשתמש בדף Cost בממשק המעקב של Dataflow כדי לעקוב אחרי העלות המשוערת של המשימות. העלות המשוערת לא תמיד משקפת את העלות בפועל של העבודה, למשל בגלל הנחות חוזיות, אבל היא יכולה לספק בסיס טוב לאופטימיזציה של העלויות. מידע נוסף מפורט במאמר בנושא מעקב אחרי עלויות.
  • ייצוא נתוני החיוב ב-Cloud ל-BigQuery וביצוע ניתוח עלויות בטבלאות של נתוני החיוב המיוצאים. הייצוא של נתוני החיוב ב-Cloud מאפשר לייצא באופן אוטומטי נתונים מפורטים של חיוב ב-Google Cloud Platform במהלך היום למערך נתונים ב-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 לשלבים ספציפיים בצינור עיבוד הנתונים.
  • חשוב לוודא שיש לכם מספיק רוחב פס ברשת כדי לגשת לנתונים ממכונות ה-VM של העובדים, במיוחד כשאתם צריכים לגשת לנתונים מקומיים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מנוע הסטרימינג מעביר את ההפעלה של צינור עיבוד הנתונים מהמכונות הווירטואליות של העובדים אל הקצה העורפי של שירות 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, בארגון הקוד מחדש של צינור הנתונים ובבדיקות קוד. אפשר לבדוק הרבה אופטימיזציות באופן מקומי בלי להריץ עבודה ב-Dataflow, למשל שינוי של טרנספורמציות מותאמות אישית שדורשות הרבה משאבי CPU.

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

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

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