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

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

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

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

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

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

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

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

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

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

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

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

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

מיקום המשרה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

‫Streaming Engine מעביר את ההרצה של הפייפליין מהמכונות הווירטואליות של העובדים אל הקצה העורפי של שירות 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.

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