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

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

הוראות ודוגמאות להגדרת מעבדי 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.

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

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

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