יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

פתרון בעיות שקשורות למכסות ולמגבלות

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

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

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

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

סקירה כללית

אם פעולה ב-BigQuery נכשלת בגלל חריגה ממכסה, ה-API מחזיר את קוד הסטטוס 403 Forbidden‏ HTTP. גוף התשובה מכיל מידע נוסף על המכסה שהגעתם אליה. גוף התשובה אמור להיראות כך:

{
  "code" : 403,
  "errors" : [ {
    "domain" : "global",
    "message" : "Quota exceeded: ...",
    "reason" : "quotaExceeded"
  } ],
  "message" : "Quota exceeded: ..."
}

בשדה message במטען הייעודי (payload) מפורטת המגבלה שהייתה חריגה ממנה. לדוגמה, בשדה message יכול להיות הערך Exceeded rate limits: too many table update operations for this table.

באופן כללי, מגבלות המכסה נחלקות לשתי קטגוריות, שמצוינות בשדה reason במטען הייעודי (payload) של התגובה.

‫rateLimitExceeded. הערך הזה מציין מגבלה לטווח קצר. כדי לפתור את הבעיות שקשורות למגבלות, נסו שוב לבצע את הפעולה אחרי כמה שניות. צריך להשתמש בהשהיה מעריכית לפני ניסיון חוזר בין ניסיונות חוזרים. כלומר, להגדיל באופן מעריכי את העיכוב בין כל ניסיון חוזר.
‫quotaExceeded. הערך הזה מציין מגבלה לטווח ארוך יותר. אם הגעתם למגבלת מכסת שימוש לטווח ארוך, צריך לחכות 10 דקות או יותר לפני שמנסים לבצע את הפעולה שוב. אם אתם מגיעים באופן עקבי לאחת ממגבלות המכסה לטווח ארוך, כדאי לנתח את עומס העבודה כדי למצוא דרכים לצמצם את הבעיה. הפעולות לצמצום הסיכון יכולות לכלול אופטימיזציה של עומס העבודה או בקשה להגדלת המכסה.

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

במקרים מסוימים, אפשר להגדיל את המכסה על ידי פנייה לתמיכה של BigQuery או פנייה Cloud de Confiance by S3NS לצוות המכירות, אבל אנחנו ממליצים לנסות קודם את ההצעות במאמר הזה.

אבחון

כדי לאבחן בעיות:

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

לדוגמה, השאילתה הבאה משתמשת בתצוגה INFORMATION_SCHEMA.JOBS כדי להציג רשימה של כל השגיאות שקשורות למכסה במהלך היום האחרון:
```
SELECT
job_id,
creation_time,
error_result
FROM  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY) AND
    error_result.reason IN ('rateLimitExceeded', 'quotaExceeded')
```
מחליפים את REGION_NAME באזור של הפרויקט. לפניו חייב להופיע region-. לדוגמה, כדי להשתמש במיקום US במספר אזורים, צריך להשתמש ב-region-us.
צפייה בשגיאות ביומני הביקורת של Cloud.

לדוגמה, באמצעות Logs Explorer, השאילתה הבאה מחזירה שגיאות עם Quota exceeded או limit במחרוזת ההודעה:
```
resource.type = ("bigquery_project" OR "bigquery_dataset")
protoPayload.status.code ="7"
protoPayload.status.message: ("Quota exceeded" OR "limit")
```
בדוגמה הזו, קוד הסטטוס 7 מציין PERMISSION_DENIED, שמתאים לקוד הסטטוס 403 של HTTP.

דוגמאות נוספות לשאילתות ביומני הביקורת של Cloud מופיעות במאמר בנושא שאילתות ב-BigQuery.

פתרון בעיות שקשורות למכסות או למגבלות שאפשר להגדיל

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

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

השגיאה הזו מוחזרת מ-BigQuery כשמריצים שאילתה בתוכנית ללא תשלום והחשבון מגיע למגבלת השאילתות החודשית. מידע נוסף על תמחור שאילתות זמין במאמר בנושא תוכנית שימוש בחינם.

הודעת שגיאה

Your project exceeded quota for free query bytes scanned

רזולוציה

כדי להמשיך להשתמש ב-BigQuery, צריך לשדרג את החשבון לחשבון בתשלום לחיוב ב-Cloud.

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

בקטע הזה מפורטים טיפים לפתרון בעיות שקשורות לשגיאות במכסות של נתונים שמוזרמים ל-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 החדש יותר, שכולל תפוקה גבוהה יותר, מחיר נמוך יותר ותכונות שימושיות רבות.

מידע נוסף על הזנת זרם נתונים זמין במאמר הזנת נתונים ל-BigQuery.

מספר מקסימלי של שאילתות בו-זמנית שמכילות פונקציות מרוחקות

המערכת של BigQuery מחזירה את השגיאה הזו כשמספר השאילתות המקבילות שמכילות פונקציות מרוחקות חורג מהמגבלה.

מידע נוסף על המגבלות של פונקציות מרחוק זמין במאמר פונקציות מרחוק.

הודעת שגיאה

Exceeded rate limits: too many concurrent queries with remote functions for
this project

אפשר להגדיל את המכסה הזו. כדאי לנסות קודם את הפתרונות העקיפים והשיטות המומלצות.

אבחון

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

רזולוציה

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

מספר מקסימלי של `CREATE MODEL` הצהרות

השגיאה הזו מציינת שחרגתם מהמכסה של הצהרות CREATE MODEL.

הודעת שגיאה

Quota exceeded: Your project exceeded quota for CREATE MODEL queries per
 project.

רזולוציה

אם חרגתם מהמכסה של הצהרות CREATE MODEL, אתם יכולים לשלוח אימייל לכתובת bqml-feedback@google.com ולבקש הגדלה של המכסה.

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

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

הודעת שגיאה

Your project exceeded quota for copies per project

אבחון

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

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

SELECT
creation_time, job_id, user_email, destination_table.project_id, destination_table.dataset_id, destination_table.table_id
FROM `PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 2 DAY) AND CURRENT_TIMESTAMP()
AND job_type = "COPY"
order by creation_time DESC

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

כדי לראות את כל עבודות ההעתקה בכל האזורים, אפשר להשתמש במסנן הבא ב-Cloud Logging:

resource.type="bigquery_resource"
protoPayload.methodName="jobservice.insert"
protoPayload.serviceData.jobInsertRequest.resource.jobConfiguration.tableCopy:*

רזולוציה

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

שגיאה שקשורה לחריגה מהמכסה היומית של בייטים לחילוץ

המערכת של BigQuery מחזירה את השגיאה הזו כשהחילוץ חורג מהמגבלה היומית שמוגדרת כברירת מחדל של 50 TiB בפרויקט. מידע נוסף על מגבלות של משימות חילוץ זמין במאמר משימות חילוץ.

הודעת שגיאה

Your usage exceeded quota for ExtractBytesPerDay

אבחון

אם מייצאים טבלה שגודלה יותר מ-50TiB, הייצוא נכשל כי היא חורגת ממגבלת החילוץ. אם רוצים לייצא נתונים מטבלה למחיצות ספציפיות בטבלה, אפשר להשתמש בקישוט מחיצות כדי לזהות את המחיצות שרוצים לייצא.

אם רוצים לאסוף נתוני שימוש של ייצוא נתונים מהימים האחרונים, אפשר לנסות את הפעולות הבאות:

צפייה במכסות של הפרויקט עם קריטריוני סינון כמו Name: Extract bytes per day או Metric: bigquery.googleapis.com/quota/extract/bytes, יחד עם התרשים 'הצגת השימוש', כדי לראות את מגמת השימוש לאורך כמה ימים.

אפשר גם להריץ שאילתה ב-INFORMATION_SCHEMA.JOBS_BY_PROJECT כדי לראות את סך הבייטים שחולצו במשך כמה ימים. לדוגמה, השאילתה הבאה מחזירה את סך הבייטים היומי שעובד על ידי משימות EXTRACT בשבעת הימים האחרונים.

SELECT
TIMESTAMP_TRUNC(creation_time, DAY) AS day,
SUM ( total_bytes_processed ) / POW(1024, 3) AS total_gibibytes_processed
FROM
`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP()
AND job_type = "EXTRACT"
GROUP BY 1
ORDER BY 2 DESC

לאחר מכן, תוכלו לצמצם עוד יותר את התוצאות על ידי זיהוי המשימות הספציפיות שצורכות יותר בייטים מהצפוי. בדוגמה הבאה מוצגות 100 המשימות המובילות של EXTRACT שצורכות יותר מ-100 GB שעברו עיבוד במהלך שבעת הימים האחרונים.

SELECT
creation_time,
job_id,
total_bytes_processed/POW(1024, 3) AS total_gigabytes_processed
FROM
`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP()
AND job_type="EXTRACT"
AND total_bytes_processed > (POW(1024, 3) * 100)
ORDER BY
total_bytes_processed DESC
LIMIT 100

אפשר גם להשתמש בכלי לבדיקת משרות עם מסננים כמו Bytes processed more than כדי לסנן משרות עם עומס עיבוד גבוה לתקופה מסוימת.

רזולוציה

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

בקטע ההערות במאמר משימות חילוץ מוסבר על גישות חלופיות שמאפשרות לייצא יותר מ-50 TiB.

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

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

הודעת שגיאה

Your project:[project number] exceeded quota for tabledata.list bytes per second per project

רזולוציה

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

באופן כללי, מומלץ לנסות לא לחרוג מהמגבלה הזו. לדוגמה, אפשר לשלוח את הבקשות בהפרשים גדולים יותר לאורך תקופה ארוכה יותר, עם השהיות. אם השגיאה לא מתרחשת לעיתים קרובות, אפשר לפתור את הבעיה באמצעות הטמעה של ניסיונות חוזרים עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).
אם תרחיש השימוש מצפה לקריאה מהירה ותכופה של כמות גדולה של נתונים מטבלה, מומלץ להשתמש ב-BigQuery Storage Read API במקום ב-API‏ tabledata.list.
אם ההצעות הקודמות לא עזרו, אפשר לבקש להגדיל את המכסה מCloud de Confiance לוח הבקרה של ה-API במסוף:
1. עוברים אל Cloud de Confiance מרכז הבקרה של ה-API במסוף.
2. במרכז הבקרה, מסננים לפי מכסה: Tabledata list bytes per minute (default quota).
3. בוחרים את המכסה ופועלים לפי ההוראות במאמר בקשה לשינוי מכסה.
יכול להיות שיחלפו כמה ימים עד שנבדוק את הבקשה ונטפל בה.

שגיאות שקשורות לחריגה מהמספר המקסימלי של בקשות API

השגיאה הזו מוחזרת מ-BigQuery כשמגיעים למגבלת הקצב של מספר בקשות API ל-BigQuery API לכל משתמש לכל שיטה – לדוגמה, קריאות לשיטה tables.get מחשבון שירות, או קריאות לשיטה jobs.insert מכתובת אימייל אחרת של משתמש.

לרוב שיטות הליבה של BigQuery API יש מכסה של עד 100 בקשות API לכל משתמש לכל שיטה. עם זאת, לחלק משיטות הליבה האלה יכולים להיות הגבלות שונות על קצב הבקשות. לדוגמה:

לשיטה jobs.get יש מגבלה של 1,000 בקשות API לכל משתמש בשנייה.
לשיטה projects.list ולשיטה tables.insert יש מגבלה של 10 בקשות לכל משתמש בשנייה.

בנוסף, מגבלות התעריפים של BigQuery API לא חלות על הזנת זרם נתונים.

מידע נוסף על מגבלות קצב אישיות זמין במאמר בנושא מגבלת קצב של מספר מקסימלי של בקשות API לשנייה לכל משתמש לכל שיטה.

הודעת שגיאה

Quota exceeded: Your user_method exceeded quota for concurrent api requests
per user per method.

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

אבחון

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

לחשבון שירות

עוברים לפרויקט שבו מתארח חשבון השירות.
נכנסים אל מרכז הבקרה של ה-API במסוף Cloud de Confiance .

הוראות לצפייה בפרטי השימוש ב-API זמינות במאמר שימוש בלוח הבקרה של ה-API.
במרכז הבקרה של ה-API, בוחרים באפשרות BigQuery API.
כדי לראות פרטים נוספים על השימוש, בוחרים באפשרות מדדים ומבצעים את הפעולות הבאות:
1. בקטע Select Graphs (בחירת תרשימים), בוחרים באפשרות Traffic by API method (תנועה לפי שיטת API).
2. מסננים את התרשים לפי פרטי הכניסה של חשבון השירות. יכול להיות שתראו עליות חדות בשיטה בטווח הזמן שבו הבחנתם בשגיאה.

בקריאות ל-API

חלק מהקריאות ל-API מתעדות שגיאות ביומני הביקורת של BigQuery ב-Cloud Logging. כדי לזהות את השיטה שהגיעה למגבלה:

במסוף Cloud de Confiance , עוברים לתפריט הניווט Cloud de Confiance ובוחרים באפשרות Logging > Logs Explorer עבור הפרויקט:

כניסה לדף Logs Explorer

מסננים את היומנים באמצעות הרצת השאילתה הבאה:

 resource.type="bigquery_resource"
 protoPayload.authenticationInfo.principalEmail="<user email or service account>"
 "Too many API requests per user per method for this user_method"
 In the log entry, you can find the method name under the property protoPayload.method_name.

מידע נוסף זמין במאמר סקירה כללית של יומני ביקורת ב-BigQuery.

רזולוציה

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

כדי שמספר הבקשות לא יעבור את המגבלה הזו, צריך לצמצם את מספר בקשות ה-API או להוסיף השהיה בין כמה בקשות API.
אם החריגה מהמגבלה מתרחשת רק מדי פעם, אפשר להטמיע ניסיונות חוזרים בשגיאה הספציפית הזו עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).
אם אתם מכניסים נתונים לעיתים קרובות, כדאי להשתמש ב-BigQuery Storage Write API‏ (gRPC). הזרמת נתונים באמצעות ממשק ה-API הזה לא מושפעת מהמכסה של BigQuery API.
במהלך טעינת נתונים ל-BigQuery באמצעות Dataflow עם מחבר BigQuery I/O, יכול להיות שתיתקלו בשגיאה הזו בשיטה tables.get. כדי לפתור את הבעיה:
- מגדירים את מאפיין יצירת הטבלה של היעד לCREATE_NEVER. מידע נוסף מופיע במאמר יצירת פעולת סילוק.
- משתמשים ב-Apache Beam SDK בגרסה 2.24.0 ואילך. בגרסאות הקודמות של ה-SDK, הפונקציה CREATE_IF_NEEDED disposition קוראת לשיטה tables.get כדי לבדוק אם הטבלה קיימת.
- למידע נוסף על הגדלת המכסה, ראו בקשה להגדלת מכסה. הטיפול בבקשות להגדלת המכסה עשוי להימשך כמה ימים. כדי לספק מידע נוסף לבקשה, מומלץ לציין בבקשה את העדיפות של העבודה, את המשתמש שמריץ את השאילתה ואת השיטה שהושפעה.

המספר המקסימלי של בייטים לאחסון תמונות של פונקציות מוגדרות על ידי המשתמש (UDF) ב-Python לכל פרויקט בכל אזור

הגודל הכולל של כל תמונות המאגר שמשמשות פונקציות Python UDF פעילות לא יכול לחרוג מ-10 GiB לכל פרויקט לכל אזור. המגבלה הזו נאכפת כשיוצרים או מעדכנים פונקציית UDF ב-Python. אם הגודל הכולל חורג מהמגבלה האזורית, הבקשה נכשלת באופן מיידי ומוחזרת השגיאה הבאה.

הודעת שגיאה

Resources exceeded during query execution: Quota exceeded: Your project: PROJECT_ID exceeded quota for Python UDF image storage usage per region per project.

רזולוציה

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

כדי לבקש הגדלה: עוברים לדף Quotas & System Limits, מחפשים את המכסה Python UDF image storage bytes per project per region ומבקשים להגדיל אותה.
אופטימיזציה של האחסון: מחיקה של פונקציות UDF ב-Python שלא נעשה בהן שימוש באמצעות ההצהרה DROP FUNCTION כדי לפנות מקום. אחרי שמחקתם UDF, גודל התמונה שלו לא נספר יותר במכסת הנפח. אפשר לראות את גודל התמונה באמצעות RoutineBuildStatus של ה-API. מידע נוסף על הצגת סטטוס ה-build זמין במאמר סטטוס ה-build של מאגר.

מספר מקסימלי של פונקציות מוגדרות על ידי המשתמש (UDF) של Python בו-זמנית

אתם יכולים להשתמש בעד 10 פונקציות Python UDF בו-זמנית בכל פרויקט. אם מריצים יותר מ-10, מקבלים את השגיאה הבאה.

הודעת שגיאה

Exceeded rate limits: too many concurrent queries with Python UDFs in this project. Your project: PROJECT_ID exceeded quota for maximum concurrent Python UDFs per project.

כדי לראות את כל המכסות של פונקציות מוגדרות על ידי המשתמש ב-Python, אפשר לעיין בשגרות במאמר בנושא מכסות ומגבלות.

רזולוציה

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

מגבלות על קצב הביצוע של פונקציות מוגדרות על ידי המשתמש (UDF) ב-Python או שגיאות קיבולת

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

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

הודעת שגיאה

Resources exceeded during query execution: Python user-defined function execution exceeded rate limits or capacity. Check https://docs.cloud.google.com/bigquery/docs/troubleshoot-quotas for more details.

רזולוציה

כדי לפתור את השגיאה, נסו את הפעולות הבאות:

התאמת המגבלות של הקונטיינר: כדאי לבדוק את המדדים של פונקציות מוגדרות על ידי המשתמש (UDF) ב-Python ב-Cloud Monitoring כדי לבדוק את ניצול המעבד, ניצול הזיכרון ובקשות מקבילות. אם הערך של container_request_concurrency נמוך, כדאי להגדיל אותו כדי שכל מופע של קונטיינר יוכל לעבד יותר בקשות במקביל. אם הערך של container_cpu נמוך מ-1.0 vCPU בלי ערך container_request_concurrency מפורש, ערך ברירת המחדל של concurrency הוא 1 בזמן הריצה. מידע נוסף זמין במאמר בנושא הגדרת מגבלות על קונטיינרים עבור פונקציות UDF של Python.
אופטימיזציה של הביצוע של פונקציות UDF ומבנה השאילתה: כדאי לפעול לפי השיטות המומלצות לשימוש בפונקציות UDF של Python כדי לקצר את זמן הביצוע ולצמצם את נפח הבקשות לכל שאילתה. לדוגמה, כדאי לסנן את הנתונים לפני שמפעילים את ה-UDF, לשמור על מטען ייעודי (payload) קטן של שורות קלט ולבנות את השאילתה כך שתתמוך באריזה של נתונים (batching).
שולחים בקשה להגדלת הקיבולת: אם השגיאה נמשכת אחרי האופטימיזציה של ה-UDF, פונים אל התמיכה או אל צוות המכירות כדי לבקש הגדלה של מגבלת ההרחבה של מאגר התגים. בבקשה, צריך לכלול את העדיפות, תרחיש השימוש ומזהה הפרויקט.

פתרון בעיות שקשורות למכסות או למגבלות שלא ניתן להגדיל

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

חרגתם ממגבלת הצילומים של טבלאות

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

מידע נוסף על המגבלות על פעולות בטבלה ביום זמין במאמר בנושא טבלאות רגילות.

אי אפשר להגדיל את המגבלה הזו.

הודעת שגיאה

Your table exceeded quota for SNAPSHOT operations per table

רזולוציה

כדי לפתור את השגיאה הזו, כדאי לבצע את הפעולות הבאות:

להקטין את מספר פעולות הצילום שבוצעו בטבלה המושפעת בחלון של 24 שעות.
אם אין אפשרות להפחית את התדירות של יצירת ה-snapshot, פנו אל Cloud Customer Care או אל מנהל החשבון הטכני שלכם.

המספר המקסימלי של שגיאות במשימות בהמתנה

אי אפשר להגדיל את המכסה הזו.

הודעת שגיאה

Quota exceeded: concurrent number of jobs that can be in the pending state

רזולוציה

אי אפשר להגדיל את המכסה הזו.

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

הפחתת קצב השליחה: הפחתת הקצב שבו אתם שולחים עבודות ל-BigQuery.
הגבלת הפעלה בו-זמנית: לא מומלץ לשלוח מספר גדול של משימות במקביל, כי הן עלולות להיתקע במצב 'בהמתנה'.

שגיאות במגבלות על תור השאילתות

יכול להיות שתיתקלו בשגיאה הזו אם בפרויקט יש יותר שאילתות אינטראקטיביות או שאילתות אצווה ממה שמאפשרת מגבלת התור שלו.

הודעת שגיאה

Quota exceeded: Your project and region exceeded quota for max number of jobs
that can be queued per project.

רזולוציה

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

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

לדוגמה, אם השאילתה מכילה ביטוי טבלה נפוץ (CTE) – WITHפסוקית – שמופיע ביותר ממקום אחד בשאילתה, החישוב הזה מתבצע כמה פעמים. עדיף לשמור את החישובים שבוצעו על ידי CTE בטבלה זמנית, ואז להפנות אליהם בשאילתה.

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

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

כדי להימנע מהגעה למגבלת תור השאילתות, כדאי להשתמש בהמלצות שברשימה הבאה כדי לבצע אופטימיזציה של מודל השאילתות.
- שמירת נתונים (טבלאות שמורות). מעבדים מראש את הנתונים ב-BigQuery ומאחסנים אותם בטבלאות נוספות. לדוגמה, אם מריצים הרבה שאילתות דומות שדורשות הרבה חישובים באמצעות תנאי WHERE שונים, התוצאות שלהן לא נשמרות במטמון. גם שאילתות כאלה צורכות משאבים בכל פעם שהן מופעלות. כדי לשפר את הביצועים של שאילתות כאלה ולקצר את זמן העיבוד שלהן, אפשר לבצע מראש את החישוב של הנתונים ולאחסן אותם בטבלה. אפשר להריץ שאילתות SELECT על הנתונים המחושבים מראש בטבלה. לרוב אפשר לעשות את זה במהלך ההטמעה בתהליך ה-ETL, או באמצעות שאילתות מתוזמנות או תצוגות חומריות.
- שימוש במצב פרימטר לבדיקות מריצים שאילתות במצב הרצה יבשה, שבו המערכת מעריכה את מספר הבייטים שנקראו אבל לא מעבדת את השאילתה בפועל.
- תצוגה מקדימה של נתוני הטבלה כדי להתנסות בנתונים או לבדוק אותם במקום להריץ שאילתות, אפשר להשתמש בתצוגה מקדימה של טבלה ב-BigQuery.
- שימוש בתוצאות של שאילתות שנשמרו במטמון. כל תוצאות השאילתות, כולל שאילתות אינטראקטיביות ושאילתות אצווה, נשמרות במטמון בטבלאות זמניות למשך כ-24 שעות, עם כמה חריגים. הפעלת שאילתה שנשמרה במטמון עדיין נספרת במסגרת המגבלה על מספר השאילתות המקבילות, אבל שאילתות שמשתמשות בתוצאות שנשמרו במטמון מהירות משמעותית משאילתות שלא משתמשות בתוצאות שנשמרו במטמון, כי BigQuery לא צריך לחשב את קבוצת התוצאות.
- שימוש ב-BigQuery BI Engine. אם נתקלתם בשגיאה הזו כשניסיתם ליצור לוחות בקרה שמריצים שאילתות על נתונים ב-BigQuery באמצעות כלי לניתוח נתונים עסקיים (BI), מומלץ להשתמש ב-BigQuery BI Engine. השימוש ב-BigQuery BI Engine הוא אופטימלי לתרחיש השימוש הזה.
שימוש בעבודות עם עדיפות של קבוצות. אפשר להוסיף לתור יותר שאילתות אצווה מאשר שאילתות אינטראקטיביות.
חלוקת שאילתות כדאי לארגן את העומס ולחלק אותו בין פרויקטים שונים בהתאם לאופי השאילתות ולצרכים העסקיים שלכם.
הגדלת מספר המשבצות בהזמנה. להגדיל את מספר המשבצות או, אם יש לכם עומס עבודה עם ביקוש גבוה, לעבור מהמודל על פי דרישה (תשלום לפי שאילתה) למודל של הזמנות (תשלום לפי קיבולת).

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

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

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

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

שגיאות במגבלת הגודל של ערבוב השירים

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

המכסה הזו מחושבת לכל הזמנה, והיא מחולקת בין הפרויקטים של ההזמנות. צוות Cloud Customer Care לא יכול לשנות את המכסה. כדי לקבל מידע נוסף על השימוש, אפשר לשלוח שאילתה לתצוגה INFORMATION_SCHEMA.JOBS_TIMELINE.

אם אתם משתמשים במודל התמחור על פי דרישה, אתם מוגבלים למקסימום 2,000 משבצות זמן. כדי להגדיל את מספר המקומות, צריך לעבור למודל תמחור מבוסס-קיבולת.

הודעת שגיאה

מופיעה אחת מהודעות השגיאה הבאות:

Quota exceeded: Your project exceeded quota for total shuffle size limit.

Resources exceeded: Your project or organization exceeded the maximum
  disk and memory limit available for shuffle operations. Consider provisioning
  more slots, reducing query concurrency, or using more efficient logic in this
  job.

רזולוציה

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

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

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

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

כדי לראות את הערך של המגבלה Number of partition modifications per column-partitioned table per day, אפשר לעיין במאמר בנושא Partitioned tables.

הודעת שגיאה

Quota exceeded: Your table exceeded quota for
Number of partition modifications to a column partitioned table

רזולוציה

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

כדי להקטין את המספר הכולל של המחיצות, צריך לשנות את החלוקה למחיצות בטבלה כך שיהיו יותר נתונים בכל מחיצה. לדוגמה, אפשר לשנות את הפילוח לפי יום לפילוח לפי חודש או לשנות את אופן הפילוח של הטבלה.
במקום חלוקה למחיצות, משתמשים באשכולות.
אם אתם טוענים לעיתים קרובות נתונים מכמה קבצים קטנים שמאוחסנים ב-Cloud Storage, ומשתמשים במשימה לכל קובץ, כדאי לשלב כמה משימות טעינה למשימה אחת. אפשר לטעון מ-URI מרובים של Cloud Storage באמצעות רשימה מופרדת בפסיקים (לדוגמה, gs://my_path/file_1,gs://my_path/file_2) או באמצעות תווים כלליים לחיפוש (לדוגמה, gs://my_path/*).
מידע נוסף זמין במאמר בנושא טעינת נתונים באצווה.
אם אתם משתמשים בעבודות טעינה, בחירה או העתקה כדי להוסיף שורות נתונים בודדות לטבלה, למשל, כדאי לשקול לאגד כמה עבודות לעבודה אחת. הביצועים של BigQuery לא טובים כשמשתמשים בו כמסד נתונים רלציוני. מומלץ להימנע מהפעלת פעולות תכופות של הוספת שורה יחידה.
כדי להוסיף נתונים בקצב גבוה, כדאי להשתמש ב-BigQuery Storage Write API‏ (gRPC). זהו פתרון מומלץ להטמעת נתונים ברמת ביצועים גבוהה. ‫BigQuery Storage Write API ‏ (gRPC) כולל תכונות חזקות, כולל סמנטיקה של מסירה חד-פעמית. מידע על מגבלות ומכסות זמין במאמר בנושא Storage Write API, ומידע על העלויות של השימוש בממשק ה-API הזה זמין במאמר בנושא תמחור של הטמעת נתונים ב-BigQuery.
כדי לעקוב אחרי מספר המחיצות ששונו בטבלה, משתמשים בתצוגה INFORMATION_SCHEMA.
מידע על אופטימיזציה של עבודות טעינה של טבלאות כדי לא להגיע למגבלות המכסה זמין במאמר בנושא אופטימיזציה של עבודות טעינה.

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

המערכת של BigQuery מחזירה את השגיאה הזו כשהטבלה מגיעה למגבלה של קצב מקסימלי של פעולות עדכון מטא-נתונים של טבלה לכל טבלה בטבלאות רגילות. פעולות בטבלה כוללות את הסכום הכולל של כל משימות הטעינה, משימות ההעתקה ומשימות השאילתות שמצורפות לטבלת יעד או מחליפות אותה, או שמשתמשות ב-DML‏ DELETE,‏ INSERT,‏ MERGE,‏ TRUNCATE TABLE או UPDATE כדי לכתוב נתונים בטבלה.

כדי לראות את הערך של המגבלה Maximum rate of table metadata update operations per table, אפשר לעיין במאמר בנושא טבלאות רגילות.

הודעת שגיאה

Exceeded rate limits: too many table update operations for this table

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

אבחון

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

זיהוי קריאות ל-API
זיהוי משימות.

זיהוי קריאות ל-API

נכנסים לתפריט Cloud de Confiance הניווט ובוחרים באפשרות Logging > Logs Explorer:

כניסה לדף Logs Explorer

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

resource.type="bigquery_dataset"
protoPayload.resourceName="projects/my-project-id/datasets/my_dataset/tables/my_table"
(protoPayload.methodName="google.cloud.bigquery.v2.TableService.PatchTable" OR
protoPayload.methodName="google.cloud.bigquery.v2.TableService.UpdateTable" OR
protoPayload.methodName="google.cloud.bigquery.v2.TableService.InsertTable")

זיהוי משרות

השאילתה הבאה מחזירה רשימה של משימות ששינו את הטבלה המושפעת בפרויקט במהלך היום האחרון. אם אתם מצפים שכמה פרויקטים בארגון יכתבו לטבלה, מחליפים את JOBS_BY_PROJECT ב-JOBS_BY_ORGANIZATION.

SELECT
 job_id,
 user_email,
 query
FROM  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY)
AND destination_table.project_id = "my-project-id"
AND destination_table.dataset_id = "my_dataset"
AND destination_table.table_id = "my_table"

מידע נוסף זמין במאמר סקירה כללית של יומני ביקורת ב-BigQuery.

רזולוציה

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

צריך להקטין את קצב העדכון של מטא-נתונים של הטבלה.
מוסיפים השהיה בין משימות או פעולות בטבלה כדי לוודא שקצב העדכון נמצא בתוך המגבלה.
כדי להוסיף נתונים או לשנות אותם, כדאי להשתמש בפעולות DML. פעולות DML לא מושפעות מהגבלת הקצב Maximum rate of table metadata update operations per table.

לפעולות DML יש מגבלות ומכסות אחרות. מידע נוסף מופיע במאמר בנושא שימוש בשפת טיפול בנתונים (DML).
אם אתם טוענים לעיתים קרובות נתונים מכמה קבצים קטנים שמאוחסנים ב-Cloud Storage, ומשתמשים במשימה לכל קובץ, כדאי לשלב כמה משימות טעינה למשימה אחת. אפשר לטעון מ-URI מרובים של Cloud Storage באמצעות רשימה מופרדת בפסיקים (לדוגמה, gs://my_path/file_1,gs://my_path/file_2) או באמצעות תווים כלליים לחיפוש (לדוגמה, gs://my_path/*).
מידע נוסף זמין במאמר בנושא טעינת נתונים באצווה.
אם אתם משתמשים בעבודות טעינה, בחירה או העתקה כדי להוסיף שורות נתונים בודדות לטבלה, למשל, כדאי לשקול לאגד כמה עבודות לעבודה אחת. הביצועים של BigQuery לא טובים כשמשתמשים בו כמסד נתונים רלציוני. מומלץ להימנע מהפעלת פעולות תכופות של הוספת שורה יחידה.
כדי להוסיף נתונים בקצב גבוה, כדאי להשתמש ב-BigQuery Storage Write API‏ (gRPC). זהו פתרון מומלץ להטמעת נתונים ברמת ביצועים גבוהה. ‫BigQuery Storage Write API ‏ (gRPC) כולל תכונות חזקות, כולל סמנטיקה של מסירה חד-פעמית. מידע על מגבלות ומכסות זמין במאמר בנושא Storage Write API, ומידע על העלויות של השימוש בממשק ה-API הזה זמין במאמר בנושא תמחור של הטמעת נתונים ב-BigQuery.
כדי לעקוב אחרי מספר המחיצות ששונו בטבלה, משתמשים בתצוגה INFORMATION_SCHEMA.
מידע על אופטימיזציה של עבודות טעינה של טבלאות כדי לא להגיע למגבלות המכסה זמין במאמר בנושא אופטימיזציה של עבודות טעינה.

שגיאות במכסת הייבוא של טבלאות או במכסת הצירוף של שאילתות

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

כדי לראות את הערך של המגבלה Table operations per day, אפשר לעיין בטבלאות רגילות.

הודעת שגיאה

Your table exceeded quota for imports or query appends per table

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

אבחון

אם לא זיהיתם את המקור שממנו מגיעות רוב הפעולות בטבלה:

רושמים את הפרויקט, מערך הנתונים והטבלה שאליהם נכתבת השאילתה, הטעינה או העתקת המשימה שנכשלו.
אפשר להשתמש בINFORMATION_SCHEMA.JOBS_BY_* טבלאות כדי לקבל מידע נוסף על משימות שמשנות את הטבלה.

בדוגמה הבאה מוצגת ספירה לפי שעה של משימות שמקובצות לפי סוג המשימה ב-24 השעות האחרונות באמצעות JOBS_BY_PROJECT. אם אתם מצפים שכמה פרויקטים יכתבו לטבלה, מחליפים את JOBS_BY_PROJECT ב-JOBS_BY_ORGANIZATION.
```
SELECT
TIMESTAMP_TRUNC(creation_time, HOUR),
job_type,
count(1)
FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY)
AND destination_table.project_id = "my-project-id"
AND destination_table.dataset_id = "my_dataset"
AND destination_table.table_id = "my_table"
GROUP BY 1, 2
ORDER BY 1 DESC
```

רזולוציה

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

אם אתם טוענים לעיתים קרובות נתונים מכמה קבצים קטנים שמאוחסנים ב-Cloud Storage, ומשתמשים במשימה לכל קובץ, כדאי לשלב כמה משימות טעינה למשימה אחת. אפשר לטעון מ-URI מרובים של Cloud Storage באמצעות רשימה מופרדת בפסיקים (לדוגמה, gs://my_path/file_1,gs://my_path/file_2) או באמצעות תווים כלליים לחיפוש (לדוגמה, gs://my_path/*).
מידע נוסף זמין במאמר בנושא טעינת נתונים באצווה.
אם אתם משתמשים בעבודות טעינה, בחירה או העתקה כדי להוסיף שורות נתונים בודדות לטבלה, למשל, כדאי לשקול לאגד כמה עבודות לעבודה אחת. הביצועים של BigQuery לא טובים כשמשתמשים בו כמסד נתונים רלציוני. מומלץ להימנע מהפעלת פעולות תכופות של הוספת שורה יחידה.
כדי להוסיף נתונים בקצב גבוה, כדאי להשתמש ב-BigQuery Storage Write API‏ (gRPC). זהו פתרון מומלץ להטמעת נתונים ברמת ביצועים גבוהה. ‫BigQuery Storage Write API ‏ (gRPC) כולל תכונות חזקות, כולל סמנטיקה של מסירה חד-פעמית. מידע על מגבלות ומכסות זמין במאמר בנושא Storage Write API, ומידע על העלויות של השימוש בממשק ה-API הזה זמין במאמר בנושא תמחור של הטמעת נתונים ב-BigQuery.
כדי לעקוב אחרי מספר המחיצות ששונו בטבלה, משתמשים בתצוגה INFORMATION_SCHEMA.
מידע על אופטימיזציה של עבודות טעינה של טבלאות כדי לא להגיע למגבלות המכסה זמין במאמר בנושא אופטימיזציה של עבודות טעינה.

חריגה מהמכסה של מדד המכסה 'צפיות מורשות לכל מערך נתונים' והמגבלה '2,500'.

אם רשימת בקרת הגישה של מערך נתונים חורגת מהמגבלה המשולבת של משאבים מורשים, מערכת BigQuery מחזירה את הודעת השגיאה הזו.

הודעת שגיאה

Quota exceeded for quota metric 'Authorized Views per dataset' and limit '2500'.

רזולוציה

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

יש יותר מדי פקודות DML שלא בוצעו בטבלה

השגיאה הזו מציינת שמספר הצהרות ה-DML המקבילות לשינוי (UPDATE, ‏ DELETE, ‏ MERGE) שמופעלות על אותה טבלה חרג ממגבלת המכסה של שפת הטיפול בנתונים (DML). מגבלת המכסה הזו היא לכל טבלה, והיא חלה רק על הצהרות DML משתנות, שלא כוללות INSERT.

רזולוציה

כדאי להריץ את עבודות ה-DML באצווה לפי השיטות המומלצות לשימוש בפקודות DML.

שגיאות במכסת הטעינה של קובצי CSV

אם טוענים קובץ CSV גדול באמצעות הפקודה bq load עם הדגל --allow_quoted_newlines, יכול להיות שתיתקלו בשגיאה הזו.

הודעת שגיאה

Input CSV files are not splittable and at least one of the files is larger than
the maximum allowed size. Size is: ...

רזולוציה

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

מגדירים את הדגל --allow_quoted_newlines לערך false.
מפצלים את קובץ ה-CSV לחלקים קטנים יותר, שכל אחד מהם קטן מ-4GB.

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

המשתמש חרג מהמכסה של בקשות בו-זמניות `project.lists`

השגיאה הזו מתרחשת כשמשימות של Microsoft Power BI שמתקשרות עם BigQuery דרך מנהל התקן Simba ODBC או DataHub נכשלות כי הן חורגות ממגבלת ה-API של project.list. כדי לפתור את הבעיה, אפשר להשתמש בפתרונות לטווח הקצר או לטווח הארוך שמתוארים בקטע הזה.

הודעת שגיאה

Your user exceeded quota for concurrent project.lists requests

אבחון

השגיאה הזו מתרחשת במהלך שלב החיבור והגילוי של Power BI, כשדוח Power BI מתרענן ומנהל ההתקן של Simba יוצר חיבור לפרויקט BigQuery ספציפי.

פתרון לטווח הקצר

כדי לפתור את הבעיה בטווח הקצר, אפשר להשתמש בפתרונות העקיפים הבאים, שמסודרים לפי רמת היעילות שלהם (מהיעיל ביותר ועד לפחות יעיל). מטמיעים תיקונים שלוש או ארבע פעמים, בהתאם לשיטה שבה מתחברים ל-BigQuery – באמצעות מנהל ההתקן של Simba או באמצעות DataHub.

פתרונות לטווח הארוך מפורטים בקטע פתרון לטווח הארוך.

השהיית רענון הדוחות. אם אי אפשר לשנות את ה-DSN, אפשר לצמצם את מספר הבקשות בו-זמנית כדי לפתור את הבעיה שקשורה למכסת הבקשות. במקום שכל הדוחות יתעדכנו בו-זמנית (לדוגמה, בשעה 9:00), כדאי לתזמן אותם בהפרש של כמה דקות (לדוגמה, בשעה 9:01, 9:03 ו-9:05). השיטה הזו מאפשרת לפזר את הקריאות ל-API לאורך זמן, וכך מקטינה את הסיכוי שתגיעו למגבלה המקבילית.
הטמעת ניסיונות חוזרים ב-Power BI האסטרטגיה הזו מבוססת על תגובה ומאפשרת לשחזר דוח אחרי כשל זמני. ל-Power BI יש לוגיקה מובנית לניסיון חוזר במקרה של כשלים ברענון הנתונים. השיטה הזו לא מונעת את שגיאת המכסה, אבל היא משפרת את העמידות של צינור הנתונים, כי היא מאפשרת ליצור דוח בניסיון הבא אחרי שהעלייה הראשונית במספר הקריאות ל-API נרגעת. כדי להטמיע את התיקון הזה:
1. בשירות Power BI, עוברים אל הגדרות של מערך הנתונים.
2. מרחיבים את הקטע רענון מתוזמן. בקטע Retry (ניסיון חוזר), מגדירים את Power BI כך שיפעיל מחדש באופן אוטומטי רענון שנכשל.
בגרסאות קודמות של מנהל ההתקן של Simba, צריך לציין את מזהה הפרויקט בחיבור ODBC. הפעולה הזו מונעת מהדרייבר לבצע את שיחת הגילוי projects.list. במקום זאת, מנהל ההתקן מתחבר ישירות לפרויקט שצוין, וכך נמנעות קריאות מיותרות ל-API והבעיה עם המכסה נפתרת.

דרייברים חדשים יותר נכשלים מיד אם הפרויקט לא מצוין בהודעה בדומה ל-Unable to establish connection with data source. Missing settings: {[Catalog]}.

כדי לפתור את הבעיה, פועלים לפי השלבים הבאים:
1. במחשב שבו פועל Power BI Gateway או Power BI Desktop, פותחים את האפליקציה ODBC Data Sources (64-bit).
2. במסך ההגדרה הראשי של מנהל התקן Simba ODBC ל-BigQuery, ממלאים את השדה Catalog (Project) במזהה הפרויקט הספציפי שלכם – לדוגמה, Cloud de Confiance my-gcp-project-id.
בגרסאות קודמות של DataHub, מציינים את מזהה הפרויקט בהגדרת ההטמעה של DataHub. צריך לבצע את התיקון הזה אם משתמשים ב-DataHub במקום בדרייבר Simba. בדומה ל-Simba, בגרסאות מאוחרות יותר של DataHub צריך לציין את מזהה הפרויקט, אחרת לא תהיה אפשרות להתחבר ל-BigQuery.

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

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

הנה דוגמה לקטע קוד של הגדרות DataHub:
```
  source:
  type: "bigquery"
  config:
    # Instead of relying on discovery, explicitly list the projects.
    # This avoids the problematic projects.list() API call.
    project_ids:
    -  "YOUR_PRODUCTION_PROJECT_ID"
    -  "YOUR_ANALYTICS_PROJECT_ID"
    -  "ANOTHER_BQ_PROJECT"
```

פתרון לטווח ארוך

הפתרון הטוב ביותר לטווח הארוך להודעת השגיאה הזו הוא ליצורCloud de Confiance חשבונות שירות נפרדים וייעודיים לכל פונקציה. לדוגמה, אפשר ליצור חשבון שירות לכל הדוחות של Power BI וחשבון שירות להעברה של נתונים ל-DataHub.

השיטה המומלצת הזו מפרידה את השימוש ב-API למאגרי מיכסות נפרדים, ומונעת ממשימה עם עומס גבוה ב-DataHub לגרום לכשל בדוחות עסקיים קריטיים ב-Power BI.

בקטעים הבאים מפורטת תוכנית פעולה לפתרון שגיאות שקשורות למכסות לטווח ארוך ב-Power BI וב-DataHub.

שלב 1: הכנה

להודיע לבעלים של שערים של Power BI ולהגדרות של DataHub שאתם תבצעו שינויים מתואמים כדי לפתור כשלים מתמשכים בעבודות.
במסוף Cloud de Confiance , יוצרים שני חשבונות שירות חדשים – לדוגמה, sa-powerbi-gateway@... ו-sa-datahub-ingestion@....
יוצרים מפתחות לחשבונות השירות של Power BI ו-DataHub.
מעניקים לכל חשבון שירות חדש הרשאות של הרשאות מינימליות על ידי הקצאת התפקידים הבאים בניהול זהויות והרשאות גישה (IAM) שמאפשרים לו לבצע את המשימות שלו בניהול זהויות והרשאות גישה (IAM) הרלוונטי. אל תקצו תפקידים רחבים מדי, למשל ProjectEditor.

התפקידים הנדרשים

חשבון השירות של Power BI מריץ שאילתות וקורא נתונים מטבלאות. צריך להקצות את התפקידים הבאים לחשבונות שירות בכל פרויקט Cloud de Confiance שמכיל נתונים ש-Power BI צריך לגשת אליהם. מידע נוסף על התפקידים האלה מופיע במאמר תפקידים ב-BigQuery.

‫BigQuery Data Viewer (צפייה בנתוני BigQuery): מאפשר גישה לקריאה בלבד למערכי נתונים, לטבלאות ולתצוגות.
משתמש במשימות BigQuery: מספק הרשאות להרצת משימות, כולל שאילתות, שחיוניות ל-Power BI כדי לבצע את הבקשות שלו.

לחשבון השירות להעברה של DataHub נדרשת רק הרשאת קריאה של מטא-נתונים, כמו שמות טבלאות, סכימות ותיאורים, ולא של הנתונים בטבלאות. צריך להעניק את התפקיד הבא ברמת הפרויקט לכל פרויקט ש-DataHub סורק. מידע נוסף על התפקידים האלה מופיע במאמר תפקידי IAM ב-BigQuery.

‫BigQuery Metadata Viewer: התפקיד הזה מיועד במיוחד לקריאת מטא-נתונים. התפקיד הזה מאפשר לראות רשימות של מערכי נתונים וטבלאות, ולצפות במטא-נתונים שלהם, בלי לתת גישה לנתונים הבסיסיים.

שלב 2: השקה מתואמת

במהלך תקופה של שימוש נמוך, האדמין של Power BI מעדכן את הגדרות ה-ODBC DSN במכונות השער על ידי ביצוע השלבים הבאים:

שינוי שיטת האימות לשימוש במפתח החדש של חשבון השירות sa-powerbi-gateway@... שנוצר בשלב הקודם.
אם עדיין לא ביצעתם את הפעולה הזו כפתרון לטווח הקצר, צריך להזין את Cloud de Confianceמזהה הפרויקט בשדה Catalog (Project) של מנהל התקן ODBC.
בעל הגישה ל-DataHub צריך לעדכן את קובץ ה-YAML של הגדרות המקור ב-BigQuery.
מצביע על מפתח חדש של חשבון השירות sa-datahub-ingestion@... שנוצר בשלב הקודם.
אם לא בוצע כבר תיקון לטווח קצר, משתמשים בפרמטר project_ids כדי לציין במפורש את הפרויקטים שצריך לסרוק.
מבצע פריסה מחדש של מתכון ההטמעה של DataHub עם ההגדרה החדשה.

שלב 3: אימות ומעקב

כדי לאמת את התיקונים ולעקוב אחרי ההשפעות שלהם, האדמינים של Power BI ו-DataHub מבצעים את השלבים הבאים:

מפעילים ידנית רענון לכמה דוחות מרכזיים של Power BI ולהרצת הטמעה חדשה ב-DataHub. מוודאים שהעבודות האלה הושלמו בהצלחה בלי שגיאות שקשורות למכסת השימוש.
כדי לוודא שהשגיאה Quota exceeded: Your user exceeded quota for concurrent project.lists requests לא חוזרת, כדאי לעקוב אחרי יומני האפליקציה או אחרי היסטוריית ההרצות של כלי ה-BI.
אופציונלי: מוודאים שהנפח הכולל של קריאות ל-projects.list API או של שגיאות 403 קשורות בחשבונות השירות המשויכים פחת:
1. במסוף Cloud de Confiance , עוברים לדף BigQuery API API/Service Details.
  
  כניסה אל APIs & services
2. כדי לוודא שהייתה ירידה במספר השיחות ושאין שגיאות 403 קשורות, אפשר לעיין במרכזי הבקרה בכרטיסייה מדדים.

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

פתרון בעיות שקשורות למכסות ולמגבלות

סקירה כללית

אבחון

פתרון בעיות שקשורות למכסות או למגבלות שאפשר להגדיל

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

רזולוציה

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

אבחון

רזולוציה

מספר מקסימלי של שאילתות בו-זמנית שמכילות פונקציות מרוחקות

אבחון

רזולוציה

מספר מקסימלי של CREATE MODEL הצהרות

רזולוציה

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

אבחון

רזולוציה

שגיאה שקשורה לחריגה מהמכסה היומית של בייטים לחילוץ

אבחון

רזולוציה

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

רזולוציה

שגיאות שקשורות לחריגה מהמספר המקסימלי של בקשות API

אבחון

רזולוציה

המספר המקסימלי של בייטים לאחסון תמונות של פונקציות מוגדרות על ידי המשתמש (UDF) ב-Python לכל פרויקט בכל אזור

רזולוציה

מספר מקסימלי של פונקציות מוגדרות על ידי המשתמש (UDF) של Python בו-זמנית

רזולוציה

מגבלות על קצב הביצוע של פונקציות מוגדרות על ידי המשתמש (UDF) ב-Python או שגיאות קיבולת

רזולוציה

פתרון בעיות שקשורות למכסות או למגבלות שלא ניתן להגדיל

חרגתם ממגבלת הצילומים של טבלאות

רזולוציה

המספר המקסימלי של שגיאות במשימות בהמתנה

רזולוציה

שגיאות במגבלות על תור השאילתות

רזולוציה

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

שגיאות במגבלת הגודל של ערבוב השירים

רזולוציה

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

רזולוציה

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

אבחון

זיהוי קריאות ל-API

זיהוי משרות

רזולוציה

שגיאות במכסת הייבוא של טבלאות או במכסת הצירוף של שאילתות

אבחון

רזולוציה

חריגה מהמכסה של מדד המכסה 'צפיות מורשות לכל מערך נתונים' והמגבלה '2,500'.

רזולוציה

יש יותר מדי פקודות DML שלא בוצעו בטבלה

רזולוציה

שגיאות במכסת הטעינה של קובצי CSV

רזולוציה

המשתמש חרג מהמכסה של בקשות בו-זמניות project.lists

אבחון

פתרון לטווח הקצר

פתרון לטווח ארוך

שלב 1: הכנה

התפקידים הנדרשים

שלב 2: השקה מתואמת

שלב 3: אימות ומעקב

מספר מקסימלי של `CREATE MODEL` הצהרות

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

המשתמש חרג מהמכסה של בקשות בו-זמניות `project.lists`