תכנון לגמישות ויעילות ב-Dataflow

במסמך הזה מוסבר על עיצוב לגמישות ויעילות (DFE), קבוצה של שיטות מומלצות לארכיטקטורה לבניית צינורות עיבוד נתונים עמידים ב-Dataflow.

המעבר ממגבלות נוקשות של תשתית להגדרות גמישות של משאבים עוזר לכם:

  • למקסם את הזמינות של משאבי מחשוב.
  • כדי להבטיח התאמה אוטומטית לעומס (auto-scaling) בצורה חלקה בתקופות של ביקוש אזורי גבוה.
  • למנוע עיכובים בהפעלת הפייפליין ולסלק צווארי בקבוק בקיבולת.

לדוגמה, במקום להגביל את הצינור לסוג מכונה ספציפי אחד באזור אחד, כמו דרישה של n1-standard-4 עובדים ב-us-central1-a, אפשר להגדיר צורכי משאבים מינימליים (כמו 4 vCPU ו-16GB של RAM). אם יש מגבלות זמניות על הקיבולת של us-central1-a או של סדרת המכונות N1,‏ Dataflow יכול להקצות באופן אוטומטי מכונות וירטואליות תואמות של עובדים באזורים אחרים ובסדרות מכונות אחרות (כמו E2,‏ N2 או N2D). הגמישות הזו עוזרת לוודא שהצינור מתחיל ומתרחב בלי לחכות למאגר חומרה יחיד ומוגבל.

המסמך הזה מיועד למהנדסי נתונים, למומחי Cloud Architect ולאדמינים של פלטפורמות שמנהלים עומסי עבודה של Dataflow ורוצים לשפר את האמינות, את התפוקה ואת זמינות התשתית של צינורות הנתונים.

סקירה כללית על DFE

‫Dataflow הוא שירות מנוהל במלואו לעיבוד נתונים ללא שרתים, שמקצה באופן דינמי מכונות וירטואליות (VM) של Compute Engine כדי להריץ צינורות של Apache Beam. בצינורות עיבוד נתונים של אצווה וסטרימינג בקנה מידה גדול, מאגרי העובדים גדלים לעיתים קרובות לעשרות או למאות מופעים של מכונות וירטואליות.

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

  • קידוד קשיח של סוג מכונה יחיד, כמו n1-standard-4.
  • הצמדת צינור הנתונים לתחום ספציפי ב-Compute Engine.

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

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

שיטות מומלצות לשימוש ב-DFE

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

הפעלת בחירה אוטומטית של מכונה וירטואלית

במקום להגדיר סוג מכונה סטטי באמצעות האפשרות worker machine type של צינור הנתונים, כדאי להשתמש באפשרות Auto VM selection עם רמזים למשאבים של Apache Beam. כשמציינים דרישות מינימליות של משאבים (min_ram או cpu_count), ‏ Dataflow מפעיל באופן אוטומטי את ההפעלה הגמישה של מכונות ומקצה workers מתוך רשימה של סוגי מכונות תואמים.

תמיכה בעומסי עבודה:

  • צינורות עיבוד באצווה: התכונות 'התאמה מדויקת' ו'בחירת מכונה וירטואלית אוטומטית' מופעלות באופן אוטומטי כשמציינים רמזים למשאבים.
  • צינורות לעיבוד נתונים בזמן אמת: כדי להתאים את הצינורות בצורה נכונה, צריך להגדיר את האפשרות --experiments=enable_streaming_rightfitting של הצינור, יחד עם שינוי גודל אוטומטי אופקי (מופעל כברירת מחדל) וStreaming Engine‏ (--enable_streaming_engine).

כדי להגדיר בחירה אוטומטית של מכונה וירטואלית, צריך לציין דרישות מינימליות של משאבים (min_ram או cpu_count) ברמת צינור הנתונים באמצעות אפשרויות של שורת פקודה, אפשרויות של צינור נתונים ב-SDK או פרמטרים של הפעלת תבנית Flex. הוראות מפורטות להגדרה ודוגמאות קוד ל-Java ול-Python מופיעות במאמר שימוש ברמזים למשאבים.

שימוש במיקום עובדים אזורי (הימנעות מהצמדה אזורית)

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

מציינים את אפשרות הצינור --region ומשמיטים את --zone ואת --worker_zone. לדוגמה:

--region=us-central1

הפרדה של מצב וערבוב באמצעות שירותים מנוהלים

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

  • למשימות Batch – משתמשים ב-ארגון נתונים של Dataflow: התכונה ארגון נתונים של Dataflow מופעלת כברירת מחדל בפייפליינים של Batch שפועלים בסוגים נתמכים של מכונות Worker, ומעבירה פעולות מיון נתונים (shuffle) ממכונות Worker וירטואליות לשירות לקצה העורפי ייעודי שמנוהל על ידי Google.
  • לגבי עבודות סטרימינג – משתמשים ב-Streaming Engine: ‫Streaming Engine מעביר את האחסון של מצב החלון ואת ניהול הטיימרים ממכונות VM של עובדים לתשתית ייעודית של קצה עורפי עם תגובה מהירה מאוד. בצינורות (pipelines) שמשתמשים ב-Apache Beam SDK בגרסה 2.30.0 ואילך, Streaming Engine מופעל כברירת מחדל. כדי להפעיל אותו באופן מפורש, מעבירים את האפשרות --enable_streaming_engine של צינור העיבוד.

שימוש בתזמון משאבים גמיש (FlexRS) לצינורות עיבוד נתונים של אצווה

לעומסי עבודה של אצווה שלא רגישים לזמן, כמו ETL לילי, הטמעה של אגם נתונים או סיכומים יומיים, כדאי להשתמש ב-Flexible Resource Scheduling (FlexRS).

כדי להפעיל את FlexRS, מגדירים את אפשרות הצינור flexRS goal:

  • לצינורות עיבוד נתונים של Python: ‏ --flexrs_goal=COST_OPTIMIZED
  • לצינורות Java: ‏ --flexRSGoal=COST_OPTIMIZED

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

כשמפעילים פייפליינים באמצעות תבניות Flex, מכונת ה-VM להפעלת הפייפליין מוגדרת כברירת מחדל ל-e2-standard-2. ברוב המקרים, מכונת ה-VM שמוגדרת כברירת מחדל תפעל בצורה תקינה, אבל אם נתקלים במגבלות קיבולת, אפשר להתאים אישית את ההגדרה באמצעות האפשרות --launcher-machine-type כשמריצים את הפקודה gcloud dataflow flex-template run:

gcloud dataflow flex-template run my-job \
    --template-file-gcs-location="gs://my-bucket/template.json" \
    --region="us-central1" \
    --launcher-machine-type="n2-standard-2"

שיקולים תפעוליים ופשרות

יישום השיטות המומלצות של DFE משפר באופן משמעותי את הזמינות של כוח המחשוב, את מהירות התגובה של שינוי קנה המידה האוטומטי ואת האמינות התפעולית. עם זאת, כשמתכננים את הארכיטקטורה, חשוב לקחת בחשבון את הגורמים התפעוליים והפשרות הבאים:

שיקולים לגבי בחירה אוטומטית של מכונות וירטואליות

  • מהימנות לעומת ביצועים מקסימליים: התכונה 'בחירה אוטומטית של מכונות וירטואליות' נותנת עדיפות למהימנות של הפעלת המשימות ולזמינות של משאבי מחשוב על פני ביצועים מקסימליים. מכיוון ש-Dataflow מקצה משאבים מכמה משפחות מכונות מועמדות (כמו E2, ‏ N2, ‏ N4 ו-N2D), יכול להיות שיהיו הבדלים קלים בביצועים ובקצב העברת הנתונים בזמן הריצה, בהתאם למשפחת המכונות שהוקצתה. כדי לבסס בסיס ביצועים לפני פריסה רחבה של צינור הנתונים, מומלץ לבדוק אותו באמצעות התכונה 'בחירה אוטומטית של מכונות וירטואליות' (Auto VM Selection) אם הוא כולל עומסי עבודה עתירי-חישוב עם הסכמי רמת שירות (SLA) מחמירים לביצוע. אם עומס עבודה דורש פלטפורמת חומרה או מהירות שעון ספציפיות, ואתם יכולים להסתדר עם מגבלות קיבולת, אתם יכולים להמשיך להגדיר סוג מכונה ספציפי.
  • מכסת Compute Engine בכל משפחה פוטנציאלית: מכיוון שתכונת הבחירה האוטומטית של מכונות וירטואליות יכולה להקצות עובדים מכמה משפחות פוטנציאליות של מכונות, צריך לוודא שלפרויקט Google Cloud שלכם יש מכסת vCPU וזיכרון מספיקה ב-Compute Engine לכל משפחה פוטנציאלית באזור היעד. אם יש מחסור בקיבולת בקבוצה המשפחתית הראשית ולפרויקט אין מכסת נפח לקבוצה המשפחתית המשנית, הקצאת העובדים תיכשל עם שגיאה QUOTA_EXCEEDED.
  • דרישה מוקדמת לצינורות לעיבוד נתונים בזמן אמת: בצינורות לעיבוד נתונים בזמן אמת, התכונות 'התאמה נכונה' ו'בחירה אוטומטית של מכונות וירטואליות' לא מופעלות כברירת מחדל. צריך לציין במפורש את --experiments=enable_streaming_rightfitting ולוודא שגם Streaming Engine‏ (--enable_streaming_engine) וגם שינוי גודל אוטומטי אופקי פעילים.

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

    תכונה דגל או אפשרות הגדרה הערות
    סוגי מכונות מפורשים ‫--worker_machine_type או --machine_type (Python)
    --workerMachineType (Java)    		 המערכת מדלגת על בחירה אוטומטית של מכונה וירטואלית ובוחרת במקום זאת את סוג המכונה שצוין.
    סוגי דיסקים מותאמים אישית, פעולות קלט/פלט בשנייה (IOPS) או קצב העברת נתונים (throughput) שהוקצו ‫--disk_type, --disk_provisioned_iops או --disk_provisioned_throughput_mibps הבחירה האוטומטית של מכונות וירטואליות (VM) לא מתבצעת. אפשר להגדיר גודל דיסק מותאם אישית באמצעות --disk_size_gb.
    פלטפורמות CPU מינימליות ‫--min_cpu_platform (Python)
    --minCpuPlatform (Java)    		 הגדרת פלטפורמת CPU מינימלית עוקפת את התכונה 'בחירה אוטומטית של מכונות וירטואליות'.
    Confidential VM --experiments=enable_confidential_compute מכונות וירטואליות מסוג Confidential VM לא נתמכות בבחירה אוטומטית של מכונות וירטואליות.
    מאיצי GPU או TPU רמז למשאב --dataflow_service_options=worker_accelerator=... או accelerator התכונה 'בחירה אוטומטית של מכונה וירטואלית' חלה רק על עומסי עבודה ללא מאיצים.
    ‫Dataflow Prime --dataflow_service_options=enable_prime ב-Dataflow Prime נעשה שימוש בהתאמה אוטומטית לעומס (autoscaling) אנכית ובהתאמה דינמית של גודל המכונה הווירטואלית במקום בבחירה אוטומטית של מכונה וירטואלית.
    תזמון משאבים גמיש (FlexRS) ‫--flexrs_goal=COST_OPTIMIZED (Python)
    --flexRSGoal=COST_OPTIMIZED (Java)    		 ‫FlexRS מנהל את מאגר העובדים שלו ואת מאגר התזמון.

פשרות בתזמון משאבים גמיש (FlexRS)

  • חלון השהיה בתזמון:‏ FlexRS יכול להוסיף מאגר תזמון של עד 6 שעות לפני תחילת הביצוע של העבודה. לא מומלץ להשתמש ב-FlexRS בצינורות (pipelines) עם הסכמי רמת שירות (SLA) מחמירים לגבי זמן ההשלמה או עם תלות חזקה במורד הזרם.

מיקום אזורי ומיקום הנתונים

  • דרישה מוקדמת לשירות מנוהל: מיקום אזורי של workers נתמך רק במשימות שמשתמשות בארגון נתונים של Dataflow לעיבוד באצווה או ב-Streaming Engine לעיבוד בסטרימינג. עבודות שלא משתמשות בשירותים המנוהלים האלה לקצה העורפי ממוקמות אוטומטית באזור, והמערכת בוחרת את האזור הכי טוב מתוך האזור.
  • אחסון ועיבוד נתונים באופן מקומי ותעבורת נתונים יוצאת (egress) בין אזורים: מיקום אזורי מפזר את ה-workers באזורים הזמינים באזור שבחרתם. כדי לצמצם את זמן האחזור ברשת ולהימנע מחיובים על תעבורת נתונים יוצאת (egress) ברשת בין אזורים, חשוב לוודא שכל מקורות הנתונים ויעדי הנתונים (כמו באקטים של Cloud Storage, מערכי נתונים של BigQuery ונושאים של Pub/Sub) נמצאים באותו אזור שבו מוגדרת משימת Dataflow.

מקומות שמורים ב-Compute Engine

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

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