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

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

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

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

לתשומת ליבכם

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

פיתוח מקומי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יחידות GPU ומקביליות של עובדים

בצינורות עיבוד נתונים של Python שמשתמשים בארכיטקטורה של Dataflow Portable Runner, ‏ 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 אחד בתוך קונטיינר, ללא קשר למספר ה-vCPU של העובד. כדי להגדיר את ההגדרה הזו, כשמפעילים את העבודה, משתמשים באפשרויות הצינור הבאות:

    • --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 מכונה וירטואלית עם קובץ האימג' של 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

דוגמה לקובץ Dockerfile מופיעה במאמר בנושא יצירת קובץ אימג' של קונטיינר בהתאמה אישית. מוסיפים ל-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/

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

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