פתרון בעיות שקשורות לשגיאות ב-BigQuery Storage API

במאמר הזה מוסבר איך לפתור בעיות כשקוראים נתונים ב-BigQuery או מעבירים נתונים ל-BigQuery באמצעות BigQuery Storage Read API,‏ BigQuery Storage Write API‏ (gRPC) או העברות נתונים באמצעות BigQuery Storage Write API‏ (REST) (שיטת tabledata.insertAll).

ניתוח טלמטריה של סטרימינג באמצעות תצוגות של INFORMATION_SCHEMA

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

• Storage Write API (gRPC): אפשר לשלוח שאילתות לתצוגות של INFORMATION_SCHEMA.WRITE_API_TIMELINE כדי לבדוק בקשות להטמעת עדכונים בזמן אמת בסטרימינג של gRPC, את המספר הכולל של הבייטים והשורות שצורפו ואת מספר השגיאות לפי error_code.
• ‫Storage Write API (REST): אפשר להריץ שאילתות על INFORMATION_SCHEMA.STREAMING_TIMELINEviews כדי לבדוק בקשות סטרימינג של REST מדור קודםtabledata.insertAll ושגיאות שקשורות למכסה או למגבלת קצב.

בדוגמה הבאה מבוצעת שאילתה ב-INFORMATION_SCHEMA.WRITE_API_TIMELINE_BY_PROJECT כדי לאחזר את מספר השגיאות ואת הבייטים שהועברו ל-Storage Write API ‏ (gRPC) ב-24 השעות האחרונות:

SELECT
  start_timestamp,
  error_code,
  SUM(total_requests) AS request_count,
  SUM(total_input_bytes) AS input_bytes
FROM
  `region-REGION`.INFORMATION_SCHEMA.WRITE_API_TIMELINE_BY_PROJECT
WHERE
  start_timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND error_code IS NOT NULL
GROUP BY
  start_timestamp,
  error_code
ORDER BY
  start_timestamp DESC;

מחליפים את REGION בשם האזור של מערך הנתונים, כמו us או europe-west1.

פתרון בעיות שקשורות לשגיאות ב-Storage Read API

בהמשך מפורטות שגיאות נפוצות שמתרחשות כשמשתמשים ב-Storage Read API:

שגיאה: Stream removed

פתרון: שולחים מחדש את הבקשה ל-Storage Read API. סביר להניח שמדובר בשגיאה זמנית שאפשר לפתור על ידי ניסיון חוזר לשלוח את הבקשה. אם הבעיה נמשכת, פנו ל-Cloud Customer Care.

שגיאה: Stream expired

הסיבה: השגיאה הזו מתרחשת כשמגיעים לזמן הקצוב לתפוגה של 6 שעות של סשן Storage Read API.

פתרון:

1. הגדלת המקביליות של העבודה.
2. אם ניצול המעבד (CPU) של צמתי ה-worker יציב יחסית ולא חורג מ-85%, כדאי להריץ את העבודה על סוג מכונה גדול יותר.
3. צריך לפצל את העבודה לכמה עבודות או לשאילתות קטנות יותר.

מידע נוסף על ניהול סשנים וקריאת נתונים מופיע במאמר סקירה כללית על Storage Read API.

פתרון בעיות שקשורות להוספת שידורים חיים

בקטעים הבאים מוסבר איך לפתור בעיות שמתרחשות כשמעבירים נתונים ל-BigQuery באמצעות Storage Write API (REST). מידע נוסף על פתרון שגיאות שקשורות למכסות של הזנת זרם נתונים זמין במאמר בנושא שגיאות שקשורות למכסות של הזנת זרם נתונים.

קודי תגובת HTTP של כשל

אם מקבלים קוד תגובה של HTTP שמעיד על כשל, כמו שגיאה ברשת, אין דרך לדעת אם ההוספה לסטרימינג הצליחה. אם תנסו לשלוח מחדש את הבקשה, יכול להיות שיופיעו שורות כפולות בטבלה. כדי להגן על הטבלה מפני כפילויות, צריך להגדיר את המאפיין insertId כששולחים את הבקשה. מערכת BigQuery משתמשת במאפיין insertId כדי לבטל כפילויות.

אם מתקבלת שגיאת הרשאה, שגיאה של שם טבלה לא תקין או שגיאה של חריגה ממכסת נפח, לא מוכנסות שורות והבקשה כולה נכשלת.

קודי תגובת HTTP שמציינים הצלחה

גם אם מקבלים קוד תגובה של תגובת HTTP שמעיד על הצלחה, צריך לבדוק את המאפיין insertErrors של התגובה כדי לדעת אם הוספת השורות הצליחה, כי יכול להיות ש-BigQuery הצליח להוסיף רק חלק מהשורות. יכול להיות שתיתקלו באחד מהתרחישים הבאים:

• כל השורות נוספו בהצלחה: אם המאפיין insertErrors הוא רשימה ריקה, כל השורות נוספו בהצלחה.
• חלק מהשורות נוספו בהצלחה: למעט במקרים שבהם יש אי התאמה בסכימה באחת מהשורות, השורות שמצוינות במאפיין insertErrors לא נוספות, וכל שאר השורות נוספות בהצלחה. המאפיין errors מכיל מידע מפורט על הסיבה לכשל בכל שורה לא מוצלחת. המאפיין index מציין את אינדקס השורה (מבוסס-0) של הבקשה שהשגיאה רלוונטית לגביה.
• לא הוכנסו שורות בהצלחה: אם ב-BigQuery מזוהה אי התאמה בסכימה בשורות נפרדות בבקשה, אף אחת מהשורות לא מוכנסת ומוחזרת רשומה של insertErrors לכל שורה, גם לשורות שלא הייתה בהן אי התאמה בסכימה. בשורה שלא הייתה בה אי התאמה לסכימה, המאפיין reason מוגדר לערך stopped, ואפשר לשלוח אותה מחדש כמו שהיא. בשורות שנכשלו מופיע מידע מפורט על אי ההתאמה לסכימה. מידע נוסף על סוגי מאגרי אחסון לפרוטוקולים ונתוני Arrow שנתמכים

שגיאות במטא-נתונים של הזנת זרם נתונים

ממשק BigQuery streaming API מיועד לשיעורי הוספה גבוהים, ולכן השינויים במטא-נתונים של הטבלה הבסיסית עקביים בסופו של דבר כשמתבצעת אינטראקציה עם מערכת הסטרימינג. ברוב המקרים, שינויים במטא-נתונים מועברים תוך דקות, אבל במהלך התקופה הזו יכול להיות שהתגובות של ה-API ישקפו את המצב הלא עקבי של הטבלה.

דוגמאות לתרחישים:

• שינויים בסכימה: שינוי הסכימה של טבלה שקיבלה לאחרונה הוספות של נתונים בזמן אמת עלול לגרום לתגובות עם שגיאות של חוסר התאמה בסכימה, כי יכול להיות שמערכת הסטרימינג לא תזהה את השינוי בסכימה באופן מיידי.
• יצירה או מחיקה של טבלה: סטרימינג לטבלה שלא קיימת מחזיר וריאציה של תגובת notFound. יכול להיות שתוספות של נתונים בסטרימינג לא יזהו מיד טבלה שנוצרה בתגובה. באופן דומה, מחיקה או יצירה מחדש של טבלה יכולות ליצור תקופה שבה הוספות של נתונים בסטרימינג מועברות לטבלה הישנה. יכול להיות שהוספות הסטרימינג לא יופיעו בטבלה החדשה.
• חיתוך טבלה: חיתוך של נתוני טבלה (באמצעות עבודת שאילתה שמשתמשת בערך writeDisposition של WRITE_TRUNCATE) עלול לגרום להשמטה של הוספות עוקבות במהלך תקופת העקביות.

נתונים חסרים או לא זמינים

הוספות של נתונים בסטרימינג מאוחסנות באופן זמני באחסון שעבר אופטימיזציה לכתיבה, שמאופיין בזמינות שונה מזו של אחסון מנוהל. פעולות מסוימות ב-BigQuery לא מתבצעות באחסון שעבר אופטימיזציה לכתיבה, כמו משימות של העתקת טבלאות ושיטות API כמו tabledata.list. נתוני סטרימינג מהזמן האחרון לא מופיעים בטבלת היעד או בפלט.

שגיאות שקשורות למכסת הזנת זרם נתונים

בקטע הזה מפורטים טיפים לפתרון בעיות שקשורות לשגיאות במכסות של נתונים שמוזרמים ל-BigQuery.

באזורים מסוימים, המכסה של הוספות לסטרימינג גבוהה יותר אם לא מאכלסים את השדה insertId בכל שורה. מידע נוסף על מכסות להוספות בסטרימינג זמין במאמר בנושא הוספות בסטרימינג. השגיאות שקשורות למכסת השימוש ב-BigQuery Streaming תלויות בנוכחות או בהיעדר של insertId.

הודעת שגיאה

אם השדה insertId ריק, יכול להיות שתופיע שגיאת המכסה הבאה:

מגבלת מכסה	הודעת השגיאה
בייטים לשנייה לכל פרויקט	הישות שלך עם gaia_id: GAIA_ID, פרויקט: PROJECT_ID באזור: REGION חרגה מהמכסה של בייטים להוספה לשנייה.

אם השדה insertId מאוכלס, יכולות להופיע שגיאות לגבי מכסת השימוש הבאות:

מגבלת מכסה	הודעת השגיאה
שורות לשנייה לכל פרויקט	הפרויקט שלך: PROJECT_ID ב-REGION חרג מהמכסה של הוספת שורות לשנייה בסטרימינג.
שורות לשנייה לכל טבלה	הטבלה: TABLE_ID חרגה מהמכסה של הזנת זרם נתונים לשנייה.
בייטים לשנייה לכל טבלה	הטבלה שלך: TABLE_ID חרגה מהמכסה של הזנת זרם נתונים בייטים לשנייה.

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

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

אבחון

אפשר להשתמש בתצוגות STREAMING_TIMELINE_BY_* כדי לנתח את תנועת הגולשים בסטרימינג. התצוגות האלה כוללות נתונים סטטיסטיים מצטברים של סטרימינג במרווחי זמן של דקה אחת, שמקובצים לפי error_code. שגיאות שקשורות למכסות מופיעות בתוצאות עם הערך error_code ששווה ל-RATE_LIMIT_EXCEEDED או ל-QUOTA_EXCEEDED.

בהתאם למכסה הספציפית שהגעתם אליה, כדאי לעיין במידע שמופיע בקטע total_rows או בקטע total_input_bytes. אם השגיאה היא מכסת שימוש ברמת הטבלה, מסננים לפי table_id.

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

SELECT
 start_timestamp,
 error_code,
 SUM(total_input_bytes) as sum_input_bytes,
 SUM(IF(error_code IN ('QUOTA_EXCEEDED', 'RATE_LIMIT_EXCEEDED'),
     total_requests, 0)) AS quota_error
FROM
 `region-REGION_NAME`.INFORMATION_SCHEMA.STREAMING_TIMELINE_BY_PROJECT
WHERE
  start_timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY)
GROUP BY
 start_timestamp,
 error_code
ORDER BY 1 DESC

רזולוציה

כדי לפתור את השגיאה שקשורה למכסת השימוש, צריך לבצע את הפעולות הבאות:

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

• אם אתם לא משתמשים ב-insertId, או אם לא ניתן להסיר אותו, כדאי לעקוב אחרי התנועה של הסטרימינג במשך 24 שעות ולנתח את שגיאות המכסה:

  • אם אתם רואים בעיקר שגיאות RATE_LIMIT_EXCEEDED ולא שגיאות QUOTA_EXCEEDED, ונפח תנועת הגולשים הכוללת שלכם נמוך מ-80% מהמכסה, סביר להניח שהשגיאות מצביעות על עליות זמניות. כדי לטפל בשגיאות האלה, צריך לנסות שוב את הפעולה באמצעות השהיה מעריכית לפני ניסיון חוזר בין הניסיונות החוזרים.

  • אם אתם משתמשים במשימת Dataflow כדי להוסיף נתונים, כדאי להשתמש במשימות טעינה במקום בהוספות של נתונים בזמן אמת. מידע נוסף זמין במאמר בנושא הגדרת שיטת ההוספה. אם אתם משתמשים ב-Dataflow עם מחבר קלט/פלט בהתאמה אישית, כדאי לשקול שימוש במחבר קלט/פלט מובנה במקום זאת. מידע נוסף מופיע במאמר בנושא דפוסי קלט/פלט בהתאמה אישית.

  • אם אתם רואים שגיאות QUOTA_EXCEEDED או שתנועת הגולשים הכוללת חורגת באופן עקבי מ-80% מהמכסה, אתם יכולים לשלוח בקשה להגדלת המכסה. מידע נוסף זמין במאמר בנושא שליחת בקשה לשינוי המכסות.

  • אפשר גם להחליף את ההוספות של נתוני סטרימינג ב-Storage Write API החדש יותר, שכולל תפוקה גבוהה יותר, מחיר נמוך יותר ותכונות שימושיות רבות.