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

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

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

האבחון

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

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

בהתאם למגבלת המכסה הספציפית שהגעתם אליה, עיינו ב-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% מהמכסה, כנראה שהשגיאות מצביעות על עליות חדות זמניות. כדי לטפל בשגיאות האלה, אפשר לנסות שוב את הפעולה באמצעות השהיה מעריכית לפני ניסיון חוזר (exponential backoff) בין הניסיונות החוזרים.
- אם אתם משתמשים במשימת Dataflow כדי להוסיף נתונים, כדאי להשתמש במשימות טעינה במקום בהזנת זרם נתונים. מידע נוסף זמין במאמר הגדרת שיטת ההוספה. אם אתם משתמשים ב-Dataflow עם מחבר קלט/פלט בהתאמה אישית, כדאי להשתמש במחבר קלט/פלט מובנה. למידע נוסף, קראו על תבניות קלט/פלט בהתאמה אישית.
- אם אתם רואים שגיאות QUOTA_EXCEEDED או שהתנועה הכוללת חורגת באופן עקבי מ-80% מהמכסה, שלחו בקשה להגדלת המכסה. איך שולחים בקשה לשינוי המכסות
- כדאי גם לשקול להחליף את הזנת זרם הנתונים ב-Storage Write API החדש יותר, שיש לו תפוקה גבוהה יותר, מחיר נמוך יותר והרבה תכונות שימושיות.

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

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

כשפייפליין זורם (tabledata.insertAll) יוצר באופן אוטומטי טבלאות חדשות (לדוגמה, באמצעות טבלאות תבנית עם templateSuffix או טבלאות יעד דינמיות) בקצב מהיר יותר ממגבלת הקצב של יצירת טבלאות בסטרימינג לכל פרויקט, BigQuery מחזיר את השגיאה הבאה:

הודעת שגיאה

Exceeded rate limits: Your Project: PROJECT_ID exceeded quota for
Streaming Table Creation Rate. For more information, see
https://docs.cloud.google.com/bigquery/troubleshooting-errors

רזולוציה

כדי לפתור את השגיאה:

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

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

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

הודעת שגיאה

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 שצורכות יותר מ-100GB שעובדו בשבעת הימים האחרונים.

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 כשמספר הפרויקט שמוזכר בהודעת השגיאה מגיע לגודל המקסימלי של הנתונים או למספר המקסימלי של הבקשות (QPS) שאפשר לקרוא באמצעות הקריאה ל-API‏ tabledata.list בפרויקט בשנייה. מידע נוסף זמין במאמר מקסימום tabledata.list בייטים לדקה.

הודעות שגיאה

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

Exceeded rate limits: Your project:[project number] exceeded quota for tabledata.list qps per project

רזולוציה

כדי לפתור את השגיאה:

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

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

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

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

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

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

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

הודעות שגיאה

Exceeded rate limits: too many api requests per user per method for this
user_method. For more information, see
https://cloud.google.com/bigquery/docs/troubleshoot-quotas

Exceeded rate limits: too many rate INFORMATION_SCHEMA queries per user for
this user. For more information, see
https://cloud.google.com/bigquery/docs/troubleshoot-quotas

Exceeded rate limits: Your user exceeded quota for rate INFORMATION_SCHEMA
queries per user

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

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

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

האבחון

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

לחשבון שירות

נכנסים לפרויקט שמארח את חשבון השירות.
נכנסים לדף API Dashboard במסוף Google Cloud .

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

לקריאות ל-API

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

במסוף Google Cloud , פותחים את תפריט הניווט Google Cloud ובוחרים באפשרות 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" OR "too many rate INFORMATION_SCHEMA queries per user")
 In the log entry, you can find the method name under the property protoPayload.methodName.

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

רזולוציה

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

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

שגיאות שקשורות למגבלות על קצב הקריאות ל-API ועל הערכת המטא-נתונים

המערכת של BigQuery מחזירה שגיאת HTTP 403 Forbidden עם הסיבה apiLimitExceeded כשבקשה חורגת ממגבלות הגבלת קצב של יצירת בקשות של ה-API או ממגבלות ההערכה של המטא-נתונים והגישה בו-זמנית.

הודעות שגיאה

Quota exceeded for the project...
API limit exceeded: Quota exceeded for quota metric 'Read requests'...

האבחון

השגיאה הזו יכולה להופיע בתרחישים הבאים:

נפח גבוה של בקשות API בו-זמניות. אפליקציה שולחת פרץ של קריאות ל-API בו-זמנית (כמו jobs.insert,‏ tables.get או סקר מהיר של סטטוס משימה) שחורג ממגבלות הבקשות של BigQuery API.
בו-זמניות ב-BigLake Metastore. שאילתות בטבלאות חיצוניות שמגובות על ידי BigLake Metastore יוצרות נפח גבוה של בקשות קריאה בו-זמניות של מטא-נתונים.
הערכה מורכבת של IAM או של אבטחה ברמת השורה. שאילתות בו-זמניות מפנות למספר גדול של מערכי נתונים, טבלאות או כללי מדיניות של אבטחה ברמת השורה (RLS), וממצות את מגבלות הערכת הגישה בקצה העורפי.

אם הודעת השגיאה היא Quota exceeded: Your user_method exceeded quota for concurrent api requests per user per method, קראו את המאמר שגיאות שקשורות למגבלת המספר המקסימלי של בקשות API.

רזולוציה

כדי לפתור את השגיאה:

לנסות שוב עם השהיה מעריכית קטועה לפני ניסיון חוזר (truncated exponential backoff). מגדירים את אפליקציית הלקוח או הסקריפט כך שינסו שוב לשלוח בקשות שנכשלו, באמצעות השהיה מעריכית קטועה לפני ניסיון חוזר (truncated exponential backoff).
איחוד פעולות API וביצוע שלהן באצווה. כדאי לטעון נתונים או לשלוח שאילתות בקבוצות גדולות יותר, במקום לשלוח קריאות ל-API בתדירות גבוהה לשורה אחת או לטבלה אחת, ולהפחית את התדירות של קריאות הסקר של jobs.get.
לפשט את הגדרות האבטחה וניהול הזהויות והרשאות הגישה (IAM). כדי לצמצם את התקורה של בדיקת הגישה, עדיף להשתמש בקבוצות Google ובקישורי תפקידים ב-IAM ברמת מערך הנתונים, ולא במספר גדול של קישורי IAM פרטניים לכל טבלה או בכללי מדיניות חופפים של אבטחה ברמת השורה.
בדיקת השימוש במכסות במסוף Google Cloud בדקו את הדף Quotas & System Limits כדי לראות אם הגעתם למכסה של BigQuery API או BigLake API. אם אתם צריכים קיבולת גדולה יותר באופן קבוע, אתם יכולים לבקש לשנות את המכסה.

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

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

הודעת שגיאה

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

רזולוציה

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

שגיאות שקשורות למגבלות קצב ההרצה או הקיבולת של פונקציות Python UDF

השגיאה הזו מתרחשת כששאילתה שמפעילה פונקציית Python UDF חורגת ממגבלות הקצב או מיכולת ההתאמה המקסימלית של מאגר ה-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 כדי לבחון את ניצול המעבד (CPU), ניצול הזיכרון ובקשות מקבילות. אם הערך של container_request_concurrency נמוך, צריך להגדיל אותו כדי שכל מופע של קונטיינר יוכל לעבד יותר בקשות במקביל. אם הערך של container_cpu קטן מ-1.0 vCPU בלי ערך מפורש של container_request_concurrency, ברירת המחדל של מספר הבקשות בו-זמנית היא 1 בזמן הריצה. מידע נוסף זמין במאמר הגדרת מגבלות קונטיינרים לפונקציות UDF ב-Python.
אופטימיזציה של הפעלת פונקציות מוגדרות על ידי המשתמש ומבנה השאילתות: פועלים לפי השיטות המומלצות לפונקציות מוגדרות על ידי המשתמש ב-Python כדי לקצר את זמן ההפעלה ולהקטין את נפח הבקשות לכל שאילתה. לדוגמה, סננו את הנתונים לפני הפעלת ה-UDF, שמרו על מטען ייעודי (payload) קטן של שורות קלט, ובנו את השאילתה כך שתתמוך באצווה.
בקשה להגדלת הקיבולת: אם השגיאה נמשכת אחרי שביצעתם אופטימיזציה של ה-UDF, פנו לתמיכה או למחלקת המכירות כדי לבקש להגדיל את מגבלת התאמת הגודל של מאגר הנתונים. בבקשה צריך לציין את העדיפות, את תרחיש השימוש ואת מזהה הפרויקט.

שגיאות במכסת השאילתות היומית בהתאמה אישית

השגיאה הזו (reason: quotaExceeded) מוחזרת על ידי BigQuery כשפרויקט או משתמש מגיעים למכסת שימוש יומית מותאמת אישית בשאילתות (QueryUsagePerDay או QueryUsagePerUserPerDay) שהוגדרה על ידי אדמין. איך עובדות מכסות בהתאמה אישית לשאילתות?

הודעות שגיאה

Custom quota exceeded: Your usage exceeded the custom quota for QueryUsagePerDay, which is set by your administrator.
Custom quota exceeded: Your usage exceeded the custom quota for QueryUsagePerUserPerDay, which is set by your administrator.

האבחון

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

חלון האיפוס היומי והתאמה לאזור הזמן. מכסות יומיות מותאמות אישית של שאילתות מתאפסות בחצות לפי שעון החוף המערבי (ארה"ב וקנדה). אם אזור הזמן המקומי שלכם שונה משעון החוף המערבי בארה"ב, יכול להיות ששאילתות שהרצתם ביום הקלנדרי הקודם באזור הזמן המקומי שלכם עדיין ייכללו במכסה הנוכחית של 24 שעות בשעון החוף המערבי בארה"ב.
שימוש מנורמל בהצהרות BigQuery ML. בדף Quotas & System Limits במסוף Google Cloud מדווח על שימוש מנורמל בשאילתות, שיכול להיות גבוה יותר מהבייטים לחיוב ב-INFORMATION_SCHEMA.JOBS. פעולות מסוימות של BigQuery ML, כמו יצירת מודל רגרסיה לוגיסטית, מחויבות בתעריף גבוה יותר, כפי שמתואר במאמר תמחור של BigQuery ML. לדוגמה, אם פעולה מתומחרת בשיעור של פי 50 מהתעריף הרגיל על פי דרישה, משימת CREATE MODEL שמדווחת על 1TiB של total_bytes_billed ב-INFORMATION_SCHEMA.JOBS נספרת כ-50TiB של שימוש בשאילתות במכסה היומית המותאמת אישית. איך מגדירים או משנים מכסות בהתאמה אישית?

כדי לזהות אילו משימות ומשתמשים צרכו הכי הרבה בייטים שחויבו במהלך היום הנוכחי לפי שעון החוף המערבי בארה"ב, שולחים שאילתה לתצוגה INFORMATION_SCHEMA.JOBS_BY_PROJECT:

SELECT
  user_email,
  job_id,
  statement_type,
  creation_time,
  total_bytes_billed / POWER(1024, 4) AS tib_billed
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  creation_time >= TIMESTAMP(
    CURRENT_DATE('America/Los_Angeles'), 'America/Los_Angeles')
  AND job_type = 'QUERY'
ORDER BY
  tib_billed DESC
LIMIT 50;

מחליפים את REGION_NAME באזור של מערך הנתונים (לדוגמה, us או eu).

משימות עם statement_type של CREATE_MODEL עשויות להיספר במכסה בקצב גבוה יותר מזה שמוצג ב-tib_billed.

רזולוציה

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

אופטימיזציה של שאילתות בשימוש גבוה כדי לסרוק פחות בייטים. לדוגמה, סננו לפי עמודות מחולקות למחיצות ומקובצות, בחרו רק את העמודות שאתם צריכים במקום להשתמש ב-SELECT *, והשתמשו בהרצה יבשה כדי לראות בתצוגה מקדימה את הבייטים שעובדו לפני הרצת השאילתה. למידע נוסף, ראו צמצום הנתונים שעוברים עיבוד.
להריץ שאילתות מפרויקט אחר לחיוב. אם קבוצות הנתונים שלכם משותפות עם פרויקט אחר ב- Google Cloud שיש לו גישה לטבלאות הבסיסיות, ואין לו מכסה יומית מותאמת אישית או שיש לו מכסה זמינה, אתם יכולים לשלוח את משימות השאילתות מהפרויקט החלופי הזה.
מגדילים את המכסה היומית בהתאמה אישית. אם נפח השאילתות היומי של עומס העבודה גדל, בקשו מהאדמין או מהאדמין של המכסות ( Google Cloud ) (roles/servicemanagement.quotaAdmin) להגדיל את המגבלה של Query usage per day או של Query usage per day per user בדף Quotas & System Limits. איך מגדירים או משנים מכסות בהתאמה אישית?

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

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

חרגת ממגבלת התמונות של הטבלה

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

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

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

הודעת שגיאה

Your table exceeded quota for SNAPSHOT operations per table

רזולוציה

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

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

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

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

הודעת שגיאה

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

רזולוציה

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

כדי לפתור את השגיאה:

הפחיתו את קצב השליחה. מפחיתים את קצב שליחת המשימות ל-BigQuery, ומנסים שוב לשלוח את המשימות שנכשלו באמצעות השהיה מעריכית קצועה לפני ניסיון חוזר (exponential backoff).
הגבלת בו-זמניות ואיסוף פעולות קטנות יותר באצווה. הימנעו משליחת מספר גדול של משימות במקביל, שעלולות להצטבר במצב PENDING. במקום זאת, כדאי לשלב פעולות קטנות יותר של טעינה, העתקה או DML למספר קטן יותר של משימות גדולות יותר.
בדיקת משימות פעילות ומשימות בהמתנה. שולחים שאילתה לתצוגה INFORMATION_SCHEMA.JOBS לגבי משימות עם state IN ('PENDING', 'RUNNING') כדי לזהות את המשתמשים, חשבונות השירות או צינורות עיבוד הנתונים ששולחים את צבר המשימות.

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

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

הודעת שגיאה

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

רזולוציה

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

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

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

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

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

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

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

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

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

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

שגיאות במגבלות על גודל ה-shuffle

השגיאה הזו מופיעה ב-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.

רזולוציה

כדי לפתור את השגיאה:

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

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

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

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

הודעת שגיאה

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 מפורט מידע על המגבלות והמכסות, ובמאמר מחירי הטמעת הנתונים ב-BigQuery מפורט מידע על עלויות השימוש ב-API הזה.
כדי לעקוב אחרי מספר המחיצות שהשתנו בטבלה, משתמשים בתצוגה 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. For
more information, see
https://cloud.google.com/bigquery/docs/troubleshoot-quotas

Exceeded rate limits: too many partitioned table update operations for this
table. For more information, see
https://cloud.google.com/bigquery/docs/troubleshoot-quotas

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

האבחון

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

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

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

בתפריט הניווט Google Cloud , לוחצים על 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.

רזולוציה

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

מפחיתים את קצב העדכון של המטא-נתונים של הטבלה.
כדי לוודא שקצב העדכון לא חורג מהמגבלה, הוסיפו השהיה בין המשימות או בין הפעולות בטבלה, ונסו שוב לבצע את הפעולות שנכשלו באמצעות השהיה מעריכית קטועה לפני ניסיון חוזר (truncated exponential backoff).
לאחד הצהרות DDL עוקבות (כמו כמה הצהרות ALTER TABLE) להצהרת CREATE OR REPLACE TABLE אחת, או לאחד שינויים בסכימה של כמה טבלאות לעדכון מטא-נתונים של טבלה אחת, במקום להריץ פקודות עוקבות לעדכון מטא-נתונים.
כדי להוסיף או לשנות נתונים, כדאי להשתמש בפעולות DML. פעולות DML לא מושפעות ממגבלת הקצב של הקצב המקסימלי של פעולות עדכון מטא-נתונים של טבלה בכל טבלה.

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

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

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

הודעות שגיאה

Exceeded rate limits: too many concurrent reads on a table for this table. For more information, see https://cloud.google.com/bigquery/docs/troubleshoot-quotas
Exceeded rate limits: too many concurrent dataset meta table reads per dataset for this dataset. For more information, see https://cloud.google.com/bigquery/docs/troubleshoot-quotas
Exceeded rate limits: too many concurrent dataset meta table reads per project for this project. For more information, see https://cloud.google.com/bigquery/docs/troubleshoot-quotas

רזולוציה

כדי לפתור את השגיאה:

הגבלת קריאות בו-זמניות והוספת ריצוד (jitter). אם כלי תזמור (כמו Apache Airflow או dbt) מפעיל הרבה שאילתות מקבילות באותה טבלה בו-זמנית, צריך להגדיר מגבלות בו-זמניות או להוסיף עיכובים אקראיים בהתחלה (jitter).
מפעילים את תוצאות השאילתות שנשמרו במטמון. שימוש בתוצאות שנשמרו במטמון לשאילתות קריאה זהות שחוזרות על עצמן באותה טבלה.
נסו שוב עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff). לנסות שוב לשלוח שאילתות שנכשלו באמצעות השהיה מעריכית קטועה לפני ניסיון חוזר (truncated exponential backoff).
פיזור עומסי עבודה של קריאה עם בו-זמניות גבוהה. אם טבלה צריכה לשרת מספר גבוה של קוראים בו-זמנית, אפשר לפזר את העומס על ידי יצירת תצוגות מהותיות שישרתו שאילתות שונות, לשמור עותקים נפרדים של הטבלה כדי לפזר את עומס הקריאה, או לחלק למחיצות ולאשכולות את הטבלה כך ששאילתות שונות יקראו מחיצות או אשכולות שונים.
החלפת תצוגות קודמות של __TABLES__ ו-__TABLES_SUMMARY__ בתצוגות של INFORMATION_SCHEMA. אם נתקלתם בשגיאה concurrent dataset meta table reads, העבירו את השאילתות מהתצוגות שהוצאו משימוש __TABLES__ ו-__TABLES_SUMMARY__ אל INFORMATION_SCHEMA.TABLES או אל INFORMATION_SCHEMA.PARTITIONS.

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

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

הודעות שגיאה

Exceeded rate limits: too many creating jobs for this project_and_region. For more information, see https://cloud.google.com/bigquery/docs/troubleshoot-quotas
Exceeded rate limits: Your project_and_region exceeded quota for creating jobs. For more information, see https://cloud.google.com/bigquery/troubleshooting-errors

רזולוציה

כדי לפתור את השגיאה:

נסו שוב עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff). תופסים שגיאות HTTP 403 rateLimitExceeded באפליקציית הלקוח ומנסים שוב לשלוח את המשימות באמצעות השהיה מעריכית קטועה לפני ניסיון חוזר (exponential backoff).
שילוב של פקודות DML נפרדות במקום לשלוח הרבה משימות DML נפרדות עם הצהרה אחת בו-זמנית, קבצו אותן לשאילתה עם כמה הצהרות.
בודקים ומבצעים אופטימיזציה של שאילתות חלופיות ב-JOB_CREATION_OPTIONAL. אם עומס העבודה משתמש ב-JOB_CREATION_OPTIONAL, צריך לשלוח שאילתה ל-job_creation_reason.code ב-INFORMATION_SCHEMA.JOBS כדי לזהות למה השאילתות חוזרות ליצירת משימה (לדוגמה, LARGE_RESULTS או LONG_RUNNING), ולבצע אופטימיזציה של השאילתות האלה כדי להחזיר קבוצות קטנות יותר של תוצאות או כדי לפעול מהר יותר. לחלופין, אם עומס העבודה שלכם דורש באופן עקבי יצירת משימות מלאה, הגדירו את jobCreationMode לערך JOB_CREATION_REQUIRED (ברירת המחדל) וקבעו את קצב שליחת המשימות.
צמצום התחרות על משבצות או הגדלת הקיבולת של ההזמנה. אם שאילתות שפועלות במקום שמור חוזרות ל-LONG_RUNNING בגלל תחרות על משבצות, כדאי להפחית את מספר השאילתות שפועלות בו-זמנית או להגדיל את המקום השמור.

שגיאות במכסות של ייבוא טבלאות או הוספת שאילתות

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

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

הודעת שגיאה

Your table exceeded quota for imports or query appends per table

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

האבחון

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

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

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

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

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

הודעת שגיאה

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

רזולוציה

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

יותר מדי פקודות DML ממתינות לטבלה

מחרוזת השגיאה: Resources exceeded during query execution: Too many DML statements outstanding against table PROJECT_ID:DATASET.TABLE, limit is 20.

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

רזולוציה

מריצים שאילתה על התצוגה INFORMATION_SCHEMA.JOBS של משימות RUNNING ו-PENDING עם statement_type IN ('UPDATE', 'DELETE', 'MERGE', 'TRUNCATE_TABLE') כדי לזהות את המשימות שממלאות את תור ה-DML של הטבלה.
אפשר לקבץ כמה פעולות DML קטנות שמשנות נתונים למספר קטן יותר של משימות גדולות יותר. לדוגמה, אפשר לשלב הצהרות UPDATE נפרדות להצהרת UPDATE ... SET column = CASE WHEN ... END אחת, או להעביר עדכונים תכופים לטבלה נפרדת ולהחיל אותם מדי פעם על טבלת היעד באמצעות הצהרת MERGE אחת. אפשר לקרוא מידע נוסף במאמרים הימנעות מפקודות DML שמעדכנות או מוסיפות שורות בודדות ויותר מדי פקודות DML.
מבצעים חלוקה למחיצות או לאשכולות של טבלת היעד כדי לשפר את מהירות הביצוע של 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 זמין במאמר משימות טעינה.

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

השגיאה הזו (reason: apiLimitExceeded) מופיעה ב-BigQuery כשמגדירים רפליקה של מערך נתונים באזורים שונים (ALTER SCHEMA ... ADD REPLICA) וחורגים מהמספר המקסימלי של רפליקות של מערכי נתונים שאפשר להוסיף לאזור בטווח זמן נתון.

הודעת שגיאה

API limit exceeded: Cannot add more than LIMIT replicas for a region within WINDOW day(s)

האבחון

השגיאה הזו מתרחשת לעיתים קרובות כשסקריפט אוטומטי או כלי של תשתית כקוד (IaC) יוצרים ומוחקים שוב ושוב רפליקות של מערכי נתונים (ADD REPLICA ו-DROP REPLICA) בלולאה.

רזולוציה

כדי לפתור את השגיאה:

סקריפטים של אוטומציה של ביקורת ו-Infrastructure-as-Code. בדקו את כל סקריפטי הפריסה, המשימות המתוזמנות או Terraform שמנהלים את הרפליקות של מערכי הנתונים, כדי לוודא שהם לא מוחקים ויוצרים מחדש את הרפליקות בכל הרצה.
מחכים עד שחלון הזמן הדינמי יסתיים. צריך להמתין עד שיעבור חלון הזמן שצוין בהודעת השגיאה, ורק אז להפעיל שוב את ALTER SCHEMA ... ADD REPLICA באותו אזור.

המשתמש שלך חרג מהמכסה של בקשות `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, עוברים אל Settings של מערך הנתונים.
2. מרחיבים את הקטע Scheduled refresh. בקטע 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)‎ במזהה הפרויקט הספציפי ב- Google Cloud , לדוגמה 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"
```

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

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

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

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

שלב 1: הכנה

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

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

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

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

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

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

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

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

שינוי שיטת האימות כדי להשתמש במפתח החדש של חשבון השירות sa-powerbi-gateway@... שנוצר בשלב הקודם.
אם עדיין לא עשיתם את זה כתיקון לטווח קצר, מזינים את מזהה הפרויקט Google Cloudבשדה 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 לא מתרחשת יותר, עקבו אחרי יומני האפליקציה או אחרי היסטוריית ההרצה של כלי הבינה העסקית.
אופציונלי: מוודאים שהנפח הכולל של הקריאות ל-API של projects.list או של השגיאות שקשורות ל-403 ירד בחשבונות השירות המשויכים:
1. במסוף Google Cloud , נכנסים לדף API/Service Details של BigQuery API.
  
  כניסה אל APIs & services
2. בודקים את מרכזי הבקרה בכרטיסייה Metrics כדי לוודא שיש ירידה במספר הקריאות ובשגיאות 403 שקשורות אליהן.

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

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

סקירה כללית

האבחון

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

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

רזולוציה

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

האבחון

רזולוציה

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

רזולוציה

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

האבחון

רזולוציה

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

רזולוציה

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

האבחון

רזולוציה

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

האבחון

רזולוציה

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

רזולוציה

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

האבחון

רזולוציה

שגיאות שקשורות למגבלות על קצב הקריאות ל-API ועל הערכת המטא-נתונים

האבחון

רזולוציה

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

רזולוציה

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

רזולוציה

שגיאות שקשורות למגבלות קצב ההרצה או הקיבולת של פונקציות Python UDF

רזולוציה

שגיאות במכסת השאילתות היומית בהתאמה אישית

האבחון

רזולוציה

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

חרגת ממגבלת התמונות של הטבלה

רזולוציה

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

רזולוציה

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

רזולוציה

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

שגיאות במגבלות על גודל ה-shuffle

רזולוציה

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

רזולוציה

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

האבחון

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

זיהוי משרות

רזולוציה

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

רזולוציה

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

רזולוציה

שגיאות במכסות של ייבוא טבלאות או הוספת שאילתות

האבחון

רזולוציה

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

רזולוציה

יותר מדי פקודות DML ממתינות לטבלה

רזולוציה

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

רזולוציה

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

האבחון

רזולוציה

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

האבחון

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

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

שלב 1: הכנה

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

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

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

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

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

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