שיטות מומלצות לשימוש ב-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: כדי להעביר נתונים מצינורות סטרימינג ל-BigQuery, צריך לעבור מהוספות סטרימינג רגילות אל Storage Write API. ‫Storage Write API מציע ביצועים טובים יותר ומכסות גבוהות משמעותית.
  • שימוש ב-Streaming Java Runner (שנקרא בעבר Runner v1) סטנדרטי למשימות עם עוצמה גבוהה: למשימות שמעבדות מספר גדול מאוד של מפתחות ייחודיים (עוצמה גבוהה), יכול להיות ש-Streaming Java Runner יציע ביצועים טובים יותר מ-Portable Runner, אלא אם נדרשים טרנספורמציות חוצות שפות.
  • אופטימיזציה של המרחב המרכזי: הביצועים עלולים להיפגע כשצינורות פועלים על מיליוני מפתחות פעילים. משנים את הלוגיקה של צינור הנתונים כדי לבצע עבודה על מרחב מפתחות קטן יותר וקל יותר לניהול.

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

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

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

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