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

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

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

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

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

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

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

הודעת השגיאה

Your project exceeded quota for free query bytes scanned

רזולוציה

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

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

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

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

הודעת השגיאה

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

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

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

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

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

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

אבחון

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

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

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

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

רזולוציה

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

אם אתם משתמשים בשדה insertId לביטול כפילויות, והפרויקט שלכם נמצא באזור שתומך במכסת סטרימינג גבוהה יותר, מומלץ להסיר את השדה insertId. יכול להיות שיהיה צורך לבצע כמה שלבים נוספים כדי לבטל כפילויות מהנתונים באופן ידני. מידע נוסף מופיע במאמר הסרה ידנית של כפילויות.
אם אתם לא משתמשים ב-insertId, או אם אי אפשר להסיר אותו, כדאי לעקוב אחרי התנועה של הסטרימינג במשך 24 שעות ולנתח את שגיאות המכסה:
- אם אתם רואים בעיקר שגיאות RATE_LIMIT_EXCEEDED ולא שגיאות QUOTA_EXCEEDED, ותנועת הגולשים הכוללת שלכם נמוכה מ-80% מהמכסה, סביר להניח שהשגיאות מצביעות על עליות זמניות. כדי לטפל בשגיאות האלה, צריך לנסות שוב את הפעולה באמצעות השהיה מעריכית לפני ניסיון חוזר בין הניסיונות החוזרים.
- אם אתם משתמשים במשימת Dataflow כדי להוסיף נתונים, כדאי להשתמש במשימות טעינה במקום בהוספות של נתונים בזמן אמת. מידע נוסף זמין במאמר בנושא הגדרת שיטת ההוספה. אם אתם משתמשים ב-Dataflow עם מחבר קלט/פלט בהתאמה אישית, כדאי להשתמש במקום זאת במחבר קלט/פלט מובנה. מידע נוסף זמין במאמר בנושא דפוסי קלט/פלט מותאמים אישית.
- אם אתם רואים QUOTA_EXCEEDED שגיאות או שתנועת הגולשים הכוללת חורגת באופן עקבי מ-80% מהמכסה, שלחו בקשה להגדלת המכסה. מידע נוסף זמין במאמר בנושא שליחת בקשה לשינוי המכסות.
- אפשר גם להחליף את ההוספות של נתוני סטרימינג ב-Storage Write API החדש יותר, שכולל תפוקה גבוהה יותר, מחיר נמוך יותר ותכונות שימושיות רבות.

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

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

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

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

הודעת השגיאה

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

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

אבחון

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

רזולוציה

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

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

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

הודעת השגיאה

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

רזולוציה

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

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

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

הודעת השגיאה

Your project exceeded quota for copies per project

אבחון

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

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

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

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

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

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

רזולוציה

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

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

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

הודעת השגיאה

Your usage exceeded quota for ExtractBytesPerDay

אבחון

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

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

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

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

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

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

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

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

רזולוציה

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

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

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

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

הודעת השגיאה

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

רזולוציה

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

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

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

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

הודעת השגיאה

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

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

אבחון

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

לחשבון שירות

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

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

בקריאות ל-API

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

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

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

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

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

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

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

הודעת השגיאה

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 אם נתקלתם בשגיאה הזו כשניסיתם ליצור לוחות בקרה שמריצים שאילתות על נתונים ב-BigQuery באמצעות כלי לניתוח נתונים עסקיים (BI), מומלץ להשתמש ב-BigQuery BI Engine. השימוש ב-BigQuery BI Engine הוא אופטימלי לתרחיש השימוש הזה.
שימוש בעבודות עם עדיפות של אצווה. אפשר להוסיף לתור יותר שאילתות אצווה מאשר שאילתות אינטראקטיביות.
חלוקת שאילתות כדאי לארגן את העומס ולחלק אותו בין פרויקטים שונים בהתאם לאופי השאילתות ולצרכים העסקיים שלכם.
הגדלת מספר המקומות בהזמנה. להגדיל את מספר המקומות או, אם יש לכם עומס עבודה עם ביקוש גבוה, לעבור משימוש לפי דרישה (מודל תשלום לפי שאילתה) לשימוש בהזמנות (מודל מבוסס-קיבולת).

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

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

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

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

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

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

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

הודעת השגיאה

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

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

רזולוציה

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

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

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

הודעת השגיאה

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

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

אבחון

עדכונים בטבלת המטא-נתונים יכולים להתבצע על ידי קריאות 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.

רזולוציה

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

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

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

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

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

רענון דוחות לסירוגין. אם אי אפשר לשנות את ה-DSN, אפשר לנסות להקטין את מספר הבקשות בו-זמנית כדי לפתור את הבעיה שקשורה למכסת המכסות. במקום לרענן את כל הדוחות בו-זמנית (לדוגמה, בשעה 9:00), כדאי להגדיר את התזמונים בהפרש של כמה דקות (לדוגמה, בשעה 9:01, 9:03 ו-9:05). השיטה הזו מאפשרת לפזר את הקריאות ל-API לאורך זמן, וכך מקטינה את הסיכוי שתגיעו למגבלת הקריאות בו-זמנית.
הטמעת ניסיונות חוזרים ב-Power BI האסטרטגיה הזו מבוססת על תגובה, והיא עוזרת לדוח להתאושש מכשל זמני. ל-Power BI יש לוגיקה מובנית לניסיון חוזר במקרה של כשלים ברענון הנתונים. השיטה הזו לא מונעת את שגיאת המכסה, אבל היא משפרת את החוסן (resilience) של צינור הנתונים. כך, אם יש עלייה חדה במספר הקריאות ל-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. Google Cloud
בגרסאות קודמות של 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) שמאפשרים לו לבצע את המשימות שלו בניהול זהויות והרשאות גישה (IAM) הרלוונטי. אל תקצו תפקידים רחבים מדי, למשל ProjectEditor.

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

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

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

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

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

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

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

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

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

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

הפעלת רענון ידני לכמה דוחות מרכזיים של Power BI ולהרצת הטמעה חדשה ב-DataHub. מוודאים שהמשימות האלה הושלמו בהצלחה בלי שגיאות שקשורות למכסת נפח האחסון.
במסוף Google Cloud , עוברים לדף IAM & Admin > Quotas.
מסננים לפי השירות BigQuery API.
מחפשים את המכסה שנקראת Concurrent project.lists requests ולוחצים על סמל הגרף כדי לראות את השימוש לאורך זמן.

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

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

סקירה כללית

אבחון

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

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

רזולוציה

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

אבחון

רזולוציה

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

אבחון

רזולוציה

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

רזולוציה

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

אבחון

רזולוציה

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

אבחון

רזולוציה

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

רזולוציה

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

אבחון

רזולוציה

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

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

רזולוציה

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

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

רזולוציה

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

רזולוציה

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

אבחון

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

זיהוי משרות

רזולוציה

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

אבחון

רזולוציה

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

רזולוציה

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

רזולוציה

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

רזולוציה

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

אבחון

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

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

שלב 1: הכנה

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

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

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

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

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

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