increment_key

שימוש

view: my_view {
  derived_table: {
    increment_key: "created_date"
    ...
  }
}

היררכיה הצגת הקובץ view derived_table increment_key - או - קובץ מודל explore aggregate_table materialization increment_key

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

הגדרה

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

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

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

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

הפרמטר increment_key חייב לציין מאפיין LookML מבוסס-זמן:

• בטבלאות PDT שמבוססות על LookML, הפרמטר increment_key חייב להתבסס על מאפיין LookML שמוגדר בתצוגה שעליה מבוסס הפרמטר explore_source של ה-PDT. דוגמה לכך מופיעה בקטע יצירת PDT מצטבר שמבוסס על LookML בדף הזה.
• בטבלאות מסכמות, הערך של increment_key חייב להתבסס על מאפיין LookML שמוגדר בתצוגה שעליה מבוססת ה-Explore של הטבלה המסכמת. דוגמה לכך מופיעה בקטע יצירת טבלה מסכמת מצטברת בדף הזה.
• בטבלאות PDT שמבוססות על SQL, הפרמטר increment_key חייב להתבסס על מאפיין LookML שמוגדר בתוך קובץ התצוגה של ה-PDT. דוגמה לכך מופיעה בקטע יצירת PDT מצטבר שמבוסס על SQL בדף הזה.

בנוסף, increment_key חייב להיות:

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

יצירת PDT מצטבר שמבוסס על LookML

כדי להפוך PDT מבוסס LookML (מקורי) ל-PDT מצטבר, משתמשים בפרמטר increment_key כדי לציין את השם של מאפיין LookML מבוסס-זמן. צריך להגדיר את המאפיין בתצוגה שעליה מבוסס ה-explore_source של ה-PDT.

לדוגמה, הנה קובץ תצוגה של PDT שמבוסס על LookML, באמצעות הפרמטר explore_source של LookML. ה-PDT נוצר מ-Explore של flights, שבמקרה הזה מבוסס על התצוגה flights:

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 ;;
  }
...

יצירת PDT מצטבר שמבוסס על SQL

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

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

• מפתח ההגדלה חייב להתבסס על מאפיין LookML מבוסס-זמן שאתם מגדירים בקובץ התצוגה של ה-PDT.
• צריך לספק מסנן Liquid מסוג {% incrementcondition %} ב-PDT כדי לקשר את מפתח ההגדלה לעמודת הזמן במסד הנתונים שעליה מבוסס מפתח ההגדלה. במסנן {% incrementcondition %} צריך לציין את שם העמודה במסד הנתונים, ולא כינוי SQL או שם של מאפיין שמבוסס על העמודה (ראו את הדוגמה הבאה).

הפורמט הבסיסי של מסנן Liquid הוא:

   WHERE {% incrementcondition %} database_table_name.database_time_column {% endincrementcondition %}

לדוגמה, זהו קובץ התצוגה של PDT שמבוסס על SQL, שנבנה מחדש במרווחים של יום אחד (increment_key: "dep_date"), ונתונים משלושת הימים האחרונים יתווספו לטבלה כשהיא תיבנה מחדש (increment_offset: 3):

view: sql_based_incremental_date_pdt {
  derived_table: {
    datagroup_trigger: flights_default_datagroup
    increment_key: "dep_date"
    increment_offset: 3
    distribution_style: all
    sql: SELECT
        flights.id2  AS "id",
        flights.origin  AS "origin",
        DATE(flights.leaving_time )  AS "departure"
      FROM public.flights  AS flights
      WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}
          ;;
  }

  dimension_group: dep {
    type: time
    timeframes: [date, week, month, year]
    datatype: date
    sql:  ${TABLE}.departure
    ;;
  }
  dimension: id {
      type: number
    }
    dimension: origin {
      type: string
  }
}

שימו לב לנקודות הבאות בדוגמה הזו:

• הטבלה הנגזרת מבוססת על הצהרת SQL. הצהרת ה-SQL יוצרת עמודה בטבלה הנגזרת שמבוססת על העמודה flights.leaving_time במסד הנתונים. העמודה מקבלת את השם החלופי departure.
• קובץ התצוגה של ה-PDT מגדיר קבוצת מאפיינים בשם dep.
  • הפרמטר sql של קבוצת המאפיינים מציין שקבוצת המאפיינים מבוססת על העמודה departure בטבלה הנגזרת.
  • הפרמטר timeframes של קבוצת המאפיינים כולל את date כמסגרת זמן.
• השדה increment_key בטבלה הנגזרת משתמש במאפיין dep_date, שהוא מאפיין שמבוסס על מסגרת הזמן date של קבוצת המאפיינים dep. (במאמר העזרה בנושא הפרמטר dimension_group מוסבר איך קבוצות מאפיינים פועלות).
• מסנן Liquid {% incrementcondition %} משמש לחיבור מפתח ההגדלה לעמודה flights.leaving_time במסד הנתונים.
  • הערך של {% incrementcondition %} חייב לציין את השם של עמודת TIMESTAMP במסד הנתונים (או שהוא חייב להעריך עמודת TIMESTAMP במסד הנתונים).
  • הפרמטר {% incrementcondition %} צריך להתאים למה שזמין בסעיף FROM שמגדיר את ה-PDT, כמו עמודות מהטבלה שצוינה בסעיף FROM. הפונקציה {% incrementcondition %} לא יכולה להתייחס לתוצאה של הצהרת SELECT, כמו כינוי שניתן לעמודה בהצהרת ה-SQL, או שם של מאפיין שמבוסס על העמודה. בדוגמה הזו, הערך של {% incrementcondition %} הוא flights.leaving_time. מכיוון שהסעיף FROM מציין את הטבלה flights, ה-{% incrementcondition %} יכול להתייחס לעמודות מהטבלה flights.
  • השדה {% incrementcondition %} צריך להצביע על אותה עמודה במסד הנתונים שמשמשת כמפתח ההגדלה. בדוגמה הזו, מפתח ההגדלה הוא dep_date, מאפיין שמוגדר על ידי העמודה departure ב-PDT, שהיא כינוי לעמודה flights.leaving_time במסד הנתונים. לכן, המסנן מפנה אל flights.leaving_time:

WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}

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

WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}
  AND flights.leaving_time > '2020-01-01'

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

view: sql_based_incremental_15min_pdt {
  derived_table: {
    datagroup_trigger: flights_default_datagroup
    increment_key: "event_minute15"
    increment_offset: 1
    sql: SELECT PARSE_TIMESTAMP("%c", flights.text_column) as parsed_timestamp_column,
        flights.id2  AS "id",
        flights.origin  AS "origin",
      FROM public.flights  AS flights
      WHERE {% incrementcondition %} PARSE_TIMESTAMP("%c", flights.text_column)
          {% endincrementcondition %} ;;
  }

  dimension_group: event {
    type: time
    timeframes: [raw, minute15, hour, date, week, month, year]
    datatype: timestamp
    sql:  ${TABLE}.parsed_timestamp_column ;;
  }
  dimension: id {
    type: number
  }
  dimension: origin {
    type: string
  }
}

אפשר להשתמש בשם החלופי של ה-SQL בהגדרה של קבוצת המאפיינים sql, אבל צריך להשתמש בביטוי ה-SQL בסעיף WHERE. ואז, בגלל ש-minute15 הוגדר כ-לוח זמנים בקבוצת המאפיינים event, אפשר להשתמש ב-event_minute15 כמפתח המרווח כדי לקבל מרווח של 15 דקות ל-PDT.

יצירת טבלה מסכמת מצטברת

כדי ליצור טבלה מסכמת מצטברת, מוסיפים את increment_key ואת increment_offset (אופציונלי) מתחת לפרמטר materialization של הפרמטר aggregate_table. משתמשים בפרמטר increment_key כדי לציין את השם של מאפיין LookML שמבוסס על זמן. המאפיין חייב להיות מוגדר בתצוגה שעליה מבוסס ה-Explore של הטבלה המסכמת.

לדוגמה, הטבלה המסכמת הזו מבוססת על ה-Explore accidents, שבמקרה הזה מבוסס על התצוגה accidents. הטבלה המסכמת נבנית מחדש במרווחים של שבוע אחד (increment_key: event_week), שבועיים אחורה (increment_offset: 2):

explore: accidents {
  . . .
  aggregate_table: accidents_daily {
    query: {
      dimensions: [event_date, id, weather_condition]
      measures: [count]
    }
    materialization: {
      datagroup_trigger: flights_default_datagroup
      increment_key: "event_week"
      increment_offset: 2
    }
  }
}

מפתח ההגדלה משתמש במאפיין event_week, שמבוסס על מסגרת הזמן week מקבוצת המאפיינים event. (במאמר העזרה בנושא הפרמטר dimension_group מוסבר איך קבוצות מאפיינים פועלות). קבוצת המאפיינים ולוח הזמנים מוגדרים בתצוגה accidents:

. . .
view: accidents {
  . . .
  dimension_group: event {
      type: time
      timeframes: [
        raw,
        date,
        week,
        year
      ]
      sql: ${TABLE}.event_date ;;
  }
  . . .
}

מה כדאי לקחת בחשבון?

אופטימיזציה של טבלת המקור לשאילתות מבוססות-זמן

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

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

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

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

ניב	יש תמיכה?
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
ClickHouse 26+
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+
Dremio 26+ with Arrow Flight SQL
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