Abgeleitete Tabellen in Looker

In Looker ist eine abgeleitete Tabelle eine Abfrage, deren Ergebnisse wie eine tatsächliche Tabelle in der Datenbank verwendet werden.

Angenommen, Sie haben eine Datenbanktabelle namens orders mit vielen Spalten. Sie möchten einige aggregierte Kennzahlen auf Kundenebene berechnen, wie zum Beispiel die Anzahl der von den einzelnen Kunden platzierten Aufträge oder den Zeitpunkt des ersten Auftrags der verschiedenen Kunden. Mit einer nativen abgeleiteten Tabelle oder einer SQL-basierten abgeleiteten Tabelle können Sie eine neue Datenbanktabelle mit dem Namen customer_order_summary erstellen, die diese Messwerte enthält.

Sie können dann mit der abgeleiteten Tabelle customer_order_summary wie mit jeder anderen Tabelle in der Datenbank arbeiten.

Beliebte Anwendungsfälle für abgeleitete Tabellen finden Sie in Looker-Cookbooks: Abgeleitete Tabellen in Looker optimal nutzen.

Native abgeleitete Tabellen und SQL-basierte abgeleitete Tabellen

Verwenden Sie den Parameter derived_table unter einem view-Parameter, um eine abgeleitete Tabelle in Ihrem Looker-Projekt zu erstellen. Innerhalb des Parameters derived_table können Sie die Abfrage für die abgeleitete Tabelle auf zwei Arten definieren:

• Bei einer nativen abgeleiteten Tabelle definieren Sie die abgeleitete Tabelle mit einer LookML-basierten Abfrage.
• Bei einer SQL-basierten abgeleiteten Tabelle definieren Sie die abgeleitete Tabelle mit einer SQL-Abfrage.

Die folgenden Ansichtsdateien zeigen beispielsweise, wie Sie mit LookML eine Ansicht aus einer abgeleiteten customer_order_summary-Tabelle erstellen können. Die zwei Versionen der LookML veranschaulichen, wie Sie äquivalente abgeleitete Tabellen mit LookML oder SQL erstellen können, um die Abfrage für die abgeleitete Tabelle zu definieren:

• Die native abgeleitete Tabelle definiert die Abfrage mit LookML im Parameter explore_source. In diesem Beispiel basiert die Abfrage auf einer vorhandenen orders-Ansicht, die in einer separaten Datei definiert ist. In diesem Beispiel ist dies nicht der Fall. Die Abfrage explore_source in der nativen abgeleiteten Tabelle gibt die Felder customer_id, first_order und total_amount aus der Ansichtsdatei orders ein.
• Die SQL-basierte abgeleitete Tabelle definiert die Abfrage mithilfe von SQL im Parameter sql. In diesem Beispiel ist die SQL-Abfrage eine direkte Abfrage der Tabelle orders in der Datenbank.

Version der nativen abgeleiteten Tabelle

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

Version der SQL-basierten abgeleiteten Tabelle

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

Beide Versionen erstellen eine Ansicht mit dem Namen customer_order_summary, die auf der Tabelle orders mit den Spalten customer_id, first_order, und total_amount basiert.

Abgesehen vom Parameter derived_table und den zugehörigen Unterparametern funktioniert diese customer_order_summary-Ansicht wie jede andere Ansichtsdatei. Unabhängig davon, ob Sie die Abfrage der abgeleiteten Tabelle mit LookML oder SQL definieren, können Sie LookML-Messwerte und -Dimensionen erstellen, die auf den Spalten der abgeleiteten Tabelle basieren.

Nachdem Sie die abgeleitete Tabelle definiert haben, können Sie sie wie jede andere Tabelle in der Datenbank verwenden.

Native abgeleitete Tabellen

Native abgeleitete Tabellen basieren auf Abfragen, die Sie mit LookML-Begriffen definieren. Wenn Sie eine native abgeleitete Tabelle erstellen möchten, verwenden Sie den Parameter explore_source innerhalb des Parameters derived_table eines View-Parameters. Sie erstellen die Spalten der nativen abgeleiteten Tabelle, indem Sie die LookML-Dimensionen oder -Messwerte in Ihrem Modell referenzieren. Sehen Sie sich die Ansichtsdatei für die native abgeleitete Tabelle im vorherigen Beispiel an.

Im Vergleich zu SQL-basierten abgeleiteten Tabellen sind native abgeleitete Tabellen bei der Modellierung Ihrer Daten wesentlich leichter zu lesen und zu verstehen.

Weitere Informationen zum Erstellen nativer abgeleiteter Tabellen finden Sie auf der Dokumentationsseite Native abgeleitete Tabellen erstellen.

SQL-basierte abgeleitete Tabellen

Um eine SQL-basierte abgeleitete Tabelle zu erstellen, definieren Sie eine Abfrage in SQL-Begriffen und erstellen Spalten in der Tabelle mit einer SQL-Abfrage. In einer SQL-basierten abgeleiteten Tabelle sind keine Verweise auf LookML-Dimensionen und -Messwerte möglich. Sehen Sie sich die Ansichtsdatei für SQL-basierte abgeleitete Tabellen im vorherigen Beispiel an.

Am häufigsten definieren Sie die SQL-Abfrage mit dem Parameter sql im Parameter derived_table eines view-Parameters.

Eine hilfreiche Verknüpfung zum Erstellen von SQL-basierten Abfragen in Looker besteht darin, die SQL-Abfrage mit SQL Runner zu erstellen und in eine Definition für abgeleitete Tabellen umzuwandeln.

In bestimmten Grenzfällen ist die Verwendung des sql-Parameters nicht zulässig. In solchen Fällen unterstützt Looker die folgenden Parameter zum Definieren einer SQL-Abfrage für nichtflüchtige abgeleitete Tabellen (PDTs):

• create_process: Wenn Sie den Parameter sql für eine PDT verwenden, umschließt Looker im Hintergrund die CREATE TABLE DDL-Anweisung (Data Definition Language) des Dialekts um Ihre Abfrage, um die PDT aus der SQL-Abfrage zu erstellen. Einige Dialekte unterstützen keine SQL-CREATE TABLE-Anweisungen in einem einzelnen Schritt. Für diese Dialekte können Sie keine PAT mit dem Parameter sql erstellen. Stattdessen können Sie den Parameter create_process verwenden, um eine PDT in mehreren Schritten zu erstellen. Informationen und Beispiele finden Sie auf der Dokumentationsseite zum Parameter create_process.
• sql_create: Wenn für Ihren Anwendungsfall benutzerdefinierte DDL-Befehle erforderlich sind und Ihr Dialekt DDL unterstützt (z. B. BigQuery ML, der vorausschauend von Google), können Sie mit dem Parameter sql_create eine PDT erstellen, anstatt den Parameter sql zu verwenden. Informationen und Beispiele finden Sie auf der Dokumentationsseite zu sql_create.

Unabhängig davon, ob Sie den Parameter sql, create_process oder sql_create verwenden, definieren Sie in allen diesen Fällen die abgeleitete Tabelle mit einer SQL-Abfrage. Sie werden also alle als SQL-basierte abgeleitete Tabellen betrachtet.

Achten Sie beim Definieren einer SQL-basierten abgeleiteten Tabelle darauf, jeder Spalte mithilfe von AS einen sauberen Alias zuzuweisen. Das liegt daran, dass Sie in Ihren Dimensionen auf die Spaltennamen Ihrer Ergebnismenge verweisen müssen, z. B. ${TABLE}.first_order. Aus diesem Grund wird im vorherigen Beispiel MIN(DATE(time)) AS first_order statt MIN(DATE(time)) verwendet.

Hinweis: Damit eine SQL-basierte abgeleitete Tabelle als inkrementelle PAT verwendet werden kann, muss sie mit dem Parameter sql definiert werden. SQL-basierte abgeleitete Tabellen, die mit dem Parameter sql_create oder dem Parameter create_process definiert sind, können nicht inkrementell erstellt werden.

Temporäre und persistente abgeleitete Tabellen

Es wird nicht nur zwischen nativen abgeleiteten Tabellen und SQL-basierten abgeleiteten Tabellen unterschieden, sondern auch zwischen einer temporären abgeleiteten Tabelle, die nicht in die Datenbank geschrieben wird, und einer nichtflüchtigen abgeleiteten Tabelle (PDT), die in ein Schema der Datenbank geschrieben wird.

Native abgeleitete Tabellen und SQL-basierte abgeleitete Tabellen können entweder temporär oder persistent sein.

Temporäre abgeleitete Tabellen

Die vorherigen abgeleiteten Tabellen sind Beispiele für temporäre abgeleitete Tabellen. Sie sind vorübergehend, da für den Parameter derived_table keine Persistenzstrategie definiert ist.

Temporäre abgeleitete Tabellen werden nicht in die Datenbank geschrieben. Wenn ein Benutzer eine Explore-Abfrage ausführt, die eine oder mehrere abgeleitete Tabellen umfasst, erstellt Looker eine SQL-Abfrage mithilfe einer Dialekt-spezifischen Kombination aus SQL für die abgeleiteten Tabelle(n) plus den angeforderten Feldern, Joins und Filterwerten. Wenn die Kombination schon einmal ausgeführt wurde und die Ergebnisse im Cache noch gültig sind, verwendet Looker die Ergebnisse aus dem Cache. Weitere Informationen zum Abfrage-Caching in Looker finden Sie auf der Dokumentationsseite Caching-Abfragen.

Wenn Looker keine im Cache gespeicherten Ergebnisse verwenden kann, muss Looker jedes Mal eine neue Abfrage in Ihrer Datenbank ausführen, wenn ein Nutzer Daten aus einer temporären abgeleiteten Tabelle anfordert. Aus diesem Grund sollten Sie darauf achten, dass Ihre temporären abgeleiteten Tabellen leistungsstark sind und Ihre Datenbank nicht übermäßig belasten. Wenn das Ausführen der Abfrage einige Zeit in Anspruch nimmt, ist ein PDT oft die bessere Option.

Unterstützte Datenbankdialekte für temporäre abgeleitete Tabellen

Damit Looker abgeleitete Tabellen in Ihrem Looker-Projekt unterstützen kann, müssen diese auch von Ihrem Datenbankdialekt unterstützt werden. Die folgende Tabelle zeigt, welche Dialekte abgeleitete Tabellen in der neuesten Version von Looker unterstützen:

Dialekt	Unterstützt?
Lawine Actian	Ja
Amazon Athena	Ja
Amazon Aurora MySQL	Ja
Amazon Redshift	Ja
Apache Druid	Ja
Apache Druid 0.13 und höher	Ja
Apache Druid 0.18 und höher	Ja
Apache Hive 2.3+	Ja
Apache Hive 3.1.2+	Ja
Apache Spark 3 und höher	Ja
ClickHouse	Ja
Cloudera Impala 3.1+	Ja
Cloudera Impala 3.1+ mit nativem Treiber	Ja
Cloudera Impala mit nativem Fahrer	Ja
DataVirtuality	Ja
Databricks	Ja
Denodo 7	Ja
Denodo 8	Ja
Dremio	Ja
Dremio 11+	Ja
Exasol	Ja
Firebolt	Ja
Legacy-SQL von Google BigQuery	Ja
Google BigQuery-Standard-SQL	Ja
Google Cloud PostgreSQL	Ja
Google Cloud SQL	Ja
Google Spanner	Ja
Grünpflaumen	Ja
HyperSQL	Ja
IBM Netezza	Ja
MariaDB	Ja
Microsoft Azure PostgreSQL	Ja
Microsoft Azure SQL-Datenbank	Ja
Microsoft Azure Synapse-Analyse	Ja
Microsoft SQL Server 2008 und höher	Ja
Microsoft SQL Server 2012 und höher	Ja
Microsoft SQL Server 2016	Ja
Microsoft SQL Server 2017 und höher	Ja
MongoBI	Ja
MySQL	Ja
MySQL 8.0.12 oder höher	Ja
Oracle	Ja
Oracle ADWC	Ja
PostgreSQL 9.5 oder höher	Ja
PostgreSQL vor Version 9.5	Ja
PrestoDB	Ja
PrestoSQL	Ja
SAP HANA 2+	Ja
SingleStore	Ja
SingleStore 7+	Ja
Snowflake	Ja
Teradata	Ja
Trino	Ja
Vektor	Ja
Vertica	Ja

Persistente abgeleitete Tabellen

Eine persistente abgeleitete Tabelle (PDT) ist eine abgeleitete Tabelle, die in ein Scratch-Schema in Ihrer Datenbank geschrieben und nach dem Zeitplan neu generiert wird, den Sie mit einer Persistenzstrategie festlegen.

Eine PAT kann entweder eine native abgeleitete Tabelle oder eine SQL-basierte abgeleitete Tabelle sein.

Anforderungen für PATs

Wenn Sie persistente abgeleitete Tabellen (PDTs) in Ihrem Looker-Projekt verwenden möchten, benötigen Sie Folgendes:

• Einen Datenbankdialekt, der PDTs unterstützt. Im Abschnitt Unterstützte Datenbankdialekte für PATs weiter unten auf dieser Seite finden Sie eine Liste der Dialekte, die nichtflüchtige SQL-basierte abgeleitete Tabellen und nichtflüchtige native abgeleitete Tabellen unterstützen.
• Ein Scratch-Schema in der Datenbank. Dabei kann es sich um ein beliebiges Schema in Ihrer Datenbank handeln. Wir empfehlen aber, ein neues Schema zu erstellen, das nur zu diesem Zweck eingesetzt wird. Der Datenbankadministrator muss das Schema mit Schreibberechtigung für den Looker-Datenbankbenutzer konfigurieren.
• Eine Looker-Verbindung, bei der die Ein/Aus-Schaltfläche PDs aktivieren aktiviert ist. Dies wird in der Regel bei der Erstkonfiguration der Looker-Verbindung eingerichtet. Eine Anleitung für Ihren Datenbankdialekt finden Sie auf der Dokumentationsseite Looker-Dialekte. Sie können aber auch nach der Ersteinrichtung PDTs für Ihre Verbindung aktivieren.

Unterstützte Datenbankdialekte für PDTs

Damit Looker in Ihrem Looker-Projekt persistente abgeleitete Tabellen (PDTs) unterstützen kann, müssen diese auch von Ihrem Datenbankdialekt unterstützt werden.

Zur Unterstützung jeglicher PATs (entweder LookML-basiert oder SQL-basiert) muss der Dialekt neben anderen Anforderungen auch Schreibvorgänge in die Datenbank unterstützen. Es gibt einige schreibgeschützte Datenbankkonfigurationen, die Persistenz verhindern (am häufigsten Postgres-Hot-Swap-Replikatdatenbanken). In diesen Fällen können Sie stattdessen temporäre abgeleitete Tabellen verwenden.

Die folgende Tabelle zeigt die Dialekte, die persistente SQL-basierte abgeleitete Tabellen in der neuesten Version von Looker unterstützen:

Dialekt	Unterstützt?
Lawine Actian	Ja
Amazon Athena	Ja
Amazon Aurora MySQL	Ja
Amazon Redshift	Ja
Apache Druid	Nein
Apache Druid 0.13 und höher	Nein
Apache Druid 0.18 und höher	Nein
Apache Hive 2.3+	Ja
Apache Hive 3.1.2+	Ja
Apache Spark 3 und höher	Ja
ClickHouse	Nein
Cloudera Impala 3.1+	Ja
Cloudera Impala 3.1+ mit nativem Treiber	Ja
Cloudera Impala mit nativem Fahrer	Ja
DataVirtuality	Nein
Databricks	Ja
Denodo 7	Nein
Denodo 8	Nein
Dremio	Nein
Dremio 11+	Nein
Exasol	Ja
Firebolt	Nein
Legacy-SQL von Google BigQuery	Ja
Google BigQuery-Standard-SQL	Ja
Google Cloud PostgreSQL	Ja
Google Cloud SQL	Ja
Google Spanner	Nein
Grünpflaumen	Ja
HyperSQL	Nein
IBM Netezza	Ja
MariaDB	Ja
Microsoft Azure PostgreSQL	Ja
Microsoft Azure SQL-Datenbank	Ja
Microsoft Azure Synapse-Analyse	Ja
Microsoft SQL Server 2008 und höher	Ja
Microsoft SQL Server 2012 und höher	Ja
Microsoft SQL Server 2016	Ja
Microsoft SQL Server 2017 und höher	Ja
MongoBI	Nein
MySQL	Ja
MySQL 8.0.12 oder höher	Ja
Oracle	Ja
Oracle ADWC	Ja
PostgreSQL 9.5 oder höher	Ja
PostgreSQL vor Version 9.5	Ja
PrestoDB	Ja
PrestoSQL	Ja
SAP HANA 2+	Ja
SingleStore	Ja
SingleStore 7+	Ja
Snowflake	Ja
Teradata	Ja
Trino	Ja
Vektor	Ja
Vertica	Ja

Zur Unterstützung persistenter nativer abgeleiteter Tabellen (mit LookML-basierten Abfragen) muss der Dialekt auch die DDL-Funktion CREATE TABLE unterstützen. Im Folgenden finden Sie eine Liste der Dialekte, die persistente native (LookML-basierte) abgeleitete Tabellen in der neuesten Version von Looker unterstützen:

Dialekt	Unterstützt?
Lawine Actian	Ja
Amazon Athena	Ja
Amazon Aurora MySQL	Ja
Amazon Redshift	Ja
Apache Druid	Nein
Apache Druid 0.13 und höher	Nein
Apache Druid 0.18 und höher	Nein
Apache Hive 2.3+	Ja
Apache Hive 3.1.2+	Ja
Apache Spark 3 und höher	Ja
ClickHouse	Nein
Cloudera Impala 3.1+	Ja
Cloudera Impala 3.1+ mit nativem Treiber	Ja
Cloudera Impala mit nativem Fahrer	Ja
DataVirtuality	Nein
Databricks	Ja
Denodo 7	Nein
Denodo 8	Nein
Dremio	Nein
Dremio 11+	Nein
Exasol	Ja
Firebolt	Nein
Legacy-SQL von Google BigQuery	Ja
Google BigQuery-Standard-SQL	Ja
Google Cloud PostgreSQL	Ja
Google Cloud SQL	Nein
Google Spanner	Nein
Grünpflaumen	Ja
HyperSQL	Nein
IBM Netezza	Ja
MariaDB	Ja
Microsoft Azure PostgreSQL	Ja
Microsoft Azure SQL-Datenbank	Ja
Microsoft Azure Synapse-Analyse	Ja
Microsoft SQL Server 2008 und höher	Ja
Microsoft SQL Server 2012 und höher	Ja
Microsoft SQL Server 2016	Ja
Microsoft SQL Server 2017 und höher	Ja
MongoBI	Nein
MySQL	Ja
MySQL 8.0.12 oder höher	Ja
Oracle	Ja
Oracle ADWC	Ja
PostgreSQL 9.5 oder höher	Ja
PostgreSQL vor Version 9.5	Ja
PrestoDB	Ja
PrestoSQL	Ja
SAP HANA 2+	Ja
SingleStore	Ja
SingleStore 7+	Ja
Snowflake	Ja
Teradata	Ja
Trino	Ja
Vektor	Ja
Vertica	Ja

Hinweis :PATs werden für Snowflake-Verbindungen, die OAuth verwenden, nicht unterstützt.

Inkrementeller Aufbau von PDTs

Eine inkrementelle PDT ist eine nichtflüchtige abgeleitete Tabelle (PDT), die von Looker erstellt wird, indem neue Daten an die Tabelle angehängt werden, anstatt die gesamte Tabelle neu zu erstellen.

Wenn Ihr Dialekt inkrementelle PATs unterstützt und Ihre PDT eine auslösende Persistenzstrategie verwendet (datagroup_trigger, sql_trigger_value oder interval_trigger), können Sie die PDT als inkrementelle PDT definieren.

Hinweis :Inkrementelle PDTs werden für PDTs mit der persist_for-Persistenzstrategie nicht unterstützt.

Weitere Informationen finden Sie auf der Dokumentationsseite Inkrementelle PATs.

Unterstützte Datenbankdialekte für inkrementelle PDTs

Damit Looker inkrementelle PDTs in Ihrem Looker-Projekt unterstützen kann, müssen diese auch von Ihrem Datenbankdialekt unterstützt werden. Die folgende Tabelle zeigt, welche Dialekte inkrementelle PATs in der neuesten Version von Looker unterstützen:

Dialekt	Unterstützt?
Lawine Actian	Nein
Amazon Athena	Nein
Amazon Aurora MySQL	Nein
Amazon Redshift	Ja
Apache Druid	Nein
Apache Druid 0.13 und höher	Nein
Apache Druid 0.18 und höher	Nein
Apache Hive 2.3+	Nein
Apache Hive 3.1.2+	Nein
Apache Spark 3 und höher	Nein
ClickHouse	Nein
Cloudera Impala 3.1+	Nein
Cloudera Impala 3.1+ mit nativem Treiber	Nein
Cloudera Impala mit nativem Fahrer	Nein
DataVirtuality	Nein
Databricks	Ja
Denodo 7	Nein
Denodo 8	Nein
Dremio	Nein
Dremio 11+	Nein
Exasol	Nein
Firebolt	Nein
Legacy-SQL von Google BigQuery	Nein
Google BigQuery-Standard-SQL	Ja
Google Cloud PostgreSQL	Ja
Google Cloud SQL	Nein
Google Spanner	Nein
Grünpflaumen	Ja
HyperSQL	Nein
IBM Netezza	Nein
MariaDB	Nein
Microsoft Azure PostgreSQL	Ja
Microsoft Azure SQL-Datenbank	Nein
Microsoft Azure Synapse-Analyse	Ja
Microsoft SQL Server 2008 und höher	Nein
Microsoft SQL Server 2012 und höher	Nein
Microsoft SQL Server 2016	Nein
Microsoft SQL Server 2017 und höher	Nein
MongoBI	Nein
MySQL	Ja
MySQL 8.0.12 oder höher	Ja
Oracle	Nein
Oracle ADWC	Nein
PostgreSQL 9.5 oder höher	Ja
PostgreSQL vor Version 9.5	Ja
PrestoDB	Nein
PrestoSQL	Nein
SAP HANA 2+	Nein
SingleStore	Nein
SingleStore 7+	Nein
Snowflake	Ja
Teradata	Nein
Trino	Nein
Vektor	Nein
Vertica	Ja

PATs erstellen

Um eine abgeleitete Tabelle in eine persistente abgeleitete Tabelle (PDT) umzuwandeln, definieren Sie eine Persistenzstrategie für die Tabelle. Zur Leistungsoptimierung sollten Sie außerdem eine Optimierungsstrategie hinzufügen.

Persistenzstrategien

Die Persistenz einer abgeleiteten Tabelle kann von Looker oder, bei Dialekten, die materialisierte Ansichten unterstützen, von Ihrer Datenbank mithilfe von materialisierten Ansichten verwaltet werden.

Wenn Sie eine abgeleitete Tabelle persistent machen möchten, fügen Sie der Definition derived_table einen der folgenden Parameter hinzu:

• Von Looker verwaltete Persistenzparameter:
  • datagroup_trigger
  • sql_trigger_value
  • interval_trigger
  • persist_for
• Datenbankverwaltete Persistenzparameter:
  • materialized_view: yes

Bei Trigger-basierten Persistenzstrategien (datagroup_trigger, sql_trigger_value und interval_trigger) behält Looker die PDT in der Datenbank bei, bis die Neuerstellung der PDT ausgelöst wird. Nach Auslösen der PDT erstellt Looker die PDT neu, um die vorherige Version zu ersetzen. Das heißt, die Benutzer müssen mit Trigger-basierten PDTs in den meisten Fällen nicht auf die Erstellung der PDT warten, um Antworten für Explore-Abfragen aus der PDT zu erhalten.

Hinweis: Bestimmte Nutzer können die Persistenzeinstellung einer PAT überschreiben. Ein Nutzer mit der Berechtigung develop kann mit der Option Abgeleitete Tabellen neu erstellen und ausführen im Menü eines Explores die Persistenzeinstellung überschreiben und alle für die aktuelle Abfrage erforderlichen PDTs im Explore neu erstellen. Weitere Informationen finden Sie im Abschnitt PDs für eine Abfrage manuell neu erstellen auf dieser Seite.

datagroup_trigger

Datengruppen sind die flexibelste Methode, um Persistenz zu schaffen. Wenn Sie eine Datengruppe mit sql_trigger oder interval_trigger definiert haben, können Sie mit dem Parameter datagroup_trigger die Neuerstellung Ihrer persistenten abgeleiteten Tabellen (PDTs) initiieren.

Looker behält die PDT in der Datenbank bei, bis die zugehörige Datengruppe ausgelöst wird. Nach Auslösen der Datengruppe erstellt Looker die PDT neu, um die vorherige Version zu ersetzen. Das heißt, die Benutzer müssen in den meisten Fällen nicht auf die Erstellung der PDT warten. Wenn ein Benutzer Daten von der PDT anfordert, während sie erstellt wird, und die Abfrageergebnisse nicht im Cache gespeichert sind, gibt Looker Daten aus der vorhandenen PDT zurück, bis die neue PDT erstellt wird. Eine Übersicht über Datengruppen finden Sie unter Caching-Abfragen.

Weitere Informationen dazu, wie der Regenerator PATs erstellt, finden Sie im Abschnitt Looker-Regenerator.

sql_trigger_value

Der Parameter sql_trigger_value löst die Neugenerierung einer persistenten abgeleiteten Tabelle (PDT) auf Basis einer von Ihnen angegebenen SQL-Anweisung aus. Wenn das Ergebnis der SQL-Anweisung sich vom vorherigen Wert unterscheidet, wird die PDT neu generiert. Andernfalls wird die vorhandene PDT in der Datenbank beibehalten. Das heißt, die Benutzer müssen in den meisten Fällen nicht auf die Erstellung der PDT warten. Wenn ein Benutzer Daten von der PDT anfordert, während sie erstellt wird, und die Abfrageergebnisse nicht im Cache gespeichert sind, gibt Looker Daten aus der vorhandenen PDT zurück, bis die neue PDT erstellt wird.

Weitere Informationen dazu, wie der Regenerator PATs erstellt, finden Sie im Abschnitt Looker-Regenerator.

interval_trigger

Der Parameter interval_trigger löst die Neugenerierung einer persistenten abgeleiteten Tabelle (PAT) anhand eines von Ihnen angegebenen Zeitintervalls aus, z. B. "24 hours" oder "60 minutes". Ähnlich wie der Parameter sql_trigger bedeutet dies, dass die PAT in der Regel vorgefertigt wird, wenn Nutzer sie abfragen. Wenn ein Benutzer Daten von der PDT anfordert, während sie erstellt wird, und die Abfrageergebnisse nicht im Cache gespeichert sind, gibt Looker Daten aus der vorhandenen PDT zurück, bis die neue PDT erstellt wird.

persist_for

Eine weitere Möglichkeit besteht darin, mit dem Parameter persist_for festzulegen, wie lange die abgeleitete Tabelle gespeichert werden soll, bevor sie als abgelaufen markiert wird. So wird sie nicht mehr für Abfragen verwendet und aus der Datenbank gelöscht.

Eine persistente abgeleitete Tabelle (PDT) mit persist_for wird erstellt, wenn ein Nutzer zum ersten Mal eine Abfrage damit ausführt. Anschließend behält Looker die PDT in der Datenbank für den im persist_for-Parameter der PDT angegebenen Zeitraum bei. Wenn ein Nutzer die PDT innerhalb des Zeitraums von persist_for abfragt, verwendet Looker nach Möglichkeit im Cache gespeicherte Ergebnisse oder führt die Abfrage mit der PAT aus.

Nach dem persist_for-Zeitpunkt löscht Looker die PDT aus der Datenbank. Sie wird neu erstellt, wenn ein Nutzer sie das nächste Mal abfragt. Das bedeutet, dass die Abfrage auf die Neuerstellung warten muss.

PDTs, die persist_for verwenden, werden nicht automatisch vom Regenerator von Looker neu erstellt, außer im Fall einer Abhängigkeitskaskade von PDTs. Wenn eine persist_for-Tabelle Teil einer Abhängigkeitskaskade mit triggerbasierten PDTs (PDTs, die die Persistenzstrategie datagroup_trigger, interval_trigger oder sql_trigger_value verwenden), überwacht und erstellt der Regenerator die Tabelle persist_for neu, um andere Tabellen in der Kaskade neu zu erstellen. Weitere Informationen finden Sie auf dieser Seite im Abschnitt So erstellt Looker kaskadierende abgeleitete Tabellen.

materialized_view: yes

Hinweis: Die Funktion für die materialisierte Ansicht ist eine erweiterte Funktion. Abhängig von Ihrem Dialekt kann eine materialisierte Ansicht große Ressourcen verbrauchen. Daher ist es wichtig, dass Sie die Implementierung materialisierter Ansichten durch Ihren Dialekt verstehen. Informationen zum Verhalten des Dialekts und zur Häufigkeit, mit der er Daten für materialisierte Ansichten aktualisiert, finden Sie in der Dokumentation Ihres Dialekts.

Mit materialisierten Ansichten können Sie die Funktionalität Ihrer Datenbank nutzen, um abgeleitete Tabellen in Ihrem Looker-Projekt zu sichern. Wenn Ihr Datenbankdialekt materialisierte Ansichten unterstützt und Ihre Looker-Verbindung konfiguriert und die Ein/Aus-Schaltfläche PDs aktivieren aktiviert ist, können Sie eine materialisierte Ansicht erstellen, indem Sie materialized_view: yes für eine abgeleitete Tabelle angeben. Materialisierte Ansichten werden sowohl für native abgeleitete Tabellen als auch für SQL-basierte abgeleitete Tabellen unterstützt.

Ähnlich wie bei einer nichtflüchtigen abgeleiteten Tabelle ist eine materialisierte Ansicht ein Abfrageergebnis, das als Tabelle im Scratch-Schema Ihrer Datenbank gespeichert wird. Der Hauptunterschied zwischen einer PDT und einer materialisierten Ansicht besteht in der Aktualisierung der Tabellen:

• Bei PDTs wird die Persistenzstrategie von Looker definiert und die Persistenz von Looker verwaltet.
• Bei materialisierten Ansichten ist die Datenbank für die Verwaltung und Aktualisierung der Daten in der Tabelle zuständig.

Deshalb benötigen Sie für die Funktionalität der materialisierten Ansicht fortgeschrittenes Wissen um Ihren Dialekt und seine Funktionen. In den meisten Fällen aktualisiert Ihre Datenbank die materialisierte Ansicht jedes Mal, wenn die Datenbank neue Daten in den Tabellen erkennt, die von der materialisierte Ansicht abgefragt werden. Materialisierte Ansichten eignen sich ideal für Szenarien, die Echtzeitdaten erfordern.

Informationen zur Unterstützung von Dialekten, zu den Anforderungen und zu wichtigen Überlegungen finden Sie auf der Dokumentationsseite für den materialized_view-Parameter.

Optimierungsstrategien

Da persistente abgeleitete Tabellen (PDTs) in Ihrer Datenbank gespeichert sind, sollten Sie Ihre PDTs mit den folgenden Strategien optimieren, die von Ihrem Dialekt unterstützt werden:

• cluster_keys
• distribution
• distribution_style
• indexes
• partition_keys
• sortkeys

Wenn Sie beispielsweise dem Beispiel für abgeleitete Tabelle Persistenz hinzufügen möchten, können Sie festlegen, dass die Datengruppe neu erstellt wird, wenn die Datengruppe orders_datagroup ausgelöst wird, und Indexe sowohl für customer_id als auch für first_order wie folgt hinzufügen:

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

Wenn Sie keinen Index (oder eine Entsprechung für Ihren Dialekt) hinzufügen, werden Sie von Looker gewarnt, dass Sie dies tun sollten, um die Abfrageleistung zu verbessern.

Anwendungsfälle für PATs

Persistente abgeleitete Tabellen (PDTs) sind nützlich, da sie die Leistung einer Abfrage verbessern können, indem die Ergebnisse der Abfrage in einer Tabelle beibehalten werden.

Als allgemeine Best Practice sollten Entwickler versuchen, Daten ohne PATs zu modellieren, bis es absolut notwendig ist.

In einigen Fällen können Daten auf andere Weise optimiert werden. Wenn Sie beispielsweise einen Index hinzufügen oder den Datentyp einer Spalte ändern, kann ein Problem möglicherweise behoben werden, ohne dass eine PAT erstellt werden muss. Analysieren Sie unbedingt die Ausführungspläne langsamer Abfragen mit dem Tool Explain from SQL Runner.

Abgesehen von der Reduzierung der Abfragezeit und der Datenbanklast bei häufig ausgeführten Abfragen gibt es mehrere weitere Anwendungsfälle für PATs, darunter:

• Optimierungen testen
• Daten vorab verknüpfen oder aggregieren

Sie können auch eine PDT verwenden, um einen Primärschlüssel zu definieren, wenn es keine vernünftige Möglichkeit gibt, eine eindeutige Zeile in einer Tabelle als Primärschlüssel zu identifizieren.

PATs zum Testen von Optimierungen verwenden

Sie können PDTs verwenden, um verschiedene Indexierungen, Distributionen und andere Optimierungsoptionen zu testen, ohne viel Unterstützung von Ihren DBA- oder ETL-Entwicklern zu benötigen.

Stellen Sie sich einen Fall vor, bei dem Sie eine Tabelle haben, aber verschiedene Indexe testen möchten. Ihr anfänglicher LookML-Code für die Ansicht könnte wie folgt aussehen:

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

Zum Testen von Optimierungsstrategien können Sie den Parameter indexes verwenden, um dem LookML-Code Indexe wie die folgenden hinzuzufügen:

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]
  }
}

Fragen Sie die Ansicht einmal ab, um die PAT zu generieren. Führen Sie dann die Testabfragen aus und vergleichen Sie die Ergebnisse. Wenn Ihre Ergebnisse positiv ausfallen, können Sie Ihr DBA- oder ETL-Team bitten, die Indexe der ursprünglichen Tabelle hinzuzufügen.

Denken Sie daran, den Ansichtscode wieder zu ändern, um die PAT zu entfernen.

Mit PATs Daten vorab zusammenführen oder aggregieren

Es kann nützlich sein, Daten vorab zu verknüpfen oder vorab zu aggregieren, um die Abfrageoptimierung für große Datenmengen oder mehrere Datentypen anzupassen.

Angenommen, Sie möchten einen Bericht zu Kunden nach Kohorten erstellen, die auf dem Zeitpunkt ihrer ersten Bestellung basieren. Die mehrfache Ausführung dieser Abfrage kann teuer sein, wenn die Daten in Echtzeit benötigt werden. Sie können die Abfrage jedoch nur einmal berechnen und dann die Ergebnisse mit einer PDT wiederverwenden:

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]
  }
}

Kaskadierende abgeleitete Tabellen

Es ist möglich, in der Definition einer anderen auf eine abgeleitete Tabelle zu verweisen, indem Sie eine Kette von kaskadierenden abgeleiteten Tabellen oder kaskadierende persistente abgeleitete Tabellen (PDTs) erstellen. Ein Beispiel für kaskadierende abgeleitete Tabellen wäre die Tabelle TABLE_D, die von der anderen Tabelle TABLE_C abhängt, während TABLE_C von TABLE_B und TABLE_B von TABLE_A abhängt.

Hinweis: Bevor Sie kaskadierende abgeleitete Tabellen einrichten, sollten Sie wissen, wie kaskadierende Tabellen automatisch durch den Regenerator von Looker neu erstellt werden und wie sie von Nutzern manuell neu erstellt werden können. Es gibt auch andere wichtige Aspekte beim Implementieren persistenter Tabellen. All diese Themen werden weiter unten auf dieser Seite behandelt.

Syntax für den Verweis auf eine abgeleitete Tabelle

Verwenden Sie diese Syntax, um in einer abgeleiteten Tabelle auf eine andere abgeleitete Tabelle zu verweisen:

`${derived_table_or_view_name.SQL_TABLE_NAME}`

In diesem Format ist SQL_TABLE_NAME ein Literalstring. Sie können beispielsweise mit dieser Syntax auf die abgeleitete Tabelle clean_events verweisen:

`${clean_events.SQL_TABLE_NAME}`

Mit derselben Syntax können Sie auch auf eine LookML-Ansicht verweisen. Auch hier ist SQL_TABLE_NAME ein literaler String.

Hinweis :Die Syntax ${derived_table_or_view_name.SQL_TABLE_NAME} wird im Parameter sql_trigger einer Datengruppe nicht unterstützt. Daher können Sie keine abgeleitete Tabelle zum Auslösen einer Datengruppe verwenden. Sie können jedoch die Syntax ${derived_table_or_view_name.SQL_TABLE_NAME} im Parameter sql_trigger_value verwenden, um Ihre PAT-Neuerstellungen auszulösen.

Im nächsten Beispiel wird die clean_events-PDT aus der Tabelle events in der Datenbank erstellt. Die PAT clean_events enthält unerwünschte Zeilen aus der Datenbanktabelle events. Dann wird eine zweite PDT angezeigt. Die event_summary-PDT ist eine Zusammenfassung der clean_events-PDT. Die Tabelle event_summary wird neu generiert, wenn clean_events neue Zeilen hinzugefügt werden.

Die event_summary-PDT und die clean_events-PDT sind kaskadierende PDTs, wobei event_summary von clean_events abhängig ist (da event_summary mit der PDT clean_events definiert wird). Dieses spezielle Beispiel könnte mit einer einzelnen PAT effizienter durchgeführt werden, aber es ist nützlich, um Verweise auf abgeleitete Tabellen zu demonstrieren.

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

Wenn Sie auf diese Weise auf eine abgeleitete Tabelle verweisen, ist es oft nützlich, einen Alias für die Tabelle im folgenden Format zu erstellen:

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

Das ist im vorherigen Beispiel der Fall:

${clean_events.SQL_TABLE_NAME} AS clean_events

Es bietet sich an, einen Alias zu verwenden, da PDTs in der Datenbank lange Codes als Namen erhalten. In einigen Fällen (insbesondere bei ON-Klauseln) kann man leicht vergessen, dass Sie die ${derived_table_or_view_name.SQL_TABLE_NAME}-Syntax verwenden müssen, um diesen langen Namen abzurufen. Mit einem Aliasnamen kann dieser Fehler vermieden werden.

So erstellt Looker kaskadierende abgeleitete Tabellen

Wenn sich bei kaskadierenden temporären abgeleiteten Tabellen die Abfrageergebnisse eines Nutzers nicht im Cache befinden, erstellt Looker alle abgeleiteten Tabellen, die für die Abfrage erforderlich sind. Wenn Sie eine TABLE_D haben, deren Definition einen Verweis auf TABLE_C enthält, dann ist TABLE_D von TABLE_C abhängig. Wenn Sie also TABLE_D abfragen und sich die Abfrage nicht im Cache von Looker befindet, erstellt Looker TABLE_D neu. Aber zuerst muss TABLE_C neu erstellt werden.

Nehmen wir nun ein Szenario mit kaskadierenden temporären abgeleiteten Tabellen, bei dem TABLE_D von TABLE_C abhängig ist, die wiederum von TABLE_B abhängig ist, die wiederum von TABLE_A abhängig ist. Wenn Looker im Cache keine gültigen Ergebnisse für eine Abfrage zu TABLE_C hat, erstellt Looker alle für die Abfrage benötigten Tabellen. Looker erstellt also TABLE_A, dann TABLE_B und dann TABLE_C:

In diesem Szenario muss die Generierung von TABLE_A abgeschlossen sein, bevor Looker mit dem Generieren von TABLE_B beginnen kann, usw., bis TABLE_C abgeschlossen ist und Looker die Abfrageergebnisse bereitstellen kann. (Da TABLE_D zur Beantwortung dieser Abfrage nicht benötigt wird, erstellt Looker TABLE_D derzeit nicht neu.)

Auf der Dokumentationsseite zum Parameter datagroup finden Sie ein Beispielszenario für kaskadierende PDTs, die dieselbe Datengruppe verwenden.

Die gleiche grundlegende Logik gilt für PDTs: Looker erstellt jede Tabelle, die zum Beantworten einer Abfrage erforderlich ist, bis hin zur Kette der Abhängigkeiten. Bei PATs ist es jedoch häufig der Fall, dass die Tabellen bereits vorhanden sind und nicht neu erstellt werden müssen. Bei Standardnutzerabfragen mit kaskadierenden PDTs erstellt Looker die PDTs in der Kaskade nur dann neu, wenn keine gültige Version der PDTs in der Datenbank vorhanden ist. Wenn Sie die Neuerstellung für alle PDTs in einer Kaskade erzwingen möchten, können Sie die Tabellen für eine Abfrage manuell über ein Explore neu erstellen.

Ein wichtiger logischer Punkt ist, dass im Fall einer PAT-Kaskade eine abhängige PAT im Wesentlichen die PAT abfragt, von der sie abhängt. Dies ist insbesondere für PATs mit der persist_for-Strategie wichtig. In der Regel werden persist_for-PDTs erstellt, wenn ein Nutzer sie abfragt. Sie verbleiben in der Datenbank, bis das persist_for-Intervall abgelaufen ist, und werden erst dann neu erstellt, wenn sie das nächste Mal von einem Nutzer abgefragt werden. Wenn eine persist_for-PDT jedoch Teil einer Kaskade mit auslöserbasierten PDTs (PDTs, die die Persistenzstrategie datagroup_trigger, interval_trigger oder sql_trigger_value verwenden), wird die persist_for-PDT immer dann abgefragt, wenn ihre abhängigen PDTs neu erstellt werden. In diesem Fall wird die persist_for-PDT also gemäß dem Zeitplan ihrer abhängigen PDTs neu erstellt. Das bedeutet, dass persist_for PDTs von der Persistenzstrategie ihrer abhängigen Variablen betroffen sein können.

Persistente Tabellen für eine Abfrage manuell neu erstellen

Nutzer können im Menü eines Explores die Option Abgeleitete Tabellen neu erstellen und ausführen auswählen, um die Persistenzeinstellungen zu überschreiben und alle persistenten abgeleiteten Tabellen (PDTs) und aggregierten Tabellen neu zu erstellen, die für die aktuelle Abfrage im Explore erforderlich sind:

Diese Option ist nur für Nutzer mit der Berechtigung develop und erst dann verfügbar, wenn die Explore-Abfrage geladen wurde.

Mit der Option Abgeleitete Tabellen neu erstellen und ausführen werden alle persistenten Tabellen (alle PDTs und aggregierten Tabellen) neu erstellt, die zur Beantwortung der Abfrage erforderlich sind, unabhängig von ihrer Persistenzstrategie. Dazu gehören alle zusammengefassten Tabellen und PDTs in der aktuellen Abfrage sowie alle zusammengefassten Tabellen und PDTs, auf die in der aktuellen Abfrage auf die aggregierten Tabellen und PDTs verwiesen wird.

Im Fall von inkrementellen PDTs löst die Option Abgeleitete Tabellen neu erstellen und ausführen die Erstellung eines neuen Inkrements aus. Bei inkrementellen PDTs umfasst ein Inkrement den im Parameter increment_key angegebenen Zeitraum sowie gegebenenfalls die Anzahl der vorherigen Zeiträume, die im Parameter increment_offset angegeben wurden. Auf der Dokumentationsseite Inkrementelle PDTs finden Sie einige Beispielszenarien, die zeigen, wie inkrementelle PATs je nach ihrer Konfiguration erstellt werden.

Im Fall von kaskadierenden PDTs bedeutet dies, dass alle abgeleiteten Tabellen in der Kaskade neu erstellt werden, beginnend am Anfang. Gleiches Verhalten wie bei der Abfrage einer Tabelle in einer Kaskade von temporären abgeleiteten Tabellen:

Beachten Sie bei der manuellen Neuerstellung abgeleiteter Tabellen Folgendes:

• Bei dem Nutzer, der den Vorgang Abgeleitete Tabellen neu erstellen und ausführen initiiert, wartet die Abfrage mit dem Laden der Ergebnisse, bis die Tabellen neu erstellt wurden. Bei den Abfragen anderer Nutzer werden weiterhin die vorhandenen Tabellen verwendet. Wenn die persistenten Tabellen erneut erstellt wurden, verwenden alle Benutzer die neu erstellten Tabellen. Dieser Prozess soll verhindern, dass die Abfragen anderer Benutzer während der Neuerstellung der Tabellen unterbrochen werden. Diese Benutzer können jedoch trotzdem von der zusätzlichen Belastung Ihrer Datenbank betroffen sein. Wenn das Auslösen einer Neuerstellung während der Arbeitszeit die Datenbank übermäßig belasten würde, müssen Sie möglicherweise die Benutzer informieren, dass bestimmte PDTs oder aggregierte Tabellen nicht während der Geschäftszeiten neu erstellt werden sollten.

• Wenn sich ein Nutzer im Entwicklungsmodus befindet und das Explore auf einer Entwicklungstabelle basiert, wird beim Vorgang Abgeleitete Tabellen neu erstellen und ausführen die Entwicklungstabelle für das Explore neu erstellt, nicht die Produktionstabelle. Wenn das Explore im Entwicklungsmodus jedoch die Produktionsversion einer abgeleiteten Tabelle verwendet, wird die Produktionstabelle neu erstellt. Informationen zu Entwicklungstabellen und Produktionstabellen finden Sie unter Persistente Tabellen im Entwicklungsmodus.

• Wenn bei von Looker gehosteten Instanzen die Neuerstellung der abgeleiteten Tabelle länger als eine Stunde dauert, wird die Tabelle nicht erfolgreich neu erstellt und es kommt zu einer Zeitüberschreitung der Browsersitzung. Weitere Informationen zu Zeitüberschreitungen, die sich auf Looker-Prozesse auswirken können, finden Sie auf der Dokumentationsseite Administratoreinstellungen – Abfragen im Abschnitt Abfragezeitüberschreitungen und Warteschlangen.

Persistente Tabellen im Entwicklungsmodus

Looker hat einige spezielle Verhaltensweisen für die Verwaltung persistenter Tabellen im Entwicklungsmodus.

Hinweis: Dieses Verhalten gilt für jede Art von persistenten Tabellen, einschließlich aggregierter Tabellen sowie persistente abgeleitete Tabellen (PDTs).

Wenn Sie eine persistente Tabelle im Entwicklungsmodus abfragen, ohne Änderungen an ihrer Definition vorzunehmen, fragt Looker die Produktionsversion dieser Tabelle ab. Wenn Sie eine Änderung an der Tabellendefinition vornehmen, die sich auf die Daten in der Tabelle oder die Abfragemethode der Tabelle auswirkt, wird bei der nächsten Abfrage der Tabelle im Entwicklungsmodus eine neue Entwicklungsversion der Tabelle erstellt. Mit einer solchen Entwicklungstabelle können Sie Änderungen testen, ohne Endbenutzer zu stören.

Was veranlasst Looker zur Erstellung einer Entwicklungstabelle?

Soweit möglich, verwendet Looker die vorhandene Produktionstabelle zum Beantworten von Abfragen, unabhängig davon, ob Sie sich im Entwicklungsmodus befinden. Es gibt jedoch bestimmte Fälle, in denen Looker die Produktionstabelle nicht für Abfragen im Entwicklungsmodus verwenden kann:

• Wenn die persistente Tabelle einen Parameter hat, der das Dataset eingrenzt, um im Entwicklungsmodus schneller zu arbeiten
• Wenn Sie Änderungen an der Definition der persistenten Tabelle vorgenommen haben, die sich auf die Daten in der Tabelle auswirken.

Looker erstellt eine Entwicklungstabelle, wenn Sie sich im Entwicklungsmodus befinden und eine SQL-basierte abgeleitete Tabelle abfragen, die mithilfe einer bedingten WHERE-Klausel mit if prod- und if dev-Anweisungen definiert wurde.

Hinweis :Das trifft nicht auf native abgeleitete Tabellen mit dem Parameter dev_filters zu. Bei nativen abgeleiteten Tabellen mit dev_filters hat Looker die Logik, die Produktionstabelle zum Beantworten von Abfragen im Entwicklungsmodus zu verwenden, sofern Sie die Definition der Tabelle nicht ändern und dann die Tabelle im Entwicklungsmodus abfragen.

Bei persistenten Tabellen ohne Parameter zum Eingrenzen des Datasets im Entwicklungsmodus verwendet Looker die Produktionsversion der Tabelle, um Abfragen im Entwicklungsmodus zu beantworten, sofern Sie die Definition der Tabelle nicht ändern und dann die Tabelle im Entwicklungsmodus abfragen. Dies gilt für alle Änderungen an der Tabelle, die sich auf die Daten in der Tabelle auswirken oder auf die Art und Weise, wie die Tabelle abgefragt wird.

Im Folgenden finden Sie einige Beispiele für die Arten von Änderungen, die Looker zum Erstellen einer Entwicklungsversion einer persistenten Tabelle veranlassen (Looker erstellt die Tabelle nur dann, wenn Sie die Tabelle abfragen, nachdem Sie die Änderungen vorgenommen haben):

• Ändern der Abfrage, auf der die persistente Tabelle basiert, z. B. Ändern des Parameters explore_source, sql, query, sql_create oder create_process in der persistenten Tabelle selbst oder in einer beliebigen erforderlichen Tabelle (bei kaskadierenden abgeleiteten Tabellen)
• Persistenzstrategie der Tabelle ändern, z. B. den Parameter datagroup_trigger, sql_trigger_value, interval_trigger oder persist_for der Tabelle ändern
• Name der view einer abgeleiteten Tabelle ändern
• increment_key oder increment_offset einer inkrementellen PAT ändern
• Das connection ändern, das vom verknüpften Modell verwendet wird

Bei Änderungen, die die Daten der Tabelle nicht ändern oder die Art und Weise beeinflussen, wie Looker die Tabelle abfragt, erstellt Looker keine Entwicklungstabelle. Der Parameter publish_as_db_view ist ein gutes Beispiel: Wenn Sie im Entwicklungsmodus nur die publish_as_db_view-Einstellung für eine abgeleitete Tabelle ändern, muss Looker die abgeleitete Tabelle nicht neu erstellen und erstellt daher auch keine Entwicklungstabelle.

Wie lange sind Entwicklungstabellen in Looker abgeleitet?

Unabhängig von der tatsächlichen Persistenzstrategie der Tabelle behandelt Looker persistente Entwicklungstabellen so, als hätten sie eine Persistenzstrategie von persist_for: "24 hours". Looker tut dies, um sicherzustellen, dass Entwicklungstabellen nicht länger als einen Tag beibehalten werden, da ein Looker-Entwickler während der Entwicklung und jedes Mal, wenn eine neue Entwicklungstabelle erstellt wird, viele Iterationen einer Tabelle abfragen kann. Damit die Datenbank nicht durch Entwicklungstabellen überladen wird, wendet Looker die Strategie persist_for: "24 hours" an, damit die Tabellen regelmäßig aus der Datenbank bereinigt werden.

Andernfalls erstellt Looker im Entwicklungsmodus persistente abgeleitete Tabellen (PDTs) und aggregierte Tabellen auf die gleiche Weise, wie persistente Tabellen im Produktionsmodus erstellt werden.

Wenn eine Entwicklungstabelle in Ihrer Datenbank beibehalten wird, wenn Sie Änderungen an einer PAT oder einer aggregierten Tabelle bereitstellen, kann Looker häufig die Entwicklungstabelle als Produktionstabelle verwenden, sodass Ihre Benutzer nicht warten müssen, bis die Tabelle erstellt ist, wenn sie die Tabelle abfragen.

Hinweis: Wenn Sie Ihre Änderungen bereitstellen, muss die Tabelle unter Umständen immer noch neu erstellt werden, um in der Produktion abgefragt werden zu können. Das hängt von der jeweiligen Situation ab:

• Wenn seit der Abfrage der Tabelle im Entwicklungsmodus mehr als 24 Stunden vergangen sind, wird die Entwicklungsversion der Tabelle als abgelaufen gekennzeichnet und nicht für Abfragen verwendet. Sie können mithilfe der Looker-IDE oder auf der Seite Persistente abgeleitete Tabellen über den Tab Entwicklung nach nicht erstellten PATs suchen. Falls nicht erstellte PDTs vorhanden sind, können Sie diese unmittelbar vor dem Vornehmen Ihrer Änderungen im Entwicklungsmodus abfragen, damit die Entwicklungstabelle in der Produktion verwendet werden kann.
• Wenn eine persistente Tabelle den Parameter dev_filters (für native abgeleitete Tabellen) oder die bedingte WHERE-Klausel enthält, die die Anweisungen if prod und if dev (für SQL-basierte abgeleitete Tabellen) verwendet, kann die Entwicklungstabelle nicht als Produktionsversion verwendet werden, da die Entwicklungsversion ein verkürztes Dataset enthält. In diesem Fall können Sie nach der Entwicklung der Tabelle und vor der Bereitstellung der Änderungen den Parameter dev_filters oder die bedingte WHERE-Klausel auskommentieren und die Tabelle dann im Entwicklungsmodus abfragen. Looker erstellt dann eine vollständige Version der Tabelle, die für die Produktion verwendet werden kann, wenn Sie Ihre Änderungen bereitstellen.

Wenn Sie Ihre Änderungen bereitstellen und keine gültige Entwicklungstabelle vorhanden ist, die als Produktionstabelle verwendet werden kann, erstellt Looker die Tabelle bei der nächsten Abfrage im Produktionsmodus (für persistente Tabellen, die die persist_for-Strategie verwenden) oder beim nächsten Ausführen des Regenerators (bei persistenten Tabellen, die datagroup_trigger, interval_trigger oder sql_trigger_value verwenden, neu).

Nach nicht erstellten PDTs im Entwicklungsmodus suchen

Wenn eine Entwicklungstabelle in Ihrer Datenbank dauerhaft gespeichert wird, wenn Sie Änderungen an einer persistenten abgeleiteten Tabelle (PDT) oder einer aggregierten Tabelle bereitstellen, kann Looker häufig die Entwicklungstabelle als Produktionstabelle verwenden, damit Ihre Nutzer bei der Abfrage der Tabelle nicht auf die Erstellung der Tabelle warten müssen. Weitere Informationen finden Sie in den Abschnitten Wie lange werden Entwicklungstabellen in Looker gespeichert? und Gründe für die Erstellung einer Entwicklungstabelle durch Looker.

Daher ist es optimal, dass alle Ihre PATs bei der Bereitstellung für die Produktion erstellt werden, damit die Tabellen sofort als Produktionsversionen verwendet werden können.

Sie können Ihr Projekt im Bereich Projektzustand auf nicht erstellte PATs prüfen. Klicken Sie in der Looker-IDE auf das Symbol Projektzustand, um den Bereich Projektzustand zu öffnen. Klicken Sie dann auf die Schaltfläche Validate PAT Status (PDT-Status validieren).

Nicht erstellte PATs werden im Bereich Project Health (Projektzustand) aufgeführt:

Wenn Sie die Berechtigung see_pdts haben, können Sie auf die Schaltfläche Zur PAT-Verwaltung wechseln klicken. Looker öffnet den Tab Entwicklung der Seite Persistente abgeleitete Tabellen und filtert die Ergebnisse nach Ihrem spezifischen LookML-Projekt. Hier können Sie feststellen, welche Entwicklungs-PDTs erstellt und welche nicht erstellt wurden, und auf andere Informationen zur Fehlersuche zugreifen. Weitere Informationen finden Sie auf der Dokumentationsseite Administratoreinstellungen – Persistente abgeleitete Tabellen.

Nachdem Sie eine nicht erstellte PAT in Ihrem Projekt identifiziert haben, können Sie eine Entwicklungsversion erstellen. Öffnen Sie dazu ein Explore, das die Tabelle abfragt, und verwenden Sie dann im Menü „Explore“ die Option Abgeleitete Tabellen neu erstellen und ausführen. Weitere Informationen finden Sie im Abschnitt Persistente Tabellen für eine Abfrage manuell neu erstellen auf dieser Seite.

Hinweis: Wenn eine persistente Tabelle eine SQL-basierte abgeleitete Tabelle ist, die mithilfe einer bedingten WHERE-Klausel mit den Anweisungen if prod und if dev definiert wird, können Sie die Entwicklungsversion der Tabelle nicht für die Produktion verwenden, da die Entwicklungsversion der Tabelle ein verkürztes Dataset enthält. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Wie lange werden Entwicklungstabellen in Looker gespeichert?. Bei nativen abgeleiteten Tabellen mit dem Parameter dev_filters verwendet Looker die Produktionstabelle, um Abfragen im Entwicklungsmodus zu beantworten, es sei denn, Sie ändern die Definition der Tabelle und fragen die Tabelle dann im Entwicklungsmodus ab. Weitere Informationen finden Sie im Abschnitt Was führt Looker zum Erstellen einer Entwicklungstabelle aus auf dieser Dokumentationsseite.

Tabellen gemeinsam nutzen und bereinigen

Innerhalb einer Looker-Instanz können Tabellen von Benutzern gemeinsam verwendet werden, wenn die Tabellen über dieselbe Definition und dieselbe Einstellung für die Persistenzmethode verfügen. Wenn die Definition einer Tabelle nicht mehr vorhanden ist, markiert Looker die Tabelle außerdem als abgelaufen.

Das bringt mehrere Vorteile mit sich:

• Wenn Sie im Entwicklungsmodus keine Änderungen an einer Tabelle vorgenommen haben, werden für Ihre Abfragen die vorhandenen Produktionstabellen verwendet. Dies ist der Fall, es sei denn, Ihre Tabelle ist eine SQL-basierte abgeleitete Tabelle, die über eine bedingte WHERE-Klausel mit if prod- und if dev-Anweisungen definiert wird. Wenn die Tabelle mit einer bedingten WHERE-Klausel definiert ist, erstellt Looker eine Entwicklungstabelle, wenn Sie die Tabelle im Entwicklungsmodus abfragen. Bei nativen abgeleiteten Tabellen mit dem Parameter dev_filters hat Looker die Logik, Abfragen im Entwicklungsmodus anhand der Produktionstabelle zu beantworten, es sei denn, Sie ändern die Definition der Tabelle und fragen die Tabelle dann im Entwicklungsmodus ab.
• Sollten zwei Entwickler zufällig im Entwicklungsmodus dieselbe Änderung an einer Tabelle vornehmen, verwenden sie gemeinsam dieselbe Entwicklungstabelle.
• Sobald Ihre Änderungen vom Entwicklungsmodus an den Produktionsmodus übergeben wurden, ist die alte Produktionsdefinition nicht mehr vorhanden. Daraufhin wird die alte Produktionstabelle als abgelaufen markiert und verworfen.
• Wenn Sie Ihre Änderungen im Entwicklungsmodus verwerfen, ist diese Tabellendefinition nicht mehr vorhanden. Daher werden die nicht mehr benötigten Entwicklungstabellen als abgelaufen markiert und verworfen.

Schnelleres Arbeiten im Entwicklungsmodus

Es gibt Situationen, in denen das Generieren der von Ihnen erstellten persistenten abgeleiteten Tabelle (PDT) lange dauert. Dies kann zeitaufwändig sein, wenn Sie viele Änderungen im Entwicklungsmodus testen. In diesen Fällen können Sie Looker auffordern, kleinere Versionen einer abgeleiteten Tabelle zu erstellen, wenn Sie sich im Entwicklungsmodus befinden.

Für native abgeleitete Tabellen können Sie den Unterparameter dev_filters von explore_source verwenden, um Filter anzugeben, die nur auf Entwicklungsversionen der abgeleiteten Tabelle angewendet werden:

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

Dieses Beispiel enthält den Parameter dev_filters, mit dem die Daten nach den letzten 90 Tagen gefiltert werden, und den Parameter filters, mit dem die Daten nach den letzten 2 Jahren und dem Flughafen Yucca Valley gefiltert werden.

Der Parameter dev_filters fungiert in Verbindung mit dem Parameter filters, sodass alle Filter auf die Entwicklungsversion der Tabelle angewendet werden. Wenn sowohl dev_filters als auch filters Filter für dieselbe Spalte angeben, hat dev_filters in der Entwicklungsversion der Tabelle Vorrang. In diesem Beispiel wird die Entwicklungsversion der Tabelle nach den Daten der letzten 90 Tage für den Yucca Valley Airport gefiltert.

Für SQL-basierte abgeleitete Tabellen unterstützt Looker eine bedingte WHERE-Klausel mit verschiedenen Optionen für Produktionsversionen (if prod) und Entwicklungsversionen (if dev) der Tabelle:

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

In diesem Beispiel umfasst die Abfrage alle Daten ab 2000 im Produktionsmodus, im Entwicklungsmodus jedoch nur die Daten ab 2020. Änderungen im Entwicklungsmodus lassen sich wesentlich leichter validieren, wenn Sie mit dieser Funktion Ihren Ergebnissatz strategisch klug beschränken und die Abfragegeschwindigkeit erhöhen.

Hinweis: Wenn eine persistente Tabelle den Parameter dev_filters oder die bedingte WHERE-Klausel hat, kann die Entwicklungstabelle nicht als Produktionsversion verwendet werden, da die Entwicklungsversion ein verkürztes Dataset enthält. In diesem Fall können Sie nach der Entwicklung der Tabelle und vor der Bereitstellung der Änderungen den Parameter dev_filters oder die bedingte WHERE-Klausel auskommentieren und die Tabelle dann im Entwicklungsmodus abfragen. Looker erstellt dann eine vollständige Version der Tabelle, die für die Produktion verwendet werden kann, wenn Sie Ihre Änderungen bereitstellen. Weitere Informationen zur Verwendung von Entwicklungstabellen in der Produktion finden Sie auf dieser Seite im Abschnitt Wie lange werden Entwicklungstabellen in Looker gespeichert?.

So erstellt Looker PDTs

Nachdem eine persistente abgeleitete Tabelle (PDT) definiert und entweder zum ersten Mal ausgeführt oder vom Regenerator für die Neuerstellung gemäß seiner Persistenzstrategie ausgelöst wurde, durchläuft Looker die folgenden Schritte:

1. Verwenden Sie den SQL-Code der abgeleiteten Tabelle, um eine CREATE TABLE AS SELECT (oder CTAS)-Anweisung zu erstellen und auszuführen. So erstellen Sie beispielsweise eine PDT mit dem Namen customer_orders_facts neu: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
2. Anweisungen zum Erstellen der Indexe beim Erstellen der Tabelle ausgeben
3. Benennen Sie die Tabelle von LC$.. („Looker Create“) in LR$.. („Looker Read“) um, um anzugeben, dass die Tabelle einsatzbereit ist.
4. Ältere Versionen der Tabelle löschen, die nicht mehr verwendet werden sollen

Das hat einige wichtige Auswirkungen:

• Der SQL-Code, der die abgeleitete Tabelle bildet, muss innerhalb einer CTAS-Anweisung gültig sein.
• Die Spaltenaliasse in der Ergebnismenge der SELECT-Anweisung müssen gültige Spaltennamen sein.
• Die bei der Angabe von Verteilungen, Sortierschlüsseln und Indexen verwendeten Namen müssen den Spaltennamen entsprechen, die in der SQL-Definition der abgeleiteten Tabelle aufgeführt sind, und nicht die in LookML definierten Feldnamen.

Der Looker-Regenerator

Der Looker-Regenerator prüft den Status und löst Neuerstellungen für Auslöser-persistente Tabellen aus. Eine per Trigger gespeicherte Tabelle ist eine persistente abgeleitete Tabelle (PDT) oder eine zusammengefasste Tabelle, die einen Trigger als Persistenzstrategie verwendet:

• Bei Tabellen mit sql_trigger_value ist der Trigger eine Abfrage, die im Parameter sql_trigger_value der Tabelle angegeben wird. Der Looker-Regenerator löst die Wiedererstellung der Tabelle auf, wenn sich das Ergebnis der letzten Auslöser-Abfrageprüfung von dem Ergebnis der vorherigen Prüfung unterscheidet. Wenn die abgeleitete Tabelle beispielsweise mit der SQL-Abfrage SELECT CURDATE() beibehalten wird, erstellt der Looker-Regenerator die Tabelle neu, wenn der Regenerator den Trigger das nächste Mal nach der Datumsänderung überprüft.
• Bei Tabellen, die interval_trigger verwenden, ist der Trigger eine Zeitdauer, die im Parameter interval_trigger der Tabelle angegeben ist. Der Looker-Regenerator löst die Wiedererstellung der Tabelle nach Ablauf der angegebenen Zeit aus.
• Bei Tabellen mit datagroup_trigger kann der Trigger eine Abfrage sein, die im Parameter sql_trigger der zugehörigen Datengruppe angegeben ist, oder eine Zeitdauer, die im Parameter interval_trigger der Datengruppe angegeben ist.

Der Looker-Regenerator initiiert auch Neuerstellungen für persistente Tabellen, die den Parameter persist_for verwenden, aber nur, wenn die Tabelle persist_for eine Abhängigkeits-Kaskade einer durch Trigger gespeicherten Tabelle ist. In diesem Fall initiiert der Looker-Regenerator die Neuerstellung der Tabelle persist_for, da die Tabelle erforderlich ist, um die anderen Tabellen in der Kaskade neu zu erstellen. Andernfalls überwacht der Regenerator keine persistenten Tabellen, die die Strategie persist_for verwenden.

Der Looker-Regenerator-Zyklus beginnt in einem regelmäßigen Intervall, das von Ihrem Looker-Administrator in der Einstellung Wartungsplan für Datengruppen und PDTs in Ihrer Datenbankverbindung konfiguriert wird (standardmäßig ein Intervall von fünf Minuten). Der Looker-Regenerator startet jedoch erst dann einen neuen Zyklus, wenn alle Überprüfungen und PAT-Neuerstellungen aus dem letzten Zyklus abgeschlossen sind. Wenn Sie also PAT-Builds mit langer Ausführungszeit haben, wird der Looker-Regenerator-Zyklus möglicherweise nicht so oft ausgeführt, wie in der Einstellung Datengruppe und PAT-Wartungszeitplan definiert. Die Dauer der Neuerstellung Ihrer Tabellen kann auch von anderen Faktoren beeinflusst werden, wie im Abschnitt Wichtige Überlegungen zum Implementieren persistenter Tabellen auf dieser Seite beschrieben.

Wenn eine PDT nicht erstellt werden kann, kann der Regenerator versuchen, die Tabelle im nächsten Regenerator-Zyklus neu zu erstellen:

• Wenn die Einstellung Fehlgeschlagene PAT-Builds wiederholen für Ihre Datenbankverbindung aktiviert ist, versucht der Looker-Regenerator, die Tabelle während des nächsten Regenerator-Zyklus neu zu erstellen, auch wenn die Triggerbedingung der Tabelle nicht erfüllt ist.
• Wenn die Einstellung Fehlgeschlagene PAT-Builds wiederholen deaktiviert ist, versucht der Looker-Regenerator erst dann, die Tabelle neu zu erstellen, wenn die Triggerbedingung der PDT erfüllt ist.

Wenn ein Benutzer Daten aus der persistenten Tabelle anfordert, während diese erstellt wird, und die Abfrageergebnisse nicht im Cache vorhanden sind, überprüft Looker, ob die vorhandene Tabelle noch gültig ist. (Die vorherige Tabelle ist möglicherweise nicht mehr gültig, wenn sie nicht mit der neuen Version der Tabelle kompatibel ist. Dazu kann es beispielsweise kommen, wenn die neue Tabelle eine andere Definition aufweist, eine andere Datenbankverbindung verwendet oder mit einer anderen Looker-Version erstellt wurde.) Wenn die vorhandene Tabelle noch gültig ist, gibt Looker Daten aus der vorhandenen Tabelle zurück, bis die neue Tabelle erstellt wurde. Wenn die vorhandene Tabelle nicht gültig ist, gibt Looker Abfrageergebnisse an, sobald die neue Tabelle erstellt wurde.

Wichtige Aspekte beim Implementieren persistenter Tabellen

Angesichts des Nutzens persistenter Tabellen (PDTs und zusammengefasste Tabellen) ist es einfach, viele davon in Ihrer Looker-Instanz zu akkumulieren. Es ist möglich, ein Szenario zu erstellen, in dem der Looker-Regenerator viele Tabellen gleichzeitig erstellen muss. Besonders bei kaskadierenden Tabellen oder Tabellen mit langer Ausführungszeit kann es vorkommen, dass Tabellen eine lange Verzögerung bei der Neuerstellung haben oder bei denen Nutzer eine Verzögerung beim Abrufen von Abfrageergebnissen aus einer Tabelle bemerken, während die Datenbank intensiv an der Generierung der Tabelle arbeitet.

Der Regenerator von Looker prüft PDT-Trigger darauf, ob Trigger-persistierte Tabellen neu erstellt werden sollen. Der Regenerator-Zyklus wird in einem regelmäßigen Intervall festgelegt, das von Ihrem Looker-Administrator in der Einstellung Wartungszeitplan für Datengruppe und PAT in Ihrer Datenbankverbindung konfiguriert wird (standardmäßig ein Intervall von fünf Minuten).

Verschiedene Faktoren können die Zeit beeinflussen, die für die Neuerstellung Ihrer Tabellen benötigt wird:

• Möglicherweise hat Ihr Looker-Administrator das Intervall der Regenerator-Triggerprüfungen mit der Einstellung Datengruppe und PAT-Wartungszeitplan in Ihrer Datenbankverbindung geändert.
• Der Looker-Regenerator startet erst dann einen neuen Zyklus, wenn alle Überprüfungen und PAT-Neuerstellungen aus dem letzten Zyklus abgeschlossen sind. Wenn Sie also PAT-Builds mit langer Ausführungszeit haben, ist der Looker-Regenerator-Zyklus möglicherweise nicht so häufig wie bei der Einstellung Datengruppe und PAT-Wartungsplan.
• Standardmäßig kann der Regenerator die Neuerstellung von jeweils einer PDT oder aggregierten Tabelle über eine Verbindung starten. Ein Looker-Administrator kann die zulässige Anzahl gleichzeitiger Neuerstellungen des Regenerators über das Feld Maximale Anzahl von PAT-Builder-Verbindungen in den Einstellungen einer Verbindung anpassen.
• Alle PATs und aggregierten Tabellen, die durch dieselbe datagroup ausgelöst werden, werden während desselben Prozesses neu erstellt. Dies kann eine hohe Auslastung sein, wenn die Datengruppe von vielen Tabellen verwendet wird, entweder direkt oder aufgrund von kaskadierenden Abhängigkeiten.

Zusätzlich zu den vorherigen Überlegungen gibt es auch Situationen, in denen Sie das Hinzufügen von Persistenz in einer abgeleiteten Tabelle vermeiden sollten:

• Wenn abgeleitete Tabellen extended werden, wird mit jeder Erweiterung einer PAT eine neue Kopie der Tabelle in der Datenbank erstellt.
• Wenn abgeleitete Tabellen Filtervorlagen oder Liquid-Parameter verwenden, wird die Persistenz für abgeleitete Tabellen, die Filtervorlagen oder Liquid-Parameter verwenden, nicht unterstützt.
• Wenn native abgeleitete Tabellen aus Explores erstellt werden, die Nutzerattribute mit access_filters oder sql_always_where verwenden, werden für jeden angegebenen möglichen Nutzerattributwert Kopien der Tabelle in Ihrer Datenbank erstellt.
• Die zugrunde liegenden Daten ändern sich häufig und Ihr Datenbankdialekt unterstützt keine inkrementellen PATs.
• Wenn die Kosten und der Zeitaufwand für das Erstellen von PDTs zu hoch sind.

Je nach Anzahl und Komplexität der persistenten Tabellen in Ihrer Looker-Verbindung kann die Warteschlange viele persistente Tabellen enthalten, die in jedem Zyklus geprüft und neu erstellt werden müssen. Daher sollten Sie diese Faktoren beim Implementieren abgeleiteter Tabellen in Ihrer Looker-Instanz unbedingt berücksichtigen.

PATs in großem Maßstab über die API verwalten

Das Monitoring und die Verwaltung persistenter abgeleiteter Tabellen (PDTs), die nach unterschiedlichen Zeitplänen aktualisiert werden, werden immer komplexer, je mehr PDTs Sie in Ihrer Instanz erstellen. Sie können die Apache Airflow-Integration von Looker verwenden, um Ihre PAT-Zeitpläne zusammen mit Ihren anderen ETL- und ELT-Prozessen zu verwalten.

PDTs überwachen und Fehler beheben

Wenn Sie persistente abgeleitete Tabellen (PDTs) und insbesondere kaskadierende PDTs verwenden, ist es hilfreich, den Status Ihrer PDTs zu sehen. Auf der Admin-Seite Persistente abgeleitete Tabellen von Looker können Sie den Status Ihrer PDTs sehen. Weitere Informationen finden Sie auf der Dokumentationsseite Administratoreinstellungen – Persistente abgeleitete Tabellen.

Beim Versuch, Fehler bei PATs zu beheben, gilt Folgendes:

• Achten Sie bei der Untersuchung des PDT-Ereignisprotokolls besonders auf den Unterschied zwischen Entwicklungstabellen und Produktionstabellen.
• Vergewissern Sie sich, dass keine Änderungen am Scratch-Schema vorgenommen wurden, in dem Looker persistente abgeleitete Tabellen speichert. Wenn Sie Änderungen vorgenommen haben, müssen Sie möglicherweise die Verbindungseinstellungen im Bereich Admin von Looker aktualisieren und dann Looker neu starten, um die normale PAT-Funktionalität wiederherzustellen.
• Finden Sie heraus, ob es nur mit einer PDT oder mit allen Probleme gibt. Ist nur eine PDT betroffen, wird das Problem wahrscheinlich durch einen LookML- oder SQL-Fehler verursacht.
• Finden Sie heraus, ob Probleme mit der PDT mit den Zeiten übereinstimmen, zu denen sie planmäßig neu erstellt werden soll.
• Alle sql_trigger_value-Abfragen müssen erfolgreich ausgewertet werden und nur eine Zeile und Spalte zurückgeben. Für SQL-basierte PATs können Sie sie in SQL Runner ausführen. (Durch das Anwenden von LIMIT schützen Sie sich vor raffinierten Abfragen.) Weitere Informationen zur Verwendung von SQL Runner zum Debuggen von abgeleiteten Tabellen finden Sie im Communitybeitrag SQL-Runner zum Testen abgeleiteter Tabellen verwenden .
• Überprüfen Sie bei SQL-basierten PDTs mithilfe von SQL Runner, ob der SQL-Code der PDT fehlerfrei ausgeführt wird. (Achten Sie darauf, in SQL Runner einen LIMIT anzuwenden, um die Abfragezeiten angemessen zu halten.)
• Vermeiden Sie für SQL-basierte abgeleitete Tabellen die Verwendung von Common Tabellenausdrücken (CTEs). Wenn Sie CTEs mit DTs verwenden, werden verschachtelte WITH-Anweisungen erstellt, die dazu führen können, dass PATs ohne Warnung fehlschlagen. Verwenden Sie stattdessen den SQL-Code für Ihren CTE, um einen sekundären DT zu erstellen und auf diesen DT von Ihrem ersten DT mit der Syntax ${derived_table_or_view_name.SQL_TABLE_NAME} zu verweisen.
• Prüfen Sie, ob alle Tabellen vorhanden sind, von denen die problematische PDT abhängig ist – ob normale Tabellen oder PDTs selbst – und abgefragt werden können.
• Stellen Sie sicher, dass Tabellen, von denen die problematische PDT abhängig ist, keine gemeinsamen oder exklusiven Sperren aufweisen. Damit Looker eine PDT erfolgreich erstellen kann, muss eine exklusive Sperre für die zu aktualisierende Tabelle eingerichtet werden. Diese würde mit anderen für die Tabelle eingerichteten gemeinsamen oder exklusiven Sperren in Konflikt stehen. Looker kann die PDT erst aktualisieren, wenn alle anderen Sperren entfernt wurden. Dasselbe gilt für exklusive Sperren für die Tabelle, aus der Looker eine PDT erstellt. Wenn eine exklusive Sperre für eine Tabelle vorhanden ist, kann Looker erst dann eine gemeinsame Sperre erhalten, um Abfragen auszuführen, bis die exklusive Sperre aufgehoben wurde.
• Verwenden Sie die Schaltfläche Prozesse in SQL Runner. Wenn viele Prozesse aktiv sind, kann die Abfragedauer zunehmen.
• Überwachen Sie Kommentare in der Abfrage. Weitere Informationen finden Sie im Abschnitt Abfragekommentare für PATs auf dieser Seite.

Abfragekommentare für PDTs

Datenbankadministratoren können ganz einfach normale Abfragen von Abfragen unterscheiden, die persistente abgeleitete Tabellen (PDTs) generieren. Looker fügt der CREATE TABLE ... AS SELECT ...-Anweisung Kommentare hinzu, die das LookML-Modell und die Ansicht der PDT sowie eine eindeutige Kennung (Slug) für die Looker-Instanz enthalten. Wenn die PAT im Namen eines Benutzers im Entwicklungsmodus generiert wird, wird in den Kommentaren die ID des Benutzers angegeben. Die Kommentare zur PDT-Generierung werden nach diesem Muster erstellt:

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

Der Kommentar zur PAT-Generierung wird auf der SQL-Registerkarte eines Explores angezeigt, wenn Looker eine PDT für die Abfrage des Explores generieren musste. Der Kommentar wird oben in der SQL-Anweisung angezeigt.

Schließlich wird der Kommentar zur PAT-Generierung im Feld Nachricht auf dem Tab Info des Pop-up-Fensters Abfragedetails für jede Abfrage auf der Verwaltungsseite Abfragen angezeigt.

PDTs nach einem Fehler neu erstellen

Wenn eine persistente abgeleitete Tabelle (PDT) einen Fehler aufweist, geschieht bei der Abfrage dieser PDT Folgendes:

• Looker prüft anhand der Ergebnisse im Cache, ob dieselbe Abfrage bereits ausgeführt wurde. Weitere Informationen zur Funktionsweise finden Sie auf der Dokumentationsseite Caching-Abfragen.
• Wenn sich die Ergebnisse nicht im Cache befinden, ruft Looker Ergebnisse aus der PDT in der Datenbank ab, sofern eine gültige Version der PDT vorhanden ist.
• Wenn die Datenbank keine gültige PDT enthält, versucht Looker, die PDT neu zu erstellen.
• Wenn die PAT nicht neu erstellt werden kann, gibt Looker bei einer Abfrage einen Fehler zurück. Der Looker-Regenerator versucht, die PDT neu zu erstellen, wenn die PDT das nächste Mal abgefragt wird oder das nächste Mal, wenn die Persistenzstrategie der PDT eine Neuerstellung auslöst.

Bei kaskadierenden PDTs gilt dieselbe Logik, mit Ausnahme der kaskadierenden PDTs:

• Wenn eine Tabelle nicht erstellt werden kann, können auch die nachfolgenden PDTs in der Abhängigkeitskette nicht erstellt werden.
• Eine abhängige PDT fragt im Wesentlichen die PDT ab, von der sie abhängig ist. Daher kann die Persistenzstrategie einer Tabelle Neuerstellungen der PDTs auslösen, die nach oben der Kette erfolgen.

Sehen wir uns noch einmal das vorherige Beispiel der kaskadierenden Tabellen an, in dem TABLE_D von TABLE_C abhängig ist, die wiederum von TABLE_B abhängig ist, die wiederum von TABLE_A abhängig ist:

Wenn TABLE_B einen Fehler aufweist, gilt das gesamte Standardverhalten (nicht kaskadierend) für TABLE_B: Wenn TABLE_B abgefragt wird, versucht Looker zuerst, den Cache zu verwenden, um Ergebnisse zurückzugeben. Anschließend versucht Looker, wenn möglich, eine frühere Version der Tabelle zu verwenden. Danach wird ein Fehler zurückgegeben, wenn TABLE_B nicht neu erstellt werden kann. Looker versucht noch einmal, TABLE_B neu zu erstellen, wenn die Tabelle das nächste Mal abgefragt wird oder die Persistenzstrategie der Tabelle das nächste Mal eine Neuerstellung auslöst.

Dasselbe gilt auch für die abhängigen Elemente von TABLE_B. Wenn also TABLE_B nicht erstellt werden kann und eine Abfrage für TABLE_C erfolgt:

• Looker versucht, den Cache für die Abfrage am TABLE_C zu verwenden.
• Wenn sich die Ergebnisse nicht im Cache befinden, versucht Looker, Ergebnisse aus TABLE_C in der Datenbank abzurufen.
• Wenn keine gültige Version von TABLE_C vorhanden ist, versucht Looker, TABLE_C neu zu erstellen. Dadurch wird eine Abfrage für TABLE_B erstellt.
• Looker versucht dann, TABLE_B neu zu erstellen. Dies schlägt fehl, wenn TABLE_B nicht korrigiert wurde.
• Wenn TABLE_B nicht neu erstellt werden kann, kann TABLE_C nicht neu erstellt werden. Daher gibt Looker für die Abfrage auf TABLE_C einen Fehler zurück.
• Looker versucht dann, TABLE_C gemäß seiner üblichen Persistenzstrategie neu zu erstellen, oder wenn die PDT das nächste Mal abgefragt wird (einschließlich des nächsten Erstellungsversuchs von TABLE_D, da TABLE_D von TABLE_C abhängt).

Sobald Sie das Problem mit TABLE_B behoben haben, versuchen TABLE_B und jede der abhängigen Tabellen, entsprechend ihren Persistenzstrategien oder bei der nächsten Abfrage (einschließlich der nächsten Neuerstellung einer abhängigen PDT) neu zu erstellen. Wenn eine Entwicklungsversion der PDTs in der Kaskade im Entwicklungsmodus erstellt wurde, können die Entwicklungsversionen als die neuen Produktions-PDTs verwendet werden. Weitere Informationen finden Sie im Abschnitt Persistente Tabellen im Entwicklungsmodus auf dieser Seite. Alternativ können Sie mit einem Explore eine Abfrage für TABLE_D ausführen und dann die PDTs für die Abfrage manuell neu erstellen. Dadurch wird eine Neuerstellung aller PDTs erzwungen, die die Abhängigkeitskaskade durchläuft.

PAT-Leistung verbessern

Wenn Sie nichtflüchtige abgeleitete Tabellen (PDTs) erstellen, kann die Leistung zu einem Problem werden. Besonders wenn die Tabelle sehr groß ist, kann das Abfragen der Tabelle langsam sein, genau wie bei jeder anderen großen Tabelle in Ihrer Datenbank.

Sie können die Leistung verbessern, indem Sie die Daten filtern oder steuern, wie die Daten in der PAT sortiert und indexiert werden.

Filter zum Begrenzen des Datasets hinzufügen

Bei besonders großen Datasets verlangsamt viele Zeilen Abfragen in Bezug auf eine persistente abgeleitete Tabelle (PDT). Wenn Sie normalerweise nur aktuelle Daten abfragen, sollten Sie der WHERE-Klausel Ihrer PAT einen Filter hinzufügen, der die Tabelle auf Daten von maximal 90 Tagen beschränkt. Auf diese Weise werden der Tabelle bei jeder Neuerstellung nur relevante Daten hinzugefügt, sodass Abfragen viel schneller ausgeführt werden. Anschließend können Sie eine separate, größere PAT für die Verlaufsanalyse erstellen, um sowohl schnelle Abfragen aktueller Daten als auch alte Daten zu ermöglichen.

indexes oder sortkeys und distribution werden verwendet

Wenn Sie eine große persistente abgeleitete Tabelle (PDT) erstellen, können Sie die Leistung verbessern, indem Sie die Tabelle indexieren (für Dialekte wie MySQL oder Postgres) oder Sortierschlüssel und Distribution hinzufügen (für Redshift).

In der Regel empfiehlt es sich, den Parameter indexes in ID- oder Datumsfelder einzufügen.

Bei Redshift ist es in der Regel am besten, den sortkeys-Parameter in ID- oder Datumsfeldern und den distribution-Parameter in das Feld einzufügen, das für den Join verwendet wird.

Empfohlene Einstellungen zur Leistungsverbesserung

Mit den folgenden Einstellungen wird gesteuert, wie die Daten in der persistenten abgeleiteten Tabelle (PAT) sortiert und indexiert werden. Die folgenden Einstellungen sind optional, werden aber dringend empfohlen:

• Verwenden Sie für Redshift und Aster den Parameter distribution, um den Spaltennamen anzugeben, dessen Wert zur Verteilung der Daten in einem Cluster verwendet wird. Wenn zwei Tabellen durch die im Parameter distribution angegebene Spalte verknüpft werden, kann die Datenbank die Join-Daten auf demselben Knoten finden, sodass die E/A zwischen Knoten minimiert wird.
• Setzen Sie bei Redshift den distribution_style-Parameter auf all, um die Datenbank anzuweisen, eine vollständige Kopie der Daten auf jedem Knoten zu speichern. Dies wird häufig verwendet, um die E/A zwischen Knoten zu minimieren, wenn relativ kleine Tabellen zusammengeführt werden. Legen Sie diesen Wert auf even fest, um die Datenbank anzuweisen, die Daten ohne Verwendung einer Verteilungsspalte gleichmäßig über den Cluster zu verteilen. Dieser Wert kann nur angegeben werden, wenn distribution nicht festgelegt ist.
• Verwenden Sie für Redshift den Parameter sortkeys. Die Werte geben an, welche Spalten der PAT zum Sortieren der Daten auf dem Datenträger verwendet werden, um die Suche zu erleichtern. Auf Redshift können Sie entweder sortkeys oder indexes verwenden, aber nicht beides.
• Bei den meisten Datenbanken verwenden Sie den Parameter indexes. Die Werte geben an, welche Spalten der PAT indexiert werden. (In Redshift werden Indexe zum Generieren überlappender Sortierschlüssel verwendet.)