בדף הזה מפורטים טיפים נפוצים לפתרון בעיות שקשורות למינויים ל-BigQuery.
בדיקת הסטטוס של מינוי ל-BigQuery
כדי לבדוק את סטטוס המינוי:
נכנסים לדף המינוי ל-Pub/Sub במסוף Google Cloud .
בודקים את הסמל של State (מצב) במינוי ל-BigQuery.
אם הסמל הוא סימן וי ירוק, המינוי תקין.
אם הסמל הוא סימן קריאה אדום, המינוי נמצא במצב שגיאה.
לוחצים על המינוי ל-BigQuery.
ייפתח דף פרטי המינוי.
בודקים את סטטוס המינוי כדי לראות את הודעת השגיאה.
בהתאם להודעת השגיאה, עוברים אל הקטע הרלוונטי בדף הזה כדי לפתור את הבעיה.
אחרי שהבעיה תיפתר, המינוי יחזור בסופו של דבר למצב תקין.
לא ניתן ליצור או לעדכן מינוי
ריכזנו כאן כמה בעיות נפוצות שאתם עשויים להיתקל בהן אם אתם מתקשים ליצור או לעדכן מינוי ל-BigQuery.
השגיאה 'הטבלה לא נמצאה'
אם הטבלה שציינתם בתהליך העבודה של יצירה או עדכון מינוי לא קיימת, תהליך העבודה יחזיר שגיאה של טבלה לא נמצאה. ההודעה במסוף Google Cloud תיראה כך:
The BigQuery table or dataset specified cannot be found.
כדי לפתור את הבעיה, צריך ליצור את הטבלה ולוודא שאפשר לבדוק את המצב שלה לפני שמשתמשים בה עם מינוי ל-BigQuery.
שגיאה של אי התאמה בסכימה
אם הסכימות של הטבלה והנושא לא תואמות, תהליך העבודה של יצירה או עדכון של מינוי מחזיר שגיאת חוסר התאמה בסכימה. ההודעה במסוף Google Cloud תיראה כך:
Incompatible schema type for field project_ids: expected INT64, got STRING
הודעת השגיאה שצוינה מתייחסת לחוסר התאמה בסכימה של שדה שנקרא project_ids.
בהתאם לסוג אי ההתאמה של הסכימה, יכול להיות שתופיע גרסה שונה של הודעת השגיאה.
כדי לפתור את הבעיה, צריך לבדוק אם מיפויי הסכימות תואמים.
שגיאה בחשבון שירות
אם לא הגדרתם את חשבון השירות של Pub/Sub עם ההרשאות הנכונות, תוחזר שגיאה בתהליך העבודה של יצירה או עדכון של מינוי. ההודעה במסוף Google Cloud תיראה כך:
Service account service-1234234234@gcp-sa-pubsub.iam.gserviceaccount.com
is missing permissions required to write to the BigQuery table:
bigquery.tables.get, bigquery.tables.updateData.
כדי לפתור את הבעיה, צריך לבדוק אם לחשבון השירות יש הרשאות מתאימות.
במצב המינוי מופיע סימן קריאה אדום
אם עורכים את הטבלה אחרי שיוצרים מינוי, זה יכול להשפיע על האופן שבו Pub/Sub כותב הודעות לטבלה. אם שינוי גורם לבעיה, שדה המצב של המינוי מוגדר למצב שגיאה.
בדף פרטי המינוי, בודקים את הסטטוס של השדה Subscription state.
בשדה Subscription state מופיעה שגיאה ספציפית יותר,
שיכולה להיות אחת מהשגיאות הבאות:
לא נמצאה טבלה: הטבלה נמחקה. יוצרים טבלה ובודקים את המצב שלה. איך מקבלים מידע על טבלה
ההרשאה לטבלה נדחתה: לחשבון השירות של Pub/Sub אין יותר הרשאה לכתוב לטבלה. בודקים אם לחשבון השירות יש את ההרשאות הנכונות.
אי התאמה בסכימת הטבלה: סכימת הטבלה כבר לא תואמת להגדרות המינוי ב-BigQuery. בודקים אם מיפויי הסכימה תואמים.
בזמן שמנוי Pub/Sub נמצא במצב שגיאה, ההודעות לא נכתבות בטבלה ב-BigQuery ונשארות בפיגור של המנוי. שימו לב: אם מוגדר נושא להודעות ללא מוצא, ההודעות לא מועברות אליו. הודעות שלא אושרו נשמרות למשך התקופה שמוגדרת ב-message_retention_duration(7 ימים כברירת מחדל).
נוצר בקלוג
אם אתם רואים הצטברות של הודעות במינוי או שהודעות מועברות לנושא של הודעות שלא ניתן להעביר במינוי, כדאי לבדוק את הסיבות האפשריות הבאות.
הודעת השגיאה INVALID_ARGUMENT
השגיאה הזו מתרחשת כשההודעה שסופקה היא בפורמט ש-Pub/Sub מחשיב כתקין, אבל הסכימה של טבלת היעד ב-BigQuery לא תואמת. המשמעות היא שלפחות אחד מהשדות בהודעה מכיל ערכים שלא תואמים לסכמת הטבלה ב-BigQuery. בדקו את התאימות של הסכימה כדי לוודא שסוגי הנתונים והפורמטים נכונים. אלה כמה מהשגיאות הנפוצות ביותר:
מחרוזת ריקה (
"") היא לא JSON תקין. כששולחים נתונים לעמודה בטבלת JSON ב-BigQuery שאפשר להזין בה ערך null, צריך לספק אובייקט JSON ריק({}),nullאו מחרוזת JSON ריקה("\"\"")כדי לייצג ערכים חסרים. שליחת מחרוזת ריקה תוביל לשגיאה.אם ערך של שדה בהודעה חורג מהאורך המקסימלי של השדה ב-BigQuery, ההודעה נכשלת בגלל מגבלות גודל.
כדי לפתור בעיות שקשורות לשגיאות INVALID_ARGUMENT, מוסיפים נושא של הודעות שלא נמסרו למינוי הרלוונטי. נושא ההודעות שלא נמסרו (dead letter) מתעד הודעות שלא ניתן היה לכתוב ב-BigQuery, יחד עם מאפיין בשם CloudPubSubDeadLetterSourceDeliveryErrorMessage שמסביר את סיבת הכשל.
אפשר לראות את הכשלים האלה גם בMetrics Explorer.
בוחרים את המדד pubsub.googleapis.com/subscription/push_request_count ומסננים לפי response_code=invalid_argument.
הודעת השגיאה RESOURCE_EXHAUSTED
אם הכתיבה של ההודעות ל-BigQuery מתבצעת לאט, יכול להיות שתצטרכו להגדיל את מכסת הדחיפה של Pub/Sub בפרויקט או את מכסת קצב העברת הנתונים של אחסון ב-BigQuery. כדי לבדוק אם הגעתם למגבלות על המכסה, בודקים את מדד בקשות הדחיפה (subscription/push_request_count) כדי לראות אם יש שגיאות מסוג resource_exhausted.
דרך נוספת לאבחון בעיות שקשורות למכסה היא לבדוק את המכסה של הפרויקט. עוברים אל IAM & Admin > Quotas בפרויקט שמכיל את משאב Pub/Sub או את מופע BigQuery. מחפשים את המכסה הרלוונטית, pubsub.googleapis.com/regionalpushsubscriber או bigquerystorage.googleapis.com/write/append_bytes. אם אתם צריכים להגדיל את אחת המכסות, אתם יכולים לבקש שינוי מכסות.
טבלה מחולקת למחיצות (Partitions) לפי שעה שמוצג בה __UNPARTITIONED__ בעמודה של מזהה המחיצה
כשמבצעים חלוקה למחיצות של טבלת יעד ב-BigQuery לפי שעה, השורות מגיעות בהתחלה למחיצה מיוחדת עם התווית __UNPARTITIONED__ בתצוגה INFORMATION_SCHEMA.PARTITIONS.
זו התנהגות צפויה בטבלאות שמשתמשות בחלוקה למחיצות לפי זמני כתיבת הנתונים.
ב-BigQuery נעשה שימוש במאגר זמני של נתונים בסטרימינג כדי לבצע אופטימיזציה של תהליך הכתיבה.
יכול להיות שהנתונים יישארו במחיצה __UNPARTITIONED__ עד שייצבר נפח מספיק או עד שתחלוף לפחות שעה. אחרי שהתנאים האלה מתקיימים, BigQuery מחלק מחדש את הנתונים למחיצה השעתית המתאימה.
אפשר לעקוב אחרי הנתונים במחיצה __UNPARTITIONED__ באמצעות התצוגה INFORMATION_SCHEMA.PARTITIONS.
המאמרים הבאים
- אם עדיין יש לכם בעיות במינוי ל-BigQuery, תוכלו לעיין במאמר בנושא קבלת תמיכה.