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 מבוסס-זמן. צריך להגדיר את המאפיין בתצוגה שמבוססת על explore_source של PDT.

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

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

ניבים נתמכים של מסדי נתונים ל-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