טבלאות נגזרות ב-Looker

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

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

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

למקרי שימוש נפוצים בטבלאות נגזרות, בקרו ב-ספרי בישול של Looker: הפקת המרב מטבלאות נגזרות ב-Looker.

טבלאות נגזרות מקוריות וטבלאות נגזרות מבוססות SQL

כדי ליצור טבלה נגזרת בפרויקט Looker שלך, השתמש ב-derived_table פרמטר תחת אנוֹף פָּרָמֶטֶר. בתוך הפרמטר derived_table, ניתן להגדיר את השאילתה עבור הטבלה הנגזרת באחת משתי דרכים:

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

  • הטבלה הנגזרת המקורית מגדירה את השאילתה עם LookML בפרמטר explore_source. בדוגמה זו, השאילתה מבוססת על תצוגה קיימת של orders, המוגדרת בקובץ נפרד שאינו מוצג בדוגמה זו. שאילתת explore_source בטבלה הנגזרת המקורית מביאה את השדות customer_id, first_order ו-total_amount מקובץ התצוגה orders.
  • הטבלה הנגזרת מבוססת SQL מגדירה את השאילתה באמצעות SQL בפרמטר sql. בדוגמה זו, שאילתת ה-SQL היא שאילתה ישירה של הטבלה orders במסד הנתונים.
גרסת טבלה נגזרת מקורית 
view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      column: customer_id {
        field: orders.customer_id
      }
      column: first_order {
        field: orders.first_order
      }
      column: total_amount {
        field: orders.total_amount
      }
    }
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}
גרסת טבלה נגזרת מבוססת SQL 
view: customer_order_summary {
  derived_table: {
    sql:
      SELECT
        customer_id,
        MIN(DATE(time)) AS first_order,
        SUM(amount) AS total_amount
      FROM
        orders
      GROUP BY
        customer_id ;;
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}

שתי הגרסאות יוצרות תצוגה בשם customer_order_summary המבוססת על טבלת orders, עם העמודות customer_id, first_order, ו-total_amount.

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

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

טבלאות נגזרות מקוריות

טבלאות נגזרות מקוריות מבוססות על שאילתות שאתה מגדיר באמצעות מונחי LookML. כדי ליצור טבלה נגזרת מקורית, עליך להשתמש ב-explore_source פרמטר בתוך ה-derived_table פרמטר של אנוֹף פָּרָמֶטֶר. אתה יוצר את העמודות של הטבלה הנגזרת המקורית שלך על ידי התייחסות למידות או למדדים של LookML במודל שלך. ראה את קובץ תצוגת הטבלה הנגזר המקורי בדוגמה הקודמת.

בהשוואה לטבלאות נגזרות מבוססות SQL, טבלאות נגזרות מקוריות קלות הרבה יותר לקריאה ולהבנה בעת מידול הנתונים שלך.

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

טבלאות נגזרות מבוססות SQL

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

לרוב, מגדירים את שאילתת ה-SQL באמצעותsql פרמטר בתוך ה-derived_table פרמטר של אנוֹף פָּרָמֶטֶר.

קיצור דרך מועיל ליצירת שאילתות מבוססות SQL ב-Looker הוא להשתמש ב-SQL Runner כדי ליצור את שאילתת ה-SQL ולהפוך אותה להגדרת טבלה נגזרת.

מקרי קצה מסוימים לא יאפשרו את השימוש בפרמטר sql. במקרים כאלה, Looker תומך בפרמטרים הבאים להגדרת שאילתת SQL עבור טבלאות נגזרות מתמידות (PDTs):

  • create_process: כאשר אתה משתמש ב-sql פרמטר עבור PDT, ברקע Looker עוטף את הניבCREATE TABLE הצהרת שפת הגדרת נתונים (DDL) סביב השאילתה שלך כדי ליצור את ה-PDT משאילתת ה-SQL שלך. חלק מהדיאלקטים אינם תומכים במשפט SQL CREATE TABLE בשלב אחד. עבור דיאלקטים אלה, לא ניתן ליצור PDT עם הפרמטר sql. במקום זאת, ניתן להשתמש בפרמטר create_process כדי ליצור PDT במספר שלבים. ראה אתcreate_process דף תיעוד פרמטרים לקבלת מידע ודוגמאות.
  • sql_createאם מקרה השימוש שלך דורש התאמה אישיתDDL פקודות והדיאלקט שלך תומך ב-DDL (לדוגמה, תכונת החיזוי של גוגלביג-קוורי למידת מכונה ), אתה יכול להשתמש ב-sql_create פרמטר ליצירת PDT במקום להשתמש ב-sql פָּרָמֶטֶר. ראה אתsql_create דף תיעוד לקבלת מידע ודוגמאות.

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

כשמגדירים טבלה נגזרת מבוססת SQL, יש להקפיד לתת לכל עמודה כינוי נקי באמצעות AS. הסיבה לכך היא שתצטרכו להפנות לשמות העמודות של קבוצת התוצאות שלכם במידות שלכם, כגון ${TABLE}.first_order. זו הסיבה שבדוגמה הקודמת משתמשים ב-MIN(DATE(time)) AS first_order במקום רק ב-MIN(DATE(time)).

טבלאות נגזרות זמניות ומתמידות

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

טבלאות נגזרות מקוריות וטבלאות נגזרות מבוססות SQL יכולות להיות זמניות או מתמשכות.

טבלאות נגזרות זמניות

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

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

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

דיאלקטים נתמכים של מסדי נתונים עבור טבלאות נגזרות זמניות

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

טבלאות נגזרות קבועות

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

PDT יכול להיות טבלה נגזרת מקורית או טבלה נגזרת מבוססת SQL.

דרישות עבור PDTs

כדי להשתמש בטבלאות נגזרות מתמידות (PDTs) בפרויקט Looker שלך, עליך לבצע את הדברים הבאים:

  • ניב של מסד נתונים התומך ב-PDTs. עיין בסעיף דיאלקטים נתמכים של מסדי נתונים עבור PDTs בהמשך דף זה לקבלת רשימות הדיאלקטים התומכים בטבלאות נגזרות קבועות מבוססות SQL ובטבלאות נגזרות מקוריות קבועות.

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

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

דיאלקטים נתמכים של מסדי נתונים עבור PDTs

כדי ש-Looker יתמוך ב-PDTs בפרויקט Looker שלך, גם הניב של מסד הנתונים שלך חייב לתמוך בהם.

כדי לתמוך בכל סוג של PDTs (מבוססי LookML או מבוססי SQL), הניב חייב לתמוך בכתיבות למסד הנתונים, בין היתר. ישנן מספר תצורות של מסדי נתונים לקריאה בלבד שאינן מאפשרות ל-persistens לפעול (לרוב מסדי נתונים של רפליקות Postgres עם החלפה חמה). במקרים אלה, ניתן להשתמש במקום זאת בטבלאות נגזרות זמניות.

הטבלה הבאה מציגה את הניבים התומכים בשפה מתמשכתטבלאות נגזרות מבוססות SQL במהדורה האחרונה של 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

כדי לתמוך בטבלאות נגזרות מקוריות מתמשכות (שיש להן שאילתות מבוססות LookML), הניב חייב לתמוך גם בפונקציית DDL של CREATE TABLE. הנה רשימה של הניבים התומכים בטבלאות נגזרות מקוריות (מבוססות LookML) קבועות בגרסה האחרונה של 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

בנייה הדרגתית של PDTs

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

אם שלךדיאלקט תומך ב-PDTs מצטברים, וה-PDT שלך משתמש באסטרטגיית התמדה מבוססת טריגר (datagroup_trigger, sql_trigger_value, אוinterval_trigger ), אתה יכולהגדר את ה-PDT כ-PDT מצטבר.

למידע נוסף, עיין בדף התיעוד של PDTs מצטברים.

דיאלקטים נתמכים של מסדי נתונים עבור PDTs מצטברים

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

יצירת PDTs

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

אסטרטגיות התמדה

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

כדי להפוך טבלה נגזרת לקבועה, הוסף אחד מהפרמטרים הבאים להגדרת derived_table:

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

datagroup_trigger

קבוצות נתונים הן השיטה הגמישה ביותר ליצירת נוכחות (persistens). אם הגדרתם אקבוצת נתונים עִםsql_trigger אוֹinterval_trigger, אתה יכול להשתמש ב-datagroup_trigger פרמטר כדי להתחיל את בנייה מחדש של הטבלאות הנגזרות המתמידות (PDTs) שלך.

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

עיין בסעיף על המחדש של Looker למידע נוסף על אופן בניית ה-PDT.

sql_trigger_value

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

עיין בסעיף על המחדש של Looker למידע נוסף על אופן בניית ה-PDT.

interval_trigger

הinterval_trigger פרמטר מפעיל את היצירה מחדש של טבלה נגזרת מתמשכת (PDT) בהתבסס על מרווח זמן שאתה מספק, כגון"24 hours" אוֹ"60 minutes". בדומה לפרמטר sql_trigger, משמעות הדבר היא שבדרך כלל ה-PDT ייבנה מראש כאשר המשתמשים שלך יבצעו עליו שאילתה. אם משתמש מבקש נתונים מה-PDT בזמן בנייתו, ותוצאות השאילתה אינן נמצאות במטמון, Looker יחזיר נתונים מה-PDT הקיים עד לבניית ה-PDT החדש.

persist_for

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

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

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

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

materialized_view: yes

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

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

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

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

ראה אתmaterialized_view דף תיעוד פרמטרים לקבלת מידע על תמיכה בניב, דרישות ושיקולים חשובים.

אסטרטגיות אופטימיזציה

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

לדוגמה, כדי להוסיף התמדה לדוגמת הטבלה הנגזרת, ניתן להגדיר אותה לבנייה מחדש כאשר קבוצת הנתונים orders_datagroup מופעלת, ולהוסיף אינדקסים גם ב-customer_id וגם ב-first_order, כך:

view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      ...
    }
    datagroup_trigger: orders_datagroup
    indexes: ["customer_id", "first_order"]
  }
}

אם לא תוסיפו אינדקס (או מקביל לדיאלקט שלכם), Looker יזהיר אתכם שעליכם לעשות זאת כדי לשפר את ביצועי השאילתה.

מקרי שימוש עבור PDTs

טבלאות נגזרות מתמידות (PDTs) שימושיות משום שהן יכולות לשפר את ביצועי השאילתה על ידי שמירת תוצאות השאילתה בטבלה.

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

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

בנוסף להפחתת זמן השאילתה ועומס מסד הנתונים בשאילתות הפועלות לעתים קרובות, ישנם מספר מקרי שימוש נוספים עבור PDTs, כולל:

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

שימוש ב-PDTs לבדיקת אופטימיזציות

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

קחו לדוגמה מקרה שבו יש לכם טבלה אך אתם רוצים לבדוק אינדקסים שונים. ה-LookML הראשוני שלך עבור התצוגה עשוי להיראות כך:

view: customer {
  sql_table_name: warehouse.customer ;;
}

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

view: customer {
  # sql_table_name: warehouse.customer
  derived_table: {
    sql: SELECT * FROM warehouse.customer ;;
    persist_for: "8 hours"
    indexes: [customer_id, customer_name, salesperson_id]
  }
}

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

זכור לשנות את קוד התצוגה שלך בחזרה כדי להסיר את ה-PDT.

שימוש ב-PDTs לצירוף מקדים או צבירת נתונים

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

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

view: customer_order_facts {
  derived_table: {
    sql: SELECT
    c.customer_id,
    MIN(o.order_date) OVER (PARTITION BY c.customer_id) AS first_order_date,
    MAX(o.order_date) OVER (PARTITION BY c.customer_id) AS most_recent_order_date,
    COUNT(o.order_id) OVER (PARTITION BY c.customer_id) AS lifetime_orders,
    SUM(o.order_value) OVER (PARTITION BY c.customer_id) AS lifetime_value,
    RANK() OVER (PARTITION BY c.customer_id ORDER BY o.order_date ASC) AS order_sequence,
    o.order_id
    FROM warehouse.customer c LEFT JOIN warehouse.order o ON c.customer_id = o.customer_id
    ;;
    sql_trigger_value: SELECT CURRENT_DATE ;;
    indexes: [customer_id, order_id, order_sequence, first_order_date]
  }
}

טבלאות נגזרות מדורגות

ניתן להפנות לטבלה נגזרת אחת בהגדרה של אחרת, וליצור שרשרת של טבלאות נגזרות מדורגות, או טבלאות נגזרות מתמידות מדורגות (PDTs), לפי העניין. דוגמה לטבלאות נגזרות מדורגות תהיה טבלה, TABLE_D, שתלויה בטבלה אחרת, TABLE_C, בעוד ש-TABLE_C תלויה ב-TABLE_B, ו-TABLE_B תלויה ב-TABLE_A.

תחביר להפניה לטבלה נגזרת

כדי להפנות לטבלה נגזרת בטבלה נגזרת אחרת, השתמש בתחביר הבא:

`${derived_table_or_view_name.SQL_TABLE_NAME}`

בפורמט זה, SQL_TABLE_NAME הוא מחרוזת ליטרלית. לדוגמה, ניתן להפנות לטבלה הנגזרת של clean_events באמצעות התחביר הבא:

`${clean_events.SQL_TABLE_NAME}`

ניתן להשתמש באותו תחביר כדי להתייחס לתצוגת LookML. שוב, במקרה הזה, ה-SQL_TABLE_NAME הוא מחרוזת ליטרלית.

בדוגמה הבאה, ה-PDT של clean_events נוצר מהטבלה events במסד הנתונים. ה-PDT של clean_events משמיט שורות לא רצויות מטבלת מסד הנתונים של events. לאחר מכן מוצג PDT שני; ה-event_summary PDT הוא סיכום של ה-clean_events PDT. הטבלה event_summary מתחדשת בכל פעם שנוספות שורות חדשות ל-clean_events.

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

view: clean_events {
  derived_table: {
    sql:
      SELECT *
      FROM events
      WHERE type NOT IN ('test', 'staff') ;;
    datagroup_trigger: events_datagroup
  }
}

view: events_summary {
  derived_table: {
    sql:
      SELECT
        type,
        date,
        COUNT(*) AS num_events
      FROM
        ${clean_events.SQL_TABLE_NAME} AS clean_events
      GROUP BY
        type,
        date ;;
    datagroup_trigger: events_datagroup
  }
}

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

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

הדוגמה הקודמת עושה זאת:

${clean_events.SQL_TABLE_NAME} AS clean_events

כדאי להשתמש בשם כינוי מכיוון שמאחורי הקלעים, קובצי PDT נקראים עם קודים ארוכים במסד הנתונים שלך. במקרים מסוימים (במיוחד עם משפטי ON) ייתכן לשכוח שצריך להשתמש בתחביר ${derived_table_or_view_name.SQL_TABLE_NAME} כדי לאחזר שם ארוך זה. כינוי יכול לעזור למנוע טעות מסוג זה.

כיצד Looker בונה טבלאות נגזרות מדורגות

במקרה של טבלאות נגזרות זמניות מדורגות, אם תוצאות השאילתה של משתמש אינן נמצאות במטמון, Looker יבנה את כל הטבלאות הנגזרות הדרושות לשאילתה. אם יש לךTABLE_D שֶׁל מִיהגדרה מכילה הפניה אֶלTABLE_C, אזTABLE_D הואתָלוּי עַלTABLE_C. משמעות הדבר היא שאם תבצעו שאילתה ל-TABLE_D והשאילתה אינה נמצאת במטמון של Looker, Looker יבנה מחדש את TABLE_D. אבל קודם כל, עליו לבנות מחדש את TABLE_C.

נבחן תרחיש עם טבלאות נגזרות זמניות מדורגות, כאשר TABLE_D תלוי ב-TABLE_C, שתלוי ב-TABLE_B, שתלוי ב-TABLE_A. אם ל-Looker אין תוצאות תקפות עבור שאילתה על TABLE_C במטמון, Looker יבנה את כל הטבלאות הדרושות לו עבור השאילתה. אז Looker יבנה את TABLE_A, ואז את TABLE_B, ואז את TABLE_C:

בתרחיש זה, TABLE_A חייב לסיים את היצירה לפני ש-Looker יוכל להתחיל לייצר את TABLE_B, ו-TABLE_B חייב לסיים את היצירה לפני ש-Looker יוכל להתחיל לייצר את TABLE_C. כאשר TABLE_C יסיים, Looker יספק את תוצאות השאילתה. (מכיוון ש-TABLE_D אינו נחוץ כדי לענות על שאילתה זו, Looker לא יבנה מחדש את TABLE_D כרגע.)

ראה אתdatagroup דף תיעוד פרמטרים עבור תרחיש לדוגמה של PDTs מדורגים המשתמשים באותה קבוצת נתונים.

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

נקודה לוגית חשובה להבנה היא שבמקרה של רצף PDT, PDT תלוי בעצם מבצע שאילתה על ה-PDT שהוא תלוי בו. זה משמעותי במיוחד עבור PDTs המשתמשים ב-persist_for אִסטרָטֶגִיָה. בדרך כלל, קובצי PDT של persist_for נבנים כאשר משתמש מבצע עליהם שאילתה, נשארים במסד הנתונים עד לסיום מרווח הזמן של persist_for שלהם, ולאחר מכן אינם נבנים מחדש עד לשלב הבא שבו משתמש מבצע עליהם שאילתה. עם זאת, אם אpersist_for PDT הוא חלק ממסלול מפל עם PDTs מבוססי טריגר (PDTs המשתמשים ב-datagroup_trigger, interval_trigger, אוsql_trigger_value אסטרטגיית ההתמדה), הpersist_for PDT למעשה נשאלת בכל פעם ש-PDTs התלויים בו נבנים מחדש. לכן, במקרה זה, ה-PDT של persist_for ייבנה מחדש לפי לוח הזמנים של ה-PDTs התלויים בו. משמעות הדבר היא ש-persist_for PDTs עלולים להיות מושפעים מאסטרטגיית ההתמדה של התלויים בהם.

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

בנייה מחדש ידנית של טבלאות מתמידות עבור שאילתה

משתמשים יכולים לבחור באפשרות בנייה מחדש של טבלאות נגזרות והרצה מתפריט של Explore כדי לעקוף את הגדרות ההתמדה ולבנות מחדש את כל הטבלאות הנגזרות המתמידות (PDTs) ואת טבלאות הצבירה הנדרשות לשאילתה הנוכחית ב-Explore:

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

אפשרות זו גלויה רק ​​למשתמשים עםdevelop הרשאה, ורק לאחר טעינת שאילתת ה-Explore.

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

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

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

אם table_c תלוי ב- table_b, ו- table_b תלוי ב- table_a, אז בנייה מחדש של table_c תחילה בונה מחדש את table_a, לאחר מכן את table_b, ולבסוף את table_c.

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

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

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

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

טבלאות שנשמרו במצב פיתוח

ל-Looker יש כמה התנהגויות מיוחדות לניהול טבלאות מתמשכות במצב פיתוח.

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

מה גורם ל-Looker ליצור טבלת פיתוח

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

  • אם לטבלה המתמשכת שלך יש פרמטר שמצמצם את מערך הנתונים שלה כדי לעבוד מהר יותר במצב פיתוח
  • אם ביצעת שינויים בהגדרת הטבלה השמורה שלך המשפיעים על הנתונים בטבלה

Looker יבנה טבלת פיתוח אם אתה במצב פיתוח ואתה מבצע שאילתה על טבלה נגזרת מבוססת SQL המוגדרת באמצעות פסוקית מותנית WHERE עם משפטי if prod ו-if dev.

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

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

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

כמה זמן Looker ממשיך לשמור על טבלאות פיתוח

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

אחרת, Looker בונה טבלאות נגזרות מתמידות (PDTs) וטבלאות צבירה במצב פיתוח באותו אופן שהוא בונה טבלאות מתמידות במצב ייצור.

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

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

  • אם עברו יותר מ-24 שעות מאז ששלחת שאילתה לטבלה במצב פיתוח, גרסת הפיתוח של הטבלה תסומן כגרסת פג תוקף ולא תשמש לשאילתות. ניתן לבדוק אם יש PDTs שלא בנויים באמצעות ה-Looker IDE או באמצעות הכרטיסייה פיתוח בדף טבלאות נגזרות מתמידות. אם יש לך טבלת PDT שלא בנויה, תוכל לבצע שאילתה עליה במצב פיתוח ממש לפני ביצוע השינויים, כך שטבלת הפיתוח תהיה זמינה לשימוש בייצור.
  • אם בטבלה קבועה מוגדר הפרמטר dev_filters (במקרה של טבלאות נגזרות מקוריות) או פסקה מותנית conditional WHERE שמשתמשת בהצהרות if prod ו-if dev (במקרה של טבלאות נגזרות מבוססות-SQL), אי אפשר להשתמש בטבלת הפיתוח כגרסת הייצור, כי גרסת הפיתוח היא מערך נתונים מקוצר. אם זה המצב, אחרי שמסיימים לפתח את הטבלה ולפני שמפעילים את השינויים, אפשר להוסיף הערה לפרמטר dev_filters או לתנאי WHERE ואז לשלוח שאילתה לטבלה במצב פיתוח. לאחר מכן, Looker ייצור גרסה מלאה של הטבלה שאפשר להשתמש בה בייצור כשפורסים את השינויים.

אחרת, אם אתם פורסים את השינויים כשאין טבלת פיתוח תקינה שאפשר להשתמש בה כטבלת הייצור, Looker יבנה מחדש את הטבלה בפעם הבאה שתתבצע שאילתה בטבלה במצב ייצור (במקרה של טבלאות שנשמרו ומשתמשות באסטרטגיה persist_for), או בפעם הבאה שהכלי ליצירה מחדש יפעל (במקרה של טבלאות שנשמרו ומשתמשות באסטרטגיה datagroup_trigger,‏ interval_trigger או sql_trigger_value).

בדיקה של PDTs שלא נבנו במצב פיתוח

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

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

אפשר לבדוק אם יש בפרויקט PDT שלא נבנו בחלונית Project Health (תקינות הפרויקט). לוחצים על הסמל Project Health (תקינות הפרויקט) ב-Looker IDE כדי לפתוח את החלונית Project Health. לאחר מכן לוחצים על הלחצן אימות סטטוס PDT.

אם יש טבלאות PDT שלא נוצרו, הן יופיעו בחלונית Project Health:

בחלונית Project Health מוצגת רשימה של PDT שלא נבנו בפרויקט, וגם לחצן Go to PDT Management.

אם יש לכם הרשאה see_pdts, אתם יכולים ללחוץ על הלחצן מעבר לניהול PDT. מערכת Looker תפתח את הכרטיסייה Development בדף Persistent Derived Tables ותסנן את התוצאות לפי פרויקט LookML הספציפי שלכם. משם אפשר לראות אילו PDT פותחו ואילו לא, וגם לגשת למידע נוסף לפתרון בעיות. מידע נוסף זמין בדף התיעוד בנושא הגדרות אדמין – טבלאות נגזרות קבועות.

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

שיתוף וניקוי של טבלאות

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

יש לכך מספר יתרונות:

  • אם לא ביצעת שינויים בטבלה במצב פיתוח, השאילתות שלך ישתמשו בטבלאות הייצור הקיימות. זהו המקרה אלא אם כן הטבלה שלך היא טבלה נגזרת מבוססת SQL המוגדרת באמצעות פסוקית מותנית WHERE עם משפטי if prod ו-if dev. אם הטבלה מוגדרת עם פסוקית מותנית WHERE, Looker יבנה טבלת פיתוח אם תבצע שאילתה על הטבלה במצב פיתוח. (עֲבוּרטבלאות נגזרות מקוריות עם ה-dev_filters (פרמטר, ל-Looker יש את ההיגיון להשתמש בטבלת הייצור כדי לענות על שאילתות במצב פיתוח, אלא אם כן משנים את הגדרת הטבלה ולאחר מכן מבצעים שאילתה על הטבלה במצב פיתוח.)
  • אם שני מפתחים מבצעים את אותו שינוי בטבלה במצב פיתוח, הם יחלקו את אותה טבלת פיתוח.
  • לאחר שתעביר את השינויים שלך ממצב פיתוח למצב ייצור, הגדרת הייצור הישנה לא קיימת עוד, כך שטבלת הייצור הישנה תסומן שפג תוקפו ותבוטל.
  • אם תחליט לזרוק את השינויים במצב הפיתוח שלך, הגדרת הטבלה הזו לא קיימת עוד, כך שטבלאות הפיתוח המיותרות יסומנו כטבלאות שפג תוקפן ויבוטלו.

עבודה מהירה יותר במצב פיתוח

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

עֲבוּרטבלאות נגזרות מקוריות, אתה יכול להשתמש ב-dev_filters תת-פרמטר שלexplore_source כדי לציין מסננים שיוחלו רק על גרסאות פיתוח של הטבלה הנגזרת:

view: e_faa_pdt {
  derived_table: {
  ...
    datagroup_trigger: e_faa_shared_datagroup
    explore_source: flights {
      dev_filters: [flights.event_date: "90 days"]
      filters: [flights.event_date: "2 years", flights.airport_name: "Yucca Valley Airport"]
      column: id {}
      column: airport_name {}
      column: event_date {}
    }
  }
...
}

דוגמה זו כוללת פרמטר dev_filters שמסנן את הנתונים ל-90 הימים האחרונים ופרמטר filters שמסנן את הנתונים לשנתיים האחרונות ולשדה התעופה יוקה ואלי.

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

עבור טבלאות נגזרות מבוססות SQL, Looker תומך בסעיף מותנה WHERE עם אפשרויות שונות עבור גרסאות ייצור (if prod) ופיתוח (if dev) של הטבלה:

view: my_view {
  derived_table: {
    sql:
      SELECT
        columns
      FROM
        my_table
      WHERE
        -- if prod -- date > '2000-01-01'
        -- if dev -- date > '2020-01-01'
      ;;
  }
}

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

כיצד Looker בונה PDTs

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

  1. השתמש ב-SQL של ​​הטבלה הנגזרת כדי ליצור משפט CREATE TABLE AS SELECT (או CTAS) ולהפעיל אותו. לדוגמה, כדי לבנות מחדש PDT בשם customer_orders_facts: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
  2. הנפק את ההצהרות ליצירת האינדקסים כאשר הטבלה נבנית
  3. שנה את שם הטבלה מ-LC$.. ("Looker Create") ל-LR$.. ("Looker Read"), כדי לציין שהטבלה מוכנה לשימוש.
  4. השמט כל גרסה ישנה יותר של הטבלה שאינה אמורה להיות בשימוש עוד

ישנן כמה השלכות חשובות:

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

המחדש של Looker

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

  • עבור טבלאות המשתמשותsql_trigger_value, הטריגר הוא שאילתה שצוינה בטבלהsql_trigger_value פָּרָמֶטֶר. מחולל ה-Looker מפעיל בנייה מחדש של הטבלה כאשר תוצאת בדיקת שאילתת הטריגר האחרונה שונה מתוצאת בדיקת שאילתת הטריגר הקודמת. לדוגמה, אם הטבלה הנגזרת שלך נשמרת עם שאילתת ה-SQL SELECT CURDATE(), מחולל ה-Looker יבנה מחדש את הטבלה בפעם הבאה שהמחולל יבדוק את הטריגר לאחר שינוי התאריך.
  • עבור טבלאות המשתמשותinterval_trigger, הטריגר הוא משך זמן שצוין בטבלהinterval_trigger פָּרָמֶטֶר. מחולל ה-Looker מפעיל בנייה מחדש של הטבלה לאחר חלוף הזמן שצוין.
  • עבור טבלאות המשתמשותdatagroup_trigger, הטריגר יכול להיות שאילתה שצוינה בקבוצת הנתונים המשויכתsql_trigger פרמטר, או שהטריגר יכול להיות משך זמן שצוין בקבוצת הנתוניםinterval_trigger פָּרָמֶטֶר.

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

בנוסף, יוצר ה-Looker regeneratorמודלים אנליטיים במסד הנתונים שלך, אם הגדרת את המודל האנליטי באמצעות ה-derived_analytic_model פָּרָמֶטֶר. מנגנון ה-Looker מעבד מודלים אנליטיים נגזרים בדומה ל-PDTs שהם תצוגות ממומשות. גם תצוגות ממומשות וגם מודלים אנליטיים נגזרים נוצרים פעם אחת בלבד ואינם תומכים בטריגרים, כגון טריגרים של קבוצת נתונים, טריגרים של SQL או טריגרים של מרווחי זמן. מחולל ה-Looker יוצר מחדש מודלים אנליטיים במסד הנתונים שלך רק אם הגדרת ה-LookML שלהם משתנה או אם אחת מתצוגות ה-LookML שהן תלויות בהן משתנה.

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

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

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

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

שיקולים חשובים ליישום טבלאות מתמשכות

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

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

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

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

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

  • מתי טבלאות נגזרות יורחבו - כל הרחבה של PDT תיצור עותק חדש של הטבלה במסד הנתונים שלך.
  • כאשר טבלאות נגזרות משתמשות במסננים מבוססי תבניות או בפרמטרים של Liquid - שמירה על ערך קבוע אינה נתמכת עבור טבלאות נגזרות המשתמשות במסננים מבוססי תבניות או בפרמטרים של Liquid.
  • כַּאֲשֵׁרטבלאות נגזרות מקוריות בנויים מ-Explores המשתמשיםתכונות משתמש עִםaccess_filters, או עםsql_always_where — עותקים של הטבלה ייבנו במסד הנתונים שלך עבור כל ערך מאפיין משתמש אפשרי שצוין.
  • כאשר הנתונים הבסיסיים משתנים לעתים קרובות והדיאלקט של מסד הנתונים שלך אינו תומך ב-PDTs מצטברים.
  • כאשר העלות והזמן הכרוכים ביצירת PDTs גבוהים מדי.

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

ניהול PDTs בקנה מידה גדול באמצעות API

ניטור וניהול של טבלאות נגזרות מתמידות (PDTs) שמתרעננות בלוחות זמנים משתנים הופכים למורכבים יותר ויותר ככל שיוצרים יותר PDTs במופע שלך. שקלו להשתמש ב-אינטגרציה של Apache Airflow עם Looker כדי לנהל את לוחות הזמנים של PDT לצד תהליכי ETL ו-ELT אחרים שלכם.

ניטור ופתרון בעיות PDT

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

בעת ניסיון לפתור בעיות ב-PDT:

  • שימו לב במיוחד להבדל בין טבלאות פיתוח לטבלאות ייצור בעת בדיקת יומן אירועי PDT.
  • ודא שההגדרה Temp Database בחיבור Looker שלך תואמת את סכימת ה-scratch או מסד הנתונים שלך בפועל. אם ההגדרה Temp Database בחיבור אינה תואמת לסכימת הגרסה הקודמת במסד הנתונים שלך, עדכן את ההגדרה Temp Database כך ש-Looker יוכל לאחסן טבלאות נגזרות קבועות במסד הנתונים שלך.
  • קבע אם יש בעיות בכל ה-PDTs, או רק באחד. אם יש בעיה עם אחד מהם, סביר להניח שהבעיה נגרמת משגיאת LookML או SQL.
  • קבע אם בעיות עם ה-PDT תואמות את הזמנים שבהם הוא מתוכנן לשקם אותו.
  • ודא שכלsql_trigger_value שאילתות מוערכות בהצלחה ושהן מחזירות שורה ועמודה אחת בלבד. עבור PDTs מבוססי SQL, ניתן לעשות זאת על ידי הרצתם ב-SQL Runner. (החלת LIMIT מגנה מפני שאילתות בוחנות.) למידע נוסף על שימוש ב-SQL Runner לאיתור באגים בטבלאות נגזרות, עיין בפוסט הקהילתי שימוש ב-SQL Runner לבדיקת טבלאות נגזרות .
  • עבור PDTs מבוססי SQL, השתמש ב-SQL Runner כדי לוודא שה-SQL של ​​ה-PDT מבוצע ללא שגיאות. (יש לוודא שהפעלת LIMIT ב-SQL Runner תישמר זמני שאילתה סבירים.)
  • עבור טבלאות נגזרות מבוססות SQL, הימנעו משימוש בביטויי טבלה נפוצים (CTEs). שימוש ב-CTEs עם DTs יוצר משפטי WITH מקוננים שעלולים לגרום לכשל של PDTs ללא אזהרה. במקום זאת, השתמש ב-SQL עבור ה-CTE שלך כדי ליצור DT משני והפנה ל-DT הזה מה-DT הראשון שלך באמצעות ה-${derived_table_or_view_name.SQL_TABLE_NAME} תַחבִּיר.
  • בדוק שכל הטבלאות שעליהן תלוי ה-PDT הבעייתי - בין אם טבלאות רגילות או PDTs עצמם - קיימות וניתנות לשאילתה עליהן.
  • ודא שכל הטבלאות שעליהן תלוי ה-PDT הבעייתי אינן כוללות נעילות משותפות או בלעדיות. כדי ש-Looker יבנה בהצלחה PDT, הוא צריך לרכוש מנעול בלעדי על השולחן שצריך לעדכן. זה יתנגש עם מנעולים משותפים או בלעדיים אחרים שנמצאים על השולחן. Looker לא יוכל לעדכן את ה-PDT עד שכל שאר המנעולים ינוקו. אותו הדבר נכון לגבי כל נעילה בלעדית בטבלה שממנה Looker בונה PDT; אם יש נעילה בלעדית בטבלה, Looker לא יוכל לרכוש נעילה משותפת כדי להריץ שאילתות עד שהנעילה הבלעדית תתבהר.
  • השתמשו בלחצן הצג תהליכים ב-SQL Runner. אם יש מספר רב של תהליכים פעילים, הדבר עלול להאט את זמני השאילתות.
  • מעקב אחר הערות בשאילתה. עיין בקטע הערות שאילתה עבור PDTs בדף זה.

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

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

  • אם נתקלת בשגיאת 409 Conflict במהלך רענון PDT במבני PDT מקוננים עמוק (שרשראות של PDTs מדורגים עם רמות תלות מרובות), עיין בסעיף פתרון בעיות של שגיאות התנגשות 409 במבני PDT מקוננים עמוק בדף זה.

הערות שאילתה עבור PDTs

מנהלי מסדי נתונים יכולים להבדיל בין שאילתות רגילות לבין שאילתות שמייצרות טבלאות נגזרות מתמשכות (PDTs). Looker מוסיף הערות למשפט CREATE TABLE ... AS SELECT ... הכוללות את המודל והתצוגה של LookML של ה-PDT, בנוסף למזהה ייחודי (slug) עבור מופע Looker. אם ה-PDT נוצר מטעם משתמש במצב פיתוח, ההערות יציינו את מזהה המשתמש. הערות דור ה-PDT עוקבות אחר התבנית הבאה:

-- Building `<view_name>` in dev mode for user `<user_id>` on instance `<instance_slug>`
CREATE TABLE `<table_name>` SELECT ...
-- finished `<view_name>` => `<table_name>`

הערה ליצירת PDT תופיע בכרטיסיית SQL של ​​Explore אם Looker היה צריך ליצור PDT עבור שאילתת ה-Explore. ההערה תופיע בראש משפט ה-SQL.

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

בנייה מחדש של PDTs לאחר כשל

כאשר בטבלה נגזרת מתמשכת (PDT) יש כשל, כך מתרחשת שאילתה על ה-PDT הזה:

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

עם PDTs מדורגים, אותו היגיון חל, אלא שעם PDTs מדורגים:

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

נחזור על הדוגמה הקודמת של טבלאות מדורגות, כאשר TABLE_D תלוי ב-TABLE_C, שתלוי ב-TABLE_B, שתלוי ב-TABLE_A:

אם יש כשל ב-TABLE_B, כל ההתנהגות הסטנדרטית (לא מדורגת) תחול על TABLE_B:

  1. אם נשלח שאילתה ל-TABLE_B, Looker ינסה תחילה להשתמש במטמון כדי להחזיר תוצאות.
  2. אם ניסיון זה נכשל, Looker ינסה להשתמש בגרסה קודמת של הטבלה, אם אפשר.
  3. אם גם ניסיון זה נכשל, לוקר ינסה לבנות מחדש את הטבלה.
  4. לבסוף, אם לא ניתן לבנות מחדש את TABLE_B, Looker יחזיר שגיאה.

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

אותו הדבר חל גם על התלויים של TABLE_B. אז אם לא ניתן לבנות את TABLE_B, ויש שאילתה על TABLE_C, מתרחש הרצף הבא:

  1. Looker ינסה להשתמש במטמון עבור השאילתה ב-TABLE_C.
  2. אם התוצאות אינן במטמון, Looker ינסה לשלוף תוצאות מ-TABLE_C במסד הנתונים.
  3. אם אין גרסה תקפה של TABLE_C, Looker ינסה לבנות מחדש את TABLE_C, מה שיוצר שאילתה ב-TABLE_B.
  4. לאחר מכן, Looker ינסה לבנות מחדש את TABLE_B (מה שייכשל אם TABLE_B לא תוקן).
  5. אם לא ניתן לבנות מחדש את TABLE_B, אז גם את TABLE_C לא ניתן לבנות מחדש, ולכן Looker יחזיר שגיאה עבור השאילתה ב-TABLE_C.
  6. לאחר מכן, Looker ינסה לבנות מחדש את TABLE_C בהתאם לאסטרטגיית ההתמדה הרגילה שלו, או בפעם הבאה ש-PDT ייבדק (כולל הפעם הבאה ש-TABLE_D ינסה לבנות, מכיוון ש-TABLE_D תלוי ב-TABLE_C).

לאחר שתפתור את הבעיה עם TABLE_B, TABLE_B וכל אחת מהטבלאות התלויות ינסו להיבנות מחדש בהתאם לאסטרטגיות ההתמדה שלהן, או בפעם הבאה שתישאל עליהן (כולל הפעם הבאה ש-PDT תלוי ינסה להיבנות מחדש). לחלופין, אם גרסת פיתוח של ה-PDTs ב-Cascade נבנתה במצב פיתוח, ניתן להשתמש בגרסאות הפיתוח כ-PDTs הייצור החדשים. (ראה את הקטע טבלאות מתמשכות במצב פיתוח בדף זה כדי לקבל מידע על אופן הפעולה.) לחלופין, ניתן להשתמש ב-Explore כדי להריץ שאילתה על TABLE_D ולאחר מכן לבנות מחדש באופן ידני את קבצי ה-PDT עבור השאילתה, מה שיאלץ בנייה מחדש של כל קבצי ה-PDT העולים במפל התלות.

פתרון בעיות של שגיאות התנגשות 409 ב-PDTs מקוננים עמוק

כשעובדים עם מבני PDT מקוננים עמוק (שרשראות של PDTs מדורגים עם רמות תלות מרובות), הגדרת תקופות שמירת מטמון קצרות (לדוגמה, 15 דקות) עלולה לגרום למצב מרוץ שמוביל לשגיאת 409 Conflict במהלך רענון.

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

כדי לפתור או למנוע שגיאה זו, השתמש בשיטות העבודה המומלצות הבאות:

  • הגדלת תקופת שמירת המטמון: הגדר את תקופת שמירת המטמון (max_cache_age אוֹpersist_for ) עבור ה-PDTs לפחות פי שניים עד שלושה מהזמן המקסימלי שלוקח להשלמת הבנייה המלאה של כל ה-PDTs המקוננים.
  • הגדלת מרווח הרענון של קבוצת הנתונים: יש לאפשר זמן מספיק לסיום בניית PDT מקוננת עמוקה, מה שמפחית את הסיכון לתהליכי בנייה חופפים.

שיפור ביצועי PDT

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

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

הוספת מסננים להגבלת מערך הנתונים

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

באמצעות indexes או sortkeys ו-distribution

כשיוצרים טבלה נגזרת מתמשכת (PDT) גדולה, אינדוקס הטבלה (עבור דיאלקטים כמו MySQL או Postgres) או הוספת מקשי מיון והפצה (עבור Redshift) יכולים לסייע בביצועים.

בדרך כלל עדיף להוסיף אתindexes פרמטר בשדות מזהה או תאריך.

עבור הסחה לאדום, בדרך כלל עדיף להוסיף אתsortkeys פרמטר בשדות מזהה או תאריך ו-distribution פרמטר בשדה המשמש לצירוף.

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

  • עבור הסחה לאדום ואסטר, השתמשו ב-distribution פרמטר כדי לציין את שם העמודה שערכו משמש לפיזור הנתונים ברחבי אשכול. כאשר שתי טבלאות מחוברות על ידי העמודה שצוינה בפרמטר distribution, מסד הנתונים יכול למצוא את נתוני הצירוף באותו צומת, כך שקלט/פלט בין הצמתים ממוזער.
  • עבור הסחה לאדום, הגדר אתdistribution_style פרמטר לall כדי להורות למסד הנתונים לשמור עותק מלא של הנתונים בכל צומת. זה משמש לעתים קרובות כדי למזער קלט/פלט בין-צמתים כאשר מצטרפים טבלאות קטנות יחסית. הגדר ערך זה ל-even כדי להורות למסד הנתונים לפזר את הנתונים באופן שווה ברחבי האשכול מבלי להשתמש בעמודת חלוקה. ניתן לציין ערך זה רק כאשר לא צוין distribution.
  • עבור הסחה לאדום, השתמש ב-sortkeys פָּרָמֶטֶר. הערכים מציינים אילו עמודות של ה-PDT משמשות למיון הנתונים בדיסק כדי להקל על החיפוש. ב-Redshift, ניתן להשתמש ב-sortkeys או ב-indexes, אך לא בשניהם.
  • ברוב מסדי הנתונים, השתמש ב-indexes פָּרָמֶטֶר. הערכים מציינים אילו עמודות של ה-PDT מאונדקסות. (ב-Redshift, אינדקסים משמשים ליצירת מפתחות מיון משולבים.)