המרות מצטברות של PDT

ב-Looker, טבלאות נגזרות מתמידות (PDTs) נכתבות לסכימת הגרסה הבסיסית של מסד הנתונים שלך. ‫Looker שומרת ובונה מחדש PDT על סמך אסטרטגיית השמירה שלו. כאשר PDT מופעל לבנייה מחדש, כברירת מחדל, Looker בונה מחדש את כל הטבלה.

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

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

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

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

הערות לגבי כללי PDT מצטברים:

  • PDTs מצטברים נתמכים רק עבור PDTs המשתמשים באסטרטגיית התמדה מבוססת טריגר (datagroup_trigger, sql_trigger_value, אוinterval_trigger ). PDTs מצטברים אינם נתמכים עבור PDTs המשתמשים ב-persist_for אסטרטגיית התמדה.
  • כדי להשתמש ב-PDT מצטבר שמבוסס על SQL, צריך להגדיר את שאילתת הטבלה באמצעות הפרמטר sql. PDTs מבוססי SQL המוגדרים באמצעותsql_create פרמטר או ה-create_process לא ניתן לבנות פרמטר בצורה הדרגתית. כפי שאפשר לראות בדוגמה 1 בדף הזה, Looker משתמש בפקודה INSERT או בפקודה MERGE כדי ליצור את הגידולים ב-PDT מצטבר. אי אפשר להגדיר את הטבלה הנגזרת באמצעות הצהרות מותאמות אישית של שפת הגדרת נתונים (DDL), כי Looker לא יוכל לקבוע אילו הצהרות DDL נדרשות כדי ליצור תוספת מדויקת.
  • טבלת המקור של ה-PDT המצטבר צריכה להיות מותאמת לשאילתות שמבוססות על זמן. באופן ספציפי, לעמודה מבוססת-הזמן שמשמשת כמפתח מצטבר צריכה להיות מוגדרת אסטרטגיית אופטימיזציה, כמו חלוקה למחיצות, מפתחות מיון, אינדקסים או כל אסטרטגיית אופטימיזציה אחרת שנתמכת בניב שלכם. מומלץ מאוד לבצע אופטימיזציה של טבלת המקור, כי בכל פעם שהטבלה המצטברת מתעדכנת, Looker שולף שאילתה מטבלת המקור כדי לקבוע את הערכים העדכניים ביותר של העמודה שמבוססת על זמן ומשמשת כמפתח מצטבר. אם טבלת המקור אינה ממוטבת עבור שאילתות אלה, שאילתת Looker עבור הערכים העדכניים ביותר עשויה להיות איטית ויקרה.

הגדרת PDT מצטבר

ניתן להשתמש בפרמטרים הבאים כדי להפוך PDT ל-PDT מצטבר:

  • ‫increment_key (נדרש כדי להפוך את ה-PDT ל-PDT מצטבר): מגדיר את פרק הזמן שבו צריך לבצע שאילתה לגבי רשומות חדשות.
  • {% incrementcondition %}מסנן נוזלי (נדרש כדי ליצורPDT מבוסס SQL PDT מצטבר; לא רלוונטי לPDTs מבוססי LookML ): מחבר את מפתח התוספת לעמודת הזמן של מסד הנתונים שעליה מבוסס מפתח התוספת. מידע נוסף מופיע בדף התיעוד של increment_key.
  • increment_offset (אופציונלי): מספר שלם המגדיר את מספר תקופות הזמן הקודמות (ברגע הפירוט של מפתח ההגדלה) שנבנות מחדש עבור כל בנייה הדרגתית. הפרמטר increment_offset שימושי במקרים של נתונים שמגיעים באיחור, שבהם יכול להיות שבנתונים מתקופות קודמות ייכללו נתונים חדשים שלא נכללו כשתוסף הזמן המתאים נוצר וצורף ל-PDT.

בדף התיעוד של הפרמטר increment_key יש דוגמאות שמראות איך ליצור PDT מצטבר מטבלאות נגזרות מתמידות מקוריות, מטבלאות נגזרות מתמידות שמבוססות על SQL ומטבלאות מצטברות.

הנה דוגמה פשוטה לקובץ תצוגה המגדיר PDT מבוסס LookML מצטבר:

view: flights_lookml_incremental_pdt {
  derived_table: {
    indexes: ["id"]
    increment_key: "departure_date"
    increment_offset: 3
    datagroup_trigger: flights_default_datagroup
    distribution_style: all
    explore_source: flights {
      column: id {}
      column: carrier {}
      column: departure_date {}
    }
  }

  dimension: id {
    type: number
  }
  dimension: carrier {
    type: string
  }
   dimension: departure_date {
    type: date
  }
}

הטבלה הזו תיבנה במלואה בפעם הראשונה שמופעלת עליה שאילתה. לאחר מכן, ה-PDT ייבנה מחדש במרווחים של יום אחד (increment_key: departure_date), עד שלושה ימים אחורה (increment_offset: 3).

מפתח הגידול מבוסס על מאפיין departure_date, שהוא למעשה date מסגרת הזמן מקבוצת המאפיינים departure. (ראה אתdimension_group דף תיעוד פרמטרים לקבלת סקירה כללית של אופן פעולת קבוצות ממדים.) קבוצת המאפיינים וטווח הזמן מוגדרים בתצוגה flights, שהיא explore_source עבור ה-PDT הזה. כך מוגדרת קבוצת המאפיינים departure בקובץ התצוגה flights:

...
  dimension_group: departure {
    type: time
    timeframes: [
      raw,
      date,
      week,
      month,
      year
    ]
    sql: ${TABLE}.dep_time ;;
  }
...

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

ההגדרות increment_key ו-increment_offset של PDT לא תלויות בשיטת ההתמדה של ה-PDT:

  • אסטרטגיית ההתמדה של ה-PDT המצטבר קובעת רק מתי ה-PDT גדל. הכלי ליצירת PDT לא משנה את ה-PDT המצטבר אלא אם מופעלת אסטרטגיית השמירה של הטבלה, או אם ה-PDT מופעל באופן ידני באמצעות האפשרות Rebuild Derived Tables & Run (בנייה מחדש של טבלאות נגזרות והרצה) ב-Explore.
  • כאשר ה-PDT עולה, בונה ה-PDT יקבע מתי הנתונים האחרונים נוספו לטבלה, במונחים של תוספת הזמן העדכנית ביותר (תקופת הזמן המוגדרת על ידי הפרמטר increment_key). על סמך זה, כלי ה-PDT יקצץ את הנתונים לתחילת מרווח הזמן האחרון בטבלה, ואז יבנה את המרווח האחרון משם.
  • אם ל-PDT יש פרמטר increment_offset, כלי ה-PDT Builder יבנה מחדש גם את מספר התקופות הקודמות שצוינו בפרמטר increment_offset. התקופות הקודמות מתחילות מההתחלה של מרווח הזמן הנוכחי ביותר (תקופת הזמן שמוגדרת על ידי הפרמטר increment_key).

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

דוגמה 1

בדוגמה הזו נעשה שימוש ב-PDT עם המאפיינים הבאים:

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

כך הטבלה הזו תעודכן:

  • אסטרטגיית התמדה חודשית פירושה שהטבלה נבנית אוטומטית פעם בחודש. כלומר, ב-1 ביוני, השורה האחרונה בטבלה תהיה השורה שנוספה ב-1 במאי.
  • מכיוון של-PDT הזה יש מפתח מצטבר שמבוסס על תאריך, הכלי ליצירת PDT יקצץ את הנתונים של 1 במאי בחזרה לתחילת היום ויבנה מחדש את הנתונים של 1 במאי ועד היום הנוכחי, 1 ביוני.
  • בנוסף, ל-PDT הזה יש היסטוריית עלייה של 3. אז בונה ה-PDT גם בונה מחדש את הנתונים משלוש תקופות הזמן (ימים) הקודמות שלפני ה-1 במאי. התוצאה היא שהנתונים נבנים מחדש עבור התאריכים 28, 29 ו-30 באפריל, ועד היום הנוכחי, 1 ביוני.

במונחים של SQL, זו הפקודה שכלי ה-PDT Builder יריץ ב-1 ביוני כדי לקבוע אילו שורות מתוך ה-PDT הקיים צריך לבנות מחדש:

## Example SQL for BigQuery:
SELECT FORMAT_TIMESTAMP('%F %T',TIMESTAMP_ADD(MAX(pdt_name),INTERVAL -3 DAY))

## Example SQL for other dialects:
SELECT CAST(DATE_ADD(MAX(pdt_name),INTERVAL -3 DAY) AS CHAR)

זו פקודת ה-SQL שכלי ה-PDT Builder יריץ ב-1 ביוני כדי ליצור את העלייה האחרונה:

## Example SQL for BigQuery:

MERGE INTO [pdt_name] USING (SELECT [columns]
   WHERE created_at >= TIMESTAMP('4/28/21 12:00:00 AM'))
   AS tmp_name ON FALSE
WHEN NOT MATCHED BY SOURCE AND created_date >= TIMESTAMP('4/28/21 12:00:00 AM')
   THEN DELETE
WHEN NOT MATCHED THEN INSERT [columns]

## Example SQL for other dialects:

START TRANSACTION;
DELETE FROM [pdt_name]
   WHERE created_date >= TIMESTAMP('4/28/21 12:00:00 AM');
INSERT INTO [pdt_name]
   SELECT [columns]
   FROM [source_table]
   WHERE created_at >= TIMESTAMP('4/28/21 12:00:00 AM');
COMMIT;

דוגמה 2

בדוגמה הזו נעשה שימוש ב-PDT עם המאפיינים הבאים:

  • שיטת שימור: מופעלת פעם ביום
  • מפתח הוספה: חודש
  • קיזוז הגדלה: 0

כך תעודכן הטבלה הזו ב-1 ביוני:

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

כך הטבלה הזו תעודכן ב-2 ביוני:

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

דוגמה 3

בדוגמה הזו נעשה שימוש ב-PDT עם המאפיינים הבאים:

  • מפתח הוספה: חודש
  • הגדלת ההיסט: 3
  • שיטת שימור: מופעלת פעם ביום

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

כך הטבלה הזו תעודכן ב-1 ביוני:

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

כך הטבלה הזו תעודכן ב-2 ביוני:

  • ב-2 ביוני, השורה האחרונה בטבלה תתווסף ב-1 ביוני.
  • כלי ה-PDT Builder יקצר את החודש עד 1 ביוני ויבנה מחדש את הנתונים לחודש יוני, כולל 2 ביוני.
  • בנוסף, עקב קיזוז ההגדלה, בונה ה-PDT יבנה מחדש את הנתונים משלושת החודשים הקודמים לפני יוני. התוצאה היא שהנתונים בנויים מחדש ממרץ, אפריל, מאי ועד היום, ה-2 ביוני.

בדיקת PDT מצטבר במצב פיתוח

לפני פריסת PDT מצטבר חדש בסביבת הייצור שלך, תוכל לבדוק את ה-PDT כדי לוודא שהוא נבנה ומצטבר. כדי לבדוק PDT מצטבר במצב פיתוח:

  1. יוצרים ניתוח ל-PDT:

    • בקובץ מודל משויך, משתמשים בפרמטר include כדי לכלול את קובץ התצוגה של ה-PDT בקובץ המודל.
    • באותו קובץ מודל, משתמשים בפרמטר explore כדי ליצור תצוגה של PDT מצטבר ב-Explore.
     include: "/views/e_faa_pdt.view"
 explore: e_faa_pdt {}

  2. פתח את 'חקור' עבור ה-PDT. לשם כך, בחר בלחצן הצג פעולות קובץ ולאחר מכן בחר שם של 'חקור'.

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

  2. כדי לוודא ש-PDT הראשוני נוצר, אפשר לבצע את הפעולות הבאות:

    • אם יש לכם הרשאה מסוג see_logs, תוכלו לבדוק אם הטבלה נוצרה על ידי עיון ביומן האירועים של PDT. אם אתם לא רואים את האירועים של PDT ביומן האירועים של PDT, כדאי לבדוק את פרטי הסטטוס בחלק העליון של הכלי 'ניתוח נתונים' ביומן האירועים של PDT. אם מופיע הכיתוב 'מהמטמון', אפשר לבחור באפשרות ניקוי המטמון ורענון כדי לקבל מידע עדכני יותר.
    • אפשר גם לעיין בתגובות בכרטיסייה SQL בסרגל נתונים של הכלי 'ניתוח נתונים'. הכרטיסייה SQL מציגה את השאילתה ואת הפעולות שיבוצעו בעת הפעלת השאילתה ב-Explore. לדוגמה, אם ההערות בכרטיסייה SQL אומרות -- generate derived table e_incremental_pdt, זוהי הפעולה שתבוצע כשתלחצו על הפעלה.

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

  4. אפשר להשתמש באותן שיטות כמו קודם כדי לוודא ש-PDT נוצר באופן מצטבר:

    • אם יש לך את הsee_logs הרשאה, אתה יכול להשתמש ביומן אירועי PDT לראותcreate increment complete אירועים עבור ה-PDT המצטבר. אם האירוע הזה לא מופיע ביומן האירועים של PDT והסטטוס של השאילתה הוא 'ממטמון', בוחרים באפשרות ניקוי המטמון ורענון כדי לקבל מידע עדכני יותר.
    • בודקים את התגובות בכרטיסייה SQL בסרגל נתונים של התכונה 'ניתוח נתונים'. במקרה כזה, בהערות יצוין שערך ה-PDT הוגדל. לדוגמה: -- increment persistent derived table e_incremental_pdt to generation 2

  5. אחרי שמוודאים ש-PDT נוצר ושהערך שלו גדל בצורה תקינה, אפשר להסיר או להוסיף הערה לפרמטרים explore ו-include של ה-PDT מקובץ המודל, אם לא רוצים לשמור את ה-Explore הייעודי ל-PDT.

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

פתרון בעיות PDT מצטבר

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

בניית PDT מצטבר נכשלת אחרי שינוי בסכימה

אם ה-PDT המצטבר שלכם הוא טבלה נגזרת שמבוססת על SQL, והפרמטר sql כולל תו כללי לחיפוש כמו SELECT *, שינויים בסכימת מסד הנתונים הבסיסי (כמו הוספת עמודה, הסרת עמודה או שינוי סוג הנתונים של עמודה) עלולים לגרום ל-PDT להיכשל עם השגיאה הבאה:

SQL Error in incremental PDT: Query execution failed

כדי לפתור את הבעיה הזו, עורכים את ההצהרה SELECT בפרמטר sql כדי לבחור במקום זאת עמודות ספציפיות. לדוגמה, אם פסוקית ה-SELECT היא SELECT *, צריך לשנות אותה ל-SELECT column1, column2, ....

אם הסכימה משתנה ואתם רוצים לבנות מחדש את ה-PDT המצטבר מאפס, צריך להשתמש בקריאה ל-API‏ start_pdt_build ולכלול את הפרמטר full_force_incremental.

ניבים נתמכים של מסדי נתונים ל-PDT מצטברות

כדי ש-Looker יתמוך בטבלאות PDT מצטברות בפרויקט Looker, הניב של מסד הנתונים צריך לתמוך בפקודות Data Definition Language (DDL) שמאפשרות מחיקה והוספה של שורות.

בטבלה הבאה מפורטים הניבים שתומכים ב-PDT מצטבר בגרסה האחרונה של Looker (ב-Databricks, ‏ PDT מצטבר נתמך רק ב-Databricks מגרסה 12.1 ואילך):

דיאלקט נתמך?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica