מעקב אחרי תצוגות מהותיות

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

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

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

כדי לגלות תצוגות מהותיות, מריצים שאילתה על INFORMATION_SCHEMA.TABLES view. כדי לאחזר את המאפיינים של תצוגה חומרית, שולחים שאילתה לתצוגה INFORMATION_SCHEMA.TABLE_OPTIONS.

תצוגות חומריות לא מופיעות בטבלת INFORMATION_SCHEMA.VIEWS view.

מעקב אחרי רענון אוטומטי

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

צפייה בסטטוס הרענון האחרון

כדי לאחזר את הסטטוס הנוכחי של תצוגות חומריות, קוראים לשיטה tables.get או שולחים שאילתה לתצוגה INFORMATION_SCHEMA.MATERIALIZED_VIEWS.

לדוגמה:

SELECT
  table_name, last_refresh_time, refresh_watermark, last_refresh_status
FROM
  `DATASET`.INFORMATION_SCHEMA.MATERIALIZED_VIEWS;

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

הצגת משימות של רענון אוטומטי של רשימות

כדי להציג רשימה של משימות רענון אוטומטי של תצוגות חומריות, קוראים לשיטה jobs.list. כדי לאחזר פרטים על המשימות, קוראים לשיטה jobs.get. אפשר גם להריץ שאילתות על התצוגה INFORMATION_SCHEMA.JOBS_BY_* views כדי לאחזר פרטים על משימות. משימות רענון אוטומטיות מכילות את הקידומת materialized_view_refreshבתוך מזהה המשימה, והן מופעלות על ידי חשבון אדמין ב-BigQuery.

לדוגמה:

SELECT
  job_id, total_slot_ms, total_bytes_processed,
  materialized_view_statistics.materialized_view[SAFE_OFFSET(0)].rejected_reason
  AS full_refresh_reason
FROM
  `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE
  job_id LIKE '%materialized_view_refresh_%'
LIMIT 10;

כדי לעקוב אחרי העלות של עבודות הרענון ולשנות את מרווח הרענון האוטומטי אם צריך, מעיינים בשדות total_bytes_processed ו-total_slot_ms.

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

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

  1. השבתת הרענון האוטומטי.

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

הפעולות הבאות יכולות לגרום לביטול התוקף של תצוגות חומריות: חיתוך טבלה, חיתוך מחיצה, תפוגה של מחיצה ומשפטי שפת טיפול בנתונים (DML) ‏UPDATE, DELETE ו-MERGE בטבלת בסיס. אם התצוגה החומרית מחולקת למחיצות, המחיצות ששונו נפסלות. אחרת, התצוגה החומרית כולה נפסלת. לכן, כדאי לאגד את הצהרות ה-DML ולבצע את הרענון הידני בסוף השאילתה.

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

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

אתם יכולים ליצור אוטומציה כדי לעקוב אחרי רענונים של תצוגות חומריות שנכשלו ולשלוח התראות באמצעות יומני ביקורת של BigQuery ב-Cloud Logging. ‫BigQuery יוצר רשומות ביומן עבור משימות רענון של תצוגות חומריות, כולל כשלים. Logs Explorer במסוף Google Cloud עוזר לכם לאחזר, להציג ולנתח רשומות ביומן. הערכים האלה מאוחסנים בקטגוריות של יומנים, שהן הקונטיינרים שבהם Cloud Logging משתמש כדי לאחסן את נתוני היומן.

כדי ליצור מדד והתראה:

המסוף

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

יצירת מדד מבוסס-יומן

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

  2. ב-Logs Explorer, מוודאים שההגדרה Show query (הצגת השאילתה) מופעלת.

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

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

    severity: "ERROR"
protoPayload.metadata.jobChange.after: "DONE"
protoPayload.metadata.jobChange.job.jobConfig.queryConfig.query =~ "CALL BQ.REFRESH_MATERIALIZED_VIEW\('.*'\)"
protoPayload.resourceName =~ ".*materialized_view_refresh_[\w]"

  4. לוחצים על Run query.

  5. לוחצים על פעולות ואז על יצירת מדד.

  6. כדי ליצור התראה על סמך מספר השגיאות, בוחרים באפשרות Counter (מונה) בשדה Metric type (סוג המדד), ומזינים Log-based metric name (שם המדד מבוסס-היומן) ו-Description (תיאור) למדד. אפשר להשאיר את השדה Units (יחידות) ריק.

  7. כדי להגדיר את מסנן המדדים בקטע Filter selection, משתמשים בהגדרות הבאות:

    • בתפריט Select project or log bucket (בחירת פרויקט או קטגוריה ביומן) בוחרים אם המדד יספור את רשומות היומן בפרויקט Google Cloud או רק את רשומות היומן בקטגוריה ביומן ספציפית.

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

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

  8. לוחצים על הוספת תווית.

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

  10. בשדה שם השדה, מזינים את המחרוזת הבאה:

    protoPayload.metadata.jobChange.job.jobConfig.queryConfig.query

  11. בשדה ביטוי רגולרי, מזינים את המחרוזת הבאה:

    CALL BQ.REFRESH_MATERIALIZED_VIEW\('(.*)'\)

  12. לוחצים על סיום ואז על יצירת מדד.

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

יצירת התראה

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

  1. נכנסים לדף Log-based Metrics במסוף Google Cloud .

    מעבר אל Log-based Metrics

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

  3. בקטע Select a metric (בחירת מדד), בוחרים את שם המדד שציינתם קודם בשדה Log-based metric name (שם המדד מבוסס-היומן).

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

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

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

  5. בהגדרה Rolling window בקטע Transform data, מציינים ערך שגדול מ-10 דקות כדי לוודא שייכללו בספירה כמה רשומות ביומן שמתאימות למסנן, ולוחצים על Next.

  6. מציינים Threshold value (ערך הסף), לדוגמה 3, ואם רוצים, מגדירים את השדות Alert trigger (הפעלת ההתראה) ו-Threshold position (מיקום הסף). לוחצים על הבא.

  7. בוחרים ערוץ התראות להפעלת ההתראה.

  8. לוחצים על יצירת מדיניות.

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

Terraform

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

resource "google_logging_metric" "failed_mv_refresh_metric" {
project = var.project_id
name    = var.logging_metric_name
filter = trimspace(<<EOT
  severity="ERROR"
  AND protoPayload.metadata.jobChange.after="DONE"
  AND protoPayload.metadata.jobChange.job.jobConfig.queryConfig.query=~"CALL BQ.REFRESH_MATERIALIZED_VIEW\('.*'\)"
  AND protoPayload.resourceName=~".*materialized_view_refresh_[\\w]"
  EOT
  )
metric_descriptor {
  metric_kind  = "DELTA"
  value_type   = "INT64"
  unit         = "1"
  display_name = "Failed Materialized View Refresh Count"

  labels {
    key          = "materialized_view_name"
    value_type   = "STRING"
    description  = "The name of the materialized view that failed to refresh."
  }
}
label_extractors = {
  "materialized_view_name" = "REGEXP_EXTRACT(protoPayload.metadata.jobChange.job.jobConfig.queryConfig.query, \"CALL BQ\\.REFRESH_MATERIALIZED_VIEW\\('(.*)'\\)\")"
}
}

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

resource "google_monitoring_alert_policy" "failed_mv_refresh_alert" {
project      = var.project_id
display_name = var.alert_policy_display_name
combiner     = "OR"

conditions {
  display_name = "Condition: Materialized View Refresh Failure Count Exceeds Threshold"

  condition_threshold {
    filter = "metric.type=\"logging.googleapis.com/user/${google_logging_metric.failed_mv_refresh_metric.name}\" AND resource.type=\"bigquery_project\""

    duration = "${var.alert_duration_seconds}s"

    comparison = "COMPARISON_GT"

    threshold_value = var.alert_threshold_count

    aggregations {
      alignment_period   = "${var.alert_rolling_window_seconds}s"
      per_series_aligner = "ALIGN_DELTA"
      cross_series_reducer = "REDUCE_SUM"
      group_by_fields        = []
    }

    trigger {
      count = 1
    }
  }
}

notification_channels = [
  google_monitoring_notification_channel.email_channel.id,
]
}

דוגמאות נוספות:

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

מעקב אחר השימוש בתצוגות מהותיות

כדי לראות את השימוש בתצוגה חומרית בעבודת שאילתה, אפשר לקרוא ל-jobs.get method או להריץ שאילתה על INFORMATION_SCHEMA.JOBS_BY_* view ולראות את השדה materialized_view_statistics, שמספק פרטים על השימוש בתצוגות חומריות בשאילתה, כולל הפרטים הבאים:

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

לדוגמה:

SELECT
  job_id, materialized_view_statistics
FROM
  region-US.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  job_id = '<my-query-job-id>';

כדי לראות את השימוש בתצוגה מהותית לאורך זמן, שולחים שאילתה לתצוגות INFORMATION_SCHEMA.JOBS_BY_*.

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

SELECT
  mv.table_reference.dataset_id,
  mv.table_reference.table_id,
  MAX(job.creation_time) latest_job_time,
  COUNT(job_id) job_count
FROM
  region-US.INFORMATION_SCHEMA.JOBS_BY_PROJECT job,
  UNNEST(materialized_view_statistics.materialized_view) mv
WHERE
  job.creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 7 DAY)
  AND mv.table_reference.dataset_id = 'MY_DATASET'
  AND mv.table_reference.table_id = 'MY_MATERIALIZED_VIEW'
  AND mv.chosen = TRUE
GROUP BY 1, 2;

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

אם השאילתה משתמשת בתצוגות חומריות והיא פועלת לאט מהצפוי, צריך לבצע את הפעולות הבאות:

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