Abgeleitete Tabellen in Looker

In Looker ist eine abgeleitete Tabelle eine Abfrage, deren Ergebnisse so verwendet werden, als ob die Abfrage eine tatsächliche Tabelle in der Datenbank wäre.

Beispielsweise könnte es eine Datenbanktabelle namens orders geben, die viele Spalten enthält. 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. Sie können entweder eine native abgeleitete Tabelle oder eine SQL-basierte abgeleitete Tabelle verwenden, um eine neue Datenbanktabelle mit dem Namen customer_order_summary zu erstellen, die diese Metriken enthält.

Anschließend können Sie mit der abgeleiteten Tabelle customer_order_summary so arbeiten, als wäre sie jede andere Tabelle in der Datenbank.

Beliebte Anwendungsfälle für abgeleitete Tabellen finden Sie in Looker cookbooks: Getting the most out of derived tables in Looker.

Native abgeleitete Tabellen und SQL-basierte abgeleitete Tabellen

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

• Für eine native abgeleitete Tabelle definieren Sie die abgeleitete Tabelle mit einer LookML-basierten Abfrage.
• Bei einer SQL-basierten abgeleiteten Tabelle definieren Sie die abgeleitete Tabelle mit einer SQL-Abfrage.

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

• Die native abgeleitete Tabelle definiert die Abfrage mit LookML im Parameter explore_source. In diesem Beispiel basiert die Abfrage auf einer vorhandenen orders-Ansicht, die in einer separaten Datei definiert ist, die in diesem Beispiel nicht gezeigt wird. Die explore_source-Abfrage in der nativen abgeleiteten Tabelle ruft die Felder customer_id, first_order und total_amount aus der Ansichtsdatei orders ab.
• Die SQL-basierte abgeleitete Tabelle definiert die Abfrage mithilfe von SQL im Parameter sql. In diesem Beispiel handelt es sich bei der SQL-Abfrage um eine direkte Abfrage der Tabelle orders in der Datenbank.

Native abgeleitete Tabellenversion

view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      column: customer_id {
        field: orders.customer_id
      }
      column: first_order {
        field: orders.first_order
      }
      column: total_amount {
        field: orders.total_amount
      }
    }
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}

SQL-basierte Version abgeleiteter Tabellen

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 erzeugen eine Ansicht namens customer_order_summary, die auf der Tabelle orders basiert und die Spalten customer_id, first_order, und total_amount enthält.

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. Zum Erstellen einer nativen abgeleiteten Tabelle verwenden Sie den Parameter explore_source innerhalb des Parameters derived_table eines view-Parameters. Sie erstellen die Spalten der nativen abgeleiteten Tabelle, indem Sie die LookML-Dimensionen oder -Messwerte in Ihrem Modell referenzieren. Die Ansichtsdatei für die native abgeleitete Tabelle finden Sie im vorherigen Beispiel.

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

In den meisten Fällen definieren Sie die SQL-Abfrage mit dem Parameter sql innerhalb des Parameters derived_table eines view-Parameters.

Eine hilfreiche Abkürzung zum Erstellen von SQL-basierten Abfragen in Looker ist, SQL Runner zu verwenden, um die SQL-Abfrage zu erstellen und sie in die Definition einer abgeleiteten Tabelle umzuwandeln.

In bestimmten Grenzfall-Szenarien ist die Verwendung des Parameters sql nicht möglich. 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, umschließt 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. 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 sql-Parameter erstellen. Sie können stattdessen aber den create_process-Parameter verwenden, um eine PDT in mehreren Schritten zu erstellen. Informationen und Beispiele finden Sie auf der Dokumentationsseite zum Parameter create_process.
• sql_create: Wenn für Ihren Anwendungsfall benutzerdefinierte DDL-Befehle erforderlich sind und Ihr Dialekt DDL unterstützt (z. B. das Google-Vorhersagemodell BigQuery ML), können Sie den Parameter sql_create verwenden, um eine abgeleitete Tabelle zu erstellen, anstatt den Parameter sql zu verwenden. Informationen und Beispiele finden Sie auf der Dokumentationsseite zu sql_create.

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

Wenn Sie eine SQL-basierte abgeleitete Tabelle definieren, müssen Sie jeder Spalte mit 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 werden, können nicht inkrementell erstellt werden.

Temporäre und persistente abgeleitete Tabellen

Neben der Unterscheidung zwischen nativen abgeleiteten Tabellen und SQL-basierten abgeleiteten Tabellen wird auch zwischen einer temporären abgeleiteten Tabelle, die nicht in die Datenbank geschrieben wird, und einer persistenten abgeleiteten Tabelle (PAT), die in ein Schema in Ihrer Datenbank geschrieben wird, unterschieden.

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

Temporäre abgeleitete Tabellen

Die zuvor 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 mindestens einer abgeleiteten Tabelle 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 Zwischenspeichern von Abfragen in Looker finden Sie auf der Dokumentationsseite Abfragen zwischenspeichern.

Wenn Looker keine zwischengespeicherten Ergebnisse verwenden kann, muss jedes Mal, wenn ein Nutzer Daten aus einer temporären abgeleiteten Tabelle anfordert, eine neue Abfrage in der Datenbank ausgeführt werden. Daher sollten Sie sich sicher sein, 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. Die folgende Tabelle zeigt, welche Dialekte in der neuesten Version von Looker abgeleitete Tabellen unterstützen:

Klicken Sie hier, um die Tabelle aufzurufen.

Dialekt	Unterstützt?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

Persistente abgeleitete Tabellen

Eine persistente abgeleitete Tabelle (PDT) ist eine abgeleitete Tabelle, die in ein temporäres Schema Ihrer Datenbank geschrieben und nach dem von Ihnen mit einer Persistenzstrategie festgelegten Zeitplan neu generiert wird.

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 eine Liste 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 verwenden, z. B. eine Produktions- und eine QA-Instanz, stellen Sie sicher, dass Sie für jede Instanz unterschiedliche Scratch-Schemas festlegen, um PDT-Verwaltungskonflikte zu vermeiden.

• Eine Looker-Verbindung, die so konfiguriert ist, dass die Option PDTs aktivieren eingeschaltet ist. Diese PDTs aktivieren Einstellung wird normalerweise bei der Ersteinrichtung Ihrer Looker-Verbindung konfiguriert (Anweisungen für Ihren Datenbankdialekt finden Sie auf der Looker-Dialekte Dokumentationsseite), Sie können PDTs aber auch nach der Ersteinrichtung für Ihre Verbindung aktivieren.

Unterstützte Datenbankdialekte für PDTs

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

Um jegliche Art von PDTs (entweder LookML-basiert oder SQL-basiert) zu unterstützen, muss der Dialekt Schreibvorgänge in die Datenbank unterstützen.unter anderem Anforderungen Die Es gibt einige schreibgeschützte Datenbankkonfigurationen, die keine Persistenz zulassen (am häufigsten Postgres Hot-Swap-Replikatdatenbanken). In diesen Fällen können Sie stattdessen temporäre abgeleitete Tabellen verwenden.

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

Klicken Sie hier, um die Tabelle aufzurufen.

Dialekt	Unterstützt?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

Um persistente native abgeleitete Tabellen (die LookML-basierte Abfragen haben) 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:

Klicken Sie hier, um die Tabelle aufzurufen.

Dialekt	Unterstützt?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

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, die Looker erstellt, indem neue Daten an die Tabelle angehängt werden, anstatt sie vollständig neu zu erstellen.

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

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

Weitere Informationen finden Sie auf der Dokumentationsseite Incremental 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. Die folgende Tabelle zeigt, welche Dialekte inkrementelle PDTs in der neuesten Version von Looker unterstützen:

Klicken Sie hier, um die Tabelle aufzurufen.

Dialekt	Unterstützt?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

PDTs erstellen

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

Persistenzstrategien

Die Persistenz einer abgeleiteten Tabelle kann von Looker oder, für Dialekte, die materialisierte Sichten unterstützen, von Ihrer Datenbank mithilfe von materialisierten Sichten verwaltet werden.

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

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

Bei triggerbasierten Persistenzstrategien (datagroup_trigger, sql_trigger_value und interval_trigger) behält Looker den PDT in der Datenbank bei, bis der PDT zum Neuaufbau ausgelöst wird. Nach Auslösen der PDT erstellt Looker die PDT neu, um die vorherige Version zu ersetzen. Das bedeutet, dass Ihre Benutzer bei triggerbasierten PDTs nicht warten müssen, bis der PDT erstellt ist, um Antworten auf Explore-Abfragen vom PDT zu erhalten.

Hinweis: Bestimmte Benutzer können die Persistenzeinstellung eines PDT überschreiben. Ein Benutzer mit der Berechtigung develop kann die Option Abgeleitete Tabellen neu erstellen & ausführen aus dem Menü eines Explore verwenden, um die Persistenzeinstellung zu überschreiben und alle für die aktuelle Abfrage im Explore erforderlichen PDTs neu zu erstellen. Weitere Informationen finden Sie im Abschnitt Manuelles Neuerstellen von PDTs für eine Abfrage auf dieser Seite.

datagroup_trigger

Datagroups sind die flexibelste Methode zur Erzeugung von Persistenz. Wenn Sie eine datagroup mit sql_trigger oder interval_trigger definiert haben, können Sie den Parameter datagroup_trigger verwenden, um den Wiederaufbau Ihrer persistenten abgeleiteten Tabellen (PDTs) zu 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 bedeutet, dass Ihre Benutzer in den meisten Fällen nicht warten müssen, bis die PDT erstellt ist. Wenn ein Benutzer Daten vom PDT anfordert, während dieser gerade erstellt wird, und die Abfrageergebnisse nicht im Cache vorhanden sind, gibt Looker Daten vom bestehenden PDT zurück, bis der neue PDT erstellt ist. Siehe Caching queries für eine Übersicht über Datengruppen.

Weitere Informationen darüber, wie der Regenerator PDTs erstellt, finden Sie im Abschnitt The Looker regenerator.

sql_trigger_value

Der Parameter sql_trigger_value löst die Neugenerierung einer persistenten abgeleiteten Tabelle (PDT) aus, die auf einer von Ihnen bereitgestellten SQL-Anweisung basiert. 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 bedeutet, dass Ihre Benutzer in den meisten Fällen nicht warten müssen, bis die PDT erstellt ist. Wenn ein Benutzer Daten vom PDT anfordert, während dieser gerade erstellt wird, und die Abfrageergebnisse nicht im Cache vorhanden sind, gibt Looker Daten vom bestehenden PDT zurück, bis der neue PDT erstellt ist.

Weitere Informationen darüber, wie der Regenerator PDTs erstellt, finden Sie im Abschnitt The Looker regenerator.

interval_trigger

Der Parameter interval_trigger löst die Regenerierung einer persistenten abgeleiteten Tabelle (PDT) basierend auf einem von Ihnen angegebenen Zeitintervall aus, z. B. "24 hours" oder "60 minutes". Ähnlich wie beim Parameter sql_trigger bedeutet das, dass die PDT in der Regel vorab erstellt wird, wenn Ihre Nutzer sie abfragen. Wenn ein Nutzer Daten aus 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 ist die Verwendung des Parameters persist_for, um festzulegen, wie lange die abgeleitete Tabelle gespeichert werden soll, bevor sie als abgelaufen markiert wird. Sie wird dann nicht mehr für Abfragen verwendet und aus der Datenbank gelöscht.

Eine persist_for persistente abgeleitete Tabelle (PDT) wird erstellt, wenn ein Nutzer die erste 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 der persist_for-Zeit löscht Looker die PDT aus der Datenbank. Sie wird dann bei der nächsten Abfrage durch einen Nutzer neu erstellt. In dem Fall muss die Abfrage warten, bis die Neuerstellung abgeschlossen ist.

PDTs, für die persist_for verwendet wird, werden vom Looker-Regenerator nicht automatisch neu erstellt, außer bei einer Kaskade von PDTs mit Abhängigkeiten. Wenn eine persist_for-Tabelle Teil einer Abhängigkeitskaskade mit auslöserbasierten 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 Ihre Looker-Verbindung mit der Ein/Aus-Schaltfläche PDTs aktivieren konfiguriert 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 Dialektunterstützung, zu den 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 Ihre PDTs mithilfe der folgenden Strategien optimieren, sofern diese von Ihrem Dialekt unterstützt werden:

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

Um beispielsweise die Persistenz der von abgeleiteten Tabelle example zu erhöhen, könnten Sie festlegen, dass sie beim Auslösen der Datengruppe orders_datagroup neu erstellt wird, und Indizes für customer_id und first_order hinzufügen, wie folgt:

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

Wenn Sie keinen Index hinzufügen (oder ein Äquivalent für Ihren Dialekt), warnt Sie Looker, dass Sie dies tun sollten, um die Abfrageleistung zu verbessern.

Anwendungsfälle für PDTs

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

Als generelle Best Practice sollten Entwickler versuchen, Daten ohne PDTs zu modellieren, es sei denn, dies ist absolut notwendig.

In einigen Fällen können Daten auch auf anderem Wege optimiert werden. Beispielsweise kann das Hinzufügen eines Index oder das Ändern des Datentyps einer Spalte ein Problem lösen, ohne dass ein PDT erstellt werden muss. Analysieren Sie unbedingt die Ausführungspläne langsamer Abfragen mithilfe des Tools Explain from SQL Runner.

Neben der Reduzierung der Abfragezeit und der Datenbanklast bei häufig ausgeführten Abfragen gibt es noch weitere Anwendungsfälle für PDTs, darunter:

• Testoptimierungen
• Vor dem Zusammenführen oder Aggregieren von Daten

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

PDTs zum Testen von Optimierungen

Mit PDTs können Sie verschiedene Indexierungs-, Verteilungs- und andere Optimierungsoptionen testen, ohne dass dafür umfangreiche Unterstützung von Ihrem Datenbankadministrator oder Ihren ETL-Entwicklern erforderlich ist.

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

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

Um Optimierungsstrategien zu testen, können Sie den Parameter indexes verwenden, um dem LookML Indizes wie folgt hinzuzufügen:

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

Die Ansicht muss einmal abgefragt werden, um den PDT zu generieren. Führen Sie anschließend Ihre Testabfragen aus und vergleichen Sie die Ergebnisse. Wenn Ihre Ergebnisse positiv ausfallen, können Sie Ihren Datenbankadministrator oder Ihr ETL-Team bitten, die Indizes zur Originaltabelle hinzuzufügen.

Vergessen Sie nicht, Ihren Ansichtscode wieder so zu ändern, dass die PDT entfernt wird.

Verwendung von PDTs zum Vorverknüpfen oder Aggregieren von Daten

Es kann hilfreich sein, Daten vorab zu verknüpfen oder vorab zu aggregieren, um die Abfrageoptimierung bei großen Datenmengen oder mehreren Datentypen anzupassen.

Nehmen wir beispielsweise an, Sie möchten eine Abfrage für Kunden nach Kohorte erstellen, basierend darauf, wann sie ihre erste Bestellung aufgegeben haben. Diese Abfrage kann aufwändig sein, wenn sie mehrmals ausgeführt werden muss, sobald die Daten in Echtzeit benötigt werden; Sie können die Abfrage jedoch nur einmal berechnen und die Ergebnisse dann mit einem PDT wiederverwenden:

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

Kaskadierende abgeleitete Tabellen

Es ist möglich, in der Definition einer anderen abgeleiteten Tabelle auf diese zu verweisen, wodurch eine Kette von kaskadierenden abgeleiteten Tabellen oder kaskadierenden persistenten abgeleiteten Tabellen (PDTs) entsteht. 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 abhängt und TABLE_B von TABLE_A abhängt.

Hinweis: Bevor Sie kaskadierende abgeleitete Tabellen einrichten, ist es wichtig zu wissen, wie kaskadierende Tabellen automatisch vom Looker-Regenerator neu erstellt werden und wie sie manuell von Benutzern neu erstellt werden können. Es gibt auch andere wichtige Überlegungen für die Implementierung persistenter Tabellen. Alle diese Themen werden später 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 eine Literalzeichenkette. Beispielsweise können Sie mit dieser Syntax auf die abgeleitete Tabelle clean_events verweisen:

`${clean_events.SQL_TABLE_NAME}`

Mit derselben Syntax können Sie auch auf eine LookML-Ansicht verweisen. Auch in diesem Fall ist SQL_TABLE_NAME eine Literalzeichenkette.

Hinweis: Die ${derived_table_or_view_name.SQL_TABLE_NAME} Syntax wird im sql_trigger Parameter einer datagroup nicht unterstützt, daher können Sie 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 Ihre PDT-Neuerstellungen auszulösen.

Im nächsten Beispiel wird die clean_events PDT aus der events Tabelle in der Datenbank erstellt. Die clean_events PDT lässt unerwünschte Zeilen aus der events Datenbanktabelle aus. Anschließend wird ein zweiter PDT angezeigt; der event_summary PDT ist eine Zusammenfassung des clean_events PDT. Die Tabelle event_summary wird jedes Mal neu generiert, wenn neue Zeilen zu clean_events hinzugefügt werden.

Die event_summary PDT und die clean_events PDT sind kaskadierende PDTs, wobei event_summary von clean_events abhängig ist (da event_summary mithilfe der clean_events PDT definiert wird). Dieses spezielle Beispiel ließe sich effizienter in einer einzigen PDT-Datei umsetzen, eignet sich aber gut zur Veranschaulichung abgeleiteter Tabellenverweise.

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

Auch wenn es nicht immer erforderlich ist, ist es oft hilfreich, bei der Verwendung einer abgeleiteten Tabelle in diesem Format einen Alias ​​für die Tabelle zu erstellen:

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

Das ist im vorherigen Beispiel der Fall:

${clean_events.SQL_TABLE_NAME} AS clean_events

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

So erstellt Looker kaskadierende abgeleitete Tabellen

Im Falle von kaskadierenden temporären abgeleiteten Tabellen erstellt Looker alle für die Abfrage benötigten abgeleiteten Tabellen, falls die Abfrageergebnisse eines Benutzers nicht im Cache vorhanden sind. Wenn Sie ein TABLE_D haben, dessen Definition eine Referenz auf TABLE_C enthält, dann ist TABLE_D abhängig von TABLE_C. Das bedeutet, dass Looker TABLE_D neu aufbaut, wenn Sie TABLE_D abfragen und die Abfrage nicht im Looker-Cache vorhanden ist. Aber zuerst muss TABLE_C neu aufgebaut werden.

Betrachten wir ein Szenario mit kaskadierenden temporären abgeleiteten Tabellen, wobei TABLE_D von TABLE_C abhängt, welches von TABLE_B abhängt, welches von TABLE_A abhängt. Falls Looker für eine Abfrage auf TABLE_C keine gültigen Ergebnisse im Cache hat, erstellt Looker alle Tabellen, die für die Abfrage benötigt werden. 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 die Generierung von TABLE_B muss abgeschlossen sein, bevor Looker mit der Generierung von TABLE_C beginnen kann. Wenn TABLE_C abgeschlossen ist, liefert Looker die Abfrageergebnisse. (Da TABLE_D zur Beantwortung dieser Anfrage nicht benötigt wird, wird Looker TABLE_D zu diesem Zeitpunkt nicht neu erstellen.)

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 jede Tabelle, die zur Beantwortung einer Abfrage erforderlich ist, und zwar entlang der gesamten Abhängigkeitskette. Bei PDTs ist es jedoch oft so, dass die Tabellen bereits existieren und nicht neu erstellt werden müssen. Bei Standardbenutzerabfragen zu 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 einen Neuaufbau für alle PDTs in einer Kaskade erzwingen möchten, können Sie manuell die Tabellen für eine Abfrage über einen Explore neu aufbauen.

Ein wichtiger logischer Punkt, den es zu verstehen gilt, ist, dass im Falle einer PDT-Kaskade eine abhängige PDT im Wesentlichen abfragt die PDT, von der sie abhängt. Dies ist insbesondere für PDTs von Bedeutung, die die persist_for-Strategie verwenden. Typischerweise werden persist_for PDTs erstellt, wenn ein Benutzer sie abfragt, bleiben in der Datenbank, bis ihr persist_for Intervall abgelaufen ist, und werden dann erst wieder erstellt, wenn sie das nächste Mal von einem Benutzer abgefragt werden. Wenn jedoch ein persist_for PDT Teil einer Kaskade mit triggerbasierten PDTs ist (PDTs, die die Persistenzstrategie datagroup_trigger, interval_trigger oder sql_trigger_value verwenden), wird der persist_for PDT im Wesentlichen immer dann abgefragt, wenn seine abhängigen PDTs neu aufgebaut werden. In diesem Fall wird die persist_for PDT also gemäß dem Zeitplan ihrer abhängigen PDTs neu aufgebaut. Dies bedeutet, dass persist_for PDTs von der Persistenzstrategie ihrer abhängigen Elemente beeinflusst werden können.

Wenn Sie die Persistenz für tief verschachtelte PDT-Strukturen (Ketten von kaskadierenden PDTs mit mehreren Abhängigkeitsebenen) konfigurieren, stellen Sie sicher, dass Ihre Cache-Aufbewahrungsperioden und Datengruppenintervalle genügend Zeit für den Aufbau der gesamten Kaskade bieten. Kurze Cache-Speicherzeiten können eine Race Condition verursachen, die beim Aktualisieren zu einem 409 Conflict-Fehler führt. Weitere Informationen und empfohlene Vorgehensweisen finden Sie im Abschnitt Troubleshooting 409 Conflict errors in deep nested PDTs auf dieser Seite.

Persistente Tabellen für eine Abfrage manuell neu erstellen

Benutzer können die Option Abgeleitete Tabellen neu erstellen & ausführen aus dem Menü eines Explore-Fensters auswählen, um die Persistenzeinstellungen zu überschreiben und alle persistenten abgeleiteten Tabellen (PDTs) und Aggregattabellen neu zu erstellen, die für die aktuelle Abfrage im Explore-Fenster erforderlich sind:

Diese Option ist nur für Benutzer mit der Berechtigung develop sichtbar und erst nachdem die Explore-Abfrage geladen wurde.

Die Option Rebuild Derived Tables & Run erstellt alle persistenten Tabellen (alle PDTs und Aggregattabellen) neu, die zur Beantwortung der Abfrage erforderlich sind, unabhängig von ihrer Persistenzstrategie. Dies umfasst alle Aggregattabellen und PDTs in der aktuellen Abfrage sowie alle Aggregattabellen und PDTs , auf die von den Aggregattabellen und PDTs in der aktuellen Abfrage verwiesen wird.

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

Im Falle von kaskadierenden PDTs bedeutet dies, dass alle abgeleiteten Tabellen in der Kaskade neu aufgebaut werden müssen, beginnend mit der obersten. Dies entspricht dem Verhalten, das auftritt, wenn Sie eine Tabelle in einer Kaskade temporärer abgeleiteter Tabellen abfragen:

Beachten Sie Folgendes zum manuellen Neuerstellen abgeleiteter Tabellen:

• Für den Benutzer, der die Operation Rebuild Derived Tables & Run initiiert, wartet die Abfrage, bis die Tabellen neu erstellt wurden, bevor die Ergebnisse geladen werden. Die Abfragen anderer Benutzer verwenden weiterhin die bestehenden Tabellen. Wenn die persistenten Tabellen erneut erstellt wurden, verwenden alle Benutzer die neu erstellten Tabellen. Obwohl dieser Prozess so konzipiert ist, dass die Abfragen anderer Benutzer während des Tabellenneuaufbaus nicht unterbrochen werden, könnten diese Benutzer dennoch durch die zusätzliche Belastung Ihrer Datenbank beeinträchtigt werden. 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.

• Befindet sich ein Benutzer im Entwicklungsmodus und basiert die Erkundung auf einer Entwicklungstabelle, so wird die Operation Abgeleitete Tabellen neu erstellen & ausführen die Entwicklungstabelle und nicht die Produktionstabelle für die Erkundung neu erstellen. Wenn jedoch im Entwicklungsmodus die Produktionsversion einer abgeleiteten Tabelle verwendet wird, wird die Produktionstabelle neu erstellt. Siehe Persistierte Tabellen im Entwicklungsmodus für Informationen zu Entwicklungstabellen und Produktionstabellen.

• Bei Looker-gehosteten Instanzen gilt: Dauert der Wiederaufbau der abgeleiteten Tabelle länger als eine Stunde, wird die Tabelle nicht erfolgreich wiederhergestellt und die Browsersitzung wird abgebrochen. Weitere Informationen zu Timeouts, die sich auf Looker-Prozesse auswirken können, finden Sie im Abschnitt Query timeouts and queueing auf der Dokumentationsseite Admin settings - Queries.

Persistente Tabellen im Entwicklungsmodus

Looker verfügt über einige spezielle Verhaltensweisen für die Verwaltung persistenter Tabellen im Entwicklungsmodus.

Hinweis: Dieses Verhalten gilt für alle Arten von persistenten Tabellen, einschließlich Aggregattabelle sowie persistenter abgeleiteter Tabellen (PDTs).

Wenn Sie eine persistente Tabelle im Entwicklungsmodus abfragenohne Bei jeder Änderung an der Definition der Tabelle fragt Looker die Produktionsversion dieser Tabelle ab. Wenn Sie do eine Änderung an der Tabellendefinition vornehmen, die sich auf die Daten in der Tabelle oder die Art und Weise, wie die Tabelle abgefragt wird, auswirkt, wird beim nächsten Abfragen der Tabelle im Entwicklungsmodus eine neue Entwicklungsversion der Tabelle erstellt. Mithilfe einer solchen Entwicklungstabelle können Sie Änderungen testen, ohne die Benutzer 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 Ihre persistente Tabelle einen Parameter hat, der ihren Datensatz auf work faster in Development Mode einschränkt
• 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 ist nicht der Fall für native abgeleitete Tabellen mit dem dev_filters Parameter. Bei nativen abgeleiteten Tabellen mit dev_filters verwendet Looker standardmäßig die Produktionstabelle zur Beantwortung von Abfragen im Entwicklungsmodus, es sei denn, Sie ändern die Tabellendefinition und führen anschließend eine Abfrage im Entwicklungsmodus durch.

Bei persistenten Tabellen, die keinen Parameter zur Einschränkung des Datensatzes im Entwicklungsmodus besitzen, verwendet Looker die Produktionsversion der Tabelle, um Abfragen im Entwicklungsmodus zu beantworten, es sei denn, Sie ändern die Definition der Tabelle undDann Die Tabelle im Entwicklungsmodus abfragen. Dies gilt für alle Änderungen an der Tabelle, die sich auf die Daten in der Tabelle auswirken oder auf die Art und Weise, wie die Tabelle abgefragt wird.

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

• Ändern der Abfrage, auf der die persistente Tabelle basiert, z. B. durch Ändern des Parameters explore_source, sql, query, sql_create oder create_process in der persistenten Tabelle selbst oder in einer beliebigen erforderlichen Tabelle (im Fall von kaskadierenden abgeleiteten Tabellen).
• Die Persistenzstrategie der Tabelle ändern, beispielsweise durch Modifizierung des Parameters datagroup_trigger, sql_trigger_value, interval_trigger oder persist_for der Tabelle.
• Ändern des Namens einer abgeleiteten Tabelle view
• Ändern der increment_key oder increment_offset einer inkrementellen PDT
• Ändern des connection, das vom zugehörigen Modell verwendet wird

Bei Änderungen, die weder die Daten der Tabelle verändern noch 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 Einstellung publish_as_db_view für eine abgeleitete Tabelle ändern, muss Looker die abgeleitete Tabelle nicht neu erstellen und erstellt daher keine Entwicklungstabelle.

Wie lange sind Entwicklungstabellen in Looker abgeleitet?

Ungeachtet der tatsächlichen Persistenzstrategie der Tabelle behandelt Looker persistente Entwicklungstabellen so, als hätten sie einePersistenzstrategie vonpersist_for: "24 hours" Die Looker macht das, um sicherzustellen, dass Entwicklungstabellen nicht länger als einen Tag gespeichert werden, da ein Looker-Entwickler während der Entwicklung möglicherweise viele Iterationen einer Tabelle abfragt und jedes Mal eine neue Entwicklungstabelle erstellt wird. Um zu verhindern, dass die Entwicklungstabellen die Datenbank überladen, wendet Looker die persist_for: "24 hours"-Strategie an, um sicherzustellen, dass die Tabellen regelmäßig aus der Datenbank entfernt werden.

Ansonsten erstellt Looker persistente abgeleitete Tabellen (PDTs) und Aggregattabellen im Entwicklungsmodus auf die gleiche Weise, wie er persistente Tabellen im Produktionsmodus erstellt.

Wenn beim Bereitstellen von Änderungen an einer PDT- oder einer Aggregattabelle eine Entwicklungstabelle in Ihrer Datenbank persistent gespeichert wird, kann Looker die Entwicklungstabelle häufig als Produktionstabelle verwenden, sodass Ihre Benutzer nicht warten müssen, bis die Tabelle erstellt wurde, wenn sie die Tabelle abfragen.

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

• Wenn seit der letzten Abfrage der Tabelle im Entwicklungsmodus mehr als 24 Stunden vergangen sind, wird die Entwicklungsversion der Tabelle als abgelaufen gekennzeichnet und kann nicht mehr für Abfragen verwendet werden. Sie können nach nicht erstellten PDTs über die Looker IDE oder über die Registerkarte 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 Klausel WHERE besitzt, die die Anweisungen if prod und if dev verwendet (für SQL-basierte abgeleitete Tabellen), kann die Entwicklungstabelle nicht als Produktionsversion verwendet werden, da die Entwicklungsversion einen verkürzten Datensatz besitzt. In diesem Fall können Sie, nachdem Sie die Entwicklung der Tabelle abgeschlossen haben und bevor Sie Ihre Änderungen bereitstellen, den Parameter dev_filters oder die bedingte Klausel WHERE auskommentieren und die Tabelle dann im Entwicklungsmodus abfragen. Looker erstellt dann eine vollständige Version der Tabelle, die für die Produktion verwendet werden kann, wenn Sie Ihre Änderungen bereitstellen.

Andernfalls, wenn Sie Ihre Änderungen bereitstellen, während keine gültige Entwicklungstabelle vorhanden ist, die als Produktionstabelle verwendet werden kann, wird Looker die Tabelle beim nächsten Abfragen der Tabelle im Produktionsmodus (für persistente Tabellen, die die Strategie persist_for verwenden) oder beim nächsten Ausführen des regenerator (für persistente Tabellen, die datagroup_trigger, interval_trigger oder sql_trigger_value verwenden) neu erstellen.

Nach nicht erstellten PDTs im Entwicklungsmodus suchen

Wenn beim Bereitstellen von Änderungen an einer persistenten abgeleiteten Tabelle (PDT) oder einer Aggregattabelle eine Entwicklungstabelle in Ihrer Datenbank persistent gespeichert wird, kann Looker die Entwicklungstabelle oft als Produktionstabelle verwenden, sodass Ihre Benutzer nicht warten müssen, bis die Tabelle erstellt wurde, wenn sie die Tabelle abfragen. Weitere Details finden Sie in den Abschnitten Wie lange Looker Entwicklungstabellen speichert und Was Looker veranlasst, eine Entwicklungstabelle zu erstellen auf dieser Seite.

Daher ist es optimal, dass alle Ihre PDTs beim Deployment in die Produktion erstellt werden, damit die Tabellen sofort als Produktionsversionen verwendet werden können.

Im Panel Projektstatus können Sie überprüfen, ob in Ihrem Projekt nicht erstellte PDTs vorhanden sind. Klicken Sie in der Looker IDE auf das Symbol Projektstatus, um das Bedienfeld Projektstatus zu öffnen. Klicken Sie anschließend auf die Schaltfläche PDT-Status überprüfen.

Falls noch nicht erstellte PDTs vorhanden sind, werden diese im Projektstatus-Panel aufgelistet:

Wenn Sie die Berechtigung see_pdts haben, können Sie auf die Schaltfläche Zur PDT-Verwaltung klicken. Looker öffnet die Registerkarte Entwicklung der Seite Persistente abgeleitete Tabellen und filtert die Ergebnisse nach Ihrem spezifischen LookML-Projekt. Von dort aus können Sie sehen, welche Entwicklungs-PDTs erstellt und welche nicht erstellt wurden, und auf weitere Informationen zur Fehlerbehebung zugreifen. Weitere Informationen finden Sie auf der Dokumentationsseite Admin-Einstellungen - Persistente abgeleitete Tabellen.

Sobald Sie eine nicht erstellte PDT in Ihrem Projekt identifiziert haben, können Sie eine Entwicklungsversion davon erstellen, indem Sie eine Explore-Abfrage öffnen, die die Tabelle abfragt, und dann die Option Abgeleitete Tabellen neu erstellen & ausführen aus dem Explore-Menü verwenden. Siehe den Abschnitt Manuelles Wiederherstellen persistenter Tabellen für eine Abfrage auf dieser Seite.

Hinweis: Wenn es sich bei einer persistenten Tabelle um eine SQL-basierte abgeleitete Tabelle handelt, die mithilfe einer bedingten WHERE Klausel mit if prod und if dev Anweisungen definiert wurde, können Sie die Entwicklungsversion der Tabelle nicht für die Produktion verwenden, da die Entwicklungsversion der Tabelle einen verkürzten Datensatz hat. Weitere Informationen finden Sie im Abschnitt Wie lange Looker Entwicklungstabellen speichert auf dieser Seite. Für native abgeleitete Tabellen mit dem Parameter dev_filters verwendet Looker die Produktionstabelle zur Beantwortung von Abfragen im Entwicklungsmodus, es sei denn, Sie ändern die Tabellendefinition und führen anschließend eine Abfrage im Entwicklungsmodus durch (siehe den Abschnitt Was veranlasst Looker, eine Entwicklungstabelle zu erstellen auf dieser Dokumentationsseite).

Tabellen gemeinsam nutzen und bereinigen

Innerhalb einer Looker-Instanz können Tabellen von Benutzern gemeinsam verwendet werden, wenn die Tabellen über dieselbe Definition und dieselbe Einstellung für die Persistenzmethode verfügen. Sollte die Definition einer Tabelle jemals nicht mehr existieren, kennzeichnet Looker die Tabelle als abgelaufen.

Das bringt mehrere Vorteile mit sich:

• Wenn Sie im Entwicklungsmodus keine Änderungen an einer Tabelle vorgenommen haben, verwenden Ihre Abfragen die vorhandenen Produktionstabellen. Dies ist der Fall, es sei denn, Ihre Tabelle ist 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 ist, erstellt Looker eine Entwicklungstabelle, wenn Sie die Tabelle im Entwicklungsmodus abfragen. (Für native abgeleitete Tabellen mit dem Parameter dev_filters verfügt Looker über die Logik, 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 die Generierung der persistenten abgeleiteten Tabelle (PDT), die Sie erstellen, lange dauert, was zeitaufwändig sein kann, wenn Sie viele Änderungen im Entwicklungsmodus testen. Für diese Fälle können Sie Looker anweisen, im Entwicklungsmodus kleinere Versionen einer abgeleiteten Tabelle zu erstellen.

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

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

Dieses Beispiel enthält einen dev_filters-Parameter, der die Daten auf die letzten 90 Tage filtert, und einen filters-Parameter, der die Daten auf die letzten 2 Jahre und den Flughafen Yucca Valley filtert.

Der Parameter dev_filters wirkt zusammen 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 Vorrang für die Entwicklungsversion der Tabelle. 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 unterschiedlichen 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 Klausel WHERE enthält, kann die Entwicklungstabelle nicht als Produktionsversion verwendet werden, da die Entwicklungsversion einen abgekürzten Datensatz besitzt. In diesem Fall können Sie, nachdem Sie die Entwicklung der Tabelle abgeschlossen haben und bevor Sie Ihre Änderungen bereitstellen, den Parameter dev_filters oder die bedingte Klausel WHERE auskommentieren und die Tabelle dann im Entwicklungsmodus abfragen. Looker erstellt dann eine vollständige Version der Tabelle, die für die Produktion verwendet werden kann, wenn Sie Ihre Änderungen bereitstellen. Weitere Informationen zur Verwendung von Entwicklungstabellen in der Produktion finden Sie im Abschnitt Wie lange Looker Entwicklungstabellen speichert auf dieser Seite.

Wie Looker PDTs baut

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

1. Verwenden Sie die SQL-Anweisung der abgeleiteten Tabelle, um eine CREATE TABLE AS SELECT-Anweisung (oder CTAS-Anweisung) zu erstellen und diese auszuführen. Um beispielsweise eine PDT namens customer_orders_facts neu zu erstellen: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
2. Führen Sie die Anweisungen zum Erstellen der Indizes beim Erstellen der Tabelle aus.
3. Benennen Sie die Tabelle von LC$.. ("Looker Create") in LR$.. ("Looker Read") um, um anzuzeigen, dass die Tabelle einsatzbereit ist.
4. Löschen Sie alle älteren Versionen der Tabelle, die nicht mehr verwendet werden sollten.

Daraus ergeben sich einige wichtige Konsequenzen:

• Der SQL-Code, der die abgeleitete Tabelle erstellt, muss innerhalb einer CTAS-Anweisung gültig sein.
• Die Spaltenaliase im Resultset der SELECT-Anweisung müssen gültige Spaltennamen sein.
• Die bei der Angabe von Verteilung, Sortierschlüsseln und Indizes verwendeten Namen müssen die Spaltennamen sein, die in der SQL-Definition der abgeleiteten Tabelle aufgeführt sind, nicht die Feldnamen, die in der LookML definiert sind.

Der Looker-Regenerator

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

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

Der Looker-Regenerator initiiert auch Neuerstellungen für persistente Tabellen, die den Parameter persist_for verwenden, jedoch nur dann, wenn die Tabelle persist_for eine Abhängigkeit cascade einer durch einen Trigger persistenten Tabelle ist. In diesem Fall initiiert der Looker-Regenerator einen Neuaufbau für eine persist_for-Tabelle, da diese Tabelle für den Neuaufbau der anderen Tabellen in der Kaskade benötigt wird. Andernfalls überwacht der Regenerator keine persistenten Tabellen, die die persist_for-Strategie verwenden.

Darüber hinaus erstellt der Looker-Regenerator analytische Modelle in Ihrer Datenbank, wenn Sie das analytische Modell mithilfe des Parameters derived_analytic_model definiert haben. Die Looker-Regeneratorprozesse leiten analytische Modelle ähnlich wie PDTs ab, die materialisierte Ansichten sind. Sowohl materialisierte Sichten als auch abgeleitete analytische Modelle werden nur einmal erstellt und unterstützen keine Trigger wie Datagroup-Trigger, SQL-Trigger oder Intervall-Trigger. Der Looker-Regenerator erstellt analytische Modelle in Ihrer Datenbank nur dann neu, wenn sich deren LookML-Definition ändert oder wenn sich eine der LookML-Ansichten ändert, von denen sie abhängen.

Der Looker-Regeneratorzyklus beginnt in regelmäßigen Abständen, die von Ihrem Looker-Administrator in den Einstellungen Wartungsplan Ihrer Datenbankverbindung konfiguriert werden (standardmäßig beträgt das Intervall fünf Minuten). Der Looker-Regenerator startet jedoch erst dann einen neuen Zyklus, wenn alle Prüfungen und PDT-Wiederherstellungen des letzten Zyklus abgeschlossen sind. Dies bedeutet, dass bei länger laufenden PDT-Builds der Looker-Regeneratorzyklus möglicherweise nicht so häufig ausgeführt wird, wie in der Einstellung Wartungsplan festgelegt. Weitere Faktoren können die Zeit beeinflussen, die zum Wiederherstellen Ihrer Tabellen benötigt wird, wie im Abschnitt Wichtige Überlegungen zur Implementierung persistenter Tabellen auf dieser Seite beschrieben.

Falls der Aufbau einer PDT fehlschlägt, kann der Regenerator versuchen, die Tabelle im nächsten Regeneratorzyklus neu aufzubauen:

• Wenn die Einstellung Retry Failed PDT Builds für Ihre Datenbankverbindung aktiviert ist, versucht der Looker-Regenerator, die Tabelle während des nächsten Regeneratorzyklus neu zu erstellen, auch wenn die Triggerbedingung der Tabelle nicht erfüllt ist.
• Wenn die Einstellung Retry Failed PDT Builds deaktiviert ist, versucht der Looker-Regenerator erst dann, die Tabelle neu zu erstellen, wenn die Auslösebedingung des PDT erfüllt ist.

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

Wichtige Aspekte beim Implementieren persistenter Tabellen

Angesichts der Nützlichkeit persistenter Tabellen (PDTs und Aggregattabellen) ist es möglich, viele davon auf Ihrer Looker-Instanz anzusammeln. Es ist möglich, ein Szenario zu erstellen, in dem der Looker-Regenerator viele Tabellen gleichzeitig erstellen muss. Insbesondere bei kaskadierenden Tabellen oder Tabellen mit langer Laufzeit kann es zu Szenarien kommen, in denen es lange dauert, bis Tabellen neu erstellt werden, oder in denen Benutzer eine Verzögerung beim Abrufen von Abfrageergebnissen aus einer Tabelle erleben, während die Datenbank intensiv an der Generierung der Tabelle arbeitet.

Der Looker regenerator prüft PDT-Trigger, um festzustellen, ob trigger-persistente Tabellen neu aufgebaut werden sollen. Der Regeneratorzyklus wird in regelmäßigen Abständen eingestellt, die von Ihrem Looker-Administrator in den Einstellungen Wartungsplan Ihrer Datenbankverbindung konfiguriert werden (standardmäßig beträgt das Intervall fünf Minuten).

Mehrere Faktoren können die Zeit beeinflussen, die zum Wiederaufbau Ihrer Tische benötigt wird:

• Möglicherweise hat Ihr Looker-Administrator das Intervall der Regenerator-Triggerprüfungen mithilfe der Einstellung Wartungsplan in Ihrer Datenbankverbindung geändert.
• Der Looker-Regenerator startet keinen neuen Zyklus, bis er alle Prüfungen und PDT-Wiederherstellungen des letzten Zyklus abgeschlossen hat. Wenn Sie also PDT-Builds mit langer Laufzeit haben, ist der Looker-Regeneratorzyklus möglicherweise nicht so häufig wie in der Einstellung Wartungsplan festgelegt.
• 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 Rebuilds des Regenerators über das Feld Maximale Anzahl von PDT-Builder-Verbindungen in den Verbindungseinstellungen anpassen.
• Alle PDTs und Aggregattabellen, die durch dasselbe datagroup ausgelöst werden, werden während desselben Regenerationsprozesses neu aufgebaut. Dies kann eine hohe Belastung darstellen, wenn Sie viele Tabellen haben, die die Datengruppe verwenden, entweder direkt oder als Ergebnis von kaskadierenden Abhängigkeiten.

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

• Wenn abgeleitete Tabellen extended werden — Jede Erweiterung einer PDT erzeugt eine neue Kopie der Tabelle in Ihrer Datenbank.
• Wenn abgeleitete Tabellen Vorlagenfilter oder Liquid-Parameter verwenden — Die Persistenz wird für abgeleitete Tabellen, die Vorlagenfilter oder Liquid-Parameter verwenden, nicht unterstützt.
• Wenn native abgeleitete Tabellen aus Explores erstellt werden, die Benutzerattribute mit access_filters oder mit sql_always_where verwenden — werden Kopien der Tabelle in Ihrer Datenbank für jeden angegebenen möglichen Benutzerattributwert erstellt.
• Wenn sich die zugrunde liegenden Daten häufig ändern und Ihr Datenbankdialekt inkrementelle PDTs nicht unterstützt.
• Wenn der Kosten- und Zeitaufwand für die Erstellung von PDTs zu hoch ist.

Je nach Anzahl und Komplexität der persistenten Tabellen in Ihrer Looker-Verbindung kann die Warteschlange viele persistente Tabellen enthalten, die bei jedem Zyklus überprüft und neu erstellt werden müssen. Daher ist es wichtig, diese Faktoren bei der Implementierung abgeleiteter Tabellen in Ihrer Looker-Instanz zu berücksichtigen.

PDTs im großen Stil mithilfe einer API verwalten

Die Überwachung und Verwaltung persistenter abgeleiteter Tabellen (PDTs), die sich in unterschiedlichen Zeitabständen aktualisieren, wird zunehmend komplexer, je mehr PDTs Sie auf Ihrer Instanz erstellen. Erwägen Sie die Verwendung der Looker Apache Airflow-Integration, um Ihre PDT-Zeitpläne zusammen mit Ihren anderen ETL- und ELT-Prozessen zu verwalten.

PDTs überwachen und Fehler beheben

Wenn Sie persistente abgeleitete Tabellen (PDTs) verwenden, insbesondere cascading PDTs, ist es hilfreich, den Status Ihrer PDTs einzusehen. Sie können den Looker verwenden.Persistente abgeleitete Tabellen Admin-Seite um den Status Ihrer PDTs einzusehen. Sie können auch den PDT-Fehlerbehebungsbaum für eine schrittweise Fehlersuche konsultieren.

Bei dem Versuch, PDTs zu reparieren:

• Achten Sie besonders auf den Unterschied zwischenEntwicklungstabellen und Produktionstabellen bei der Untersuchung derPDT-Ereignisprotokoll Die
• Überprüfen Sie, ob die Einstellung Temp Database Ihrer Looker-Verbindung mit Ihrem tatsächlichen Scratch-Schema oder Ihrer Datenbank übereinstimmt. Wenn die Einstellung Temp Database der Verbindung nicht mit dem Scratch-Schema Ihrer Datenbank übereinstimmt, aktualisieren Sie die Einstellung Temp Database, damit Looker persistente abgeleitete Tabellen in Ihrer Datenbank speichern kann.
• 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.
• Stellen Sie sicher, dass alle sql_trigger_value-Abfragen erfolgreich ausgewertet werden und dass sie nur eine Zeile und Spalte zurückgeben. Bei SQL-basierten PDTs können Sie dies tun, indem Sie sie in SQL Runner ausführen. (Die Anwendung von LIMIT schützt vor unkontrollierten Abfragen.) Weitere Informationen zur Verwendung von SQL Runner zum Debuggen abgeleiteter Tabellen finden Sie im Community-Beitrag Using sql runner to test derived tables .
• Ü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 ein LIMIT anzuwenden, um die Abfragezeiten in einem angemessenen Rahmen zu halten.)
• Bei SQL-basierten abgeleiteten Tabellen sollte Folgendes vermieden werden:Gemeinsame Tabellenausdrücke (CTEs) Die Die Verwendung von CTEs mit DTs erzeugt verschachtelte WITH-Anweisungen, die dazu führen können, dass PDTs ohne Vorwarnung fehlschlagen. Verwenden Sie stattdessen die SQL-Anweisung für Ihre CTE, um einen sekundären DT zu erstellen und diesen DT von Ihrem ersten DT aus mit der Syntax ${derived_table_or_view_name.SQL_TABLE_NAME} zu referenzieren.
• Prüfen Sie, ob alle Tabellen, von denen die problematische PDT abhängt – seien es normale Tabellen oder PDTs selbst – existieren und abgefragt werden können.
• Stellen Sie sicher, dass keine Tabellen, von denen die problematische PDT abhängt, gemeinsame oder exklusive Sperren aufweisen. Damit Looker erfolgreich eine PDT erstellen kann, muss es eine exklusive Sperre für die zu aktualisierende Tabelle erlangen. Dies steht im Konflikt mit anderen gemeinsamen oder exklusiven Sperren, die derzeit zur Debatte stehen. Looker kann die PDT erst aktualisieren, wenn alle anderen Sperren entfernt wurden. Das Gleiche gilt für alle exklusiven Sperren auf der Tabelle, aus der Looker einen PDT erstellt; wenn eine exklusive Sperre auf einer Tabelle besteht, kann Looker keine gemeinsame Sperre erwerben, um Abfragen auszuführen, bis die exklusive Sperre aufgehoben ist.
• Verwenden Sie die Schaltfläche Prozesse anzeigen in SQL Runner. Wenn viele Prozesse aktiv sind, kann die Abfragedauer zunehmen.
• Überwachen Sie Kommentare in der Abfrage. Siehe den Abschnitt Abfragekommentare für PDTs auf dieser Seite.

• Wenn datenbankspezifische Datumsfunktionen (wie z. B. current_date()) in der SQL-Abfrage einer abgeleiteten Tabelle verwendet werden, besteht die Gefahr einer Zeitzonenabweichung zwischen der Looker-Sitzung des Benutzers und der zugrunde liegenden Datenbank. Da Datenbankfunktionen direkt innerhalb der Datenbank ausgeführt werden und nicht der von Looker verwendeten Zeitzonenkonvertierung unterliegen, kann diese Diskrepanz zu unerwarteten Ergebnissen bei Datumsfiltern führen (beispielsweise könnte ein Datumsfilter für „Gestern“ ein Ergebnis von vor zwei Tagen gegen Mitternacht liefern).

  Um dieses Problem zu beheben, stellen Sie sicher, dass die Zeitzone zwischen Ihrer Datenbank und der Looker-Instanz korrekt ausgerichtet ist. Gegebenenfalls ist eine Abstimmung mit Ihrem Data-Engineering-Team erforderlich.

• Wenn Sie während einer PDT-Aktualisierung in tief verschachtelten PDT-Strukturen (Ketten von kaskadierenden PDTs mit mehreren Abhängigkeitsebenen) auf einen 409 Conflict-Fehler stoßen, lesen Sie den Abschnitt Troubleshooting 409 Conflict errors in deep nested PDTs auf dieser Seite.

Abfragekommentare für PDTs

Datenbankadministratoren können normale Abfragen von solchen unterscheiden, die persistente abgeleitete Tabellen (PDTs) erzeugen. Looker fügt der CREATE TABLE ... AS SELECT ...-Anweisung Kommentare hinzu, die das LookML-Modell und die Ansicht des PDT sowie eine eindeutige Kennung (Slug) für die Looker-Instanz enthalten. Wird das PDT im Auftrag eines Benutzers im Entwicklungsmodus generiert, geben die Kommentare die Benutzer-ID an. 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 wird auf der Registerkarte „SQL“ eines Explore-Fensters angezeigt, wenn Looker für die Abfrage des Explore-Fensters eine PDT generieren musste. Der Kommentar wird oben in der SQL-Anweisung angezeigt.

Schließlich erscheint der PDT-Generierungskommentar im Feld Message auf der Registerkarte Info des Pop-ups Query Details für jede Abfrage auf der Administrationsseite Queries.

PDTs nach einem Fehler neu erstellen

Wenn eine persistente abgeleitete Tabelle (PDT) einen Fehler aufweist, passiert Folgendes bei der Abfrage 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 Caching queries.)
• Falls die Ergebnisse nicht im Cache vorhanden sind, ruft Looker die Ergebnisse aus dem PDT in der Datenbank ab, sofern eine gültige Version des PDT existiert.
• Wenn die Datenbank keine gültige PDT enthält, versucht Looker, die PDT neu zu erstellen.
• Wenn die PDT nicht wiederhergestellt werden kann, gibt Looker einen Fehler für eine Abfrage zurück. DerLooker-Regenerator wird versuchen, den PDT neu aufzubauen, wenn der PDT das nächste Mal abgefragt wird oder wenn die Persistenzstrategie des PDT das nächste Mal einen Neuaufbau auslöst.

Bei kaskadierenden PDTs gilt die gleiche Logik, außer dass bei kaskadierenden PDTs:

• Wenn eine Tabelle nicht erstellt werden kann, können auch die nachfolgenden PDTs in der Abhängigkeitskette nicht erstellt werden.
• Eine abhängige PDT fragt im Wesentlichen die PDT ab, auf die sie sich stützt, sodass die Persistenzstrategie einer Tabelle den Wiederaufbau der PDTs auslösen kann, die nach oben in der Kette gehen.

Betrachten wir noch einmal das vorherige Beispiel der kaskadierenden Tabellen, wobei TABLE_D von TABLE_C abhängt, welches wiederum von TABLE_B abhängt, welches von TABLE_A abhängt:

Wenn TABLE_B einen Fehler aufweist, gilt für TABLE_B das gesamte Standardverhalten (nicht kaskadierend):

1. Wenn TABLE_B abgefragt wird, versucht Looker zunächst, Ergebnisse aus dem Cache zurückzugeben.
2. Wenn dieser Versuch fehlschlägt, versucht Looker als nächstes, wenn möglich, eine frühere Version der Tabelle zu verwenden.
3. Wenn auch dieser Versuch fehlschlägt, versucht Looker anschließend, die Tabelle neu aufzubauen.
4. Sollte TABLE_B nicht wiederhergestellt werden können, gibt Looker schließlich eine Fehlermeldung zurück.

Looker wird versuchen, TABLE_B erneut aufzubauen, wenn die Tabelle das nächste Mal abgefragt wird oder wenn die Persistenzstrategie der Tabelle das nächste Mal einen Wiederaufbau auslöst.

Das Gleiche gilt auch für die von TABLE_B abhängigen Elemente. Wenn also TABLE_B nicht aufgebaut werden kann und eine Anfrage an TABLE_C vorliegt, erfolgt die folgende Sequenz:

1. Looker wird versuchen, für die Abfrage auf TABLE_C den Cache zu verwenden.
2. Falls die Ergebnisse nicht im Cache vorhanden sind, versucht Looker, Ergebnisse von TABLE_C in der Datenbank abzurufen.
3. Falls keine gültige Version von TABLE_C existiert, versucht Looker, TABLE_C neu zu erstellen, wodurch eine Abfrage auf TABLE_B erzeugt wird.
4. Looker versucht dann, TABLE_B neu aufzubauen (was fehlschlägt, wenn TABLE_B nicht repariert wurde).
5. Wenn TABLE_B nicht wiederhergestellt werden kann, dann kann auch TABLE_C nicht wiederhergestellt werden, sodass Looker für die Abfrage von TABLE_C einen Fehler zurückgibt.
6. Looker wird dann versuchen, TABLE_C gemäß seiner üblichen Persistenzstrategie wiederherzustellen, oder beim nächsten Abfragen des PDT (was auch den nächsten Versuch des Aufbaus von TABLE_D einschließt, da TABLE_D von TABLE_C abhängt).

Sobald das Problem mit TABLE_B behoben ist, versuchen TABLE_B und jede der abhängigen Tabellen, sich gemäß ihrer Persistenzstrategie oder beim nächsten Abfragen (einschließlich des nächsten Wiederherstellungsversuchs einer abhängigen PDT) neu aufzubauen. Wenn eine Entwicklungsversion der PDTs in der Kaskade im Entwicklungsmodus erstellt wurde, können die Entwicklungsversionen als die neuen Produktions-PDTs verwendet werden. (Wie das funktioniert, erfahren Sie im Abschnitt Persistente Tabellen im Entwicklungsmodus auf dieser Seite.) Alternativ können Sie mit Explore eine Abfrage auf TABLE_D ausführen und dann manuell die PDTs für die Abfrage neu erstellen, was einen Neuaufbau aller PDTs entlang der Abhängigkeitskaskade erzwingt.

Fehlerbehebung bei 409-Konfliktfehlern in tief verschachtelten PDTs

Bei der Arbeit mit tief verschachtelten PDT-Strukturen (Ketten von kaskadierenden PDTs mit mehreren Abhängigkeitsebenen) kann die Konfiguration kurzer Cache-Aufbewahrungszeiten (z. B. 15 Minuten) zu einer Race Condition führen, die beim Aktualisieren einen 409 Conflict-Fehler zur Folge hat.

Diese Race Condition entsteht, weil der Cache für die PDTs der unteren Ebene ablaufen könnte, während die PDTs der oberen Ebene noch erstellt werden. Wenn diese Situation eintritt, löst Looker eine neue, doppelte Build-Anforderung für die PDTs der unteren Ebene aus, während der ursprüngliche Job noch im Data Warehouse verarbeitet wird, was zu dem Konflikt führt.

Um diesen Fehler zu beheben oder zu vermeiden, befolgen Sie die folgenden bewährten Vorgehensweisen:

• Erhöhen Sie die Cache-Aufbewahrungsdauer: Legen Sie die Cache-Aufbewahrungsdauer (max_cache_age oder persist_for) für die PDTs auf mindestens das Zwei- bis Dreifache der maximalen Zeit fest, die für den vollständigen Aufbau aller verschachtelten PDTs benötigt wird.
• Erhöhen Sie das Datengruppen-Aktualisierungsintervall: Gewähren Sie ausreichend Zeit, damit tief verschachtelte PDT-Builds abgeschlossen werden können, wodurch das Risiko sich überschneidender Build-Prozesse verringert wird.

Verbesserung der PDT-Leistung

Wenn duErstellen persistenter abgeleiteter Tabellen (PDTs) Die Leistungsfähigkeit kann ein Problem darstellen. Insbesondere wenn die Tabelle sehr groß ist, kann die Abfrage der Tabelle langsam sein, genau wie bei jeder anderen großen Tabelle in Ihrer Datenbank.

Die Leistung lässt sich verbessern, indem man die Daten filtert oder indem man steuert, wie die Daten im PDT sortiert und indiziert werden.

Hinzufügen von Filtern zur Einschränkung des Datensatzes

Bei besonders großen Datensätzen verlangsamt die große Anzahl an Zeilen die Abfragen an eine persistente abgeleitete Tabelle (PDT). Wenn Sie üblicherweise nur aktuelle Daten abfragen, sollten Sie einen Filter zur WHERE-Klausel Ihrer PDT hinzufügen, der die Tabelle auf Daten der letzten 90 Tage oder weniger beschränkt. Auf diese Weise werden bei jedem Neuaufbau der Tabelle nur relevante Daten hinzugefügt, sodass Abfragen wesentlich schneller ausgeführt werden können. Anschließend können Sie ein separates, größeres PDT für die historische Analyse erstellen, um sowohl schnelle Abfragen aktueller Daten als auch die Möglichkeit zur Abfrage alter Daten zu ermöglichen.

Verwendung von indexes oder sortkeys und distribution

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

Es empfiehlt sich in der Regel, den Parameter indexes bei ID- oder Datumsfeldern hinzuzufügen.

Für Redshift ist es üblicherweise am besten, den Parameter sortkeys bei ID- oder Datumsfeldern und den Parameter distribution bei dem Feld hinzuzufügen, das für die Verknüpfung verwendet wird.

Empfohlene Einstellungen zur Leistungsverbesserung

Die folgenden Einstellungen steuern, wie die Daten in der persistenten abgeleiteten Tabelle (PDT) sortiert und indiziert werden. Diese Einstellungen sind optional, aber dringend empfehlenswert:

• Bei Redshift und Aster verwenden Sie den Parameter distribution, um den Spaltennamen anzugeben, dessen Wert zur Verteilung der Daten innerhalb eines Clusters verwendet wird. Wenn zwei Tabellen über die im Parameter distribution angegebene Spalte verknüpft werden, kann die Datenbank die Verknüpfungsdaten auf demselben Knoten finden, sodass die knotenübergreifende E/A minimiert wird.
• Für Redshift setzen Sie den Parameter distribution_style auf all, um die Datenbank anzuweisen, auf jedem Knoten eine vollständige Kopie der Daten zu speichern. Dies wird häufig verwendet, um die E/A zwischen den Knoten zu minimieren, wenn relativ kleine Tabellen verknüpft werden. Setzen Sie diesen Wert auf even, um die Datenbank anzuweisen, die Daten gleichmäßig im Cluster zu verteilen, ohne eine Verteilungsspalte zu verwenden. Dieser Wert kann nur angegeben werden, wenn distribution nicht angegeben ist.
• Für die Rotverschiebung verwenden Sie den Parameter sortkeys. Die Werte legen fest, welche Spalten der PDT verwendet werden, um die Daten auf der Festplatte zu sortieren und so die Suche zu erleichtern. Auf Redshift können Sie entweder sortkeys oder indexes verwenden, aber nicht beides.
• Bei den meisten Datenbanken verwenden Sie den Parameter indexes. Die Werte geben an, welche Spalten der PDT indiziert werden. (Bei Redshift werden Indizes verwendet, um verschachtelte Sortierschlüssel zu generieren.)