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

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

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

סוג המכונה

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

Java

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

Python

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

המשך

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

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

  • יש תמיכה אוטומטית במכונות וירטואליות מסוג 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. התעריפים האלה מחויבים למרות שמכונות עם ליבה משותפת (shared-core) מספקות פחות זמן מעבד (CPU) מתמשך מאשר ה-vCPUs שמחויבים.

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

כדי לציין סוג מכונה בהתאמה אישית, משתמשים בפורמט הבא: 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: האזור של הדיסק לאחסון מתמיד, לדוגמה us-central1-b
  • ‫DISK_TYPE: סוג הדיסק, לדוגמה pd-ssd,‏ pd-standard או hyperdisk-balanced

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

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

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

Java

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

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 לשנייה. למידע נוסף, קראו את המאמר מידע על Hyperdisk Balanced במסמכי התיעוד של Compute Engine.

מגבלות

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

גודל כונן

גודל ה-Persistent Disk.

Java

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

Python

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

המשך

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

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

הקטנת גודל הדיסק מפחיתה את קלט/פלט הזמין לערבוב. משימות שמוגבלות על ידי ארגון הנתונים ולא משתמשות בארגון נתונים של Dataflow או ב-Streaming Engine עלולות להאריך את זמן הריצה ולהגדיל את עלות המשימה.

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

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

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

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

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

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

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

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

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

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

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

  1. נכנסים למסוף Cloud Logging במסוף Google Cloud .

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

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

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

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

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

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