כברירת מחדל, Cloud Data Fusion משתמש בפרופיל של מחשוב עם שינוי גודל אוטומטי. קשה להעריך את המספר האופטימלי של עובדי אשכול (צמתים) לעומס עבודה, ולעתים קרובות גודל אשכול יחיד לצינור שלם הוא לא אידיאלי. התכונה 'מידרוג אוטומטי של Managed Service for Apache Spark' מספקת מנגנון לאוטומציה של ניהול משאבי האשכול, ומאפשרת מידרוג אוטומטי של מכונות וירטואליות של עובדים באשכול. מידע נוסף זמין במאמר בנושא שינוי אוטומטי של גודל הקבוצה.
בדף Compute config, שבו מוצגת רשימה של פרופילים, יש עמודה בשם Total cores. בעמודה הזו מופיע מספר המעבדים הווירטואליים המקסימלי שאליו הפרופיל יכול להתרחב, כמו Up to 84.
אם רוצים להשתמש בפרופיל החישוב של Managed Service for Apache Spark , אפשר לנהל את גודלי האשכולות על סמך גודל צינור הנתונים.
צומת ראשי
צמתים ראשיים משתמשים במשאבים באופן יחסי למספר צינורות הנתונים או האפליקציות הנוספות שפועלות באשכול. אם אתם מפעילים צינורות עיבוד ב клаסטרים זמניים, צריך להשתמש ב-2 מעבדים ובזיכרון בנפח 8GB לצמתים הראשיים. אם אתם משתמשים באשכולות קבועים, יכול להיות שתצטרכו צמתים ראשיים גדולים יותר כדי לעמוד בקצב של תהליך העבודה. כדי להבין אם אתם צריכים צמתים ראשיים גדולים יותר, אתם יכולים לעקוב אחרי השימוש בזיכרון ובמעבד בצומת. מומלץ להגדיר את גודל הצמתים של העובדים עם לפחות 2 מעבדים ו-8GB של זיכרון. אם הגדרתם את צינורות העיבוד כך שישתמשו בכמויות גדולות יותר של זיכרון, אתם צריכים להשתמש בעובדים גדולים יותר.
כדי למזער את זמן הביצוע, חשוב לוודא שיש מספיק צמתים באשכול כדי לאפשר עיבוד מקביל ככל האפשר.
עובדים
בקטעים הבאים מתוארים היבטים של קביעת הגודל של צמתי העובדים.
מעבד (CPU) וזיכרון
מומלץ להגדיר את גודל צמתי העובדים עם לפחות 2 CPU ו-8 GB של זיכרון. אם הגדרתם את צינורות הנתונים כך שישתמשו בכמויות גדולות יותר של זיכרון, כדאי להשתמש בעובדים גדולים יותר. לדוגמה, אם יש לכם צומת עובד עם 4 מעבדים ו-15 GB, לכל עובד יהיו 4 מעבדים ו-12 GB זמינים להרצת קונטיינרים של YARN. אם צינור העברת הנתונים מוגדר להפעיל מעבד אחד, 8GB של קבצים להרצה, YARN לא יכול להפעיל יותר מקונטיינר אחד לכל צומת עובד. לכל צומת עובד יהיו 3 ליבות CPU נוספות ו-4GB של זיכרון RAM שלא מנוצלים כי אי אפשר להשתמש בהם להרצת שום דבר. כדי למקסם את ניצול המשאבים באשכול, כדאי שזיכרון ה-YARN ומעבדי ה-CPU יהיו כפולה מדויקת של הכמות שנדרשת לכל תהליך Spark executor. אפשר לבדוק כמה זיכרון כל worker שמר ל-YARN באמצעות המאפיין yarn.nodemanager.resource.memory-mb ב-YARN.
אם אתם משתמשים ב-Managed Service for Apache Spark, הזיכרון שזמין לקונטיינרים של YARN יהיה בערך 75% מהזיכרון של המכונה הווירטואלית. גודל המכולה המינימלי של YARN מותאם גם הוא בהתאם לגודל של מכונות ה-VM של העובדים. בטבלה הבאה מפורטים כמה גדלים נפוצים של worker וההגדרות התואמות שלהם ב-YARN.
| מעבד של קובץ שירות | זיכרון של תהליך העבודה (GB) | זיכרון של צומת YARN (GB) | זיכרון מינימלי להקצאה ב-YARN (MB) |
|---|---|---|---|
| 1 | 4 | 3 | 256 |
| 2 | 8 | 6 | 512 |
| 4 | 16 | 12 | 1024 |
| 8 | 32 | 24 | 1024 |
| 16 | 64 | 51 | 1024 |
חשוב לזכור שבקשות של Spark לזיכרון גדולות יותר מהזיכרון של תהליך ההפעלה שהוגדר לצינור, ו-YARN מעגל את הסכום המבוקש כלפי מעלה. לדוגמה, נניח שהגדרתם את הזיכרון של ה-executor ל-2, 048 MB ולא ציינתם ערך לפרמטר spark.yarn.executor.memoryOverhead, כלומר נעשה שימוש בערך ברירת המחדל של 384 MB. המשמעות היא ש-Spark מבקש 2,048 MB + 384 MB לכל תהליך, ו-YARN מעגל את זה למספר שהוא כפולה מדויקת של ההקצאה המינימלית של YARN. כשמריצים על צומת עובד של 8 GB, מכיוון שההקצאה המינימלית של YARN היא 512 MB, היא מעוגלת כלפי מעלה ל-2.5 GB. המשמעות היא שכל תהליך עובד יכול להריץ שני קונטיינרים, תוך שימוש בכל המעבדים הזמינים, אבל נשאר 1GB של זיכרון YARN (6GB – 2.5GB – 2.5GB) ללא שימוש. המשמעות היא שאפשר להקצות לצומת העובד גודל קטן יותר, או להקצות למבצעים קצת יותר זיכרון.
כשמריצים את הפקודה בצומת עובד של 16GB, 2048MB + 1024MB מעוגל כלפי מעלה ל-3GB כי ההקצאה המינימלית של YARN היא 1024MB.
המשמעות היא שכל צומת עובד יכול להריץ ארבעה קונטיינרים, עם כל יחידות העיבוד המרכזיות (CPU) והזיכרון של YARN בשימוש.
כדי לספק הקשר, בטבלה הבאה מוצגות מידות מומלצות של Worker בהינתן מידות נפוצות של Executor.
| Executor CPU | זיכרון של רכיב ההפעלה (MB) | Worker CPU | זיכרון של העובד ( GB) |
|---|---|---|---|
| 1 | 2048 | 4 | 15 |
| 1 | 3072 | 4 | 21 |
| 1 | 4096 | 4 | 26 |
| 2 | 8192 | 4 | 26 |
לדוגמה, צומת עובד בנפח 26GB מתורגם לזיכרון בנפח 20GB שניתן לשימוש להרצת קונטיינרים של YARN. אם הזיכרון של ה-executor מוגדר ל-4GB, נוסף 1GB כעלות תקורה, כלומר 5GB של קונטיינרים של YARN לכל executor. כלומר, העובד יכול להריץ ארבעה קונטיינרים בלי שיישארו משאבים נוספים. אפשר גם להכפיל את הגודל של העובדים. לדוגמה, אם זיכרון המבצע מוגדר ל-4,096GB, גם עובד עם 8 מעבדים וזיכרון של 52GB יתאים. במכונות וירטואליות ב-Compute Engine יש הגבלה על נפח הזיכרון של המכונה הווירטואלית, בהתאם למספר ליבות המעבד. לדוגמה, למכונה וירטואלית עם 4 ליבות צריך להיות לפחות 7.25 GB של זיכרון ולכל היותר 26 GB של זיכרון. כלומר, אם מוגדר למבצע שימוש במעבד אחד ובזיכרון בנפח 8GB, הוא ישתמש ב-2 מעבדים ובזיכרון בנפח 26GB במכונה הווירטואלית. אם במקום זאת תגדירו את ה-executors לשימוש ב-2 מעבדים וב-8GB זיכרון, כל המעבדים ינוצלו.
דיסק
הדיסק חשוב לחלק מהצינורות, אבל לא לכולם. אם צינור העיבוד לא מכיל פעולות ערבוב, נעשה שימוש בדיסק רק כשנגמר הזיכרון של Spark וצריך להעביר נתונים לדיסק. בדרך כלל, הגודל והסוג של הדיסק לא ישפיעו באופן משמעותי על הביצועים של סוגי צינורות כאלה. אם צינור הנתונים שלכם מערבב הרבה נתונים, ביצועי הדיסק ישפיעו על התוצאות. אם אתם משתמשים ב-Managed Service for Apache Spark, מומלץ להשתמש בגדלי דיסקים של 1TB לפחות, כי ביצועי הדיסק גדלים עם גודל הדיסק. מידע על ביצועי הדיסק זמין במאמר הגדרת דיסקים בהתאם לדרישות הביצועים.
מספר העובדים
כדי למזער את זמן הביצוע, צריך לוודא שהאשכול גדול מספיק כדי שיוכל להריץ כמה שיותר פעולות במקביל. לדוגמה, אם מקור צינור עיבוד הנתונים קורא נתונים באמצעות 100 פיצולים, צריך לוודא שהאשכול גדול מספיק כדי להריץ 100 תהליכי הפעלה בו-זמנית.
הדרך הקלה ביותר לדעת אם הגודל של האשכול קטן מדי היא לבדוק את הזיכרון בהמתנה של YARN לאורך זמן. אם אתם משתמשים ב-Managed Service for Apache Spark, תוכלו למצוא גרף בדף הפרטים של האשכול.
אם הזיכרון בהמתנה גבוה למשך תקופות ארוכות, אפשר להגדיל את מספר העובדים כדי להוסיף את הקיבולת הנוספת הזו לאשכול. בדוגמה הקודמת, צריך להגדיל את האשכול בכ-28 GB כדי להבטיח שרמת המקביליות המקסימלית תושג.
מצב גמישות משופר (EFM)
EFM מאפשר לציין שרק צמתי עובדים ראשיים ישתתפו בפעולת ערבוב הנתונים. מכיוון שעובדים משניים לא אחראים יותר לנתוני ערבוב ביניים, כשמסירים אותם מאשכול, משימות Spark לא נתקלות בעיכובים או בשגיאות. מכיוון שאין הקטנה של מספר העובדים הראשיים, האשכול עובר הקטנה בצורה יציבה ויעילה יותר. אם אתם מפעילים צינורות עם ערבובים באשכול סטטי, מומלץ להשתמש ב-EFM.
מידע נוסף על EFM זמין במאמר מצב גמישות משופר של Managed Service for Apache Spark.