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

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

Gängige Anwendungsfälle für abgeleitete Tabellen finden Sie unter Looker-Cookbooks: 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 Tabelle vom Typ customer_order_summary 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, die in diesem Beispiel nicht gezeigt wird. Die explore_source-Abfrage in der nativen abgeleiteten Tabelle importiert die Felder customer_id, first_order und total_amount aus der Ansichtsdatei orders.
• 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 seinen Unterparametern funktioniert diese Ansicht customer_order_summary 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. Sehen Sie sich dazu die Ansichtsdatei der SQL-basierten abgeleiteten Tabelle im vorherigen Beispiel an.

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

Ein hilfreiches Kürzel zum Erstellen von SQL-basierten Abfragen in Looker ist die Verwendung von SQL Runner, um die SQL-Abfrage zu erstellen und in eine Definition einer abgeleiteten Tabelle umzuwandeln.

In manchen Edge-Fällen kann der sql-Parameter nicht verwendet werden. In solchen 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 Dialekts mit Ihrer Abfrage, um die PDT aus Ihrer SQL-Abfrage zu erstellen. Einige Dialekte unterstützen keine SQL-CREATE TABLE-Anweisung in einem einzelnen Schritt. Für diese Dialekte können Sie keine PDT mit dem Parameter sql erstellen. Stattdessen können Sie den Parameter create_process verwenden, um eine PDT in mehreren Schritten zu erstellen. Weitere Informationen und Beispiele finden Sie auf der Seite mit der Parameterdokumentation zu create_process.
• sql_create: Wenn Ihr Anwendungsfall benutzerdefinierte DDL-Befehle erfordert und Ihr Dialekt DDL unterstützt (z. B. das Vorhersage-Tool BigQuery ML von Google), können Sie mit dem Parameter sql_create anstelle des Parameters sql eine PDT erstellen. 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 all diesen Fällen mit einer SQL-Abfrage. Daher werden alle als SQL-basierte abgeleitete Tabellen betrachtet.

Achten Sie beim Definieren einer SQL-basierten abgeleiteten Tabelle darauf, dass Sie jeder Spalte mithilfe von AS einen eindeutigen Alias geben. Grund dafür ist, dass Sie die Spaltennamen Ihres Ergebnissatzes in Ihren Dimensionen referenzieren müssen, z. B. ${TABLE}.first_order. Aus diesem Grund 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 einen Unterschied zwischen einer temporären 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 derived_table-Parameter 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 mithilfe 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. Aus diesem Grund sollten Sie sicher sein, dass Ihre temporären abgeleiteten Tabellen leistungsfähig sind und Ihre 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 Lawine	Ja
Amazon Athena	Ja
Amazon Aurora MySQL	Ja
Amazon Redshift	Ja
Druid	Ja
Apache Druid 0.13+	Ja
Apache Druid 0.18+	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+	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 Database	Ja
Microsoft Azure Synapse Analytics	Ja
Microsoft SQL Server 2008 oder 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+	Ja
PostgreSQL vor Version 9.5	Ja
PrestoDB	Ja
PrestoSQL	Ja
SAP HANA 2 und höher	Ja
SingleStore	Ja
SingleStore 7 und höher	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. Eine Liste der Dialekte, die persistente SQL-basierte abgeleitete Tabellen und persistente native abgeleitete Tabellen unterstützen, finden Sie im Abschnitt Unterstützte Datenbankdialekte für PDTs weiter unten auf dieser Seite.
• 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 PDTs aktivieren aktiviert ist. Dies wird normalerweise bei der Erstkonfiguration der Looker-Verbindung eingerichtet. 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 in Ihrem Looker-Projekt persistente abgeleitete Tabellen (PDTs) unterstützen kann, müssen diese auch von Ihrem Datenbankdialekt unterstützt werden.

Damit alle Arten von PDTs (entweder LookML- oder SQL-basiert) unterstützt werden, 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-Replikatdatenbanken). 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 Lawine	Ja
Amazon Athena	Ja
Amazon Aurora MySQL	Ja
Amazon Redshift	Ja
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+	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 Database	Ja
Microsoft Azure Synapse Analytics	Ja
Microsoft SQL Server 2008 oder 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+	Ja
PostgreSQL vor Version 9.5	Ja
PrestoDB	Ja
PrestoSQL	Ja
SAP HANA 2 und höher	Ja
SingleStore	Ja
SingleStore 7 und höher	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. Hier finden Sie eine Liste der Dialekte, die persistente native (LookML-basierte) abgeleitete Tabellen in der neuesten Version von Looker unterstützen:

Dialekt	Unterstützt?
Actian Lawine	Ja
Amazon Athena	Ja
Amazon Aurora MySQL	Ja
Amazon Redshift	Ja
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+	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 Database	Ja
Microsoft Azure Synapse Analytics	Ja
Microsoft SQL Server 2008 oder 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+	Ja
PostgreSQL vor Version 9.5	Ja
PrestoDB	Ja
PrestoSQL	Ja
SAP HANA 2 und höher	Ja
SingleStore	Ja
SingleStore 7 und höher	Ja
Snowflake	Ja
Teradata	Ja
Trino	Ja
Vektor	Ja
Vertica	Ja

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

Inkrementeller Aufbau von PDTs

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

Wenn Ihr Dialekt inkrementelle PDTs unterstützt und Ihre PDT eine Trigger-basierte 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 Lawine	Nein
Amazon Athena	Nein
Amazon Aurora MySQL	Nein
Amazon Redshift	Ja
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+	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 oder 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 und höher	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.

Fügen Sie der derived_table-Definition einen der folgenden Parameter hinzu, um eine abgeleitete Tabelle persistent zu machen:

• 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. Ein Nutzer mit der Berechtigung develop kann die Funktionen Abgeleitete Tabellen neu erstellen und Ausführen aus dem Menü eines Explores, um die Persistenzeinstellung zu überschreiben und alle PDTs, die für die aktuelle Abfrage im Explore erforderlich sind, neu zu erstellen. Weitere Informationen finden Sie im Abschnitt PDTs für eine Abfrage manuell neu erstellen auf dieser Seite.

datagroup_trigger

Datengruppen sind die flexibelste Methode zur Schaffung von Persistenz. Wenn Sie eine datagroup mit sql_trigger oder interval_trigger definiert haben, können Sie den Parameter datagroup_trigger verwenden, um die Neuerstellung Ihrer persistenten abgeleiteten Tabellen (PDTs) zu starten.

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 diese erstellt wird, und die Abfrageergebnisse sich nicht im Cache befinden, gibt Looker Daten aus der vorhandenen PDT zurück, bis die neue PDT erstellt wurde. Eine Übersicht über Datengruppen finden Sie unter Abfragen zwischenspeichern.

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

sql_trigger_value

Der Parameter sql_trigger_value löst die Neuerstellung einer persistenten abgeleiteten Tabelle (PDT) anhand einer von Ihnen bereitgestellten 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 diese erstellt wird, und die Abfrageergebnisse sich nicht im Cache befinden, 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 Neuerstellung einer persistenten abgeleiteten Tabelle (PDT) anhand eines von Ihnen angegebenen Zeitintervalls 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 Benutzer Daten von der PDT anfordert, während diese erstellt wird, und die Abfrageergebnisse sich nicht im Cache befinden, gibt Looker Daten aus der vorhandenen PDT zurück, bis die neue PDT erstellt wurde.

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 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 dem persist_for-Zeitpunkt löscht Looker die PDT aus der Datenbank. Die PDT wird dann neu erstellt, wenn ein Nutzer sie das nächste Mal abfragt. Die Abfrage muss also 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 Trigger-basierten PDTs (PDTs, die die Persistenzstrategie datagroup_trigger, interval_trigger oder sql_trigger_value verwenden) ist, überwacht der Regenerator die Tabelle persist_for und erstellt sie 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. Informationen zum Verhalten des Dialekts und zur Häufigkeit, mit der er Daten für materialisierte Ansichten aktualisiert, finden Sie in der Dokumentation zu Ihrem Dialekt.

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 Option PDTs aktivieren für Ihre Looker-Verbindung 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, zu Anforderungen und zu wichtigen Überlegungen finden Sie auf der Dokumentationsseite zum Parameter 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 der abgeleiteten Tabelle Persistenz hinzufügen möchten, können Sie sie so einstellen, dass sie neu erstellt wird, wenn die Datengruppe orders_datagroup ausgelöst wird, und Indexe sowohl für customer_id als auch für first_order 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 zur Steigerung der Abfrageleistung nachholen sollten.

Anwendungsfälle für PDTs

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

Als allgemeine Best Practice sollten Entwickler versuchen, Daten so lange ohne PDTs zu modellieren, bis es absolut erforderlich ist.

In einigen Fällen können Daten 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 vorab zusammenführen oder aggregieren

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

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 Datenbankadministratoren 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 zu ändern, um die PDT zu entfernen.

Daten vor dem Zusammenführen oder Aggregieren mithilfe von PDTs verknüpfen

Es kann nützlich sein, Daten vorab zusammenzuführen oder zu aggregieren, 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. 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 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 die 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 kaskadierende abgeleitete Tabellen einrichten, sollten Sie wissen, wie kaskadierende abgeleitete Tabellen vom Looker-Regenerator automatisch neu erstellt werden und wie sie von Nutzern manuell neu erstellt werden können. Außerdem sind weitere wichtige Überlegungen bei der Implementierung persistenter Tabellen zu beachten. 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 literaler String. 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 Syntax ${derived_table_or_view_name.SQL_TABLE_NAME} im Parameter sql_trigger_value verwenden, um die Neuerstellung von PDTs auszulösen.

Im nächsten Beispiel wird die PDT clean_events aus der Tabelle events in der Datenbank erstellt. Die PDT clean_events schließt unerwünschte Zeilen aus der Datenbanktabelle events aus. 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 mit der PDT clean_events definiert wird). Dieses spezielle Beispiel könnte effizienter in einer einzelnen PDT ausgefü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 häufig nützlich, einen Alias für die Tabelle in diesem 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) 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 ein 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 aber TABLE_C neu erstellt werden.

Sehen wir uns nun ein Szenario mit verschachtelten temporären abgeleiteten Tabellen an, 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. 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 der Generierung von TABLE_B beginnen kann, und so weiter, bis TABLE_C abgeschlossen 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 Dokumentationsseite zum Parameter datagroup finden Sie ein Beispielszenario für kaskadierende PDTs, die dieselbe Datengruppe verwenden.

Für PDTs gilt die gleiche grundlegende Logik: Looker erstellt alle Tabellen, die zum Beantworten einer Abfrage erforderlich sind, entlang der gesamten Kette der Abhängigkeiten. Bei PDTs sind die Tabellen aber oft schon vorhanden, sodass sie nicht neu erstellt werden müssen. Bei Standard-Benutzerabfragen für kaskadierende 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 Neuerstellung für alle PDTs in einer Kaskade erzwingen möchten, können Sie über ein Explore 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 Trigger-basierten PDTs (PDTs, die die Persistenzstrategie datagroup_trigger, interval_trigger oder sql_trigger_value verwenden) ist, wird die persist_for-PDT im Wesentlichen immer dann abgefragt, wenn ihre abhängigen PDTs neu erstellt werden. In diesem Fall wird die PDT persist_for 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 die Option Abgeleitete Tabellen neu erstellen und Ausführen aus dem Menü eines Explores, 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 sichtbar und nur nach dem Laden der explorativen Datenanalyse.

Das Modul abgeleitete Tabellen neu erstellen und Run (Ausführen) erstellt alle persistenten Tabellen (alle PDTs und aggregierten Tabellen), die zum Beantworten der Abfrage erforderlich sind, unabhängig von ihrer Persistenzstrategie neu. 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 abhängig von ihrer Konfiguration erstellt werden.

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

Beachten Sie bei der manuellen Neuerstellung abgeleiteter Tabellen Folgendes:

• 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. Wenn die persistenten Tabellen erneut erstellt wurden, verwenden alle Benutzer die neu erstellten Tabellen. Dieser Prozess soll jedoch verhindern, dass das Abfragen während der Neuerstellung der Tabellen durchgeführt, könnten diese Benutzer 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 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 Entwicklungstabellen 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

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

Hinweis :Diese Verhaltensweisen gelten für alle Arten 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 Abfrageart der Tabelle auswirkt, wird bei Ihrer 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:

• Die persistente Tabelle enthält einen Parameter, der das Dataset einschränkt, damit das Dataset 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 Datasets 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 Sie 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):

• Änderung der Abfrage, auf der die persistente Tabelle basiert, z. B. Ändern der Parameter explore_source, sql, query, sql_create oder create_process in der persistenten Tabelle selbst oder in jeder erforderlichen Tabelle (bei kaskadierenden abgeleiteten Tabellen)
• Änderung der Speicherstrategie der Tabelle, z. B. Änderung des Parameters datagroup_trigger, sql_trigger_value, interval_trigger oder persist_for der Tabelle
• Den Namen der view einer abgeleiteten Tabelle ändern
• increment_key oder increment_offset einer inkrementellen PDT ändern
• Den connection ändern, der vom verknüpften Modell verwendet wird

Bei Änderungen, die die Daten der Tabelle nicht verä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 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". 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. 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 Ihrer Datenbank persistent ist, wenn Sie Änderungen an einer PDT oder aggregierten Tabelle bereitstellen, kann Looker die Entwicklungstabelle häufig als Produktionstabelle verwenden, damit Ihre Benutzer beim Abfragen der Tabelle nicht auf die Erstellung der Tabelle warten müssen.

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 vor mehr als 24 Stunden im Entwicklungsmodus abgefragt haben, wird die Entwicklungsversion der Tabelle als abgelaufen gekennzeichnet 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 dem Entwickeln der Tabelle und vor dem Bereitstellen der Änderungen den Parameter dev_filters oder die bedingte WHERE-Klausel auskommentieren und dann 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 in den Abschnitten Wie lange sind Entwicklungstabellen in Looker abgeleitet? und Wofür wird Looker zum Erstellen einer Entwicklungstabelle aufgefordert? auf dieser Seite.

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.

Im Bereich Projektzustand können Sie Ihr Projekt auf nicht erstellte PDTs prü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.

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

Wenn Sie die Berechtigung see_pdts haben, können Sie auf die Schaltfläche Go to PDT Management (Zur PDT-Verwaltung wechseln) 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 mithilfe einer bedingten WHERE-Klausel mit if prod- und if dev-Anweisungen definiert wird, können Sie die Entwicklungsversion der Tabelle nicht für die Produktion verwenden, da die Entwicklungsversion der Tabelle ein abgekürztes Dataset 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 zum Beantworten von Abfragen im Entwicklungsmodus, es sei denn, Sie ändern die Definition der Tabelle und fragen die Tabelle dann im Entwicklungsmodus ab. Weitere Informationen dazu finden Sie auf dieser Dokumentationsseite im Abschnitt Wie Looker zum Erstellen einer Entwicklungstabelle aufgefordert wird.

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. 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 verfügt Looker über die Logik, um die Produktionstabelle zur Beantwortung von Abfragen im Entwicklungsmodus zu verwenden, 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 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 {}
    }
  }
...
}

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

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 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 Produktions- (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 enthält, kann die Entwicklungstabelle nicht als Produktionsversion verwendet werden, da die Entwicklungsversion ein abgekürztes Dataset enthält. In diesem Fall können Sie nach dem Entwickeln der Tabelle und vor dem Bereitstellen der Änderungen den Parameter dev_filters oder die bedingte WHERE-Klausel auskommentieren und dann 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 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 namens customer_orders_facts neu: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
2. Beim Erstellen der Tabelle die Anweisungen zum Erstellen der Indexe ausgeben
3. Benennen Sie die Tabelle von „LC$...“ („Looker Create“) in „LR$...“ („Looker Read“) um, damit 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 mit sql_trigger_value ist der Trigger eine Abfrage, die im Parameter sql_trigger_value 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 mit datagroup_trigger kann der Trigger eine Abfrage sein, die im Parameter sql_trigger der zugehörigen Datengruppe angegeben ist, oder eine im interval_trigger-Parameter der Datengruppe angegebene Zeitdauer.

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 initiiert der Looker-Regenerator die Neuerstellung einer persist_for-Tabelle, da die Tabelle benötigt wird, 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 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 dann einen neuen Zyklus, wenn alle Prüfungen und Neuerstellungen der PDT aus dem letzten Zyklus abgeschlossen sind. Das bedeutet, dass der Looker-Regenerator-Zyklus bei lang andauernden PDT-Builds möglicherweise nicht so oft ausgeführt wird, wie in der Einstellung Datengruppe und PDT-Wartungszeitplan festgelegt. Die Dauer der Neuerstellung Ihrer Tabellen kann durch andere Faktoren beeinflusst werden, wie im Abschnitt Wichtige Überlegungen zum 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 nicht, die Tabelle neu zu erstellen, bis die Triggerbedingung 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. Besonders bei kaskadierenden Tabellen oder Tabellen mit langer Ausführungszeit können Sie ein Szenario schaffen, bei dem die Neuerstellung von Tabellen erheblich verzögert ist oder bei dem Nutzer Abfrageergebnisse aus einer Tabelle verzögert abrufen, während die Datenbank intensiv an der Generierung der Tabelle arbeitet.

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 Ihr Looker-Administrator in der Einstellung Wartungszeitplan für Datengruppen und PDTs für Ihre Datenbankverbindung konfiguriert. Standardmäßig beträgt das Intervall fünf Minuten.

Die Zeit, die für die Neuerstellung Ihrer Tabellen benötigt wird, kann von mehreren Faktoren beeinflusst werden:

• Möglicherweise hat Ihr Looker-Administrator das Intervall der Überprüfungen des Regenerators mithilfe der Einstellung Datengruppe und PDT-Wartungszeitplan für Ihre Datenbankverbindung geändert.
• 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. Dies kann eine hohe 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: Mit jeder Erweiterung einer PDT wird eine neue Kopie der Tabelle in Ihrer Datenbank erstellt.
• Wenn abgeleitete Tabellen Filtervorlagen oder Liquid-Parameter verwenden, wird Persistenz für abgeleitete Tabellen nicht unterstützt, die Filtervorlagen oder Liquid-Parameter verwenden.
• Wenn native abgeleitete Tabellen aus Explores erstellt werden, die Nutzerattribute mit access_filters oder mit sql_always_where verwenden, werden für jeden angegebenen möglichen Nutzerattributwert in Ihrer Datenbank 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 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.

PDTs in großem Maßstab über API 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.

Wenn Sie versuchen, Probleme mit PDTs zu beheben:

• Achten Sie bei der Untersuchung des PDT-Ereignisprotokolls besonders auf die Unterscheidung zwischen Entwicklungstabellen und 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. SQL-basierte PDTs können Sie dazu in SQL Runner ausführen. (Ein LIMIT schützt vor unkontrollierten Abfragen.) Weitere Informationen zur Verwendung von SQL Runner zum Debuggen von abgeleiteten Tabellen finden Sie unter SQL Runner zum Testen abgeleiteter Tabellen verwenden Communitybeitrag.
• Ü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 den SQL-Code für Ihren CTE, um einen sekundären DT zu erstellen und diesen mit der ${derived_table_or_view_name.SQL_TABLE_NAME}-Syntax aus dem ersten DT zu referenzieren.
• 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.
• 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 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 die Schaltfläche Show Processes (Prozesse anzeigen) 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 PDTs auf dieser Seite.

Abfragekommentare für PDTs

Datenbankadministratoren können leicht zwischen normalen Abfragen und Abfragen unterscheiden, die persistente abgeleitete Tabellen (Persistent Derived Tables, PDTs) generieren. Looker fügt der Anweisung CREATE TABLE ... AS SELECT ... Kommentare hinzu, die das LookML-Modell und die Ansicht der PDT 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-up-Fensters Abfragedetails für jede Abfrage auf der Verwaltungsseite für 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 zur Funktionsweise finden Sie auf der Dokumentationsseite Abfragen zwischenspeichern.
• 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 PDT nicht neu erstellt werden kann, gibt Looker für eine Abfrage einen Fehler 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.

Für kaskadierende PDTs gilt dieselbe Logik, mit der Ausnahme, dass bei kaskadierenden PDTs Folgendes gilt:

• 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.

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

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 und dann, die Tabelle neu zu erstellen. Wenn TABLE_B nicht neu erstellt werden kann, wird schließlich ein Fehler zurückgegeben. 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 abhängige Personen 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 am TABLE_C zu verwenden.
• Wenn sich die Ergebnisse nicht im Cache befinden, versucht Looker, Ergebnisse aus 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 zu 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.

Nachdem 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 des nächsten Neuerstellungsversuchs durch eine abhängige 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. Informationen zur Funktionsweise finden Sie im Abschnitt Persistente Tabellen im Entwicklungsmodus auf dieser Seite. Alternativ können Sie ein Explore verwenden, um eine Abfrage für TABLE_D auszuführen und dann die PDTs für die Abfrage manuell neu zu erstellen. Dadurch wird eine Neuerstellung aller PDTs erzwungen, die die Abhängigkeitskaskade hinaufgehen.

PDT-Leistung verbessern

Beim Erstellen persistenter abgeleiteter Tabellen (PDTs) kann es zu Leistungseinbußen kommen. Besonders wenn die Tabelle sehr groß ist, kann das Abfragen der Tabelle länger dauern, so wie es bei jeder großen Tabelle in Ihrer Datenbank der Fall sein kann.

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

Filter zum Einschränken des Datasets hinzufügen

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. Auf diese Weise werden bei jeder Neuerstellung nur relevante Daten zur Tabelle 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 alter 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.

Für Redshift ist es in der Regel am besten, den Parameter sortkeys in ID- oder Datumsfelder und den Parameter distribution in das Feld einzufügen, das für die Zusammenführung verwendet wird.

Empfohlene Einstellungen zur Leistungssteigerung

Die folgenden Einstellungen steuern, 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 verknüpft werden, kann die Datenbank die Join-Daten auf demselben Knoten finden, damit die knotenübergreifende E/A minimiert wird.
• Setzen Sie für Redshift den Parameter distribution_style auf all, um die Datenbank anzuweisen, eine vollständige Kopie der Daten auf jedem Knoten zu speichern. 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, um die Datenbank anzuweisen, die Daten gleichmäßig auf den Cluster zu verteilen, ohne eine Verteilungsspalte zu verwenden. 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.
• Bei den meisten Datenbanken verwenden Sie 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.)