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

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

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

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

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

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

הגדרת יעדי SLO

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מיקום המשרה

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

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

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

ההתאמות הבאות למכונות הווירטואליות של ה-workers יכולות לשפר את יעילות העלות.

  • מריצים את המשימה עם סוג המכונה הקטן ביותר שנדרש. משנים את סוג המכונה לפי הצורך, בהתאם לדרישות של צינור עיבוד הנתונים. לדוגמה, במשימות סטרימינג עם צינורות עיבוד נתונים שצורכים הרבה משאבי מעבד, לפעמים כדאי לשנות את סוג המכונה מסוג ברירת המחדל. למידע נוסף, קראו את המאמר סוג מכונה.
  • לעומסי עבודה שדורשים הרבה זיכרון או הרבה משאבי מחשוב, השתמשו בסוגי מכונות מתאימים. למידע נוסף, ראו ציוני CoreMark של מכונות וירטואליות לפי משפחה.
  • מגדירים את מספר ה-workers הראשוני. כשמשימה עוברת התאמה לעומס, צריך להפיץ מחדש את העבודה למכונות הווירטואליות החדשות. אם אתם יודעים כמה עובדים נדרשים למשימות שלכם, תוכלו להימנע מהעלות הזו על ידי הגדרת המספר הראשוני של העובדים. כדי להגדיר את המספר הראשוני של ה-workers, משתמשים בnumWorkers או בnum_workers pipeline option.
  • מגדירים את מספר העובדים המקסימלי. הגדרת ערך לפרמטר הזה יכולה להגביל את העלות הכוללת של המשימה. כשבודקים את צינור עיבוד הנתונים בפעם הראשונה, כדאי להתחיל עם ערך מקסימלי נמוך יחסית. אחר כך מגדילים את הערך עד שהוא גבוה מספיק כדי להריץ עומס עבודה בסביבת הייצור. לפני שאתם מגדירים ערך מקסימלי, כדאי שתביאו בחשבון את יעדי ה-SLO של הצינור. מידע נוסף זמין במאמר Horizontal Autoscaling.
  • משתמשים בהתאמה נכונה כדי להתאים אישית את דרישות המשאבים לשלבים ספציפיים בצינור עיבוד הנתונים.
  • בצינורות עיבוד נתונים מסוימים כדאי להשתמש במעבדים גרפיים. מידע נוסף זמין במאמר מעבדים גרפיים עם Dataflow. באמצעות התאמה נכונה, אתם יכולים להגדיר מעבדים גרפיים לשלבים ספציפיים בצינור עיבוד הנתונים.
  • חשוב לוודא שיש לכם מספיק רוחב פס ברשת כדי לגשת לנתונים מה-worker VMs, במיוחד כשצריך לגשת לנתונים מקומיים.

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

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

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

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

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

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

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

שינוי ההגדרות של התאמה אוטומטית לעומס (autoscaling)

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

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

הפסקת משימות ארוכות

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

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

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

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

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

שימוש במצב "לפחות פעם אחת"

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

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

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

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

שינוי ההגדרות של התאמה אוטומטית לעומס (autoscaling)

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

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

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

הפסקת משימות ארוכות

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

ביצועי צינור עיבוד הנתונים

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

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

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

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

רישום ביומן

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

בדיקה

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

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

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

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