שימוש בתובנות של 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. מגדירים אימות.

   Select the tab for how you plan to use the samples on this page:

   gcloud

   In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

   REST

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

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

   gcloud init

   אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

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

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

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

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

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

   תובנות

   זוהה fan-out גבוה

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

   High fan-out detected
   

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

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

   • אחרי הפעולה הראשונה של ParDo, מוסיפים GroupByKey ומבטלים את הקיבוץ. שירות 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.

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

   כש-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()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.

   שליחת משוב