increment_key

Usage

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 מצטברת היא טבלה נגזרת מתמידה (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 שמוגדר בתצוגה שעליה מבוסס הניתוח של הטבלה המצטברת. דוגמה מופיעה בקטע יצירת טבלת צבירה מצטברת בדף הזה.
• במקרה של PDT מבוסס-SQL, ‏increment_key חייב להתבסס על מאפיין LookML שמוגדר בקובץ התצוגה של ה-PDT. דוגמה מופיעה בקטע יצירת PDT מצטבר מבוסס-SQL בדף הזה.

בנוסף, הפרמטר increment_key צריך להיות:

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

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

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

לדוגמה, קובץ תצוגה של PDT שמבוסס על LookML, עם פרמטר LookML‏ explore_source. ה-PDT נוצר מתוך 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
  }
}

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

המאפיין departure_date הוא למעשה מסגרת הזמן של קבוצת המאפיינים datedeparture. (במאמר בנושא פרמטר 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

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

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

• מפתח הגידול חייב להתבסס על מאפיין LookML מבוסס-זמן שמוגדר בקובץ התצוגה של ה-PDT.
• צריך לספק מסנן {% incrementcondition %} Liquid ב-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 תתבסס רק על נתונים מתאריך מסוים ואילך. ה-PDT הבא WHERE יוצר נתונים מתאריך אחרי 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 מבוסס-זמן. צריך להגדיר את המאפיין בתצוגה שעליה מבוסס הניתוח של טבלת הצבירה.

לדוגמה, הטבלה המצטברת הזו מבוססת על accidents Explore, שבמקרה הזה מבוסס על התצוגה 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 המצטבר מותאמת לשאילתות מבוססות-זמן. באופן ספציפי, בעמודה מבוססת-הזמן שמשמשת כמפתח מצטבר צריך להיות מוגדרת אסטרטגיית אופטימיזציה, כמו חלוקה למחיצות, sortkeys, indexes או כל אסטרטגיית אופטימיזציה אחרת שנתמכת בניב שלכם. מומלץ מאוד לבצע אופטימיזציה של טבלת המקור, כי בכל פעם שמעדכנים את הטבלה המצטברת, Looker שולף שאילתה מטבלת המקור כדי לקבוע את הערכים העדכניים ביותר של העמודה שמבוססת על זמן ומשמשת כמפתח מצטבר. אם טבלת המקור לא מותאמת לשאילתות האלה, השאילתה של Looker לקבלת הערכים האחרונים עלולה להיות איטית ויקרה.

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

כדי ש-Looker יתמוך בטבלאות PDT מצטברות בפרויקט Looker, הניב של מסד הנתונים צריך לתמוך בפקודות Data Definition Language (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
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