In Looker ist eine abgeleitete Tabelle eine Abfrage, deren Ergebnisse wie eine tatsächliche Tabelle in der Datenbank verwendet werden.
Angenommen, Sie haben eine Datenbanktabelle mit dem Namen orders
mit vielen Spalten. Sie möchten einige aggregierte Kennzahlen auf Kundenebene berechnen, wie zum Beispiel die Anzahl der von den einzelnen Kunden platzierten Aufträge oder den Zeitpunkt des ersten Auftrags der verschiedenen Kunden. 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 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
Verwenden Sie zum Erstellen einer abgeleiteten Tabelle in Ihrem Looker-Projekt den Parameter derived_table
unter einem view-Parameter. Innerhalb des Parameters derived_table
können Sie die Abfrage für die abgeleitete Tabelle auf 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 vorhandenenorders
-Ansicht, die in einer separaten Datei definiert ist, die in diesem Beispiel nicht gezeigt wird. Dieexplore_source
-Abfrage in der nativen abgeleiteten Tabelle importiert die Feldercustomer_id
,first_order
undtotal_amount
aus der Ansichtsdateiorders
. - 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 Tabelleorders
in der Datenbank.
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 ;; } }
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 view-Parameters. Sie erstellen die Spalten der nativen abgeleiteten Tabelle, indem Sie die LookML-Dimensionen oder -Messwerte in Ihrem Modell referenzieren. Sehen Sie sich die Ansichtsdatei für die native abgeleitete Tabelle im vorherigen Beispiel an.
Im Vergleich zu SQL-basierten abgeleiteten Tabellen sind native abgeleitete Tabellen bei der Modellierung Ihrer Daten wesentlich leichter zu lesen und zu verstehen.
Weitere Informationen zum Erstellen nativer abgeleiteter Tabellen finden Sie auf der Dokumentationsseite Native abgeleitete Tabellen erstellen.
SQL-basierte abgeleitete Tabellen
Um eine SQL-basierte abgeleitete Tabelle zu erstellen, definieren Sie eine Abfrage in SQL-Begriffen und erstellen Spalten in der Tabelle mit einer SQL-Abfrage. In einer SQL-basierten abgeleiteten Tabelle sind keine Verweise auf LookML-Dimensionen und -Messwerte möglich. Sehen Sie sich dazu die Ansichtsdatei der SQL-basierten abgeleiteten Tabelle im vorherigen Beispiel an.
Üblicherweise definieren Sie die SQL-Abfrage mithilfe des sql
-Parameters innerhalb des derived_table
-Parameters eines view-Parameters.
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 bestimmten Grenzfällen kann der Parameter sql
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 Parametersql
für eine PDT verwenden, umschließt Looker im Hintergrund die DDL-AnweisungCREATE TABLE
des Dialekts um die Abfrage, um die PDT aus der 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 Parametersql
erstellen. Stattdessen können Sie den Parametercreate_process
verwenden, um eine PDT in mehreren Schritten zu erstellen. Informationen und Beispiele finden Sie auf der Dokumentationsseite zum Parametercreate_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 Parametersql_create
anstelle des Parameterssql
eine PDT erstellen. Weitere Informationen und Beispiele finden Sie auf der Dokumentationsseite zusql_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. Das liegt daran, dass Sie in den Dimensionen auf die Spaltennamen Ihrer Ergebnismenge verweisen müssen, z. B. ${TABLE}.first_order
. Aus diesem Grund wird im vorherigen Beispiel MIN(DATE(time)) AS first_order
anstelle von MIN(DATE(time))
verwendet.
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 Benutzer eine Explore-Abfrage ausführt, die eine oder mehrere abgeleitete Tabellen umfasst, erstellt Looker eine SQL-Abfrage. Dazu wird eine Dialekt-spezifische Kombination aus SQL für die abgeleiteten Tabellen und den angeforderten Feldern, Joins und Filterwerten verwendet. 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 im Cache gespeicherten Ergebnisse verwenden kann, muss Looker jedes Mal eine neue Abfrage für Ihre Datenbank ausführen, wenn ein Benutzer Daten aus einer temporären abgeleiteten Tabelle anfordert. 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 Ausführung der Abfrage einige Zeit in Anspruch nimmt, ist ein PDT oft die bessere Option.
Unterstützte Datenbankdialekte für temporäre abgeleitete Tabellen
Damit Looker abgeleitete Tabellen in Ihrem Looker-Projekt unterstützen kann, müssen diese auch von Ihrem Datenbankdialekt unterstützt werden. Die folgende Tabelle zeigt, welche Dialekte abgeleitete Tabellen in der neuesten Version von Looker unterstützen:
Dialekt | Unterstützt? |
---|---|
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+ 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-Datenbank | Ja |
Microsoft Azure Synapse-Analyse | 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 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) ist eine abgeleitete Tabelle, die in ein Scratch-Schema in der Datenbank geschrieben und nach dem Zeitplan, den Sie mit einer Persistenzstrategie festgelegt haben, neu generiert wird.
Eine PDT kann entweder eine native abgeleitete Tabelle oder eine SQL-basierte abgeleitete Tabelle sein.
Anforderungen für 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 zu Looker-Dialekten. Sie können PDTs aber auch nach der Ersteinrichtung für Ihre Verbindung aktivieren.
Unterstützte Datenbankdialekte für PDTs
Damit Looker in Ihrem Looker-Projekt persistente abgeleitete Tabellen (PDTs) unterstützen kann, müssen diese auch von Ihrem Datenbankdialekt unterstützt werden.
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.
Die folgende Tabelle zeigt die Dialekte, die persistente SQL-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+ | Nein |
Apache Druid 0.18+ | 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+ 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-Datenbank | Ja |
Microsoft Azure Synapse-Analyse | 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 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+ | Nein |
Apache Druid 0.18+ | 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+ 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-Datenbank | Ja |
Microsoft Azure Synapse-Analyse | 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 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 |
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 gesamte Tabelle 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.
Weitere Informationen finden Sie auf der Dokumentationsseite Inkrementelle 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:
Dialekt | Unterstützt? |
---|---|
Actian Lawine | Nein |
Amazon Athena | Nein |
Amazon Aurora MySQL | Nein |
Amazon Redshift | Ja |
Druid | Nein |
Apache Druid 0.13+ | Nein |
Apache Druid 0.18+ | 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+ 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-Analyse | 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+ | Ja |
PostgreSQL vor 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 von Looker oder – bei Dialekten, die materialisierte Ansichten unterstützen – von Ihrer 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: <ph type="x-smartling-placeholder">
- Datenbankverwaltete Persistenzparameter:
<ph type="x-smartling-placeholder">
- </ph>
materialized_view: yes
Mit Trigger-basierten Persistenzstrategien (datagroup_trigger
, sql_trigger_value
und interval_trigger
) behält Looker die PDT in der Datenbank bei, bis die Neuerstellung 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.
datagroup_trigger
Datengruppen sind die flexibelste Methode zur Schaffung von Persistenz. Wenn Sie eine Datengruppe mit sql_trigger
oder interval_trigger
definiert haben, können Sie 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 dazu, wie der Regenerator PDTs erstellt, finden Sie im Abschnitt Der 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 Parameter sql_trigger
bedeutet dies, dass die PDT normalerweise vorgefertigt wird, wenn Nutzer sie abfragen. 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 persistente abgeleitete Tabelle (PDT) mit persist_for
wird erstellt, wenn ein Nutzer zum ersten Mal eine Abfrage in ihr ausführt. Looker behält die PDT dann so lange in der Datenbank bei, wie im Parameter persist_for
der PDT angegeben ist. Wenn ein Nutzer die PDT innerhalb der Zeit von persist_for
abfragt, verwendet Looker nach Möglichkeit im Cache gespeicherte Ergebnisse oder führt die Abfrage für die PDT aus.
Nach dem persist_for
-Zeitpunkt löscht Looker die PDT aus Ihrer 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 Kaskade von PDTs aufgrund einer Abhängigkeit. 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
Mit materialisierten Ansichten können Sie die Funktionen Ihrer Datenbank nutzen, um abgeleitete Tabellen in Ihrem Looker-Projekt zu persistieren. Wenn Ihr Datenbankdialekt materialisierte Ansichten unterstützt und die Looker-Verbindung mit der Ein/Aus-Schaltfläche PDTs aktivieren konfiguriert ist, können Sie eine materialisierte Ansicht erstellen. Geben Sie dazu materialized_view: yes
für eine abgeleitete Tabelle an. Materialisierte Ansichten werden sowohl für native abgeleitete Tabellen als auch für SQL-basierte abgeleitete Tabellen unterstützt.
Ähnlich wie bei einer persistenten abgeleiteten Tabelle (PDT) ist eine materialisierte Ansicht ein Abfrageergebnis, das als Tabelle im Scratch-Schema Ihrer Datenbank gespeichert wird. Der Hauptunterschied zwischen einer PDT und einer materialisierten Ansicht besteht in der Aktualisierung der Tabellen:
- Bei PDTs wird die Persistenzstrategie von Looker definiert und die Persistenz von Looker verwaltet.
- Bei materialisierten Ansichten ist die Datenbank für die Verwaltung und Aktualisierung der Daten in der Tabelle zuständig.
Deshalb benötigen Sie für die Funktionalität der materialisierten Ansicht fortgeschrittenes Wissen um Ihren Dialekt und seine Funktionen. In den meisten Fällen aktualisiert Ihre Datenbank die materialisierte Ansicht jedes Mal, wenn die Datenbank neue Daten in den Tabellen erkennt, die von der materialisierte Ansicht abgefragt werden. Materialisierte Ansichten eignen sich ideal für Szenarien, die Echtzeitdaten erfordern.
Informationen zur Unterstützung von Dialekten, zu 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 mit den folgenden Strategien optimieren, die von Ihrem Dialekt unterstützt werden:
Wenn Sie beispielsweise dem Beispiel einer 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 tun sollten, um die Abfrageleistung zu verbessern.
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. Achten Sie darauf, die Ausführungspläne langsamer Abfragen mit dem Tool Explain from SQL Runner zu analysieren.
Neben der Reduzierung der Abfragezeit und der Datenbanklast bei häufig ausgeführten Abfragen gibt es weitere Anwendungsfälle für PDTs, darunter:
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
Sie können PDTs verwenden, um verschiedene Indexierungen, Verteilungen und andere Optimierungsoptionen zu testen, ohne viel Unterstützung von Ihren DBA- oder ETL-Entwicklern zu benötigen.
Stellen Sie sich einen Fall vor, in dem Sie eine Tabelle haben, aber verschiedene Indexe testen möchten. Ihr anfänglicher LookML-Code für die Ansicht könnte wie folgt aussehen:
view: customer {
sql_table_name: warehouse.customer ;;
}
Zum Testen von Optimierungsstrategien können Sie den Parameter indexes
verwenden, um dem LookML Indexe 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]
}
}
Fragen Sie die Ansicht einmal ab, um die PDT zu generieren. Führen Sie dann die Testabfragen aus und vergleichen Sie die Ergebnisse. Wenn Ihre Ergebnisse positiv ausfallen, können Sie Ihr DBA- oder ETL-Team bitten, die Indexe der ursprünglichen Tabelle hinzuzufügen.
Denken Sie daran, den Ansichtscode wieder zu ändern, um die PDT zu entfernen.
Mit PDTs Daten vorab zusammenführen oder aggregieren
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 einen Bericht zu Kunden nach Kohorte anhand des Zeitpunkts ihrer ersten Bestellung erstellen. 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 anderen auf eine abgeleitete Tabelle zu verweisen. Dabei entsteht eine Kette von kaskadierenden abgeleiteten Tabellen oder kaskadierenden persistenten abgeleiteten Tabellen (PDTs). 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.
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. Sie können beispielsweise mit dieser Syntax auf die abgeleitete Tabelle clean_events
verweisen:
`${clean_events.SQL_TABLE_NAME}`
Mit derselben Syntax können Sie auch auf eine LookML-Ansicht verweisen. Auch in diesem Fall ist SQL_TABLE_NAME
ein literaler String.
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 gezeigt. Die PDT event_summary
ist eine Zusammenfassung der PDT clean_events
. Die Tabelle event_summary
wird jedes Mal neu erstellt, 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) wird leicht vergessen, dass Sie die ${derived_table_or_view_name.SQL_TABLE_NAME}
-Syntax verwenden müssen, um diesen langen Namen abzurufen. Mit einem Aliasnamen kann dieser Fehler vermieden werden.
So erstellt Looker kaskadierende abgeleitete Tabellen
Bei kaskadierenden temporären abgeleiteten Tabellen: Wenn sich die Abfrageergebnisse eines Nutzers nicht im Cache befinden, erstellt Looker alle abgeleiteten Tabellen, die für die Abfrage erforderlich sind. Wenn Sie eine TABLE_D
haben, deren Definition einen Verweis auf TABLE_C
enthält, ist TABLE_D
von TABLE_C
abhängig. Wenn Sie also TABLE_D
abfragen und die Abfrage sich nicht im Cache von Looker befindet, erstellt Looker TABLE_D
neu. Zuerst muss jedoch TABLE_C
neu erstellt werden.
Nehmen wir nun ein Szenario, bei dem temporäre abgeleitete Tabellen kaskadiert werden. Dabei ist TABLE_D
von TABLE_C
abhängig, das wiederum von TABLE_B
abhängig ist, das wiederum von TABLE_A
abhängt. Wenn Looker keine gültigen Ergebnisse für eine Abfrage zu TABLE_C
im Cache hat, erstellt Looker alle für die Abfrage erforderlichen 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
zum Beantworten dieser Abfrage nicht erforderlich ist, wird TABLE_D
zu diesem Zeitpunkt 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 ist es jedoch oft der Fall, dass die Tabellen bereits vorhanden sind und 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.
Ein wichtiger logischer Punkt, der zu verstehen ist, ist, dass im Fall einer PDT-Kaskade eine abhängige PDT im Wesentlichen die PDT abfragt, von der sie abhängig ist. Das ist insbesondere bei PDTs mit der Strategie persist_for
wichtig. In der Regel werden persist_for
-PDTs erstellt, wenn ein Nutzer sie abfragt. Sie bleiben in der Datenbank, bis das persist_for
-Intervall abgelaufen ist, und werden dann erst neu erstellt, wenn sie das nächste Mal 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 Personen beeinflusst werden 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
und erst nach dem Laden der Explore-Abfrage sichtbar.
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. Dies umfasst alle aggregierten Tabellen und PDTs in der aktuellen Abfrage sowie alle aggregierten Tabellen und PDTs, auf die in der aktuellen Abfrage von den aggregierten Tabellen und PDTs verwiesen wird.
Im Fall von inkrementellen PDTs verwenden die Methoden Neu erstellen abgeleitete Tabellen und Ausführen löst den Build 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 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. Es ist das gleiche Verhalten wie bei der Abfrage einer Tabelle in einer Kaskade temporärer abgeleiteter Tabellen:
Beachten Sie bei der manuellen Neuerstellung abgeleiteter Tabellen Folgendes:
- Für den Nutzer, der die Funktion Abgeleitete Tabellen neu erstellen und Run-Vorgang ausführen, wartet die Abfrage, bis die Tabellen neu erstellt wurden, bevor die Ergebnisse geladen werden. Das von anderen Nutzern Abfragen 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, werden die abgeleiteten Tabellen neu erstellen und Mit dem Befehl „Run“ wird die Entwicklungstabelle für das Explore neu erstellt, nicht die Produktionstabelle. Wenn das Explore im Entwicklungsmodus jedoch die Produktionsversion einer abgeleiteten Tabelle verwendet, wird die Produktionstabelle neu erstellt. Informationen zu Entwicklungstabellen und Produktionstabellen finden Sie unter Persistente Tabellen im Entwicklungsmodus.
Wenn die Neuerstellung der abgeleiteten Tabelle bei von Looker gehosteten Instanzen länger als eine Stunde dauert, wird die Tabelle nicht erfolgreich 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 Dokumentationsseite Administratoreinstellungen – Abfragen im Abschnitt Zeitüberschreitungen bei Abfragen und Warteschlangen.
Persistente Tabellen im Entwicklungsmodus
Looker hat einige spezielle Verhaltensweisen für die Verwaltung persistenter Tabellen im Entwicklungsmodus.
Wenn Sie eine persistente Tabelle im Entwicklungsmodus abfragen, ohne Änderungen an der 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 mithilfe einer bedingten WHERE
-Klausel mit if prod
- und if dev
-Anweisungen definiert ist.
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
odercreate_process
in der persistenten Tabelle selbst oder in jeder erforderlichen Tabelle (bei kaskadierenden abgeleiteten Tabellen) - Persistenzstrategie der Tabelle ändern, z. B. den Parameter
datagroup_trigger
,sql_trigger_value
,interval_trigger
oderpersist_for
der Tabelle ändern - Den Namen der
view
einer abgeleiteten Tabelle ändern increment_key
oderincrement_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 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?
Unabhängig von der tatsächlichen Persistenzstrategie der Tabelle behandelt Looker beibehaltene Tabellen in der Entwicklung 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 Entwicklungstabellen die Datenbank überladen, wendet Looker die Strategie persist_for: "24 hours"
an, um dafür zu sorgen, dass die Tabellen regelmäßig aus der Datenbank bereinigt werden.
Andernfalls erstellt Looker persistente abgeleitete Tabellen (PDTs) und aggregierte Tabellen im Entwicklungsmodus auf die gleiche Weise, wie persistente Tabellen im Produktionsmodus erstellt werden.
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 mit der Looker IDE oder über den Tab Entwicklung der Seite Persistente abgeleitete Tabellen nach nicht erstellten PDTs 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 bedingteWHERE
-Klausel, die die Anweisungenif prod
undif dev
verwendet, (für SQL-basierte abgeleitete Tabellen) 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 Parameterdev_filters
oder die bedingteWHERE
-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 und es keine gültige Entwicklungstabelle gibt, die als Produktionstabelle verwendet werden kann, erstellt Looker die Tabelle neu, wenn die Tabelle das nächste Mal im Produktionsmodus abgefragt wird (bei persistenten Tabellen, die die Strategie persist_for
verwenden) oder wenn der Regenerator das nächste Mal ausgeführt wird (bei persistenten Tabellen, die datagroup_trigger
, interval_trigger
oder sql_trigger_value
verwenden).
Nach nicht erstellten PDTs im Entwicklungsmodus suchen
Wenn eine Entwicklungstabelle in Ihrer Datenbank persistent ist, wenn Sie Änderungen in einer persistenten abgeleiteten Tabelle (PDT) oder einer aggregierten Tabelle bereitstellen, kann Looker die Entwicklungstabelle häufig als Produktionstabelle verwenden, damit Ihre Benutzer nicht warten müssen, bis die Tabelle erstellt wurde, wenn sie die Tabelle 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 alle PDTs bei der Bereitstellung in der Produktion erstellt werden, 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 Projektzustand, um den Bereich Projektzustand 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. Looker öffnet den Tab Entwicklung der Seite Persistente abgeleitete Tabellen und filtert die Ergebnisse nach Ihrem spezifischen LookML-Projekt. Hier können Sie feststellen, welche Entwicklungs-PDTs erstellt und welche nicht erstellt wurden, und auf andere Informationen zur Fehlersuche zugreifen. Weitere Informationen finden Sie auf der Dokumentationsseite Administratoreinstellungen – Persistente abgeleitete Tabellen.
Nachdem Sie eine nicht erstellte PDT in Ihrem Projekt identifiziert haben, können Sie eine Entwicklungsversion erstellen. Öffnen Sie dazu ein Explore, das die Tabelle abfragt, und verwenden Sie dann die Option Abgeleitete Tabellen neu erstellen und Run (Ausführen) aus dem Menü „Explore“. Weitere Informationen finden Sie im Abschnitt Persistente Tabellen für eine Abfrage manuell neu erstellen auf dieser Seite.
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 markiert Looker die Tabelle als abgelaufen, wenn die Definition einer Tabelle nicht mehr existiert.
Dies hat mehrere Vorteile:
- Wenn Sie im Entwicklungsmodus keine Änderungen an einer Tabelle vorgenommen haben, werden für Ihre Abfragen die vorhandenen Produktionstabellen verwendet. Dies ist der Fall, es sei denn, es handelt sich bei der Tabelle um eine SQL-basierte abgeleitete Tabelle, die mit einer bedingten
WHERE
-Klausel mitif prod
- undif dev
-Anweisungen definiert wird. Ist die Tabelle mit einer bedingtenWHERE
-Klausel definiert, erstellt Looker eine Entwicklungstabelle, wenn Sie die Tabelle im Entwicklungsmodus abfragen. Bei nativen abgeleiteten Tabellen mit dem Parameterdev_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 persistenten abgeleiteten Tabelle (PDT), die Sie erstellen, sehr lange dauert. Dies kann sehr zeitaufwendig sein, wenn Sie viele Änderungen im Entwicklungsmodus testen. In diesen Fällen können Sie Looker auffordern, kleinere Versionen einer abgeleiteten Tabelle zu erstellen, wenn Sie sich im Entwicklungsmodus befinden.
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
fungiert in Verbindung mit dem Parameter filters
, sodass alle Filter auf die Entwicklungsversion der Tabelle angewendet werden. Wenn sowohl dev_filters
als auch filters
Filter für dieselbe Spalte angeben, hat dev_filters
für die 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.
Wie Looker PDTs erstellt
Nachdem eine persistente abgeleitete Tabelle (PDT) definiert wurde und entweder zum ersten Mal ausgeführt wurde oder vom Regenerator zur Neuerstellung gemäß seiner Persistenzstrategie ausgelöst wurde, durchläuft Looker die folgenden Schritte:
- 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 ...
- Beim Erstellen der Tabelle die Anweisungen zum Erstellen der Indexe ausgeben
- Benennen Sie die Tabelle von „LC$...“ („Looker Create“) in LR$.. („Looker Read“) um, damit die Tabelle einsatzbereit ist.
- Ältere Versionen der Tabelle löschen, die nicht mehr verwendet werden sollen
Dies hat einige wichtige Auswirkungen:
- Die SQL-Abfrage, die die abgeleitete Tabelle bildet, muss innerhalb einer CTAS-Anweisung gültig sein.
- Die Spaltenaliasse im Ergebnissatz der SELECT-Anweisung müssen gültige Spaltennamen sein.
- Die bei der Angabe von Distribution, Sortierschlüsseln und Indexen verwendeten Namen müssen den Spaltennamen entsprechen, die in der SQL-Definition der abgeleiteten Tabelle aufgeführt sind, und nicht den in LookML definierten Feldnamen.
Der Looker-Regenerator
Der Looker-Regenerator prüft den Status und löst Neuerstellungen für Auslöser-persistente Tabellen aus. Eine Trigger-persistente Tabelle ist eine persistente abgeleitete Tabelle (Persistent Derived Table, PDT) oder eine zusammengefasste Tabelle, die einen Trigger als Persistenzstrategie verwendet:
- Bei Tabellen mit
sql_trigger_value
ist der Trigger eine Abfrage, die im Parametersql_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 die abgeleitete Tabelle beispielsweise mit der SQL-AbfrageSELECT CURDATE()
beibehalten wird, erstellt der Looker-Regenerator die Tabelle neu, wenn der Regenerator den Trigger das nächste Mal nach der Datumsänderung überprüft. - Bei Tabellen mit
interval_trigger
ist der Trigger eine im Parameterinterval_trigger
der Tabelle angegebene Zeit. 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 Parametersql_trigger
der zugehörigen Datengruppe angegeben ist, oder eine iminterval_trigger
-Parameter der Datengruppe angegebene Zeitdauer.
Der Looker-Regenerator initiiert auch Neuerstellungen für persistente Tabellen, die den Parameter persist_for
verwenden, aber nur, wenn die Tabelle persist_for
eine Abhängigkeit Kaskade einer trigger-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 Zyklus des Looker-Regenerators beginnt in einem regelmäßigen Intervall, das Ihr Looker-Administrator in der Einstellung Datengruppe und PDT-Wartungszeitplan für Ihre Datenbankverbindung konfiguriert hat (standardmäßig ein 5-Minuten-Intervall). 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 wiederholen aktiviert ist, versucht der Looker-Regenerator die Tabelle im nächsten Regenerator-Zyklus neu zu erstellen, auch wenn die Triggerbedingung 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 Benutzer Daten aus der persistenten Tabelle anfordert, während diese erstellt wird, und die Abfrageergebnisse sich nicht im Cache befinden, 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) nützlich sind, ist es leicht, viele davon in Ihrer Looker-Instanz zu akkumulieren. Es ist möglich, ein Szenario zu erstellen, in dem der Looker-Regenerator viele Tabellen gleichzeitig erstellen muss. Besonders bei kaskadierenden Tabellen oder Tabellen mit langer Ausführungszeit 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 Regenerator von Looker prüft PAT-Trigger, um festzustellen, ob Tabellen mit Trigger-persistenten Daten neu erstellt werden sollen. Der Regenerator-Zyklus wird in einem regelmäßigen Intervall festgelegt, das von Ihrem Looker-Administrator in der Einstellung Datengruppe und PDT-Wartungszeitplan für Ihre Datenbankverbindung konfiguriert wird (standardmäßig ein 5-Minuten-Intervall).
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 dann einen neuen Zyklus, wenn alle Prüfungen und PDT-Neuerstellungen aus dem letzten Zyklus abgeschlossen sind. Bei PDT-Builds mit langer Ausführungszeit ist der Looker-Regenerator-Zyklus möglicherweise nicht so häufig wie die Einstellung Datagroup and PDT Maintenance Schedule (Datengruppe und PDT-Wartungszeitplan).
- Standardmäßig kann der Regenerator die Neuerstellung von jeweils einer PDT oder aggregierten Tabelle über eine Verbindung starten. Ein Looker-Administrator kann die zulässige Anzahl gleichzeitiger Neuerstellungen des Regenerators über das Feld Max number of PDT Builder connections (Max. Anzahl von PDT-Builder-Verbindungen) in den Verbindungseinstellungen anpassen.
- Alle PDTs und aggregierten Tabellen, die von derselben
datagroup
ausgelöst werden, werden während desselben Neuerstellungsvorgangs 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 vorherigen Überlegungen gibt es auch 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 mitsql_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 persistenten abgeleiteten Tabellen (Persistent Derived Tables, PDTs), die nach unterschiedlichen Zeitplänen aktualisiert werden, wird immer komplexer, je mehr PDTs in der Instanz erstellt werden. Erwägen Sie die Verwendung der Apache Airflow-Integration von Looker, um Ihre PDT-Zeitpläne neben Ihren anderen ETL- und ELT-Prozessen zu verwalten.
PDTs überwachen und Fehler beheben
Wenn Sie persistente abgeleitete Tabellen (PDTs) und insbesondere kaskadierende PDTs verwenden, ist es hilfreich, den Status Ihrer PDTs zu sehen. Auf der Admin-Seite Persistente abgeleitete Tabellen von Looker können Sie den Status Ihrer PDTs 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 Einstellungen für Verbindung im Bereich Admin von Looker aktualisieren und Looker dann möglicherweise neu starten, um die normale PDT-Funktionalität wiederherzustellen.
- Finden Sie heraus, ob es nur mit einer PDT oder mit allen Probleme gibt. Ist nur eine PDT betroffen, wird das Problem wahrscheinlich durch einen LookML- oder SQL-Fehler verursacht.
- Finden Sie heraus, ob Probleme mit der PDT mit den Zeiten übereinstimmen, zu denen sie planmäßig neu erstellt werden soll.
- 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. (EinLIMIT
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
LIMIT
anzuwenden, um die Abfragezeiten in einem angemessenen Rahmen zu halten.) - Vermeiden Sie bei SQL-basierten abgeleiteten Tabellen die Verwendung von allgemeinen Tabellenausdrücken. Bei der Verwendung von CTEs mit DTs werden verschachtelte
WITH
-Anweisungen erstellt, die dazu führen können, dass PDTs ohne Warnung fehlschlagen. 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. - Überprü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 vorhanden ist, kann Looker erst dann eine gemeinsame Sperre zum Ausführen von Abfragen abrufen, wenn die exklusive Sperre aufgehoben wird.
- 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 normale Abfragen leicht von Abfragen unterscheiden, die persistente abgeleitete Tabellen (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 Benutzers im Entwicklungsmodus generiert wird, geben die Kommentare die ID des Benutzers 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 in der SQL-Registerkarte eines Explores angezeigt, wenn Looker eine PDT für die Abfrage des Explores generieren musste. Der Kommentar wird oben in der SQL-Anweisung angezeigt.
Schließlich wird der Kommentar zur 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) ausfällt, geschieht Folgendes, wenn diese PDT abgefragt wird:
- 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 die PDT das nächste Mal abgefragt wird oder wenn die Persistenzstrategie der PDT das nächste Mal 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 Wesentlichen die PDT ab, auf die sie sich verlässt, sodass die Persistenzstrategie einer Tabelle Neuerstellungen der PDTs in der Kette auslösen kann.
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 TABLE_B
einen Fehler aufweist, gilt das gesamte (nicht kaskadierende) Standardverhalten für TABLE_B
: Wenn TABLE_B
abgefragt wird, versucht Looker zuerst, den Cache zum Zurückgeben von Ergebnissen zu verwenden. Anschließend wird nach Möglichkeit versucht, eine frühere Version der Tabelle zu verwenden. Anschließend wird versucht, die Tabelle neu zu erstellen. Wenn TABLE_B
nicht neu erstellen kann, wird ein Fehler zurückgegeben. Looker versucht noch einmal, TABLE_B
neu zu erstellen, wenn die Tabelle das nächste Mal abgefragt wird oder wenn die Persistenzstrategie der Tabelle das nächste Mal eine Neuerstellung auslöst.
Dasselbe gilt für abhängige Personen von TABLE_B
. Wenn also TABLE_B
nicht erstellt werden kann und eine Abfrage für TABLE_C
vorliegt:
- Looker versucht, den Cache für die Abfrage am
TABLE_C
zu verwenden. - Wenn sich die Ergebnisse nicht im Cache befinden, versucht Looker, Ergebnisse aus
TABLE_C
in der Datenbank abzurufen. - Wenn keine gültige Version von
TABLE_C
vorhanden ist, versucht Looker,TABLE_C
neu zu erstellen. Dadurch wird eine Abfrage fürTABLE_B
erstellt. - Looker versucht dann,
TABLE_B
neu zu erstellen. Dieser Vorgang schlägt fehl, wennTABLE_B
nicht behoben wurde. - Wenn
TABLE_B
nicht neu erstellt werden kann, kannTABLE_C
auch nicht neu erstellt werden. Daher gibt Looker einen Fehler für die Abfrage inTABLE_C
zurück. - Looker versucht dann,
TABLE_C
gemäß seiner üblichen Persistenzstrategie oder bei der nächsten Abfrage der PDT neu zu erstellen (dazu gehört auch der nächste Build-Versuch vonTABLE_D
, daTABLE_D
vonTABLE_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.
PAT-Leistung verbessern
Wenn Sie persistente abgeleitete Tabellen (PDTs) erstellen, kann die Leistung ein Problem darstellen. 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 Datasets verlangsamen viele Zeilen Abfragen einer persistenten abgeleiteten Tabelle (PDT). Wenn Sie normalerweise nur aktuelle Daten abfragen, können Sie der WHERE
-Klausel Ihrer PDT einen Filter hinzufügen, mit dem die Daten in der Tabelle auf maximal 90 Tage begrenzt werden. 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 historische Analyse erstellen, um sowohl schnelle Abfragen für neue Daten als auch die Möglichkeit, alte Daten abzufragen, zu ermöglichen.
indexes
oder sortkeys
und distribution
werden verwendet
Wenn Sie eine große persistente abgeleitete Tabelle (PDT) erstellen, kann das Indexieren der Tabelle (für Dialekte wie MySQL oder Postgres) oder das Hinzufügen von Sortierschlüsseln und einer Verteilung (für Redshift) die Leistung verbessern.
Normalerweise empfiehlt es sich, den Parameter indexes
in ID- oder Datumsfelder einzufügen.
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 zum Verteilen der Daten um einen Cluster verwendet werden soll. Wenn zwei Tabellen über die im Parameterdistribution
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
aufall
, um die Datenbank anzuweisen, eine vollständige Kopie der Daten auf jedem Knoten zu speichern. Dies wird häufig verwendet, um die E/A zwischen Knoten zu minimieren, wenn relativ kleine Tabellen verknüpft werden. Legen Sie diesen Wert aufeven
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, wenndistribution
nicht angegeben ist. - Verwenden Sie für Redshift den Parameter
sortkeys
. Die Werte geben an, welche Spalten der PDT zum Sortieren der Daten auf dem Laufwerk verwendet werden, um die Suche zu vereinfachen. In Redshift können Sie entwedersortkeys
oderindexes
verwenden, aber nicht beides. - Bei den meisten Datenbanken verwenden Sie den Parameter
indexes
. Die Werte geben an, welche Spalten der PDT indexiert sind. (In Redshift werden Indizes verwendet, um verschränkte Sortierschlüssel zu generieren.)