שיטות מומלצות לעבודה עם GPU ב-Dataflow

בדף הזה מתוארות שיטות מומלצות לבניית צינורות עיבוד נתונים באמצעות יחידות GPU.

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

דרישות מוקדמות לשימוש ב-GPU ב-Dataflow

לתשומת ליבכם

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

פיתוח מקומי

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

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

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

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

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

  • כשמריצים ניסויים מקומיים, צריך לשכפל את הסביבה של העובד של Dataflow בצורה הכי מדויקת שאפשר. בהתאם לספרייה, יכול להיות שתצטרכו מכונה עם GPU וספריות GPU נדרשות מותקנות. יכול להיות שהסוג הזה של מכונה לא זמין בסביבה המקומית שלכם. אפשר לבצע אמולציה של סביבת ההפעלה של Dataflow באמצעות קונטיינר שפועל במכונה וירטואלית ב-Google Cloud Platform שמצוידת ב-GPU.

מפרטים של סוגי מכונות

פרטים על התמיכה בסוגי מכונות לכל דגם GPU מופיעים במאמר פלטפורמות GPU. מעבדי GPU שנתמכים בסוגי מכונות N1 תומכים גם בסוגי מכונות N1 בהתאמה אישית.

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

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

לפרטים נוספים, אפשר לקרוא את המאמר מעבדי GPU ב-Compute Engine.

אופטימיזציה של השימוש במשאבים

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

התאמה נכונה משתמשת ברמזים למשאבים של Apache Beam כדי להתאים אישית את משאבי העובדים לצינורות עיבוד הנתונים של אצווה. כשהתכונה 'התאמה נכונה' מופעלת, Dataflow משתמש ב-GPU רק בשלבים של צינור עיבוד הנתונים שזקוקים להם. כתוצאה מכך, התכונה הזו משפרת את הגמישות והיכולת של צינורות הנתונים, ויכולה גם להפחית את העלויות.

מידע נוסף מופיע במאמר בנושא התאמה נכונה.

יחידות GPU והקצאת עובדים במקביל

בצינורות עיבוד נתונים של Python שמשתמשים בארכיטקטורה של Dataflow Runner v2, ‏ Dataflow מפעיל תהליך אחד של Apache Beam SDK לכל ליבת מכונה וירטואלית. כל תהליך SDK פועל בקונטיינר Docker משלו, ובתורו יוצר הרבה תהליכים, שכל אחד מהם מעבד נתונים נכנסים.

מעבדי GPU משתמשים בארכיטקטורה של ריבוי תהליכים, ומעבדי GPU בתהליכי העבודה של Dataflow גלויים לכל התהליכים והשרשורים.

אם אתם מריצים כמה תהליכי SDK ב-GPU משותף, אתם יכולים לשפר את היעילות והניצול של ה-GPU על ידי הפעלת NVIDIA Multi-Process Service ‏ (MPS). ‫MPS משפר את המקביליות של העובדים ואת התפוקה הכוללת של צינורות GPU, במיוחד עבור עומסי עבודה עם שימוש נמוך במשאבי GPU. מידע נוסף מופיע במאמר שיפור הביצועים ב-GPU משותף באמצעות NVIDIA MPS.

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

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

    • --experiments=no_use_multiple_sdk_containers
    • --number_of_worker_harness_threads

    מידע נוסף על מספר ה-threads שמומלץ להשתמש בהם מופיע במאמר בנושא צמצום מספר ה-threads.

  • מפעילים את MPS.

עומסי עבודה של הסקה

כשמשתמשים במודלים של למידת מכונה (ML) כדי לבצע היקש מקומי ומרוחק, כדאי להשתמש בטרנספורמציה RunInference המובנית של Apache Beam. ‫RunInference API הוא PTransform שעבר אופטימיזציה להסקת מסקנות של למידת מכונה. השימוש בטרנספורמציה RunInference יכול לשפר את היעילות כשמשתמשים במודלים של ML בצינורות הנתונים.

תהליך עבודה

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

  1. יצירת פייפליין

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

    1. ליצור את כל הטרנספורמציות שקשורות לשימוש ב-GPU, כמו קליטה ומניפולציה של נתונים.

    2. יוצרים stub לטרנספורמציה של ה-GPU עם העברה או שינוי בסכימה.

  2. בדיקה מקומית

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

    1. יוצרים קובץ אימג' של Docker עם כל הספריות הנדרשות.

    2. מתחילים לפתח את קוד ה-GPU.

    3. מתחילים את מחזור הקוד באמצעות מכונה וירטואלית של Google Cloud Platform עם קובץ האימג' של Docker. כדי לשלול בעיות תאימות של ספריות, מריצים את קוד ה-GPU בתהליך Python מקומי בנפרד מצינור Apache Beam. לאחר מכן, מריצים את כל צינור עיבוד הנתונים ב-Direct Runner או מפעילים את צינור עיבוד הנתונים ב-Dataflow.

שימוש במכונת VM שמופעלת בה מערכת הפעלה שמותאמת לקונטיינרים

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

התהליך הכללי הוא:

  1. יוצרים מכונה וירטואלית.

  2. מתחברים למכונה הווירטואלית ומריצים את הפקודות הבאות:

    sudo cos-extensions install gpu -- -version latest
sudo mount --bind /var/lib/nvidia /var/lib/nvidia
sudo mount -o remount,exec /var/lib/nvidia

  3. מוודאים שה-GPU זמין:

    ./nvidia-smi

  4. מפעילים קונטיינר Docker עם דרייברים של GPU מה-VM שמוגדר כנפחים. לדוגמה:

    sudo docker run --rm -it --entrypoint /bin/bash
--volume /var/lib/nvidia/lib64:/usr/local/nvidia/lib64
--volume /var/lib/nvidia/bin:/usr/local/nvidia/bin
--privileged gcr.io/bigdatapivot/image_process_example:latest

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

מידע נוסף על שימוש בקובץ אימג' של Docker שהוגדר מראש לשימוש ב-GPU זמין במאמר שימוש בתמונה קיימת שהוגדרה לשימוש ב-GPU.

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

  • כדי להגדיר את Docker CLI כך שישתמש ב-docker-credential-gcr ככלי עזר לפרטי כניסה עבור קבוצת ברירת המחדל של Google Container Registries ‏ (GCR), משתמשים בפקודה:

    sudo docker-credential-gcr configure-docker

    מידע נוסף על הגדרת פרטי כניסה ל-Docker זמין במאמר docker-credential-gcr.

  • כדי להעתיק קבצים, כמו קוד צינור, אל מכונה וירטואלית או ממנה, משתמשים ב-toolbox. הטכניקה הזו שימושית כשמשתמשים בתמונה שעברה אופטימיזציה בהתאמה אישית. לדוגמה:

    toolbox /google-cloud-sdk/bin/gsutil cp gs://bucket/gpu/image_process/* /media/root/home/<userid>/opencv/

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

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