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

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

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

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

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

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

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

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

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

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

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

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