שיטות מומלצות לשימוש ב-Pub/Sub עם BigQuery

בדף הזה מפורטות שיטות מומלצות לאופטימיזציה של צינור Dataflow שקורא מ-Pub/Sub וכותב ל-BigQuery. בהתאם לתרחיש השימוש שלכם, יכול להיות שההצעות הבאות יובילו לשיפור בביצועים.

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

אם צינור נתונים מ-Pub/Sub ל-BigQuery חווה גידול בפיגור ולא מצליח לעמוד בקצב של ההודעות הנכנסות, אפשר לבצע את הפעולות המיידיות הבאות:

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

אופטימיזציות של קוד וצינורות עיבוד נתונים לטווח ארוך

כדי לשמור על ביצועים ויציבות לאורך זמן, מומלץ לבצע את השינויים הבאים בארכיטקטורה ובקוד:

  • צמצום הקריאות ל-BigQuery של שיטת getTable: קריאות מוגזמות לשיטת getTable עלולות להוביל להגבלת קצב ולצווארי בקבוק בביצועים. כדי לצמצם את הסיכון:
    • כדי להימנע מקריאות חוזרות לאותה טבלה, כדאי לשמור במטמון בזיכרון של העובד את המידע על קיום הטבלה.
    • ‫Batch getTable מתבצע על בסיס כל חבילה בנפרד, ולא על בסיס כל רכיב בנפרד.
    • מבצעים רפקטורינג של קוד צינור הנתונים כדי שלא יהיה צורך לבדוק את קיום הטבלה לכל הודעה.
  • שימוש ב-BigQuery Storage Write API: בצינורות להעברת נתונים בזמן אמת שכותבים ל-BigQuery, צריך לעבור מהוספות סטנדרטיות של נתונים בזמן אמת אל Storage Write API. ‫Storage Write API מציע ביצועים טובים יותר ומכסות גבוהות משמעותית.
  • שימוש ב-Dataflow runner מדור קודם לעבודות עם עוצמה גבוהה: לעבודות שמעבדות מספר גדול מאוד של מפתחות ייחודיים (עוצמה גבוהה), יכול להיות ש-Dataflow runner מדור קודם יציע ביצועים טובים יותר מ-Runner v2, אלא אם נדרשים טרנספורמציות חוצות שפות.
  • אופטימיזציה של מרחב המפתחות: הביצועים עלולים להיפגע כשצינורות פועלים על מיליוני מפתחות פעילים. משנים את הלוגיקה של צינור הנתונים כדי לבצע עבודה במרחב קטן יותר של מפתחות שאפשר לנהל בקלות רבה יותר.

ניהול משאבים, מכסות והגדרות

הקצאה והגדרה נכונות של משאבים הן קריטיות לתקינות של צינור הנתונים:

  • ניהול פרואקטיבי של מכסות: כדאי לעקוב אחרי המכסות ולבקש להגדיל אותן אם יש סיכוי שתגיעו למכסה במהלך אירועי הרחבה. לדוגמה, נניח את אירועי ההתאמה הבאים:
    • קצב גבוה של קריאות לשיטות TableService.getTable או tabledata.insertAll עלול לחרוג מהמספר המקסימלי של שאילתות לשנייה (QPS). מידע נוסף על מגבלות ועל בקשת הגדלת מכסה זמין במאמר מכסות ומגבלות ב-BigQuery.
    • יכול להיות שהמכסות של Compute Engine לכתובות IP ולמעבדים שנמצאים בשימוש יעלו על המגבלות המקסימליות. למידע נוסף על מגבלות ועל בקשות להגדלת המכסות, אפשר לעיין במאמר מכסות ומגבלות ב-Compute Engine.
  • אופטימיזציה של הגדרת העובד: כדי למנוע שגיאות של חוסר זיכרון (OOM) ולשפר את היציבות:

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