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

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

ב-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- חייב לבוא 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: ‏ `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, יחד עם התרשים Show usage (הצגת נתוני השימוש), כדי לראות את מגמת השימוש לאורך כמה ימים.

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

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

הגודל הכולל של כל תמונות המאגר שמשמשות פונקציות פעילות מוגדרות על ידי המשתמש ב-Python לא יכול לחרוג מ-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 ומגישים בקשה להגדלה.
אופטימיזציה של האחסון: מחיקה של פונקציות Python UDF שלא נעשה בהן שימוש באמצעות ההצהרה DROP FUNCTION כדי לפנות מקום. אחרי שמחקתם פונקציה להגדרת משתמש, גודל התמונה שלה לא נספר יותר במכסת נפח האחסון. אפשר לראות את גודל התמונה באמצעות RoutineBuildStatus של ה-API. מידע נוסף על הצגת סטטוס ה-build זמין במאמר סטטוס ה-build של מאגר.

מספר מקסימלי של פונקציות UDF של Python בו-זמנית

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

רזולוציה

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

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

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

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

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

הודעת השגיאה

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) – WITHclause – שמופיע ביותר ממקום אחד בשאילתה, החישוב הזה מתבצע כמה פעמים. עדיף לשמור את החישובים שבוצעו על ידי CTE בטבלה זמנית, ואז להפנות אליהם בשאילתה.

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

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

כדי להימנע מהגעה למגבלת תור השאילתות, כדאי להשתמש בהמלצות שברשימה הבאה כדי לבצע אופטימיזציה של מודל השאילתות.
- שמירת נתונים (טבלאות שמורות). מעבדים מראש את הנתונים ב-BigQuery ומאחסנים אותם בטבלאות נוספות. לדוגמה, אם מריצים הרבה שאילתות דומות שדורשות הרבה חישובים באמצעות תנאי WHERE שונים, התוצאות שלהן לא נשמרות במטמון. בנוסף, כל הרצה של שאילתות כאלה צורכת משאבים. כדי לשפר את הביצועים של שאילתות כאלה ולקצר את זמן העיבוד שלהן, אפשר לבצע חישוב מראש של הנתונים ולאחסן אותם בטבלה. אפשר להפעיל שאילתות SELECT על הנתונים שחושבו מראש בטבלה. לרוב אפשר לעשות את זה במהלך ההטמעה בתהליך ETL, או באמצעות שאילתות מתוזמנות או תצוגות חומריות.
- שימוש במצב פרימטר לבדיקות מריצים שאילתות במצב הרצה יבשה, שבו המערכת מעריכה את מספר הבייטים שנקראו אבל לא מעבדת את השאילתה בפועל.
- תצוגה מקדימה של נתוני הטבלה כדי להתנסות בנתונים או לחקור אותם במקום להריץ שאילתות, אפשר להשתמש בתצוגה מקדימה של טבלה ב-BigQuery.
- שימוש בתוצאות של שאילתות שנשמרו במטמון. כל תוצאות השאילתות, כולל שאילתות אינטראקטיביות ושאילתות אצווה, נשמרות במטמון בטבלאות זמניות למשך כ-24 שעות, עם כמה חריגים. הפעלת שאילתה שנשמרה במטמון עדיין נספרת במסגרת המגבלה על מספר השאילתות המקבילות, אבל שאילתות שמשתמשות בתוצאות שנשמרו במטמון מהירות משמעותית משאילתות שלא משתמשות בתוצאות שנשמרו במטמון, כי מערכת BigQuery לא צריכה לחשב את קבוצת התוצאות.
- שימוש ב-BigQuery BI Engine אם נתקלתם בשגיאה הזו כשניסיתם ליצור לוחות בקרה באמצעות כלי לניתוח נתונים עסקיים (BI) כדי להריץ שאילתות על נתונים ב-BigQuery, מומלץ להשתמש ב-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. זהו פתרון מומלץ להעברה של נתונים ברמת ביצועים גבוהה. ‫BigQuery Storage Write API כולל תכונות חזקות, כולל סמנטיקה של מסירה חד-פעמית. מידע על מגבלות ומכסות זמין במאמר בנושא 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. זהו פתרון מומלץ להעברה של נתונים ברמת ביצועים גבוהה. ‫BigQuery Storage Write API כולל תכונות חזקות, כולל סמנטיקה של מסירה חד-פעמית. מידע על מגבלות ומכסות זמין במאמר בנושא 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. זהו פתרון מומלץ להעברה של נתונים ברמת ביצועים גבוהה. ‫BigQuery Storage Write API כולל תכונות חזקות, כולל סמנטיקה של מסירה חד-פעמית. מידע על מגבלות ומכסות זמין במאמר בנושא 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) במזהה הפרויקט הספציפי שלכם – למשל, my-gcp-project-id. Cloud de Confiance
בגרסאות קודמות של 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 (צפייה במטא-נתונים של BigQuery): התפקיד הזה מיועד במיוחד לקריאת מטא-נתונים. התפקיד הזה מאפשר להציג רשימה של מערכי נתונים וטבלאות ולראות את המטא-נתונים שלהם, בלי לתת גישה לנתונים הבסיסיים.

שלב 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 , עוברים לדף API/Service Details של BigQuery API.
  
  כניסה אל APIs & services
2. כדי לוודא שהייתה ירידה בנפח השיחות ושמופיעות שגיאות 403 שקשורות לכך, אפשר לעיין במרכזי הבקרה בכרטיסייה מדדים.

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

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

סקירה כללית

אבחון

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

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

רזולוציה

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

אבחון

רזולוציה

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

אבחון

רזולוציה

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

רזולוציה

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

אבחון

רזולוציה

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

אבחון

רזולוציה

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

רזולוציה

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

אבחון

רזולוציה

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

רזולוציה

מספר מקסימלי של פונקציות UDF של Python בו-זמנית

רזולוציה

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

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

רזולוציה

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

רזולוציה

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

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

רזולוציה

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

רזולוציה

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

אבחון

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

זיהוי משרות

רזולוציה

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

אבחון

רזולוציה

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

רזולוציה

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

רזולוציה

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

רזולוציה

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

אבחון

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

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

שלב 1: הכנה

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

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

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

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

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

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