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

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

סקירה כללית

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

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

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

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

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

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

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

    gcloud

    במסוף Google Cloud , מפעילים את Cloud Shell.

    הפעלת Cloud Shell

    בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

    REST

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

      התקינו את ה-CLI של Google Cloud.

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-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

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

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

  • ‫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: Autoscaling: המספר המקסימלי של העובדים יכול לגדול. העבודה משתמשת בהתאמה אוטומטית לעומס, יש בה ניצול גבוה של מעבד (CPU) והיא משתמשת במספר המקסימלי של workers שהוגדר. הגדלת המספר המקסימלי של העובדים יכולה לשפר את הביצועים.
  • ‫WORKER_OUT_OF_MEMORY: חלק מהעובדים של המשימה נכשלו בגלל חוסר זיכרון, מה שיכול להאט את המשימה או לגרום לה להיכשל.
  • ‫PREBUILD_NOT_UTILIZED: שימוש בתהליך עבודה של בנייה מראש של תמונת העובד כדי לשפר את זמן ההפעלה של העובד ואת האמינות של התאמה אוטומטית לעומס.
  • ‫ACTIVE_KEYS (תצוגה מקדימה): מספר המפתחות הפעילים הכולל קטן ממספר ליבות המעבד הכולל, והגדלת קנה המידה לא תעזור.
  • ‫LONG_WORK_ITEM: העיבוד של פעולה בשלב מיזוג נמשך יותר מדי זמן, מה שמצביע על פעולה איטית או תקועה.

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

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

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

תובנות

זוהה fan-out גבוה

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

High fan-out detected

ההודעה הזו מוצגת כשמתבצעת מיזוג של ParDo עם 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 העובדים נמצאים בשימוש עם ניצול ממוצע של CPU של העובדים מעל 50%, ולמשימה יש זמן עיבוד משוער של יותר מ-2 דקות.

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

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

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

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

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

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

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

Some workers are out of memory

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

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

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

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

pre-build workflow not utilized

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

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

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

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

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

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

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

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

מומלץ להגדיל את מספר המחיצות, או לכלול טרנספורמציה של withRedistribute()RedistributewithRedistribute() ולשקול שימוש במצב של ביטול כפילויות של היסט 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.

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