שימוש בתובנות של Dataflow

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

סקירה כללית

‫Dataflow Insights מספק תובנות לגבי שיפור הביצועים של העבודות, הפחתת העלויות ופתרון בעיות. התובנות של Dataflow הן חלק משירות ההמלצות, והן זמינות דרך סוג google.dataflow.diagnostics.Insight.

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

לפני שמתחילים

לפני שמתחילים להשתמש ב-Dataflow Insights, צריך לבצע את השלבים הבאים.

1. מפעילים את Recommender API.

2. מגדירים אימות.

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

   gcloud

   מתקינים את ה-CLI של Google Cloud ואז נכנסים ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם. אחרי שנכנסתם לחשבון, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה:

   gcloud init

   REST

   כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.

   מתקינים את ה-CLI של Google Cloud ואז נכנסים ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם.

   מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .

3. ודאו שיש לחשבון שלכם את ההרשאות הבאות:

   • recommender.dataflowDiagnosticsInsights.get
   • recommender.dataflowDiagnosticsInsights.list
   • recommender.dataflowDiagnosticsInsights.update

   אפשר להעניק את ההרשאות האלה בנפרד, או להעניק אחד מהתפקידים הבאים:

   • roles/recommender.dataflowDiagnosticsViewer
   • roles/recommender.dataflowDiagnosticsAdmin
   • roles/dataflow.viewer
   • roles/dataflow.developer
   • roles/dataflow.admin

בקשה לקבלת תובנות לגבי Dataflow

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

תובנות לגבי Dataflow

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

gcloud

כדי לראות את כל התובנות של Dataflow לגבי הפרויקט באזור מסוים, משתמשים בפקודה gcloud recommender insights list.

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

• ‫PROJECT_ID: מזהה הפרויקט שרוצים לראות את התובנות לגביו.
• ‫REGION: האזור שבו משימות Dataflow פועלות. לדוגמה: us-west1.

gcloud recommender insights list --insight-type=google.dataflow.diagnostics.Insight \
  --project=PROJECT_ID \
  --location=REGION

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

REST

אפשר להשתמש בשיטה insights.list של Recommender API כדי לראות את כל התובנות לגבי Dataflow בפרויקט באזור מסוים.

לפני שמשתמשים בנתוני הבקשה, מחליפים את המשתנים הבאים בערכים:

• ‫PROJECT_ID: מזהה הפרויקט שרוצים לראות את התובנות לגביו.
• ‫REGION: האזור שבו משימות Dataflow פועלות. לדוגמה: us-west1.

ה-method של ה-HTTP וכתובת ה-URL:

GET https://recommender.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/insightTypes/google.dataflow.diagnostics.Insight/insights

כדי לשלוח את הבקשה באמצעות curl‏ (Linux,‏ macOS או Cloud Shell), מריצים את הפקודה הבאה:

curl -X GET \
  -H "Authorization: Bearer "$(gcloud auth print-access-token) \
  "https://recommender.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/insightTypes/google.dataflow.diagnostics.Insight/insights"

קבלת תובנה אחת מ-Dataflow

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

gcloud

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

• ‫INSIGHT_ID: המזהה של התובנה שרוצים להציג.
• ‫PROJECT_ID: מזהה הפרויקט שרוצים לראות את התובנות לגביו.
• ‫REGION: האזור שבו משימות Dataflow פועלות. לדוגמה: us-west1.

gcloud recommender insights describe INSIGHT_ID \
  --insight-type=google.dataflow.diagnostics.Insight \
  --project=PROJECT_ID \
  --location=REGION

הפלט מציג את התובנה בפירוט.

REST

ה-method insights.get של Recommender API מחזירה תובנה אחת. אלה הנתונים שצריך להחליף לפני שמשתמשים בדוגמה:

• ‫PROJECT_ID: מזהה הפרויקט שרוצים לראות את התובנות לגביו.
• ‫REGION: האזור שבו משימות Dataflow פועלות. לדוגמה: us-west1.
• ‫INSIGHT_ID: המזהה של התובנה שרוצים להציג.

ה-method של ה-HTTP וכתובת ה-URL:

GET https://recommender.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/insightTypes/google.dataflow.diagnostics.Insight/insights/INSIGHT_ID

כדי לשלוח את הבקשה באמצעות curl‏ (Linux,‏ macOS או Cloud Shell), מריצים את הפקודה הבאה:

curl -X GET \
  -H "Authorization: Bearer "$(gcloud auth print-access-token) \
  "https://recommender.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/insightTypes/google.dataflow.diagnostics.Insight/insights/INSIGHT_ID"

הסבר על התובנות ב-Dataflow

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

• ‫AUTOSCALING_NOT_ENABLED: יכול להיות שהתאמת גודל אוטומטית מופעלת. העבודה משתמשת במעבד (CPU) במידה גבוהה, והיא משתמשת במספר המקסימלי של עובדים שהוגדר. הפעלת שינוי גודל אוטומטי יכולה לשפר את הביצועים.
• ‫HIGH_FAN_OUT: אפשר להוסיף הפסקה של מיזוג אחרי טרנספורמציות אחת או יותר כדי להגדיל את המקביליות.
• ‫MAX_NUM_WORKERS: שינוי גודל אוטומטי: יכול להיות שהמספר המקסימלי של העובדים יגדל. העבודה משתמשת בהתאמת קנה מידה אוטומטית, יש ניצול גבוה של המעבד (CPU) והיא משתמשת במספר המקסימלי של העובדים שהוגדר. הגדלת המספר המקסימלי של העובדים יכולה לשפר את הביצועים.
• ‫WORKER_OUT_OF_MEMORY: חלק מהעובדים של המשימה נכשלו בגלל אין זיכרון פנוי (OOM), מה שיכול להאט את המשימה או לגרום לה להיכשל.
• ‫PREBUILD_NOT_UTILIZED: שימוש בתהליך עבודה של בנייה מראש של תמונת worker כדי לשפר את זמן ההפעלה של ה-worker ואת האמינות של שינוי הגודל האוטומטי.
• ‫ACTIVE_KEYS (תצוגה מקדימה): מספר המפתחות הפעילים הכולל קטן ממספר ליבות המעבד הכולל, והגדלת קנה המידה לא תעזור.
• ‫LONG_WORK_ITEM: העיבוד של פעולה בשלב מיזוג נמשך יותר מדי זמן, מה שמצביע על פעולה איטית או תקועה.

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

ב-Dataflow Insights יש גם שדה מיוחד content שמכיל שדות משנה עם מידע נוסף ומטא-נתונים על תובנה. בהתאם לתרחיש השימוש, יכול להיות שיהיה לכם שימוש בשדות המשנה הבאים של content:

• ‫jobName: שם המשימה ב-Dataflow.
• ‫description: תיאור התובנה באנגלית.
• ‫title: השם של התובנה באנגלית.

תובנות

זוהה fan-out גבוה

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

High fan-out detected

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

כדי לפתור את הבעיה:

• מוסיפים GroupByKey ומבטלים את הקיבוץ אחרי הפעולה הראשונה של ParDo. שירות Dataflow אף פעם לא ממזג פעולות ParDo בצבירה. מידע נוסף זמין במאמר בנושא אופטימיזציה של מיזוג
• מעבירים את ה-PCollection הביניים כקלט צדדי ל-ParDo אחר. שירות Dataflow תמיד מממש קלט צדדי.
• הוספת שלב של שינוי הסדר. הפעולה Reshuffle מונעת מיזוג, יוצרת נקודות ביקורת בנתונים ומגדירה מחדש את אסטרטגיית החלונות כך שלא יאבדו נתונים. ‫Reshuffle נתמך על ידי Dataflow, למרות שהוא מסומן כהוצאה משימוש במסמכי התיעוד של Apache Beam (שימו לב: ערבוב מחדש של נתונים עלול להגדיל את העלות של הפעלת צינור הנתונים).

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

כש-Dataflow מזהה שמשימה משתמשת במספר המקסימלי של עובדים שמותרים, maxNumWorkers (או max_num_workers), ושהמשימה עשויה להשתמש בעובדים נוספים אם המקסימום הזה יוגדל, מופיעה ההודעה הבאה:

maximum number of workers could be increased

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

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

כדי לפתור את הבעיה:

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

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

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

תהליכי Worker נכשלים עם שגיאות OutOfMemory

כש-Dataflow מזהה שעובדים של משימה נכשלים בגלל שגיאות של אין זיכרון פנוי (OOM), מוצגת ההודעה הבאה:

Some workers are out of memory

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

כדאי לנסות את ההצעות הבאות:

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

לא נעשה שימוש בתהליך עבודה שנוצר מראש

כש-Dataflow מזהה צינור עיבוד נתונים שלא נעשה בו שימוש בתהליך העבודה של בנייה מראש של תמונת העובד, מוצגת ההודעה הבאה:

pre-build workflow not utilized

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

כדי לפתור את הבעיה, משתמשים בתהליך העבודה של בנייה מראש של תמונת העובד כשמפעילים את צינור הנתונים. מידע נוסף זמין במאמר Pre-build Python dependencies.

אם כבר נעשה שימוש במאגר מותאם אישית מוכן מראש, כדי להימנע מהתקנות מיותרות, מוסיפים את האפשרות ‎ '--sdk_location=container'‎ ומסירים את האפשרויות הבאות:

• '--setup_file'
• '--requirements_file'
• '--extra_package(s)'

מספר המפתחות הפעילים נמוך

תצוגה מקדימה

השימוש במוצר או בתכונה כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. מידע נוסף זמין בקטע תיאור שלבי ההשקה.

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

Active keys can be increased

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

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

פתרונות אפשריים להגדלת מספר המפתחות: - אפשר להגדיל את מספר המפתחות באמצעות שימוש בסוג מפתח ספציפי יותר. לדוגמה, אם סוג המפתח הוא IP address, יש פחות מקשים זמינים. עם זאת, אם משנים את סוג המפתח ל-IP + [user identifier], יש יותר מפתחות זמינים, מה שמגדיל את המקביליות. – לגבי צינורות שכותבים ל-BigQuery, שבהם יכול להיות שהיעדים הם צוואר הבקבוק, אפשר לעיין במאמר הזה. ‫– במקורות או ביעדים אחרים, בודקים אם יש פרמטר numShards ומגדילים אותו. בדרך כלל, כל רסיס ממופה למפתח אחד. – הנחיות כלליות נוספות לגבי מודל הביצוע שלנו זמינות במאמר הזה. ‫- Fanout יכול לשמש לקבלת מפתח קלט יחיד ולהוספת hash אליו כדי ליצור כמה מפתחות פלט. מקור מידע

השלב נמשך יותר מדי זמן

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

Stage spending too long on work

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

הבעיה הזו יכולה להיגרם בגלל טרנספורמציות של משתמשים שנתקעו או איטיות. אפשר לזהות את השינויים האלה באמצעות אזהרות שמופיעות ב-Cloud Logging ובכרטיסייה Diagnostics שלו, עם הביטויים "Operation ongoing" (הפעולה מתבצעת) או "Processing stuck" (העיבוד נתקע). כדי לאבחן אם הבעיה הזו נגרמת בגלל טרנספורמציה של משתמש, אפשר להשתמש ב-Cloud Profiler כדי לבדוק את הביצועים של טרנספורמציות של משתמשים. אחר כך בודקים איזה קוד גורם להאטה ובאיזו תדירות. מידע נוסף זמין במאמר פתרון בעיות נפוצות בתהליכי העברת נתונים.

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

משימה תקועה בפריט עבודה

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

Job is stuck due to failed and retried work item

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

• עיכוב של סימן המים
• עיכוב מצטבר
• מניעת השלמה של פעולת ניקוז

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

מנוע הסטרימינג לא מופעל

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

This job isn't using Streaming Engine. It might benefit from having Streaming Engine enabled.

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

מספר המחיצות ב-Kafka נמוך

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

The partition count provided by the Kafka source is too low, consider increasing
partitions or redistributing to more keys.

מומלץ להגדיל את מספר המחיצות, או לכלול טרנספורמציה של חלוקה מחדש withRedistribute() ולהשתמש במצב של ביטול כפילויות של היסט withOffsetDeduplication(). מידע נוסף על שיטות מומלצות לשימוש ב-Kafka Read במקביל זמין במאמר בנושא קריאה מ-Kafka.

עלות של Kafka persistence

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

Redistribute requires persistence of Kafka outputs as part of the shuffle phase,
consider reducing latency and cost with offset deduplication mode.

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