Abgeleitete Tabellen in Looker

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

Angenommen, Sie verwenden eine Datenbanktabelle mit dem Namen orders mit zahlreichen 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.

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

Informationen zu gängigen Anwendungsfällen von abgeleiteten Tabellen finden Sie unter Looker-Rezeptbücher: Abgeleitete Tabellen in Looker optimal nutzen.

Native abgeleitete Tabellen und SQL-basierte abgeleitete Tabellen

Wenn Sie eine abgeleitete Tabelle in Ihrem Looker-Projekt erstellen möchten, verwenden Sie den Parameter derived_table unter einem Ansicht-Parameter. Im derived_table-Parameter können Sie die Abfrage für die abgeleitete Tabelle auf eine von zwei Arten definieren:

• Eine native abgeleitete Tabelle definieren Sie mit einer LookML-basierten Abfrage.
• Eine SQL-basierte abgeleitete Tabelle definieren Sie 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 beiden 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:

• In der nativen abgeleiteten Tabelle wird die Abfrage mit LookML im Parameter explore_source definiert. In diesem Beispiel basiert die Abfrage auf einer vorhandenen orders-Ansicht, die in einer separaten Datei definiert ist, die in diesem Beispiel nicht angezeigt wird. Die Abfrage explore_source in der nativen abgeleiteten Tabelle ruft die Felder customer_id, first_order und total_amount aus der Ansichtsdatei orders ab.
• In der SQL-basierten abgeleiteten Tabelle wird die Abfrage im Parameter sql mit SQL definiert. 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 ;;
  }
}

In beiden Versionen wird eine Ansicht namens customer_order_summary erstellt, die auf der Tabelle orders mit den Spalten customer_id, first_order, und total_amount basiert.

Abgesehen vom Parameter derived_table und seinen 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 basierend auf den Spalten der abgeleiteten Tabelle erstellen.

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. Um eine native abgeleitete Tabelle zu erstellen, verwenden Sie den Parameter explore_source im Parameter derived_table eines Ansichtsparameters. Sie erstellen die Spalten der nativen abgeleiteten Tabelle, indem Sie die LookML-Dimensionen oder -Messwerte in Ihrem Modell referenzieren. Sie finden sie in der Beispieldatei oben.

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. Sie finden sie in der Ansichtsdatei für die SQL-basierte abgeleitete Tabelle im vorherigen Beispiel.

In den meisten Fällen wird die SQL-Abfrage mit dem Parameter sql im Parameter derived_table eines Ansichtsparameters definiert.

Eine praktische Verknüpfung zum Erstellen von SQL-basierten Abfragen in Looker ist die SQL-Abfrage mit SQL Runner erstellen und in eine Definition einer abgeleiteten Tabelle umwandeln.

In manchen Edge-Fällen kann der sql-Parameter nicht verwendet werden. In diesen Fällen unterstützt Looker die folgenden Parameter zum Definieren einer SQL-Abfrage für persistente abgeleitete Tabellen (PDTs):

• create_process: Wenn Sie den Parameter sql für eine PDT verwenden, umgibt Looker im Hintergrund die CREATE TABLE DDL-Anweisung (Data Definition Language) des Dialects mit Ihrer Abfrage, um die PDT aus Ihrer SQL-Abfrage zu erstellen. Eine SQL-CREATE TABLE-Anweisung in einem einzigen Schritt wird von einigen Dialekten nicht unterstützt. Bei diesen Dialekten können Sie keine PDT mit dem Parameter sql erstellen. Sie können stattdessen aber den Parameter create_process verwenden, um PDTs in mehreren Schritten zu erstellen. Weitere Informationen und Beispiele finden Sie auf der Seite mit der Parameterdokumentation zu create_process.
• sql_create: Wenn für Ihren Anwendungsfall benutzerdefinierte DDL-Befehle erforderlich sind und Ihr Dialekt DDL unterstützt (z. B. die Google-Prognosefunktion BigQuery ML), können Sie den Parameter sql_create verwenden, um eine PDT zu erstellen, anstatt den Parameter sql. Weitere 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 die abgeleitete Tabelle in jedem Fall mit einer SQL-Abfrage. Daher werden diese als SQL-basierte abgeleitete Tabellen betrachtet.

Achten Sie beim Definieren einer SQL-basierten abgeleiteten Tabelle darauf, jeder Spalte einen eindeutigen Alias mit AS zuzuweisen. Grund dafür ist, dass Sie die Spaltennamen Ihres Ergebnissatzes in Ihren Dimensionen referenzieren müssen, z. B. ${TABLE}.first_order. Deshalb wird im vorherigen Beispiel MIN(DATE(time)) AS first_order anstelle von MIN(DATE(time)) verwendet.

Hinweis: Damit eine SQL-basierte abgeleitete Tabelle als inkrementelle PDT 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

Neben der Unterscheidung zwischen nativen abgeleiteten Tabellen und SQL-basierten abgeleiteten Tabellen gibt es auch eine Unterscheidung zwischen einer vorübergehenden abgeleiteten Tabelle, die nicht in die Datenbank geschrieben wird, und einer persistenten abgeleiteten Tabelle (PDT), die in ein Schema in Ihrer Datenbank geschrieben wird.

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

Temporäre abgeleitete Tabellen

Die oben gezeigten abgeleiteten Tabellen sind Beispiele für temporäre abgeleitete Tabellen. Sie sind temporär, da im Parameter derived_table keine Persistenzstrategie definiert ist.

Temporäre abgeleitete Tabellen werden nicht in die Datenbank geschrieben. Wenn ein Nutzer eine Explore-Abfrage mit einer oder mehreren abgeleiteten Tabellen ausführt, erstellt Looker eine SQL-Abfrage mit einer dialektspezifischen Kombination des SQL-Codes für die abgeleitete(n) Tabelle(n) sowie für die angeforderten Felder, Joins und Filterwerte. 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 Abfragen im Cache speichern.

Wenn Looker keine zwischengespeicherten Ergebnisse verwenden kann, muss jedes Mal, wenn ein Benutzer Daten von einer temporären abgeleiteten Tabelle anfordert, eine neue Abfrage in der Datenbank ausgeführt werden. Daher sollten Sie darauf achten, dass Ihre temporären abgeleiteten Tabellen leistungsstark sind und die Datenbank nicht übermäßig belasten. Wenn die Abfrage längere Zeit in Anspruch nimmt, ist eine PDT oftmals die bessere Lösung.

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. In der folgenden Tabelle ist zu sehen, welche Dialekte abgeleitete Tabellen in der aktuellen Looker-Version unterstützen:

Dialekt	Unterstützt?
Actian Avalanche	Ja
Amazon Athena	Ja
Amazon Aurora MySQL	Ja
Amazon Redshift	Ja
Apache Druid	Ja
Apache Druid 0.13 oder höher	Ja
Apache Druid 0.18 und höher	Ja
Apache Hive 2.3 und höher	Ja
Apache Hive 3.1.2 und höher	Ja
Apache Spark 3 und höher	Ja
ClickHouse	Ja
Cloudera Impala 3.1 und höher	Ja
Cloudera Impala 3.1 und höher mit nativem Treiber	Ja
Cloudera Impala mit nativem Treiber	Ja
DataVirtuality	Ja
Databricks	Ja
Denodo 7	Ja
Denodo 8	Ja
Dremio	Ja
Dremio 11 und höher	Ja
Exasol	Ja
Firebolt	Ja
Google BigQuery Legacy SQL	Ja
Google BigQuery Standard SQL	Ja
Google Cloud PostgreSQL	Ja
Google Cloud SQL	Ja
Google Spanner	Ja
Greenplum	Ja
HyperSQL	Ja
IBM Netezza	Ja
MariaDB	Ja
Microsoft Azure PostgreSQL	Ja
Microsoft Azure SQL-Datenbank	Ja
Microsoft Azure Synapse Analytics	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 und höher	Ja
Oracle	Ja
Oracle ADWC	Ja
PostgreSQL 9.5 und höher	Ja
PostgreSQL vor Version 9.5	Ja
PrestoDB	Ja
PrestoSQL	Ja
SAP HANA 2 und höher	Ja
SingleStore	Ja
SingleStore 7+	Ja
Snowflake	Ja
Teradata	Ja
Trino	Ja
Vektor	Ja
Vertica	Ja

Persistente abgeleitete Tabellen

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

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

Anforderungen an PDTs

Um persistente abgeleitete Tabellen (PDTs) in Ihrem Looker-Projekt zu verwenden, benötigen Sie Folgendes:

• Einen Datenbankdialekt, der PDTs unterstützt. Im Abschnitt Unterstützte Datenbankdialekte für PDTs weiter unten auf dieser Seite finden Sie Listen der Dialekte, die persistente SQL-basierte abgeleitete Tabellen und persistente 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.

  Warnung :Wenn Sie mehrere Looker-Instanzen haben, z. B. eine Produktions- und eine QA-Instanz, müssen Sie für jede Instanz unterschiedliche Scratch-Schemas festlegen, um Konflikte bei der PDT-Verwaltung zu vermeiden.

• Eine Looker-Verbindung, für die die Option PDTs aktivieren aktiviert ist. Diese Einstellung wird normalerweise bei der Erstkonfiguration der Looker-Verbindung vorgenommen. Eine Anleitung für Ihren Datenbankdialekt finden Sie auf der Dokumentationsseite Looker-Dialekte. Sie können PDTs für Ihre Verbindung aber auch nach der Ersteinrichtung aktivieren.

Unterstützte Datenbankdialekte für PDTs

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

Um alle Arten von PDTs (sowohl LookML-basiert als auch SQL-basiert) zu unterstützen, muss der Dialekt unter anderem Schreibvorgänge in die Datenbank unterstützen. Es gibt einige schreibgeschützte Datenbankkonfigurationen, die Persistenz verhindern (vor allem Postgres Hot-Swap-Replikationsdatenbanken). In diesen Fällen können Sie stattdessen temporäre abgeleitete Tabellen verwenden.

In der folgenden Tabelle sind die Dialekte aufgeführt, die in der neuesten Version von Looker persistente SQL-basierte abgeleitete Tabellen unterstützen:

Dialekt	Unterstützt?
Actian Avalanche	Ja
Amazon Athena	Ja
Amazon Aurora MySQL	Ja
Amazon Redshift	Ja
Apache Druid	Nein
Apache Druid 0.13 oder höher	Nein
Apache Druid 0.18 und höher	Nein
Apache Hive 2.3 und höher	Ja
Apache Hive 3.1.2 und höher	Ja
Apache Spark 3 und höher	Ja
ClickHouse	Nein
Cloudera Impala 3.1 und höher	Ja
Cloudera Impala 3.1 und höher mit nativem Treiber	Ja
Cloudera Impala mit nativem Treiber	Ja
DataVirtuality	Nein
Databricks	Ja
Denodo 7	Nein
Denodo 8	Nein
Dremio	Nein
Dremio 11 und höher	Nein
Exasol	Ja
Firebolt	Nein
Google BigQuery Legacy SQL	Ja
Google BigQuery Standard SQL	Ja
Google Cloud PostgreSQL	Ja
Google Cloud SQL	Ja
Google Spanner	Nein
Greenplum	Ja
HyperSQL	Nein
IBM Netezza	Ja
MariaDB	Ja
Microsoft Azure PostgreSQL	Ja
Microsoft Azure SQL-Datenbank	Ja
Microsoft Azure Synapse Analytics	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 und höher	Ja
Oracle	Ja
Oracle ADWC	Ja
PostgreSQL 9.5 und höher	Ja
PostgreSQL vor Version 9.5	Ja
PrestoDB	Ja
PrestoSQL	Ja
SAP HANA 2 und höher	Ja
SingleStore	Ja
SingleStore 7+	Ja
Snowflake	Ja
Teradata	Ja
Trino	Ja
Vektor	Ja
Vertica	Ja

Um persistente native abgeleitete Tabellen (mit LookML-basierten Abfragen) zu unterstützen, muss der Dialekt auch eine CREATE TABLE-DDL-Funktion unterstützen. Hier ist eine Liste der Dialekte, die persistente native (LookML-basierte) abgeleitete Tabellen in der neuesten Version von Looker unterstützen:

Dialekt	Unterstützt?
Actian Avalanche	Ja
Amazon Athena	Ja
Amazon Aurora MySQL	Ja
Amazon Redshift	Ja
Apache Druid	Nein
Apache Druid 0.13 oder höher	Nein
Apache Druid 0.18 und höher	Nein
Apache Hive 2.3 und höher	Ja
Apache Hive 3.1.2 und höher	Ja
Apache Spark 3 und höher	Ja
ClickHouse	Nein
Cloudera Impala 3.1 und höher	Ja
Cloudera Impala 3.1 und höher mit nativem Treiber	Ja
Cloudera Impala mit nativem Treiber	Ja
DataVirtuality	Nein
Databricks	Ja
Denodo 7	Nein
Denodo 8	Nein
Dremio	Nein
Dremio 11 und höher	Nein
Exasol	Ja
Firebolt	Nein
Google BigQuery Legacy SQL	Ja
Google BigQuery Standard SQL	Ja
Google Cloud PostgreSQL	Ja
Google Cloud SQL	Nein
Google Spanner	Nein
Greenplum	Ja
HyperSQL	Nein
IBM Netezza	Ja
MariaDB	Ja
Microsoft Azure PostgreSQL	Ja
Microsoft Azure SQL-Datenbank	Ja
Microsoft Azure Synapse Analytics	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 und höher	Ja
Oracle	Ja
Oracle ADWC	Ja
PostgreSQL 9.5 und höher	Ja
PostgreSQL vor Version 9.5	Ja
PrestoDB	Ja
PrestoSQL	Ja
SAP HANA 2 und höher	Ja
SingleStore	Ja
SingleStore 7+	Ja
Snowflake	Ja
Teradata	Ja
Trino	Ja
Vektor	Ja
Vertica	Ja

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

Inkrementelle Erstellung von PDTs

Eine inkrementelle PDT ist eine persistente abgeleitete Tabelle (PDT), die von Looker erstellt wird. Dabei werden neue Daten an die Tabelle angehängt, anstatt dass die ganze Tabelle neu erstellt wird.

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

Hinweis: Inkrementelle PDTs werden nicht für PDTs unterstützt, die die persist_for-Persistenzstrategie verwenden.

Weitere Informationen finden Sie auf der Dokumentationsseite zu inkrementellen PDTs.

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. In der folgenden Tabelle ist zu sehen, welche Dialekte in der aktuellen Looker-Version inkrementelle PDTs unterstützen:

Dialekt	Unterstützt?
Actian Avalanche	Nein
Amazon Athena	Nein
Amazon Aurora MySQL	Nein
Amazon Redshift	Ja
Apache Druid	Nein
Apache Druid 0.13 oder höher	Nein
Apache Druid 0.18 und höher	Nein
Apache Hive 2.3 und höher	Nein
Apache Hive 3.1.2 und höher	Nein
Apache Spark 3 und höher	Nein
ClickHouse	Nein
Cloudera Impala 3.1 und höher	Nein
Cloudera Impala 3.1 und höher mit nativem Treiber	Nein
Cloudera Impala mit nativem Treiber	Nein
DataVirtuality	Nein
Databricks	Ja
Denodo 7	Nein
Denodo 8	Nein
Dremio	Nein
Dremio 11 und höher	Nein
Exasol	Nein
Firebolt	Nein
Google BigQuery Legacy SQL	Nein
Google BigQuery Standard SQL	Ja
Google Cloud PostgreSQL	Ja
Google Cloud SQL	Nein
Google Spanner	Nein
Greenplum	Ja
HyperSQL	Nein
IBM Netezza	Nein
MariaDB	Nein
Microsoft Azure PostgreSQL	Ja
Microsoft Azure SQL-Datenbank	Nein
Microsoft Azure Synapse Analytics	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 und höher	Ja
Oracle	Nein
Oracle ADWC	Nein
PostgreSQL 9.5 und höher	Ja
PostgreSQL vor Version 9.5	Ja
PrestoDB	Nein
PrestoSQL	Nein
SAP HANA 2 und höher	Nein
SingleStore	Nein
SingleStore 7+	Nein
Snowflake	Ja
Teradata	Nein
Trino	Nein
Vektor	Nein
Vertica	Ja

PDTs 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 in Looker oder, bei Dialekten, die materialisierte Ansichten unterstützen, in der Datenbank mithilfe von materialisierten Ansichten verwaltet werden.

Um eine abgeleitete Tabelle persistent zu machen, fügen Sie einen der folgenden Parameter zur derived_table-Definition hinzu:

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

Bei triggerbasierten 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 PDT überschreiben. Nutzer mit der Berechtigung develop können über das Menü eines Explores die Option Abgeleitete Tabellen neu erstellen und ausführen verwenden, um die Einstellung für die Persistenz zu überschreiben und alle PATs neu zu erstellen, die für die aktuelle Abfrage im Explore erforderlich sind. Weitere Informationen finden Sie auf dieser Seite im Abschnitt PDTs für eine Abfrage manuell neu erstellen.

datagroup_trigger

Datengruppen sind die flexibelste Methode zur Schaffung von Persistenz. 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 Nutzer Daten von der PDT anfordert, während diese erstellt wird, und die Abfrageergebnisse nicht im Cache enthalten sind, gibt Looker Daten aus der vorhandenen PDT zurück, bis die neue PDT erstellt wurde. Eine Übersicht über Datengruppen finden Sie unter Abfragen im Cache speichern.

Weitere Informationen zur Erstellung von PDTs durch den Regenerator finden Sie im Abschnitt Looker-Regenerator.

sql_trigger_value

Der Parameter sql_trigger_value löst die Neugenerierung einer persistenten abgeleiteten Tabelle (PDT) basierend auf 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 Nutzer Daten von der PDT anfordert, während diese erstellt wird, und die Abfrageergebnisse nicht im Cache enthalten sind, gibt Looker Daten aus der vorhandenen PDT zurück, bis die neue PDT erstellt wurde.

Weitere Informationen zur Erstellung von PDTs durch den Regenerator finden Sie im Abschnitt Looker-Regenerator.

interval_trigger

Der Parameter interval_trigger löst die Regeneration einer persistenten abgeleiteten Tabelle (PDT) basierend auf einem von Ihnen angegebenen Zeitintervall aus, z. B. "24 hours" oder "60 minutes". Ähnlich wie beim sql_trigger-Parameter bedeutet dies, dass die PDT normalerweise vorab erstellt wird, wenn der Nutzer diese anfragt. Wenn ein Nutzer Daten von der PDT anfordert, während diese erstellt wird, und die Abfrageergebnisse nicht im Cache enthalten sind, gibt Looker Daten aus der vorhandenen PDT zurück, bis die neue PDT erstellt wurde.

persist_for

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

Eine persist_for persistente abgeleitete Tabelle (PDT) wird erstellt, wenn ein Nutzer zum ersten Mal eine Abfrage damit ausführt. Looker behält die PDT dann so lange wie im persist_for-Parameter der PDT angegeben in der Datenbank bei. Wenn ein Nutzer die PDT innerhalb der persist_for-Zeit abfragt, verwendet Looker nach Möglichkeit zwischengespeicherte Ergebnisse. Andernfalls wird die Abfrage mit der PDT ausgeführt.

Nach Ablauf der persist_for löscht Looker die PDT aus der Datenbank. Sie wird dann bei der nächsten Abfrage durch einen Benutzer neu erstellt. In dem Fall muss die Abfrage warten, bis die Neuerstellung abgeschlossen ist.

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

materialized_view: yes

Hinweis :Die Funktion für eine materialisierte Ansicht ist eine erweiterte Funktion. Abhängig von Ihrem Dialekt kann eine materialisierte Ansicht viele Ressourcen verbrauchen. Es ist daher wichtig, dass Sie verstehen, wie Ihr Dialekt materialisierte Ansichten implementiert. In der Dokumentation Ihres Dialekts finden Sie weitere Informationen zum Verhalten Ihres Dialekts und zur Häufigkeit, mit der er Daten von materialisierten Ansichten aktualisiert.

Mit materialisierten Ansichten können Sie die Funktionen Ihrer Datenbank nutzen, um abgeleitete Tabellen in Ihrem Looker-Projekt zu speichern. Wenn Ihr Datenbankdialekt materialisierte Ansichten unterstützt und die Looker-Verbindung so konfiguriert ist, dass die Option PDTs 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 eine persistente abgeleitete Tabelle (PDT) ist eine materialisierte Ansicht ein Abfrageergebnis, das im Scratch-Schema Ihrer Datenbank als Tabelle 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, Anforderungen und wichtigen Überlegungen finden Sie auf der Seite mit der Parameterdokumentation zu materialized_view.

Optimierungsstrategien

Da persistente abgeleitete Tabellen (PDTs) in Ihrer Datenbank gespeichert werden, sollten Sie die PDTs mit den folgenden Strategien optimieren, je nach Unterstützung durch Ihren Dialekt:

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

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

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 zur Steigerung der Abfrageleistung nachholen sollten.

Anwendungsfälle für PDTs

Persistent Derived Tables (PDTs, persistente abgeleitete Tabellen) sind nützlich, da sie die Leistung einer Abfrage verbessern können, indem die Ergebnisse der Abfrage in einer Tabelle gespeichert werden.

Als allgemeine Best Practice sollten Entwickler versuchen, Daten so weit wie möglich ohne PDTs zu modellieren.

In einigen Fällen können Daten auch auf andere Weise optimiert werden. Beispielsweise kann ein Problem durch das Hinzufügen eines Index oder das Ändern des Datentyps einer Spalte behoben werden, ohne dass eine PDT erstellt werden muss. Analysieren Sie die Ausführungspläne langsamer Abfragen mit dem Tool „Erläutern“ in SQL Runner.

Neben der Verringerung der Abfragezeit und der Datenbankbelastung bei häufig ausgeführten Abfragen gibt es noch mehrere andere Anwendungsfälle für PDTs, darunter:

• Optimierungen testen
• Daten vor dem Zusammenführen zusammenführen oder aggregieren

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

PDTs zum Testen von Optimierungen verwenden

Mithilfe von PDTs können Sie verschiedene Indexierungs-, Verteilungs- und andere Optimierungsoptionen testen, ohne dass Sie viel Unterstützung von Ihren DBAs oder ETL-Entwicklern benötigen.

Angenommen, Sie haben eine Tabelle, möchten aber verschiedene Indizes testen. Die erste LookML-Datei für die Ansicht könnte so aussehen:

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

Wenn Sie Optimierungsstrategien testen möchten, können Sie mit dem Parameter indexes Indizes zur LookML hinzufügen. So gehts:

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

Stellen Sie eine einmalige Abfrage an die Ansicht, um die PDT zu generieren. Führen Sie dann Ihre Testabfragen aus und vergleichen Sie die Ergebnisse. Wenn die Ergebnisse positiv sind, können Sie Ihr DBA- oder ETL-Team bitten, die Indizes der ursprünglichen Tabelle hinzuzufügen.

Denken Sie daran, den Ansichtscode wieder so zu ändern, dass die PDT entfernt wird.

Daten vor dem Zusammenführen oder Aggregieren mithilfe von PDTs zusammenführen

Es kann nützlich sein, Daten vorab zusammenzuführen oder zusammenzufassen, um die Abfrageoptimierung für große Datenmengen oder mehrere Datentypen anzupassen.

Angenommen, Sie möchten eine Abfrage für Kunden nach Kohorte erstellen, basierend darauf, wann sie ihre erste Bestellung aufgegeben haben. Wenn diese Abfrage jedes Mal ausgeführt werden muss, wenn die Daten in Echtzeit benötigt werden, kann das teuer werden. Sie können die Abfrage jedoch nur einmal berechnen und die Ergebnisse dann 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 abgeleiteten Tabelle auf eine andere zu verweisen. Dies kann eine Kette von kaskadierenden abgeleiteten Tabellen oder kaskadierenden persistenten abgeleiteten Tabellen (PDTs) bilden. Ein Beispiel für kaskadierende abgeleitete Tabellen wäre eine Tabelle TABLE_D, die von einer anderen Tabelle TABLE_C abhängt, während TABLE_C von TABLE_B und TABLE_B von TABLE_A abhängt.

Hinweis: Bevor Sie abgeleitete Tabellen mit Kaskade einrichten, sollten Sie wissen, wie diese automatisch vom Looker-Regenerator neu erstellt und wie sie manuell von Nutzern neu erstellt werden. 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. Beispiel: Sie können mit der folgenden 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 in diesem Fall ist SQL_TABLE_NAME ein literaler String.

Hinweis :Die ${derived_table_or_view_name.SQL_TABLE_NAME}-Syntax wird im Parameter sql_trigger einer Datengruppe nicht unterstützt. Sie können also keine abgeleitete Tabelle verwenden, um eine Datengruppe auszulösen. Sie können jedoch die ${derived_table_or_view_name.SQL_TABLE_NAME}-Syntax im Parameter sql_trigger_value verwenden, um Neuaufbaue der PDT auszulösen.

Im nächsten Beispiel wird die PDT clean_events aus der Tabelle events in der Datenbank erstellt. In der PDT clean_events werden unerwünschte Zeilen aus der Datenbanktabelle events ausgelassen. 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 PDT event_summary und die PDT clean_events sind kaskadierende PDTs, wobei event_summary von clean_events abhängig ist, da event_summary anhand der PDT clean_events definiert ist. Dieser spezielle Beispielvorgang könnte in einer einzelnen PDT effizienter durchgeführt werden, ist aber nützlich zur Veranschaulichung von Verweisen auf abgeleitete Tabellen.

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

Oftmals ist es hilfreich, beim Verweisen auf eine abgeleitete Tabelle in dieser Form einen Aliasnamen für die Tabelle im folgenden Format zu verwenden:

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

Das vorherige Beispiel führt Folgendes aus:

${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) vergisst man schnell, dass man zum Abrufen dieses langen Namens die Syntax ${derived_table_or_view_name.SQL_TABLE_NAME} verwenden muss. Mit einem Aliasnamen kann dieser Fehler vermieden werden.

So erstellt Looker kaskadierende abgeleitete Tabellen

Wenn die Abfrageergebnisse eines Nutzers bei kaskadierenden temporären abgeleiteten Tabellen nicht im Cache enthalten sind, erstellt Looker alle abgeleiteten Tabellen, die für die Abfrage benötigt werden. Wenn TABLE_D eine Definition mit einem Verweis auf TABLE_C enthält, ist TABLE_D von TABLE_C abhängig. Wenn Sie also TABLE_D abfragen und die Abfrage nicht im Cache von Looker enthalten ist, erstellt Looker TABLE_D neu. Zuerst muss TABLE_C neu erstellt werden.

Betrachten wir nun ein Szenario mit verschachtelten temporären abgeleiteten Tabellen, bei dem TABLE_D von TABLE_C abhängt, das wiederum von TABLE_B abhängt, das wiederum von TABLE_A abhängt. Wenn Looker keine gültigen Ergebnisse für eine Abfrage von TABLE_C im Cache enthält, erstellt Looker alle für die Abfrage benötigten Tabellen. In Looker werden also zuerst TABLE_A, dann TABLE_B und dann TABLE_C erstellt:

In diesem Szenario muss die Generierung von TABLE_A abgeschlossen sein, bevor Looker mit der Generierung von TABLE_B beginnen kann. So geht es weiter, bis TABLE_C fertig ist und Looker die Abfrageergebnisse bereitstellen kann. Da TABLE_D nicht zur Beantwortung dieser Abfrage benötigt wird, wird TABLE_D in Looker derzeit nicht neu erstellt.

Auf der Seite mit der Parameterdokumentation für datagroup finden Sie ein Beispielszenario für kaskadierende PDTs, die dieselbe Datengruppe verwenden.

Dieselbe grundlegende Logik gilt für PDTs: Looker erstellt alle zum Beantworten einer Abfrage erforderlichen Tabellen entlang der ganzen Abhängigkeitskette. Bei PDTs sind die Tabellen aber oft schon vorhanden, sodass sie nicht neu erstellt werden müssen. Bei Standardbenutzerabfragen 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 eine Erzwingung der Neuerstellung für alle PDTs in einer Kaskade erzwingen möchten, können Sie die Tabellen für eine Abfrage manuell neu erstellen.

Beachten Sie unbedingt im Zusammenhang mit einer PDT-Kaskade, dass eine abhängige PDT im Wesentlichen die PDT abfragt, von der sie abhängig ist. Das ist vor allem für PDTs wichtig, die die persist_for-Strategie verwenden. In der Regel werden persist_for-PDTs erstellt, wenn ein Nutzer sie abfragt. Sie verbleiben dann bis zum Ende ihres persist_for-Intervalls in der Datenbank und werden dann erst wieder neu erstellt, wenn sie erneut von einem Nutzer abgefragt werden. Wenn eine persist_for-PDT jedoch Teil einer Kaskade mit triggerbasierten PDTs ist (PDTs, die die Persistenzstrategie datagroup_trigger, interval_trigger oder sql_trigger_value verwenden), wird die persist_for-PDT im Grunde immer 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 PDTs 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 Einstellungen für die Persistenz 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 sichtbar und nur nach dem Laden der explorativen Datenanalyse.

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

Bei inkrementellen PDTs wird mit der Option Abgeleitete Tabellen neu erstellen und ausführen ein neues Inkrement erstellt. Bei inkrementellen PDTs enthält ein Inkrement den im Parameter increment_key angegebenen Zeitraum sowie gegebenenfalls die Anzahl der vorherigen Zeiträume, die im Parameter increment_offset angegeben sind. Auf der Dokumentationsseite Inkrementelle PDTs finden Sie einige Beispielszenarien, die zeigen, wie inkrementelle PDTs je nach Konfiguration erstellt werden.

Bei kaskadierenden PDTs werden alle abgeleiteten Tabellen in der Kaskade von oben nach unten neu erstellt. Das ist mit dem Verhalten beim Abfragen einer Tabelle in einer Kaskade aus temporären abgeleiteten Tabellen identisch:

Beachten Sie Folgendes, wenn Sie abgeleitete Tabellen manuell neu erstellen:

• Für den Nutzer, der den Vorgang Abgeleitete Tabellen neu erstellen und ausführen startet, werden die Ergebnisse erst geladen, wenn die Tabellen neu erstellt wurden. Abfragen anderer Nutzer verwenden weiterhin die vorhandenen Tabellen. Sobald die persistenten Tabellen neu erstellt wurden, verwenden alle Nutzer die neu erstellten Tabellen. Dieser Prozess soll verhindern, dass die Abfragen anderer Nutzer während der Neuerstellung der Tabellen unterbrochen werden. Diese Nutzer können allerdings dennoch von der zusätzlichen Belastung der 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 Nutzer 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 mit dem Vorgang Abgeleitete Tabellen neu erstellen und ausführen die Entwicklungstabelle und nicht die Produktionstabelle für das Explore neu erstellt. Wenn im Explore im Entwicklungsmodus jedoch die Produktionsversion einer abgeleiteten Tabelle verwendet wird, wird die Produktionstabelle neu erstellt. Informationen zu Entwicklungs- und Produktionstabellen finden Sie unter Persistente Tabellen im Entwicklungsmodus.

• Bei Looker-gehosteten Instanzen dauert die Neuerstellung der abgeleiteten Tabelle länger als eine Stunde. In diesem Fall wird die Tabelle nicht neu erstellt und die Browsersitzung läuft ab. Weitere Informationen zu Zeitüberschreitungen, die sich auf Looker-Prozesse auswirken können, finden Sie auf der Seite Verwaltungseinstellungen – Abfragen im Abschnitt Abfragezeitüberschreitungen und ‑warteschlangen.

Persistente Tabellen im Entwicklungsmodus

In Looker gibt es spezielle Verhaltensweisen zum Verwalten persistenter Tabellen im Entwicklungsmodus.

Hinweis: Diese Verhaltensweisen gelten für alle Arten von persistenten Tabellen, einschließlich aggregierter Tabellen und nichtflüchtiger abgeleiteter 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 Änderungen an der Tabellendefinition vornehmen, die sich auf die Daten in der Tabelle oder auf die Abfrageart der Tabelle auswirken, wird beim nächsten Abfragen 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 aufweist, mit dem das Dataset verringert wird, damit es im Entwicklungsmodus schneller funktioniert
• 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 mit einer bedingten WHERE-Klausel mit if prod- und if dev-Anweisungen definiert ist.

Hinweis: Dies gilt nicht für native abgeleitete Tabellen mit dem Parameter dev_filters. Bei nativen abgeleiteten Tabellen mit dev_filters verwendet Looker die Produktionstabelle zum Beantworten von Abfragen im Entwicklungsmodus, es sei denn, Sie ändern die Definition der Tabelle und fragen die Tabelle dann im Entwicklungsmodus ab.

Bei persistenten Tabellen, die keinen Parameter zum Eingrenzen des Datensatzes im Entwicklungsmodus haben, verwendet Looker die Produktionsversion der Tabelle, um Abfragen im Entwicklungsmodus zu beantworten, es sei denn, Sie ändern die Definition der Tabelle und fragen die Tabelle dann im Entwicklungsmodus ab. 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. durch Ändern des Parameters explore_source, sql, query, sql_create oder create_process in der persistenten Tabelle selbst oder in einer erforderlichen Tabelle (bei abgeleiteten Tabellen mit Kaskade)
• Änderung der Speicherstrategie der Tabelle, z. B. Änderung der Parameter datagroup_trigger, sql_trigger_value, interval_trigger oder persist_for der Tabelle
• view einer abgeleiteten Tabelle ändern
• increment_key oder increment_offset einer inkrementellen PDT ändern
• Ändern der connection, die vom verknüpften Modell verwendet wird

Bei Änderungen, die die Daten der Tabelle nicht modifizieren oder sich auf die Abfrage der Tabelle durch Looker auswirken, 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 deshalb 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 die Persistenzstrategie persist_for: "24 hours". So wird sichergestellt, dass Entwicklungstabellen nicht länger als einen Tag lang persistent bleiben. Immerhin könnte ein Looker-Entwickler viele Iterationen einer Tabelle bei der Entwicklung abfragen, sodass jedes Mal eine neue Entwicklungstabelle erstellt wird. Um zu verhindern, dass die Datenbank mit zu vielen Entwicklungstabellen überlastet wird, wendet Looker die persist_for: "24 hours"-Strategie an. Damit werden die Tabellen regelmäßig aus der Datenbank gelöscht.

Davon abgesehen erstellt Looker persistente abgeleitete Tabellen (PDTs) und aggregierte Tabellen im Entwicklungsmodus genauso wie persistente Tabellen im Produktionsmodus.

Wenn eine Entwicklungstabelle in der Datenbank persistent ist, wenn Sie Änderungen an einer PDT oder aggregierten Tabelle bereitstellen, kann Looker die Entwicklungstabelle häufig als Produktionstabelle verwenden, sodass die Benutzer nicht erst auf die Erstellung der Tabelle warten müssen, wenn sie sie 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 Sie die Tabelle seit mehr als 24 Stunden nicht im Entwicklungsmodus abgefragt haben, wird die Entwicklungsversion der Tabelle als abgelaufen markiert und nicht für Abfragen verwendet. Sie können nach nicht erstellten PDTs in der Looker IDE oder auf dem Tab Entwicklung der Seite Persistente abgeleitete Tabellen 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 mit den Anweisungen if prod und if dev (für SQL-basierte abgeleitete Tabellen) enthält, kann die Entwicklungstabelle nicht als Produktionsversion verwendet werden, da die Entwicklungsversion einen reduzierten Datensatz enthält. In diesem Fall können Sie nach Abschluss der Tabellenentwicklung und vor Bereitstellung der Änderungen den dev_filters-Parameter oder die bedingte WHERE-Klausel herauskommentieren und anschließend die Tabelle 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, ohne dass es eine gültige Entwicklungstabelle gibt, die als Produktionstabelle verwendet werden kann, erstellt Looker die Tabelle bei der nächsten Abfrage im Produktionsmodus neu (für persistente Tabellen mit der Strategie persist_for) oder beim nächsten Ausführen des Regenerators (für persistente Tabellen mit datagroup_trigger, interval_trigger oder sql_trigger_value).

Nach nicht erstellten PDTs im Entwicklungsmodus suchen

Wenn eine Entwicklungstabelle in der Datenbank persistent ist, wenn Sie Änderungen an einer persistenten abgeleiteten Tabelle (PDT) oder einer aggregierten Tabelle bereitstellen, kann Looker die Entwicklungstabelle häufig als Produktionstabelle verwenden, sodass die Benutzer nicht erst auf die Erstellung der Tabelle warten müssen, wenn sie sie abfragen. Weitere Informationen finden Sie auf dieser Seite in den Abschnitten Wie lange sind Entwicklungstabellen in Looker abgeleitet? und Was veranlasst Looker zur Erstellung einer Entwicklungstabelle?.

Daher sollten im Optimalfall alle Ihre PDTs bei der Bereitstellung in der Produktion erstellt sein, damit die Tabellen sofort als Produktionsversionen verwendet werden können.

Sie können Ihr Projekt im Bereich Projektstatus auf nicht erstellte PDTs überprüfen. Klicken Sie in der Looker IDE auf das Symbol Projektstatus, um den Bereich Projektstatus zu öffnen. Klicken Sie dann auf die Schaltfläche PDT-Status validieren.

Falls nicht erstellte PDTs vorhanden sind, werden diese im Bereich Projektstatus aufgeführt:

Wenn Sie die Berechtigung see_pdts haben, können Sie auf die Schaltfläche Zur PAT-Verwaltung klicken. In Looker wird der Tab Entwicklung der Seite Persistente abgeleitete Tabellen geöffnet und die Ergebnisse werden auf Ihr LookML-Projekt gefiltert. 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 PDT in Ihrem Projekt gefunden haben, können Sie eine Entwicklungsversion davon erstellen, indem Sie einen Explore öffnen, der die Tabelle abfragt, und dann die Option Abgeleitete Tabellen neu erstellen und ausführen im Explore-Menü verwenden: 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 mit einer bedingten WHERE-Klausel mit if prod- und if dev-Anweisungen definiert ist, können Sie die Entwicklungsversion der Tabelle nicht für die Produktion verwenden, da die Entwicklungsversion der Tabelle einen reduzierten Datensatz enthält. Weitere Informationen finden Sie im Abschnitt Wie lange sind Entwicklungstabellen in Looker abgeleitet? auf dieser Seite. 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 veranlasst Looker, eine Entwicklungstabelle zu erstellen? auf dieser Dokumentationsseite.

Tabellen gemeinsam nutzen und bereinigen

Innerhalb einer Looker-Instanz können persistente Tabellen von Nutzern gemeinsam verwendet werden, wenn die Tabellen über dieselbe Definition und dieselbe Einstellung für die Persistenzmethode verfügen. Außerdem wird eine Tabelle von Looker als abgelaufen markiert, sobald ihre Definition nicht mehr vorhanden ist.

Dies hat mehrere Vorteile:

• Wenn Sie im Entwicklungsmodus keine Änderungen an einer Tabelle vorgenommen haben, werden Ihre Abfragen auf die vorhandenen Produktionstabellen angewendet. Dies gilt, es sei denn, es handelt sich bei Ihrer Tabelle um eine SQL-basierte abgeleitete Tabelle, die mit einer bedingten WHERE-Klausel mit if prod- und if dev-Anweisungen definiert ist. Wenn die Tabelle mit einer bedingten WHERE-Klausel definiert wird, erstellt Looker eine Entwicklungstabelle, wenn Sie die Tabelle im Entwicklungsmodus abfragen. Bei nativen abgeleiteten Tabellen mit dem Parameter dev_filters verwendet Looker die Produktionstabelle zum Beantworten von Abfragen im Entwicklungsmodus, 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, existiert die alte Produktionsdefinition nicht mehr. 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.

Schneller im Entwicklungsmodus arbeiten

Es gibt Situationen, in denen das Generieren der PDT, die Sie gerade erstellen, sehr lange dauert. Wenn Sie viele Änderungen im Entwicklungsmodus testen möchten, kann dies sehr zeitaufwendig sein. In diesen Fällen können Sie Looker auffordern, kleinere Versionen einer abgeleiteten Tabelle zu erstellen, wenn Sie sich im Entwicklungsmodus befinden.

Bei nativen abgeleiteten Tabellen können Sie mit dem Unterparameter dev_filters von explore_source Filter angeben, 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 {}
    }
  }
...
}

Dazu gehören der Parameter dev_filters, der die Tabelle nach den Daten der letzten 90 Tage filtert, und der Parameter filters, der die Tabelle nach den Daten der letzten zwei Jahre filtert, die sich auf den Yucca Valley Airport beziehen.

Der Parameter dev_filters agiert in Kombination 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 werden in der Entwicklungsversion der Tabelle die 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 Klausel WHERE enthält, kann die Entwicklungstabelle nicht als Produktionsversion verwendet werden, da die Entwicklungsversion einen reduzierten Datensatz enthält. In diesem Fall können Sie nach Abschluss der Tabellenentwicklung und vor Bereitstellung der Änderungen den dev_filters-Parameter oder die bedingte WHERE-Klausel herauskommentieren und anschließend die Tabelle 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 sind Entwicklungstabellen in Looker abgeleitet?.

So erstellt Looker PDTs

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

1. Verwenden Sie die SQL-Abfrage für die abgeleitete Tabelle, um eine CREATE TABLE AS SELECT-Anweisung (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 ausführen
3. Benennen Sie die Tabelle von LC$.. („Looker Create“) in LR$.. („Looker Read“) um, um anzugeben, dass die Tabelle einsatzbereit ist.
4. Löschen Sie alle älteren Versionen der Tabelle, die nicht mehr verwendet werden sollten.

Das hat einige wichtige Auswirkungen:

• Der SQL-Code, aus dem die abgeleitete Tabelle besteht, muss in einer CTAS-Anweisung gültig sein.
• Die Spaltenaliasse in der Ergebnismenge der SELECT-Anweisung müssen gültige Spaltennamen sein.
• Die Namen, die bei der Angabe von Verteilung, Sortierschlüsseln und Indexen verwendet werden, müssen die Spaltennamen sein, die in der SQL-Definition der abgeleiteten Tabelle aufgeführt sind, und nicht die Feldnamen, die in der LookML-Datei definiert sind.

Der Looker-Regenerator

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

• Bei Tabellen, für die sql_trigger_value verwendet wird, ist der Trigger eine Abfrage, die im sql_trigger_value-Parameter der Tabelle angegeben ist. 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 beispielsweise Ihre abgeleitete Tabelle mit der SQL-Abfrage SELECT CURDATE() persistent ist, baut der Looker-Regenerator die Tabelle neu auf, wenn er den Auslöser das nächste Mal überprüft, nachdem das Datum geändert wurde.
• Bei Tabellen, für die interval_trigger verwendet wird, ist der Trigger eine Zeitdauer, die im interval_trigger-Parameter der Tabelle angegeben ist. Der Looker-Regenerator löst die Wiedererstellung der Tabelle nach Ablauf der angegebenen Zeit aus.
• Bei Tabellen, für die datagroup_trigger verwendet wird, kann der Trigger eine Abfrage sein, die im Parameter sql_trigger der zugehörigen Datengruppe angegeben ist. Alternativ kann der Trigger eine Zeitspanne sein, die im Parameter interval_trigger der Datengruppe angegeben ist.

Der Looker-Regenerator löst auch Neuerstellungen für persistente Tabellen aus, die den Parameter persist_for verwenden. Dies geschieht jedoch nur, wenn die persist_for-Tabelle eine Abhängigkeitskaskade einer Auslöser-persistenten Tabelle ist. In diesem Fall erstellt der Looker-Regenerator eine persist_for-Tabelle neu, da die Tabelle für die Neuerstellung der anderen Tabellen in der Kaskade benötigt wird. Andernfalls überwacht der Regenerator keine persistenten Tabellen mit der persist_for-Strategie.

Der Looker-Regenerator-Zyklus beginnt in einem regelmäßigen Intervall, das von Ihrem Looker-Administrator in der Einstellung Wartungszeitplan für Datengruppen und PDTs für Ihre Datenbankverbindung konfiguriert wird. Standardmäßig beträgt das Intervall fünf Minuten. Der Looker-Regenerator startet jedoch erst einen neuen Zyklus, wenn alle Prüfungen und Neuerstellungen von PDTs aus dem letzten Zyklus abgeschlossen sind. Das bedeutet, dass der Looker-Regenerator-Zyklus bei langwierigen PDT-Builds möglicherweise nicht so oft ausgeführt wird, wie in der Einstellung Wartungszeitplan für Datengruppe und PAT definiert. Die Dauer der Neuerstellung Ihrer Tabellen kann allerdings von anderen Faktoren beeinflusst werden, wie im Abschnitt Wichtige Aspekte beim Implementieren persistenter Tabellen auf dieser Seite beschrieben.

In Fällen, in denen eine PDT nicht erstellt werden kann, kann der Regenerator versuchen, die Tabelle im nächsten Regenerator-Zyklus neu zu erstellen:

• Wenn die Einstellung Fehlgeschlagene PDT-Builds noch einmal versuchen für Ihre Datenbankverbindung aktiviert ist, versucht der Looker-Regenerator, die Tabelle im nächsten Regenerator-Zyklus neu zu erstellen, auch wenn die Auslösebedingung der Tabelle nicht erfüllt ist.
• Wenn die Einstellung Fehlgeschlagene PDT-Builds wiederholen deaktiviert ist, versucht der Looker-Regenerator erst dann, die Tabelle neu zu erstellen, wenn die Auslösebedingung der PDT erfüllt ist.

Wenn ein Nutzer Daten von der persistenten Tabelle anfordert, während diese erstellt wird, und die Abfrageergebnisse nicht im Cache enthalten sind, prü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

Da persistente Tabellen (PDTs und aggregierte Tabellen) sehr nützlich sind, können sich schnell viele von ihnen in Ihrer Looker-Instanz ansammeln. Es kann vorkommen, dass der Looker-Regenerator viele Tabellen gleichzeitig erstellen muss. Insbesondere bei abfolgebasierten Tabellen oder lang laufenden Tabellen kann es zu einer langen Verzögerung beim Neuerstellen der Tabellen kommen oder Nutzer müssen länger auf Abfrageergebnisse warten, während die Datenbank die Tabelle generiert.

Der Looker-Regenerator prüft PDT-Trigger, um festzustellen, ob Tabellen, die durch Auslöser erstellt wurden, neu erstellt werden müssen. Der Regenerator-Zyklus wird in einem regelmäßigen Intervall festgelegt, das von Ihrem Looker-Administrator in der Einstellung Wartungszeitplan für Datengruppen und PDTs für Ihre Datenbankverbindung konfiguriert wird. Standardmäßig beträgt das Intervall fünf Minuten.

Die Dauer der Neuerstellung Ihrer Tabellen kann von mehreren Faktoren beeinflusst werden:

• Ihr Looker-Administrator hat möglicherweise das Intervall der regenerator trigger checks geändert, indem er die Einstellung Wartungszeitplan für Datengruppen und PDTs für Ihre Datenbankverbindung verwendet hat.
• Der Looker-Regenerator startet erst einen neuen Zyklus, wenn alle Prüfungen und Neuerstellungen von PDTs aus dem letzten Zyklus abgeschlossen sind. Wenn Sie also PDT-Builds mit langer Laufzeit haben, ist der Looker-Regeneratorzyklus möglicherweise nicht so häufig wie die Einstellung Wartungszeitplan für Datengruppe und PAT.
• 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 Neuaufbaue des Regenerators über das Feld Max. Anzahl der Verbindungen für PDT-Generator in den Einstellungen einer Verbindung anpassen.
• Alle PDTs und aggregierten Tabellen, die von derselben datagroup ausgelöst werden, werden im Laufe desselben Regenerationsprozesses neu erstellt. Das kann eine große Belastung darstellen, wenn die Datengruppe von vielen Tabellen verwendet wird, entweder direkt oder aufgrund von kaskadierenden Abhängigkeiten.

Zusätzlich zu den oben aufgeführten Überlegungen gibt es außerdem Situationen, in denen Sie es vermeiden sollten, einer abgeleiteten Tabelle Persistenz hinzuzufügen:

• Wenn abgeleitete Tabellen erweitert werden: Bei jeder Erweiterung einer PDT wird eine neue Kopie der Tabelle in Ihrer Datenbank erstellt.
• Wenn abgeleitete Tabellen Filtervorlagen oder Liquid-Parameter verwenden: Für abgeleitete Tabellen, die Filtervorlagen oder Liquid-Parameter verwenden, wird keine Persistenz unterstützt.
• Wenn native abgeleitete Tabellen aus explorativen Datenanalysen erstellt werden, in denen Nutzerattribute mit access_filters oder sql_always_where verwendet werden, werden in Ihrer Datenbank für jeden möglichen Wert eines Nutzerattributs Kopien der Tabelle erstellt.
• Wenn sich die zugrunde liegenden Daten häufig ändern und Ihr Datenbankdialekt keine inkrementellen PDTs unterstützt.
• Wenn die Kosten und der Zeitaufwand für die Erstellung 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.

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

Das Überwachen und Verwalten von PDTs, die in variierenden Zeiplänen aktualisiert werden, wird zunehmend komplexer, je mehr PDTs Sie in Ihrer Instanz erstellen. Sie können die Apache Airflow-Integration von Looker verwenden, um Ihre PDT-Zeitpläne zusammen mit Ihren anderen ETL- und ELT-Prozessen zu verwalten.

PDTs überwachen und Fehler beheben

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

Beachten Sie Folgendes, wenn Sie versuchen, Fehler bei PDTs zu beheben:

• Vergleichen Sie bei Auswertung des PDT-Ereignisprotokolls besonders die Entwicklungstabellen mit den Produktionstabellen.
• Vergewissern Sie sich, dass keine Änderungen am Scratch-Schema vorgenommen wurden, in dem Looker persistente abgeleitete Tabellen speichert. Wenn Änderungen vorgenommen wurden, müssen Sie möglicherweise die Verbindungseinstellungen im Bereich Verwaltung in Looker aktualisieren und Looker dann neu starten, um die normale PDT-Funktion 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.
• Achten Sie darauf, dass alle sql_trigger_value-Abfragen erfolgreich ausgewertet werden und nur eine Zeile und Spalte zurückgeben. Bei SQL-basierten PDTs können Sie sie in SQL Runner ausführen. (Die Anwendung eines LIMIT schützt vor übermäßigen Abfragen.) Weitere Informationen zur Verwendung von SQL Runner zum Debuggen abgeleiteter Tabellen finden Sie im Communitybeitrag Abgeleitete Tabellen mit SQL Runner testen .
• Ü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-Wert anzuwenden, damit die Abfragedauer im Rahmen bleibt.)
• Verwenden Sie für SQL-basierte abgeleitete Tabellen keine allgemeinen Tabellenausdrücke (Common Table Expressions, CTEs). Die Verwendung von CTEs mit DTs generiert verschachtelte WITH-Anweisungen, die einen Fehlschlag von PDTs ohne Warnung verursachen können. Verwenden Sie stattdessen die SQL-Anweisung für die CTE, um eine sekundäre Datentabelle zu erstellen, und verweisen Sie mit der Syntax ${derived_table_or_view_name.SQL_TABLE_NAME} auf diese Datentabelle aus der ersten Datentabelle.
• Prüfen Sie, ob Tabellen, von denen die problematische PDT abhängig ist (ob normale Tabellen oder PDTs), vorhanden sind und abgefragt werden können.
• Achten Sie darauf, 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 alle exklusiven Sperren für die Tabelle, aus der Looker eine PDT erstellt. Wenn eine exklusive Sperre für eine Tabelle eingerichtet ist, kann Looker erst dann eine gemeinsame Sperre für die Ausführung von Abfragen einrichten, wenn die exklusive Sperre entfernt wurde.
• Verwenden Sie in SQL Runner die Schaltfläche Prozesse anzeigen. Wenn viele Prozesse aktiv sind, kann die Abfragedauer zunehmen.
• Überwachen Sie Kommentare in der Abfrage. Weitere Informationen finden Sie im Abschnitt Abfragekommentare für PDTs auf dieser Seite.

Kommentare für PDTs abfragen

Datenbankadministratoren können leicht zwischen normalen Abfragen und Abfragen unterscheiden, die persistente abgeleitete Tabellen (Persistent Derived Tables, PDTs) generieren. Looker fügt der CREATE TABLE ... AS SELECT ...-Anweisung Kommentare hinzu, die das LookML-Modell der PDT und die zugehörige Ansicht sowie eine eindeutige Kennung (Slug) für die Looker-Instanz enthalten. Wenn die PDT im Auftrag eines Nutzers im Entwicklungsmodus generiert wird, wird in Kommentaren die ID des Nutzers 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 PDT-Generierung ist auch auf der SQL-Registerkarte eines Explores zu sehen, wenn Looker für die Abfrage des Explores eine PDT erstellen musste. Der Kommentar wird oben in der SQL-Anweisung angezeigt.

Schließlich wird der Kommentar zur PDT-Generierung im Feld Nachricht auf dem Tab Info des Pop-ups Abfragedetails für jede Abfrage auf der Admin-Seite Abfragen angezeigt.

PDTs nach einem Fehler neu erstellen

Wenn eine persistente abgeleitete Tabelle (PDT) einen Fehler aufweist, geschieht Folgendes beim Abfragen dieser PDT:

• Looker prüft anhand der Ergebnisse im Cache, ob dieselbe Abfrage bereits ausgeführt wurde. Eine Erklärung dazu finden Sie auf der Dokumentationsseite Abfragen im Cache speichern.
• Wenn die Ergebnisse nicht im Cache enthalten sind, ruft Looker Ergebnisse von 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 PDT nicht neu erstellt werden kann, gibt Looker einen Fehler bei einer Abfrage zurück. Der Looker-Regenerator versucht, die PDT neu zu erstellen, wenn sie das nächste Mal abgefragt wird oder wenn die Persistenzstrategie der PDT eine Neuerstellung auslöst.

Bei kaskadierenden PDTs gilt dieselbe Logik mit folgenden Ausnahmen:

• 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 Grunde die PDT ab, von der sie abhängig ist. Daher kann die Persistenzstrategie einer Tabelle Neuerstellungen der PDTs weiter oben in der Kette auslösen.

Denken Sie an das vorherige Beispiel mit abgestuften Tabellen, bei dem TABLE_D von TABLE_C abhängt, das wiederum von TABLE_B abhängt, das wiederum von TABLE_A abhängt:

Wenn bei TABLE_B ein Fehler auftritt, gilt für TABLE_B das Standardverhalten (kein Kaskadenverhalten): Wenn TABLE_B abgefragt wird, versucht Looker zuerst, mithilfe des Caches Ergebnisse zurückzugeben, dann nach Möglichkeit eine frühere Version der Tabelle zu verwenden, dann die Tabelle neu zu erstellen und schließlich einen Fehler zurückzugeben, wenn TABLE_B nicht neu erstellt werden kann. Looker versucht erneut, TABLE_B neu zu erstellen, wenn die Tabelle das nächste Mal abgefragt wird oder wenn die Persistenzstrategie der Tabelle eine Neuerstellung auslöst.

Dasselbe gilt für die Angehörigen von TABLE_B. Wenn TABLE_B also nicht erstellt werden kann und es eine Abfrage für TABLE_C gibt, geschieht Folgendes:

• Looker versucht, den Cache für die Abfrage unter TABLE_C zu verwenden.
• Wenn die Ergebnisse nicht im Cache enthalten sind, versucht Looker, Ergebnisse von TABLE_C in der Datenbank abzurufen.
• Wenn es keine gültige Version von TABLE_C gibt, versucht Looker, TABLE_C neu zu erstellen. Dadurch wird eine Abfrage für TABLE_B erstellt.
• Looker versucht dann, TABLE_B neu zu erstellen. (Dieser Vorgang schlägt fehl, wenn das Problem mit TABLE_B nicht behoben wurde.)
• Wenn TABLE_B nicht neu erstellt werden kann, kann auch TABLE_C nicht neu erstellt werden. In diesem Fall gibt Looker einen Fehler für die Abfrage für TABLE_C zurück.
• Looker versucht dann, TABLE_C gemäß der üblichen Persistenzstrategie neu zu erstellen oder beim nächsten Abfragen der PDT. Dazu gehört auch der nächste Versuch, TABLE_D zu erstellen, da TABLE_D von TABLE_C abhängt.

Sobald Sie das Problem mit TABLE_B behoben haben, werden TABLE_B und alle abhängigen Tabellen gemäß ihren Persistenzstrategien neu erstellt oder beim nächsten Abfragen, einschließlich der nächsten Neuerstellung einer abhängigen PDT. Wenn eine Entwicklungsversion der PDTs in der Kaskade im Entwicklungsmodus erstellt wurde, können die Entwicklungsversionen als die neuen Produktions-PDTs verwendet werden. (Dieser Vorgang wird im Abschnitt Persistente Tabellen im Entwicklungsmodus auf dieser Seite erläutert.) Sie können auch mit einem Explore eine Abfrage auf TABLE_D ausführen und dann die PDTs für die Abfrage manuell neu erstellen. Dadurch werden alle PDTs in der Abhängigkeitskaskade neu erstellt.

PDT-Leistung verbessern

Beim Erstellen von persistenten abgeleiteten Tabellen (PDTs) kann es zu Leistungseinbußen kommen. Besonders bei sehr großen Tabellen kann die Abfrage der Tabelle langsam sein, wie bei jeder großen Tabelle in Ihrer Datenbank.

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

Filter hinzufügen, um den Datensatz einzugrenzen

Bei besonders großen Datensätzen verlangsamen viele Zeilen die Abfragen in einer persistenten abgeleiteten Tabelle (PDT). Wenn Sie in der Regel nur aktuelle Daten abfragen, sollten Sie der WHERE-Klausel Ihrer PDT einen Filter hinzufügen, der die Tabelle auf Daten von maximal 90 Tagen beschränkt. So werden der Tabelle bei jedem Neuaufbau nur relevante Daten hinzugefügt, sodass Abfragen viel schneller ausgeführt werden können. Anschließend können Sie eine separate, größere PDT für die Verlaufsanalyse erstellen, um sowohl schnelle Abfragen für aktuelle Daten als auch Abfragen für alte Daten zu ermöglichen.

indexes oder sortkeys und distribution verwenden

Wenn Sie eine große persistente abgeleitete Tabelle (PDT) erstellen, kann die Indexierung der Tabelle (für Dialekte wie MySQL oder Postgres) oder das Hinzufügen von Sortierschlüsseln und Verteilungen (für Redshift) die Leistung verbessern.

Der Parameter indexes sollte in der Regel in ID- oder Datumsfeldern verwendet werden.

Bei Redshift sollten Sie in der Regel den Parameter sortkeys zu ID- oder Datumsfeldern und den Parameter distribution zu dem Feld hinzufügen, das für die Zusammenführung verwendet wird.

Empfohlene Einstellungen zur Leistungssteigerung

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

• Verwenden Sie für Redshift und Aster den Parameter distribution, um den Spaltennamen anzugeben, dessen Wert verwendet wird, um die Daten auf einen Cluster zu verteilen. Wenn zwei Tabellen über die im Parameter distribution angegebene Spalte zusammengeführt werden, kann die Datenbank die Join-Daten auf demselben Knoten finden. Dadurch wird die I/O zwischen den Knoten minimiert.
• Legen Sie für Redshift den Parameter distribution_style auf all fest, damit die Datenbank auf jedem Knoten eine vollständige Kopie der Daten aufbewahrt. Dies wird häufig verwendet, um die I/O zwischen Knoten zu minimieren, wenn relativ kleine Tabellen zusammengeführt werden. Legen Sie diesen Wert auf even fest, damit die Datenbank die Daten ohne Verwendung einer Verteilungsspalte gleichmäßig im Cluster verteilt. Dieser Wert kann nur angegeben werden, wenn distribution nicht angegeben ist.
• Verwenden Sie für Redshift den Parameter sortkeys. Die Werte geben an, mit welchen Spalten der PDT die Daten auf dem Laufwerk sortiert werden, um die Suche zu erleichtern. In Redshift können Sie entweder sortkeys oder indexes verwenden, aber nicht beides.
• Verwenden Sie bei den meisten Datenbanken den Parameter indexes. Mit den Werten wird angegeben, welche Spalten der PDT indexiert werden. In Redshift werden Indizes verwendet, um verschränkte Sortierschlüssel zu generieren.