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

במאמר הזה מוסבר איך לפתור בעיות נפוצות שקשורות לתצוגות חומריות ב-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'.

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

הודעת שגיאה:

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

פתרון:

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

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

תסמינים:

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

הסיבה:

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

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

פתרון:

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

התייחסות לתצוגה INFORMATION_SCHEMA

הודעת שגיאה:

Illegal operation on INFORMATION_SCHEMA view: PROJECT_ID:DATASET_OR_REGION.INFORMATION_SCHEMA.VIEW_NAME

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

Unsupported operator in materialized view: KEYWORD

או

Materialized view queries do not support FEATURE

או

Materialized views cannot reference logical views.

הסיבה:

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

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

• יכול להיות שבהודעת השגיאה Illegal operation on INFORMATION_SCHEMA viewVIEW_NAME יופיע שם של טבלה פנימית במערכת (לדוגמה, _HASH_JOBS_DELETE) במקום שם התצוגה INFORMATION_SCHEMA שציינתם בשאילתה.
• בתצוגות חומריות מצטברות, BigQuery מאמת את הגדרת ה-SQL הפנימית המורחבת של התצוגה INFORMATION_SCHEMA לפני שהוא בודק את התמיכה במסד נתונים טבלאי. אם ההגדרה הפנימית הזו מכילה תחביר או פונקציות של SQL שלא נתמכים בתצוגות חומריות מצטברות, השאילתה תיכשל קודם עם השגיאה unsupported SQL operator or syntax.

פתרון:

• אפשר להריץ שאילתה ישירות בתצוגה INFORMATION_SCHEMA, או ליצור תצוגה לוגית רגילה מעל התצוגה INFORMATION_SCHEMA אם לא צריך אחסון עם חישוב מראש.
• אם אתם צריכים להפוך מטא-נתונים של INFORMATION_SCHEMA לנתונים ממשיים (לדוגמה, כדי לשמור מטא-נתונים היסטוריים או לשפר את ביצועי השאילתות), אתם יכולים לכתוב את תוצאות השאילתה לטבלה ב-BigQuery באמצעות הצהרת CREATE TABLE AS SELECT או שאילתה מתוזמנת. אחרי כן תוכלו לשלוח שאילתה ישירות לטבלה הרגילה הזו או ליצור תצוגה חומרית מעליה.

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

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

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

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

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

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

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

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

הסיבה:

ב-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
  ...

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

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