פתרון בעיות בתצוגות מהותיות

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

תהליך עבודה של אבחון

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

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

    SELECT
 table_name,
 table_type
FROM
 `PROJECT_ID.DATASET`.INFORMATION_SCHEMA.TABLES
WHERE
 table_name = 'MATERIALIZED_VIEW';

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: הפרויקט שמכיל את התצוגה החומרית.
    • ‫DATASET: מערך הנתונים שמכיל את התצוגה החומרית.
    • ‫MATERIALIZED_VIEW: השם של התצוגה החומרית.

    כדי לבדוק אפשרויות הגדרה כמו enable_refresh,‏ refresh_interval_minutes ו-max_staleness, מריצים שאילתה בתצוגה INFORMATION_SCHEMA.TABLE_OPTIONS:

    SELECT
 table_name,
 option_name,
 option_value
FROM
 `PROJECT_ID.DATASET`.INFORMATION_SCHEMA.TABLE_OPTIONS
WHERE
 table_name = 'MATERIALIZED_VIEW';

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

    SELECT
 table_name,
 last_refresh_time,
 refresh_watermark,
 last_refresh_status
FROM
 `PROJECT_ID.DATASET`.INFORMATION_SCHEMA.MATERIALIZED_VIEWS
WHERE
 table_name = 'MATERIALIZED_VIEW';

    אם last_refresh_status לא שווה ל-NULL, המשימה האחרונה של הרענון האוטומטי נכשלה. אם הערך של last_refresh_time הוא NULL או ערך ישן, התצוגה החומרית מעולם לא השלימה רענון בהצלחה או שהרענון שלה נכשל.

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

    SELECT
 job_id,
 creation_time,
 end_time,
 state,
 error_result.reason AS error_reason,
 error_result.message AS error_message,
 total_slot_ms,
 total_bytes_processed
FROM
 `region-REGION`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
 job_id LIKE '%materialized_view_refresh_%'
 AND creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY
 creation_time DESC
LIMIT 50;

    מחליפים את REGION באזור של קבוצת הנתונים – לדוגמה, us או europe-west3.

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

    SELECT
 job_id,
 total_slot_ms,
 total_bytes_billed,
 materialized_view_statistics
FROM
 `region-REGION`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
 job_id = 'JOB_ID';

    מחליפים את JOB_ID במזהה של משימת השאילתה.

פתרון בעיות שגיאה ביצירת תצוגות מהותיות

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

תחביר או אופרטור SQL לא נתמכים

הודעת שגיאה:

Unsupported operator in materialized view: KEYWORD

או

Materialized view queries do not support FEATURE

הסיבה:

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

  • פונקציות לא דטרמיניסטיות (לדוגמה, CURRENT_TIMESTAMP(),‏ RAND() או SESSION_USER())
  • פונקציות אנליטיות (window functions) עם OVER()
  • סעיפים ORDER BY או LIMIT
  • DISTINCT ללא צבירת נתונים
  • שאילתות משנה בסעיפים WHERE או SELECT
  • פונקציות בהגדרת המשתמש (UDF)

פתרון:

  • מעיינים ברשימה של תכונות SQL שלא נתמכות.

  • אם השאילתה שלכם דורשת יכולות SQL רחבות יותר, כדאי ליצור תצוגה חומרית לא מצטברת על ידי הגדרת allow_non_incremental_definition = true והגדרת מרווח max_staleness:

    CREATE MATERIALIZED VIEW `PROJECT_ID.DATASET.MATERIALIZED_VIEW`
OPTIONS (
enable_refresh = true,
refresh_interval_minutes = 60,
max_staleness = INTERVAL "4" HOUR,
allow_non_incremental_definition = true
) AS
SELECT
...

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: הפרויקט שמכיל את התצוגה החומרית.
    • ‫DATASET: מערך הנתונים שמכיל את התצוגה החומרית.
    • ‫MATERIALIZED_VIEW: השם של התצוגה החומרית.

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

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

הערך של max_staleness לא תקין בטבלת הבסיס של CDC

הודעת שגיאה:

Materialized view PROJECT_ID:DATASET.MATERIALIZED_VIEW has a CDC table as base table PROJECT_ID:DATASET.TABLE but does not have valid max_staleness. Materialized views over CDC tables must have max_staleness set at least 2 times the base table's max_staleness: 0-0 0 0:0:0

הסיבה:

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

פתרון:

  1. בודקים את הערך max_staleness של טבלת ה-CDC הבסיסית על ידי שליחת שאילתה לתצוגה INFORMATION_SCHEMA.TABLE_OPTIONS.
  2. מגדירים את האפשרות max_staleness של התצוגה הממומשת לערך שהוא לפחות פי שניים מהערך max_staleness של טבלת הבסיס. לדוגמה, אם הערך של max_staleness בטבלת ה-CDC הבסיסית הוא 15 דקות, צריך להגדיר את הערך של max_staleness בתצוגה החומרית ל-30 דקות לפחות. מידע נוסף זמין במאמר בנושא הצהרות בשפת הגדרת נתונים (DDL) ב-GoogleSQL, בקטע 'הצהרת ALTER MATERIALIZED VIEW SET OPTIONS'.

תצוגה מהותית מחולקת למחיצות (Partitions) מעל מסד נתונים טבלאי שלא מחולק למחיצות

הודעת שגיאה:

Partitioned incremental materialized view must be created on top of partitioned managed storage base table.

הסיבה:

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

פתרון:

  • אם רוצים שהתצוגה החומרית תהיה מחולקת למחיצות, צריך לוודא שהטבלה הבסיסית מחולקת למחיצות ולהגדיר את התצוגה החומרית כך שתשתמש באותה עמודה של חלוקה למחיצות. מידע נוסף מופיע במאמר בנושא התאמת מחיצות.
  • אם מסד הנתונים הטבלאי לא מחולק למחיצות, יוצרים את התצוגה המהותית בלי פסוקית PARTITION BY.
  • אם אתם צריכים תצוגה מחולקת למחיצות של טבלה שלא מחולקת למחיצות, אתם יכולים ליצור תצוגה מהותית לא מצטברת עם allow_non_incremental_definition = true ו-max_staleness. תצוגות חומריות לא מצטברות לא מחייבות התאמה של מחיצות לטבלאות בסיס.

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

הודעת שגיאה:

The dataset replica of the cross region dataset 'PROJECT_ID:DATASET' in region 'REGION' is read-only because it's not the primary replica.

הסיבה:

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

פתרון:

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

חריגה ממגבלת הטבלה הבסיסית

הודעת שגיאה:

Materialized views support at most 10 source tables, query has NUMBER_OF_SOURCE_TABLES

הסיבה:

תצוגות חומריות ב-BigQuery תומכות בצירופים של עד 10 טבלאות בסיס.

פתרון:

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

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

הודעת שגיאה:

Resources exceeded during query execution: The data accessed in this query is too large; consider accessing fewer tables, or for partitioned tables, fewer partitions.

הסיבה:

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

פתרון:

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

בעיות בטבלאות BigLake ובשמירת מטא-נתונים במטמון

תסמינים:

תצוגות חומריות מעל טבלאות חיצוניות של BigLake נכשלות במהלך היצירה או הרענון.

הסיבה:

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

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

פתרון:

  1. מוודאים שהפעלתם שמירת מטמון של מטא-נתונים בכל טבלאות הבסיס של BigLake.
  2. מגדירים את max_staleness בתצוגה החומרית לערך גבוה יותר מרווח מטמון המטא-נתונים של טבלאות הבסיס. לדוגמה, אם מרווח הזמן של מטמון מסד נתונים טבלאי הוא 30 דקות, צריך להגדיר את max_staleness של התצוגה המהותית ל-45 דקות לפחות כדי לאפשר מאגר נתונים זמני לביצוע הרצה.
  3. אל תערבבו בין טבלאות חיצוניות לבין טבלאות מנוהלות בהגדרה של תצוגה חומרית.

פתרון בעיות ברענון

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

שינויים בסכימת הטבלה הבסיסית (invalidQuery)

תסמינים:

בעמודה last_refresh_status ב-INFORMATION_SCHEMA.MATERIALIZED_VIEWS מוצגת שגיאת invalidQuery, והרענונים האוטומטיים מפסיקים לפעול.

הסיבה:

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

פתרון:

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

  1. יוצרים מחדש את התצוגה המהותית באמצעות הצהרת CREATE OR REPLACE MATERIALIZED VIEW:

    CREATE OR REPLACE MATERIALIZED VIEW `PROJECT_ID.DATASET.MATERIALIZED_VIEW`
OPTIONS (
 enable_refresh = true,
 refresh_interval_minutes = 30
) AS
SELECT
 ...

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: הפרויקט שמכיל את התצוגה החומרית.
    • ‫DATASET: מערך הנתונים שמכיל את התצוגה החומרית.
    • ‫MATERIALIZED_VIEW: השם של התצוגה החומרית.

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

תפוגה, חיתוך או שינויים ב-DML של מחיצת מסד נתונים טבלאי

תסמינים:

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

הסיבה:

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

  • חיתוך של מסד נתונים טבלאי או מחיצה של מסד נתונים טבלאי (TRUNCATE TABLE)
  • תפוגה של מחיצה בטבלת בסיס
  • DELETE או MERGE הצהרות של שפת טיפול בנתונים (DML) בטבלאות לא מחולקות או בטבלאות בסיס משניות עם הצטרפות

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

פתרון:

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

    CALL BQ.REFRESH_MATERIALIZED_VIEW('PROJECT_ID.DATASET.MATERIALIZED_VIEW');

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

רענון משרות שפג תוקף

תסמינים:

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

הסיבה:

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

פתרון:

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

הודעת רענון כפולה

הודעה:

Materialized view is already being refreshed.

הסיבה:

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

פתרון:

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

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

תסמינים:

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

הסיבה:

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

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

פתרון:

  • אם נדרשת עקביות קריאה בזמן אמת בנתוני סטרימינג, מתכנן השאילתות משלב באופן אוטומטי נתונים של תצוגה חומרית עם דלתאות של טבלת הבסיס.
  • אם לא נדרשת עקביות בזמן אמת ואתם רוצים להימנע מסריקה של מאגר הנתונים הזמני של הסטרימינג בכל שאילתה, צריך להגדיר max_staleness בתצוגה החומרית (לדוגמה, max_staleness = INTERVAL "15" MINUTE). לאחר מכן, השאילתות יכולות לקרוא ישירות מהתצוגה החומרית שעברה חישוב מראש, בלי עיבוד של דלתא.

פתרון בעיות שקשורות לביצועים של שאילתות וכוונון חכם

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

אימות השימוש בכוונון חכם

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

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

SELECT
  job_id,
  total_slot_ms,
  total_bytes_billed,
  mv.table_reference.dataset_id,
  mv.table_reference.table_id,
  mv.chosen,
  mv.rejected_reason
FROM
  `region-REGION`.INFORMATION_SCHEMA.JOBS_BY_PROJECT,
  UNNEST(materialized_view_statistics.materialized_view) AS mv
WHERE
  job_id = 'JOB_ID';

מחליפים את מה שכתוב בשדות הבאים:

  • ‫REGION: האזור של מערך הנתונים (לדוגמה, us או europe-west3).
  • ‫JOB_ID: מזהה עבודת השאילתה.

באובייקט materialized_view_statistics, כל רשומה במערך materialized_view מכילה את השדות הבאים:

  • ‫table_reference: מזהה את התצוגה החומרית הפוטנציאלית.
  • ‫chosen: ערך בוליאני שמציין אם הכלי לאופטימיזציה של שאילתות בחר בתצוגה החומרית לביצוע (true) או דחה אותה (false).
  • ‫estimated_bytes_saved: מספר הבייטים המשוער שהשאילתה לא סרקה באמצעות התצוגה החומרית.
  • ‫rejected_reason: אם chosen הוא false, מציין את הסיבה שבגללה האופטימיזציה דחתה את התצוגה המהותית.

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

סיבות נפוצות לדחיית תצוגה חומרית

כאשר chosen הוא false, בודקים את הערך של rejected_reason כדי לאבחן את הסיבה:

ערך של rejected_reason תיאור רזולוציה
NO_DATA לתצוגה החומרית אין נתונים במטמון כי היא עדיין לא רעננה, או שהרענון הראשוני נכשל. מפעילים רענון ידני באמצעות CALL BQ.REFRESH_MATERIALIZED_VIEW(...).
COST הכלי לאופטימיזציה של שאילתות העריך ששאילתה של מסד נתונים טבלאי (או קריאה ממטמון השאילתות) זולה יותר משאילתה של התצוגה החומרית. בודקים את המסננים והמחיצות של השאילתה. אם השאילתה של מסד הנתונים הטבלאי סורקת רק מחיצה קטנה, בעוד התצוגה החומרית משתרעת על פני כמה מחיצות, יכול להיות שיותר יעיל לשלוח שאילתה ישירות למסד הנתונים הטבלאי.
BASE_TABLE_DATA_CHANGE שינויים בנתונים באחת או יותר מטבלאות הבסיס גרמו לביטול התוקף של הנתונים שבמטמון מחוץ לחלון הזמן להצגת נתונים לא עדכניים שהוגדר. מבצעים רענון ידני או מגדירים את max_staleness כך שאילתות יוכלו לקרוא נתונים לא פעילים בלי לחזור לטבלאות הבסיס.
BASE_TABLE_TRUNCATED מסד נתונים טבלאי נחתך, ולכן כל הנתונים בתצוגה המהותית לא תקפים. אחרי שהנתונים מאוכלסים מחדש, צריך לרענן את התצוגה החומרית.
BASE_TABLE_EXPIRED_PARTITION תוקף המחיצה בטבלת הבסיס פג. מוודאים שהגדרות התפוגה של המחיצות זהות בטבלת הבסיס ובתצוגה החומרית, ומרעננים את התצוגה.
BASE_TABLE_PARTITION_EXPIRATION_CHANGE משך התפוגה של מחיצה בטבלת בסיס שונה. מרעננים את התצוגה החומרית כדי ליישר מחדש את המטא-נתונים של תפוגת המחיצות.
BASE_TABLE_INCOMPATIBLE_METADATA_CHANGE שינוי במטא-נתונים התרחש במסד נתונים טבלאי (למשל, שינוי בסכימה). יוצרים מחדש את התצוגה המהותית באמצעות CREATE OR REPLACE MATERIALIZED VIEW.
BASE_TABLE_TOO_STALE המטא-נתונים ששמורים במטמון של טבלת בסיס (למשל בטבלה חיצונית של BigLake) ישנים יותר מהסף המותר. מרעננים את מטמון המטא-נתונים של הטבלה החיצונית.
BASE_TABLE_FINE_GRAINED_SECURITY_POLICY למשתמש ששולח את השאילתה אין גישה לפי מדיניות בקרת גישה ברמת השורה או ברמת העמודה בטבלת הבסיס. בודקים את ההרשאות ב-IAM ואת ההרשאות שניתנו במדיניות הנתונים.
TIME_ZONE התצוגה רועננה באמצעות אזור זמן ששונה מאזור הזמן של השאילתה הנוכחית. התאמת הגדרות אזור הזמן בין הסביבה שלכם לבין משימות הרענון.

לא נלקחה בחשבון תצוגה מהותית (מבנה השאילתה לא תואם)

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

הסיבות הנפוצות לכך הן:

  1. אי התאמה בין צבירה לסינון. השאילתה משתמשת בפונקציות צבירה, בעמודות קיבוץ או בפרדיקטים של מסננים שלא ניתן לחשב מהצבירות שחושבו מראש בתצוגה המגובה בחומר.
    • פתרון: צריך להתאים בין פונקציות הצבירה והקיבוצים בשאילתות לבין ההגדרה של התצוגה הממומשת.
  2. תצוגות מהותיות לא מצטברות. תצוגות מפורטות שנוצרו באמצעות allow_non_incremental_definition = true לא תומכות בהתאמה חכמה.
    • פתרון: כדי לשלוח שאילתה ישירות לתצוגות חומריות לא מצטברות, צריך לציין את שם התצוגה בסעיף FROM.
  3. שאילתה ישירה על תצוגה לא עדכנית. אם מפעילים שאילתה ישירות על תצוגה חומרית עם הגדרה של max_staleness, השאילתה מחזירה תוצאות מחושבות מראש שהן לא עדכניות, עד max_staleness, בלי עיבוד של נתוני דלתא מטבלאות הבסיס.

שגיאה בשרטוט HyperLogLog לא תואם

הודעת שגיאה:

Invalid or incompatible sketch in HLL_COUNT.MERGE_PARTIAL

הסיבה:

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

פתרון:

מוודאים שפרמטר הדיוק (לדוגמה, HLL_COUNT.INIT(x, 12)) זהה גם בהגדרת התצוגה החומרית וגם בשאילתות שמפנות לתצוגה או משכתבות אותה.

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

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

עריכה של סכימת תצוגה מהותית

הבעיה:

ניסיון להוסיף או לשנות עמודות בתצוגה חומרית באמצעות ALTER TABLEאו מסוף Google Cloud גורם לשגיאה, או שהאפשרות עריכת סכימה לא זמינה.

הסיבה:

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

פתרון:

  • אפשר לשנות את האפשרויות של תצוגה חומרית (כמו enable_refresh,‏ refresh_interval_minutes ו-max_staleness) באמצעות הצהרת ALTER MATERIALIZED VIEW SET OPTIONS:

    ALTER MATERIALIZED VIEW `PROJECT_ID.DATASET.MATERIALIZED_VIEW`
SET OPTIONS (
enable_refresh = true,
refresh_interval_minutes = 20
);

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: הפרויקט שמכיל את התצוגה החומרית.
    • ‫DATASET: מערך הנתונים שמכיל את התצוגה החומרית.
    • ‫MATERIALIZED_VIEW: השם של התצוגה החומרית.

  • כדי לשנות את ההגדרה של שאילתת ה-SQL, להוסיף עמודות או לשנות את סוגי הנתונים של העמודות, צריך ליצור מחדש את התצוגה באמצעות CREATE OR REPLACE MATERIALIZED VIEW:

    CREATE OR REPLACE MATERIALIZED VIEW `PROJECT_ID.DATASET.MATERIALIZED_VIEW`
AS SELECT
...

המאמרים הבאים