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

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

כברירת מחדל, Dataflow בוחר את סוג המכונה עבור worker VM שמריצים את העבודה, וגם את הגודל והסוג של Persistent Disk. כדי להתאים אישית את המשאבים האלה, מגדירים את אפשרויות הצינור הבאות כשיוצרים את העבודה.

סוג המכונה

סוג המכונה ב-Compute Engine שבה Dataflow משתמשת כשמפעילים worker VM. אפשר להשתמש בסוגי מכונות x86 או Arm, כולל סוגי מכונות מותאמים אישית.

Java

מגדירים את אפשרות צינור עיבוד הנתונים workerMachineType.

Python

מגדירים את אפשרות צינור עיבוד הנתונים machine_type.

המשך

מגדירים את אפשרות צינור עיבוד הנתונים worker_machine_type.

  • ב-Arm, סדרות המכונות Tau T2A ו-C4A נתמכות. מידע נוסף על שימוש במכונות וירטואליות של Arm זמין במאמר שימוש במכונות וירטואליות של Arm ב-Dataflow.

  • יש תמיכה אוטומטית במכונות וירטואליות (VM) מסוג x86.

  • לא מומלץ להשתמש בסוגי מכונות עם ליבות משותפות (לדוגמה, f1-micro, ‏ g1-small, ‏ e2-micro,‏ e2-small ו-e2-medium) לעבודות Dataflow, והם לא נתמכים במסגרת הסכם רמת השירות של Dataflow.

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

  • עבור סוגי המכונות f1-micro ו-g1-small, החיוב ב-Dataflow מתבצע כאילו יש להן vCPU אחד, ועבור סוגי המכונות e2-micro,‏ e2-small ו-e2-medium, החיוב ב-Dataflow מתבצע כאילו יש להן 2‏ vCPU. החיוב על התעריפים האלה מתבצע גם אם סוגי המכונות עם ליבות משותפות מספקים פחות מליבות ה-vCPU שחויבו בזמן השימוש הרציף במעבד.

סוגי מכונות בהתאמה אישית

כדי לציין סוג מכונה בהתאמה אישית, צריך להשתמש בפורמט הבא: FAMILY-vCPU-MEMORY. מחליפים את הערכים בשדות הבאים:

  • FAMILY. משתמשים באחד מהערכים הבאים:
    סדרת מכונותערך
    N1custom
    N2n2-custom
    N2Dn2d-custom
    E2e2-custom
  • ‫vCPU. מספר המעבדים הווירטואליים.
  • ‫MEMORY. הזיכרון, ב-MB.

כדי להפעיל זיכרון מורחב, מוסיפים את -ext לסוג המכונה. דוגמאות: n2-custom-6-3072, n2-custom-2-32768-ext.

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

סוגי מכונות שלא נתמכים ב-Hyperdisk Balanced

כשמשתמשים בדיסקים מסוג Hyperdisk Balanced, יכול להיות שהעבודה תיכשל עם שגיאה דומה לזו שמופיעה בהמשך:

hyperdisk-balanced disk type cannot be used by MACHINE_TYPE machine type

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

סוג הדיסק

סוג הדיסק לאחסון מתמיד שבו ייעשה שימוש.

אל תציינו Persistent Disk כשמשתמשים ב-Streaming Engine או בסוג המכונה N4.

Java

מגדירים את אפשרות צינור עיבוד הנתונים workerDiskType.

Python

מגדירים את אפשרות צינור עיבוד הנתונים worker_disk_type.

המשך

מגדירים את אפשרות צינור עיבוד הנתונים disk_type.

כדי לציין את סוג הדיסק, משתמשים בפורמט הבא: compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/diskTypes/DISK_TYPE.

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט
  • ‫ZONE: האזור של ה-Persistent Disk, לדוגמה us-central1-b
  • ‫DISK_TYPE: סוג הדיסק, לדוגמה pd-ssd,‏ pd-standard או hyperdisk-balanced

מידע נוסף מופיע במאמרי העזרה של ה-API של Compute Engine בנושא diskTypes.

הקצאת IOPS ותפוקה

כשמשתמשים בדיסקים מסוג Hyperdisk Balanced, אפשר להקצות IOPS ו-Throughput בלי קשר לגודל הדיסק. כדי להקצות IOPS ו-Throughput, משתמשים באפשרויות הבאות של צינור עיבוד הנתונים:

Java

  • כדי להקצות IOPS, מגדירים את האפשרות diskProvisionedIOPS של צינור הנתונים.
  • כדי להקצות משאבים לפי התפוקה שנקבעה ב-MiB/s, מגדירים את diskProvisionedThroughput pipeline option.

Python

  • כדי להקצות IOPS, מגדירים את האפשרות disk_provisioned_iops של צינור הנתונים.
  • כדי להקצות נפח נתונים ב-MiB/s, מגדירים את האפשרות disk_provisioned_throughput_mibps של צינור הנתונים.

המשך

  • כדי להקצות IOPS, מגדירים את האפשרות disk_provisioned_iops של צינור הנתונים.
  • כדי להקצות נפח נתונים ב-MiB/s, מגדירים את האפשרות disk_provisioned_throughput_mibps של צינור הנתונים.

אם לא מגדירים את האפשרויות האלה, עבודות שמשתמשות בדיסקים מסוג hyperdisk-balanced מוגדרות כברירת מחדל לביצועים בסיסיים של 3,000 IOPS וקצב העברה של 140MiB/s. למידע נוסף, אפשר לעיין במאמר בנושא Hyperdisk Balanced במסמכי העזרה של Compute Engine.

מגבלות

  • הקצאת IOPS וקצב העברת נתונים ל-Hyperdisk Balanced נתמכת בגרסאות 2.74.0 ואילך של Apache Beam SDK.

גודל כונן

גודל ה-Persistent Disk.

Java

מגדירים את אפשרות צינור עיבוד הנתונים diskSizeGb.

Python

מגדירים את אפשרות צינור עיבוד הנתונים disk_size_gb.

המשך

מגדירים את אפשרות צינור עיבוד הנתונים disk_size_gb.

אם מגדירים את האפשרות הזו, צריך לציין לפחות 30 GB כדי להביא בחשבון את קובץ אימג' לאתחול של ה-worker ואת היומנים המקומיים.

הקטנת גודל הדיסק מקטינה את קצב העברת הנתונים (I/O) הזמין לערבוב. עבודות שמוגבלות על ידי פעולת ה-Shuffle ולא משתמשות ב-ארגון נתונים של Dataflow או במנוע סטרימינג עלולות להוביל להגדלת זמן הריצה ולעלות העבודה.

משימות באצווה

למשימות באצווה באמצעות ארגון נתונים של Dataflow, האפשרות הזו מגדירה את הגודל של דיסק האתחול של worker VM. עבור משימות אצווה שלא משתמשות בארגון נתונים של Dataflow, האפשרות הזו מגדירה את גודל הדיסקים שמשמשים לאחסון נתונים שעברו ערבוב. גודל דיסק האתחול לא מושפע.

אם משימת אצווה משתמשת בארגון נתונים של Dataflow, גודל ברירת המחדל של הדיסק הוא 25 GB. אחרת, ברירת המחדל היא 250 GB.

משרות שקשורות לסטרימינג

לגבי משימות סטרימינג באמצעות Streaming Engine, האפשרות הזו מגדירה את הגודל של דיסקי האתחול. במשימות של סטרימינג שלא נעשה בהן שימוש ב-Streaming Engine, האפשרות הזו מגדירה את הגודל של כל דיסק נוסף של Persistent Disk שנוצר על ידי שירות Dataflow. דיסק האתחול לא מושפע.

אם עבודת סטרימינג לא משתמשת ב-Streaming Engine, אפשר להגדיר את גודל דיסק האתחול באמצעות דגל הניסוי streaming_boot_disk_size_gb. לדוגמה, מציינים --experiments=streaming_boot_disk_size_gb=80 כדי ליצור דיסקי אתחול בגודל 80GB.

אם עבודת סטרימינג משתמשת ב-Streaming Engine, גודל הדיסק שמוגדר כברירת מחדל הוא 30 GB. אחרת, ברירת המחדל היא 400 GB.

פלטפורמת CPU מינימלית

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

כדי לציין את פלטפורמת ה-CPU המינימלית, מגדירים את min_cpu_platform experimental pipeline option. הערך צריך להיות השם המדויק של פלטפורמת ה-CPU שנבחרה, כמו AMD Milan או Intel Ice Lake. לדוגמה, כדי להגדיר את פלטפורמת ה-CPU המינימלית ל-AMD Milan, מציינים את הערך --experiments=min_cpu_platform='AMD Milan'. רשימה של פלטפורמות CPU מינימליות נתמכות זמינה במאמר זמינות של פלטפורמות CPU. מידע על מגבלות מופיע במאמר בנושא מגבלות כשמציינים פלטפורמת CPU מינימלית.

כדי לוודא שהמכונות הווירטואליות של העובדים ב-Dataflow נוצרו עם פלטפורמת המינימום של המעבד שצוינה, בודקים את הרשומות ב-Cloud Logging של המשימה באופן הבא:

  1. עוברים אל מסוף Cloud Logging במסוף Google Cloud .

  2. משתמשים במסנן הבא ומחליפים את פלטפורמת ה-CPU לדוגמה ואת מזהה משימת Dataflow במידע של המשימה שלכם.

    resource.type="gce_instance"
protoPayload.request.minCpuPlatform="AMD Milan"
"dataflow_job_id"

  3. בודקים את היומנים שנוצרו כדי לוודא ש-Dataflow ציין בהצלחה את פלטפורמת המעבד המינימלית במהלך תהליך יצירת המכונה הווירטואלית.

שימוש ב-Cloud Storage FUSE כדי לטעון את קטגוריות של Cloud Storage במכונות וירטואליות של Dataflow

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

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