Abgeleitete Tabellen in Looker

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

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

Sie können dann mit der abgeleiteten Tabelle customer_order_summary so arbeiten, als wäre sie eine andere Tabelle in der Datenbank.

Native abgeleitete Tabellen und SQL-basierte abgeleitete Tabellen

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

Die folgenden Ansichtsdateien zeigen beispielsweise, wie Sie mithilfe von LookML eine Ansicht aus der abgeleiteten Tabelle 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:

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 abgeleitete Tabellenversion
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 namens 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 customer_order_summary-Ansicht wie jede andere Ansichtsdatei. Unabhängig davon, ob Sie die abgeleitete Abfrage mit LookML oder mit SQL definieren, können Sie LookML-Messwerte und -Dimensionen erstellen, die auf den Spalten der abgeleiteten Tabelle basieren.

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

Native abgeleitete Tabellen

Native abgeleitete Tabellen basieren auf Abfragen, die Sie mit LookML-Begriffen definieren. Zum Erstellen einer nativen abgeleiteten Tabelle verwenden Sie den Parameter explore_source innerhalb des Parameters derived_table eines Parameters view. Sie erstellen die Spalten der nativen abgeleiteten Tabelle, indem Sie die LookML-Dimensionen oder -Messwerte in Ihrem Modell referenzieren. Im vorherigen Beispiel sehen Sie die native abgeleitete Tabellenansichtsdatei.

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. Weitere Informationen finden Sie in der SQL-basierten abgeleiteten Tabellenansichtsdatei im vorherigen Beispiel.

In den meisten Fällen wird die SQL-Abfrage mit dem Parameter sql im Parameter derived_table des Parameters view definiert.

Eine hilfreiche Tastenkombination zum Erstellen von SQL-basierten Abfragen in Looker besteht darin, mit SQL Runner die SQL-Abfrage zu erstellen und in eine abgeleitete Tabellendefinition 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 (PDAs):

  • create_process: Wenn Sie den Parameter sql für eine PDT verwenden, umgibt die Hintergrundabfrage von Looker im Hintergrund die DDL-Anweisung (Data Definition Language) für Ihre SQL-Abfrage. Einige Dialekte unterstützen die SQL-CREATE TABLE-Anweisung in einem Schritt nicht. Für diese Dialekte können Sie keine PDT mit dem Parameter sql erstellen. Stattdessen können Sie den Parameter create_process verwenden, um eine PDT in mehreren Schritten zu erstellen. Weitere Informationen und Beispiele finden Sie auf der 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-Vorhersage-Tool BigQuery ML, können Sie den Parameter sql_create verwenden, um eine PDT 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 in allen diesen Fällen die abgeleitete Tabelle mit einer SQL-Abfrage, sodass alle als SQL-basierte abgeleitete Tabellen gelten.

Wenn Sie eine SQL-basierte abgeleitete Tabelle definieren, müssen Sie jeder Spalte mit AS einen sauberen Alias zuweisen. Das liegt daran, dass Sie auf die Spaltennamen in den Dimensionen, z. B. ${TABLE}.first_order, verweisen müssen. Deshalb wird im vorherigen Beispiel MIN(DATE(time)) AS first_order statt MIN(DATE(time)) verwendet.

Temporäre und persistente abgeleitete Tabellen (PDTs)

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

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

Temporäre abgeleitete Tabellen

Die vorher abgeleiteten Tabellen sind Beispiele für vorübergehende abgeleitete Tabellen. Sie sind temporär, weil im Parameter derived_table keine Persistenzstrategie definiert ist.

Temporäre abgeleitete Tabellen werden nicht in die Datenbank geschrieben. Wenn ein Benutzer eine Explore-Abfrage unter Beteiligung mindestens einer abgeleiteten Tabelle ausführt, erstellt Looker mithilfe einer dialektspezifischen Kombination des SQL-Codes für die abgeleitete(n) Tabelle(n) sowie für die angeforderten Felder, Joins und Filterwerte eine SQL-Abfrage. 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 Dokumentation Caching-Abfragen und Neuerstellung von PDTs mit Datengruppen.

Wenn Looker keine im Cache gespeicherten Ergebnisse verwenden kann, muss jedes Mal eine neue Abfrage für Ihre Datenbank ausgeführt werden, wenn ein Nutzer Daten aus einer temporären abgeleiteten Tabelle anfordert. Aus diesem Grund sollten Sie darauf achten, dass Ihre temporären abgeleiteten Tabellen leistungsstark sind und Ihre Datenbank nicht übermäßig belasten. In Fällen, in denen die Abfrage eine gewisse Zeit in Anspruch nimmt, ist eine PDT häufig besser geeignet.

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

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

Persistente abgeleitete Tabellen (PDTs)

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

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

Anforderungen für PDTs

Um 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 weiter unten auf dieser Seite im Abschnitt Unterstützte Datenbankdialekte für PDTs.
  • 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, die mit aktivierter Option Persistente abgeleitete Tabellen konfiguriert ist Dies wird normalerweise bei der Erstkonfiguration der Looker-Verbindung eingerichtet. Auf der Dokumentationsseite Looker-Dialekte finden Sie eine Anleitung für den Datenbankdialekt. Sie können die 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.

Damit alle PDT-Typen (entweder LookML- oder SQL-basiert) unterstützt werden, muss der Dialekt unter anderem Schreibvorgänge in der Datenbank unterstützen. Weitere Informationen Es gibt einige schreibgeschützte Datenbankkonfigurationen, die die Persistenz nicht erlauben (meist bei Postgres- Hot-Swap-Replikatdatenbanken). In diesen Fällen können Sie stattdessen temporär abgeleitete Tabellen verwenden.

In der folgenden Tabelle sehen Sie die Dialekte, die in der neuesten Version von Looker nichtflüchtige SQL-basierte abgeleitete Tabellen unterstützen:

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

Inkrementeller Aufbau von PDTs

Sie können in Ihrem Projekt inkrementelle PDTs erstellen, wenn diese von Ihrem Dialekt unterstützt werden. Eine inkrementelle PDT ist eine persistente abgeleitete Tabelle (PDT), die Looker erstellt, indem aktuelle Daten an die Tabelle angehängt werden, anstatt die Tabelle vollständig neu zu erstellen. 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 in der neuesten Version von Looker inkrementelle PDTs unterstützen:

Persistente abgeleitete Tabellen (PDTs) erstellen

Um eine abgeleitete Tabelle in eine persistente abgeleitete Tabelle (PDT) umzuwandeln, definieren Sie eine Persistenzstrategie für die Tabelle. Zur Optimierung der Leistung sollten Sie auch eine Optimierungsstrategie hinzufügen.

Persistenzstrategien

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

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

Bei Trigger-basierten Persistenzstrategien (datagroup_trigger, sql_trigger und interval_trigger) behält Looker die PDT in der Datenbank bei, bis die PDT zur 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, um Persistenz zu schaffen. Wenn Sie einen datagroup für Ihre Caching-Richtlinien definiert haben, können Sie den Parameter datagroup_trigger verwenden, um die Neuerstellung der PDT nach demselben Zeitplan wie Ihre Caching-Richtlinien einzuleiten.

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

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

sql_trigger_value

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

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

interval_trigger

Der Parameter interval_trigger löst die Neuerstellung einer PDT auf der Grundlage eines von Ihnen angegebenen Zeitintervalls 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 Nutzer sie abfragen. Wenn ein Nutzer während der Erstellung Daten von der PDT anfordert und die Abfrageergebnisse nicht im Cache gespeichert sind, gibt Looker Daten von 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. Sie wird dann nicht mehr für Abfragen verwendet und aus der Datenbank gelöscht.

Eine persist_for-PDT wird erstellt, wenn ein Nutzer erstmals eine Abfrage darauf ausführt. Looker speichert dann die PDT in der Datenbank für die im PDT-Parameter persist_for angegebene Dauer. Wenn ein Nutzer die PDT innerhalb der persist_for-Zeit abfragt, verwendet Looker nach Möglichkeit im Cache gespeicherte Ergebnisse oder führt die Abfrage auf der PDT aus.

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

PDTs, die persist_for verwenden, werden nicht automatisch durch den Regenerator von Looker neu erstellt, außer bei einer Abhängigkeit von PDTs. Wenn eine persist_for-Tabelle Teil einer abhängigen Kaskade mit Trigger-basierten PDTs ist, die die Persistenzstrategie datagroup_trigger, interval_trigger oder sql_trigger_value verwenden, ü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 Datenbankfunktionen nutzen, um abgeleitete Tabellen in Ihrem Looker-Projekt zu speichern. Wenn der Datenbankdialekt materialisierte Ansichten unterstützt und Ihre Looker-Verbindung mit aktivierter Option Persistente abgeleitete Tabellen konfiguriert ist, können Sie eine materialisierte Ansicht erstellen, indem Sie für eine abgeleitete Tabelle materialized_view: yes angeben. 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.

In der Dokumentation zum Parameter materialized_view finden Sie Informationen zur Dialektunterstützung, Anforderungen und wichtige Überlegungen.

Optimierungsstrategien

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

Um dem abgeleiteten Tabellenbeispiel Persistenz hinzuzufügen, könnten Sie festlegen, dass es bei Auslösung der Datengruppe orders_datagroup neu erstellt wird. Fügen Sie dann Indexe für customer_id und first_order hinzu. Das sieht dann so aus:

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 in Ihrem Dialekt) hinzufügen, werden Sie von Looker darauf hingewiesen, dass Sie das tun sollten, um die Abfrageleistung zu verbessern.

Anwendungsfälle für PDTs

PDTs sind hilfreich, da häufig eine Tabelle erstellt wurde, wenn ein Nutzer Daten aus einer Tabelle anfordert. So werden Abfragezeit und Datenbanklast reduziert.

Als allgemeine Best Practice sollten Entwickler versuchen, Daten zu modellieren, ohne PDT zu verwenden, bis dies absolut notwendig ist.

In einigen Fällen lassen sich Daten auf andere Weise optimieren. Wenn Sie beispielsweise einen Index hinzufügen oder den Datentyp einer Spalte ändern, kann ein Problem behoben werden, ohne dass eine PDT erstellt werden muss. Achten Sie darauf, die Ausführungspläne langsamer Abfragen mit dem Explain from SQL Runner-Tool zu analysieren.

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

Sie können auch einen PDT zur Definition eines Primärschlüssels verwenden, wenn es keine vernünftige Möglichkeit gibt, eine einzelne Zeile in einer Tabelle als Primärschlüssel zu identifizieren.

PDTs zum Testen von Optimierungen verwenden

Sie können mit PDTs verschiedene Indexierungs-, Distributions- und andere Optimierungsoptionen testen, ohne große Unterstützung durch Ihre DBA- oder ETL-Entwickler zu benötigen.

Angenommen, Sie haben eine Tabelle, möchten aber verschiedene Indexe testen. Die anfängliche LookML für die Ansicht kann so aussehen:

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

Zum Testen von Optimierungsstrategien können Sie den Parameter indexes verwenden, um Indexe zu LookML 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 das PDT zu generieren. Führen Sie dann die Testabfragen aus und vergleichen Sie die Ergebnisse. Bei positiven Ergebnissen können Sie Ihr DBA- oder ETL-Team bitten, die Indexe der ursprünglichen Tabelle hinzuzufügen.

Denken Sie daran, Ihren Aufrufcode zurückzuändern, um die PDT zu entfernen.

Mit PDTs Daten vorab zusammenführen oder aggregieren

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

Angenommen, Sie möchten Kunden nach Kohorten basierend auf dem Zeitpunkt ihrer ersten Bestellung erfassen. Diese Abfrage kann teuer sein, wenn Daten in Echtzeit benötigt werden. Sie können die Abfrage jedoch nur einmal berechnen und dann die Ergebnisse 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, auf eine abgeleitete Tabelle in der Definition einer anderen zu verweisen und eine Kette von kaskadenförmigen abgeleiteten Tabellen oder kaskadenförmigen PDTs zu erstellen, je nach Fall. Ein Beispiel für kaskadierende abgeleitete Tabellen wäre eine Tabelle, TABLE_D, die von einer anderen Tabelle abhängt, TABLE_C, 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 Literalstring. Mit dieser Syntax können Sie beispielsweise auf die abgeleitete Tabelle clean_events verweisen:

`${clean_events.SQL_TABLE_NAME}`

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

Im nächsten Beispiel wird die PDT clean_events aus der Tabelle events in der Datenbank erstellt. Beim PDT clean_events werden unerwünschte Zeilen aus der Datenbanktabelle events weggelassen. Danach wird eine zweite PDT angezeigt. Die event_summary PDT ist eine Zusammenfassung der clean_events PDT. Die Tabelle event_summary wird immer dann neu generiert, wenn clean_events neue Zeilen hinzugefügt wird.

Die event_summary PDT und die clean_events PDT sind kaskadierende PDT, wobei event_summary von clean_events abhängig ist, da event_summary mit der clean_events PDT definiert ist. Dieses spezielle Beispiel lässt sich mit einer einzigen PDT effizienter ausführen. Es ist jedoch nützlich, um abgeleitete Tabellenreferenzen zu veranschaulichen.

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, wenn Sie auf diese Weise auf eine abgeleitete Tabelle verweisen, ist es häufig sinnvoll, 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 mit ON-Klauseln) kann man leicht vergessen, dass Sie die Syntax ${derived_table_or_view_name.SQL_TABLE_NAME} verwenden müssen, um diesen langen Namen abzurufen. Mit einem Aliasnamen kann dieser Fehler vermieden werden.

So erstellt Looker kaskadierende abgeleitete Tabellen

Wenn die vorübergehenden abgeleiteten Tabellen kaskadiert werden und die Abfrageergebnisse eines Nutzers im Cache liegen, erstellt Looker alle abgeleiteten Tabellen, die für die Abfrage benötigt werden. Wenn Sie eine TABLE_D haben, deren Definition einen Verweis auf TABLE_C enthält, dann ist TABLE_D von TABLE_C abhängig. Wenn Sie also TABLE_D abfragen und sich die Abfrage nicht im Looker-Cache befindet, erstellt Looker TABLE_D neu. Zuerst muss jedoch TABLE_C neu erstellt werden.

Sehen wir uns nun ein Szenario an, in dem temporäre abgeleitete Tabellen kaskadiert werden, wobei TABLE_D von TABLE_C abhängig ist, was wiederum von TABLE_B abhängig ist, die wiederum von TABLE_A abhängt. Wenn Looker keine gültigen Ergebnisse für eine Abfrage in TABLE_C im Cache hat, erstellt Looker alle Tabellen, die für die Abfrage erforderlich sind. Daher erstellt Looker zuerst TABLE_A, dann TABLE_B und dann TABLE_C:

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

Ein Beispiel für kaskadierende PDTs, die dieselbe Datengruppe verwenden, finden Sie auf der Dokumentationsseite zum Parameter datagroup.

Für PDTs gilt dieselbe grundlegende Logik: Looker erstellt jede Tabelle, die zum Beantworten einer Abfrage erforderlich ist, bis hin zur Abhängigkeiten-Kette. Bei PDTs sind es jedoch häufig die Tabellen bereits vorhanden und müssen nicht neu erstellt werden. Bei Standardabfragen von Nutzern zu kaskadierenden PDTs erstellt Looker die PDTs im Kaskaden nur dann neu, wenn in der Datenbank keine gültige Version der PDTs vorhanden ist. Wenn Sie eine Neuerstellung für alle PDTs in einer Kaskade erzwingen möchten, können Sie die Tabellen für eine Abfrage manuell über eine explorative Datenanalyse neu erstellen.

Ein logischer Punkt, den Sie verstehen sollten, ist, dass bei einer PDT-Kaskade ein abhängige PDT im Grunde eine Abfrage des PDT ist, von dem er abhängt. Dies ist insbesondere bei PDTs wichtig, die die Strategie persist_for verwenden. Normalerweise werden persist_for-PDTs erstellt, wenn ein Nutzer sie abfragt. Sie bleiben in der Datenbank, bis ihr persist_for-Intervall abgelaufen ist, und werden erst dann neu erstellt, wenn sie das nächste Mal von einem Nutzer abgefragt werden. Wenn jedoch eine persist_for-PDT Teil einer Kaskade mit Trigger-basierten PDTs ist, die die Persistenzstrategie datagroup_trigger, interval_trigger oder sql_trigger_value verwenden, wird die persist_for-PDT im Grunde 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 PDTs für persist_for von der Persistenzstrategie der ihnen abhängigen Elemente betroffen sein können.

Persistente Tabellen für eine Abfrage manuell neu erstellen

Nutzer können im Menü „Erkunden“ die Option Abgeleitete Tabellen & Ausführung erstellen auswählen, um die Persistenzeinstellungen zu überschreiben und alle PDTs und zusammengefasste Tabellen neu zu erstellen, die für die aktuelle Abfrage in „Erkunden“ erforderlich sind:

Wenn Sie auf die Schaltfläche „Erkunden“ klicken, wird das Menü „Erkunden“ geöffnet, aus dem Sie „Abgeleitete Tabellen neu erstellen &Ausführen“ auswählen können.

Diese Option ist nur für Nutzer mit der Berechtigung develop sichtbar und erst, nachdem die Abfrage „Erkunden“ geladen wurde.

Mit der Option Abgeleitete Tabellen &Ausführen erstellen werden alle nichtflüchtigen Tabellen (alle PDTs und zusammengefasste Tabellen) neu erstellt, die unabhängig von der Persistenzstrategie zum Beantworten der Abfrage erforderlich sind. Dies umfasst alle zusammengefassten Tabellen und PDTs in der aktuellen Abfrage sowie alle aggregierten Tabellen und PDTs, auf die in der aktuellen Abfrage mit den zusammengefassten Tabellen und PDTs verwiesen wird.

Bei inkrementellen PDTs löst die Option Abgeleitete Tabellen &Ausführen wiederherstellen den Build eines neuen Inkrementierens aus. Bei inkrementellen PDTs umfasst ein Inkrement den im Parameter increment_key angegebenen Zeitraum und ggf. die Anzahl der vorherigen Zeiträume im Parameter increment_offset. Auf der Dokumentationsseite Inkrementelle PDTs finden Sie einige Beispielszenarien, in denen die Erstellung zusätzlicher PDTs abhängig von ihrer Konfiguration veranschaulicht wird.

Bei kaskadenförmigen PDTs bedeutet das, dass alle abgeleiteten Tabellen in der Kaskade neu erstellt werden, beginnend mit der Spitze. Das gilt auch, wenn Sie eine Tabelle in einem Kaskaden temporärer abgeleiteter Tabellen abfragen:

Wenn Table_c von Tabelle_b und Tabelle_b von Tabelle_a abhängt, wird Tabelle_c zuerst neu erstellt, dann Tabelle_b und schließlich Tabelle_c.

Beachten Sie beim manuellen Erstellen abgeleiteter Tabellen Folgendes:

  • Für den Nutzer, der den Vorgang Abgeleitete Tabellen &ausführen startet, wartet die Abfrage, bis die Tabellen neu erstellt wurden, bevor die Ergebnisse geladen werden. Andere Nutzer verwenden die vorhandenen Tabellen weiterhin. Wenn die persistenten Tabellen erneut erstellt wurden, verwenden alle Benutzer die neu erstellten Tabellen. Obwohl bei diesem Vorgang vermieden wird, dass andere Abfragen unterbrochen werden, während die Tabellen neu erstellt werden, können diese Nutzer weiterhin 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 der Tab „Entdecken“ auf einer Entwicklungstabelle basiert, erstellt der Vorgang Abgeleitete Tabellen &Ausführen die Entwicklungstabelle (nicht die Produktionstabelle) für „Entdecken“ neu. Wenn jedoch „Entdecken“ im Entwicklungsmodus die Produktionsversion einer abgeleiteten Tabelle verwendet, wird die Produktionstabelle neu erstellt. Weitere Informationen zu Entwicklungs- und Produktionstabellen finden Sie unter Feste Tabellen im Entwicklungsmodus.

  • Wenn es bei von Looker gehosteten Instanzen mehr als eine Stunde für die Neuerstellung der abgeleiteten Tabelle dauert, wird die Tabelle nicht erfolgreich neu erstellt und bei der Browsersitzung wird eine Zeitüberschreitung auftreten. Weitere Informationen zu Zeitlimits, die sich auf Looker-Prozesse auswirken, finden Sie im Hilfeartikel Zeitüberschreitungen und Warteschlangen für Abfragen.

Persistente Tabellen im Entwicklungsmodus

Looker hat einige besondere Verhaltensweisen für die Verwaltung beibehaltener 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 Änderungen an der Tabellendefinition vornehmen, die sich auf die Daten in der Tabelle oder auf die Abfrage der Tabelle auswirkt, wird bei der nächsten Abfrage der Tabelle im Entwicklungsmodus eine neue Entwicklungsversion der Tabelle erstellt. Mit einer solchen Entwicklungstabelle können Sie Änderungen testen, ohne Endbenutzer zu stören.

Was veranlasst Looker zur Erstellung einer Entwicklungstabelle?

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

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

Looker erstellt eine Entwicklungstabelle, wenn Sie sich im Entwicklungsmodus befinden, und fragen eine SQL-basierte abgeleitete Tabelle ab, die mit 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 dann die Tabelle 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):

Bei Änderungen, die keine Auswirkungen auf die Daten der Tabelle haben oder sich darauf auswirken, 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, damit keine Entwicklungstabelle erstellt wird.

Wie lange sind Entwicklungstabellen in Looker abgeleitet?

Unabhängig von der eigentlichen Persistenzstrategie der Tabelle behandelt Looker die persistenten Entwicklungstabellen so, als hätte sie die Persistenzstrategie persist_for: "24 hours". Dies sorgt dafür, dass Entwicklungstabellen länger als einen Tag beibehalten werden, da ein Looker-Entwickler während der Entwicklung möglicherweise viele Iterationen einer Tabelle abfragt und jedes Mal, wenn eine neue Entwicklungstabelle erstellt wird. Damit die Entwicklungstabellen die Datenbank nicht überladen, versucht Looker, die Strategie persist_for: "24 hours" anzuwenden, damit die Tabellen regelmäßig aus der Datenbank bereinigt werden.

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

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

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

  • Wenn seit der Abfrage der Tabelle im Entwicklermodus mehr als 24 Stunden vergangen sind, ist die Entwicklungsversion der Tabelle als abgelaufen gekennzeichnet und wird nicht für Abfragen verwendet. Sie können nicht mit der Looker-IDE oder mit dem Tab Entwicklung auf 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 bedingte WHERE-Klausel enthält, die die if prod- und if dev-Anweisungen verwendet (für SQL-basierte abgeleitete Tabellen), kann die Entwicklungstabelle nicht als Produktionsversion verwendet werden, da die Entwicklungsversion ein gekürztes Dataset hat. In diesem Fall können Sie nach dem Entwickeln der Tabelle und bevor Sie Ihre Änderungen bereitstellen, den dev_filters-Parameter oder die bedingte WHERE-Klausel auskommentieren und die Tabelle dann im Entwicklungsmodus abfragen. Looker erstellt dann eine vollständige Version der Tabelle, die für die Produktion verwendet werden kann, wenn Sie Ihre Änderungen bereitstellen.

Wenn Sie Ihre Änderungen bereitstellen und 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 (für persistente Tabellen, die die Strategie persist_for verwenden) oder das nächste Mal die Neugenerator-Ausführung (für persistente Tabellen, die datagroup_trigger, interval_trigger oder sql_trigger_value verwenden).

Nach nicht erstellten PDTs im Entwicklungsmodus suchen

Wenn eine Entwicklungstabelle in Ihrer Datenbank beibehalten wird, wenn Sie Änderungen an einer PDT oder einer aggregierten Tabelle bereitstellen, kann Looker oft die Entwicklungstabelle als Produktionstabelle verwenden, sodass Ihre Nutzer nicht warten müssen, bis die Tabelle erstellt wird, wenn sie die Tabelle abfragen. Weitere Informationen finden Sie auf dieser Seite in den Abschnitten Wie lange Looker mit Entwicklungstabellen fortbesteht und Warum wird Looker zum Erstellen einer Entwicklungstabelle aufgefordert?.

Daher ist es optimal, dass alle PDTs bei der Bereitstellung in der Produktion erstellt werden, damit die Tabellen sofort als Produktionsversionen verwendet werden können.

Sie können Ihr Projekt im Bereich Projektzustand 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.

Wenn nicht erstellte PDTs vorhanden sind, werden sie im Bereich Projektzustand aufgeführt:

Der Bereich „Projektzustand“ zeigt sowohl eine Liste der nicht erstellten PDTs für das Projekt als auch eine Schaltfläche „Zur PDT-Verwaltung“.

Wenn Sie die Berechtigung see_pdts haben, können Sie auf die Schaltfläche PDT-Verwaltung aufrufen 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 – Endgültig abgeleitete Tabellen.

Wenn Sie in Ihrem Projekt einen nicht erstellten PDT identifiziert haben, können Sie eine Entwicklungsversion erstellen. Öffnen Sie dazu den Tab „Erkunden“, der die Tabelle abfragt, und verwenden Sie dann im Menü „Erkunden“ die Option Abgeleitete Tabellen &Ausführen. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Persistente Tabellen für eine Abfrage manuell erstellen.

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 gilt: Wenn die Definition einer Tabelle irgendwann nicht mehr vorhanden ist, markiert Looker die Tabelle als abgelaufen.

Das bringt mehrere Vorteile mit sich:

  • Wenn Sie im Entwicklungsmodus keine Änderungen an einer Tabelle vorgenommen haben, werden für Ihre Abfragen die vorhandenen Produktionstabellen verwendet. Dies ist der Fall, wenn die Tabelle eine SQL-basierte abgeleitete Tabelle ist, die mithilfe einer bedingten WHERE-Klausel mit if prod- und if dev-Anweisungen definiert wird. Wenn die Tabelle mit einer bedingten WHERE-Klausel definiert ist, erstellt Looker eine Entwicklungstabelle, wenn Sie die Tabelle im Entwicklungsmodus abfragen. Bei nativen abgeleiteten Tabellen mit dem Parameter dev_filters hat Looker die Logik, um Abfragen in der Produktionstabelle zu beantworten, es sei denn, Sie ändern die Definition der Tabelle und fragen dann die Tabelle 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

Manchmal kann es sehr lange dauern, bis eine PDT erstellt wird. Das kann 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.

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 umfasst einen dev_filters-Parameter, der die Daten nach den letzten 90 Tagen filtert, und einen filters-Parameter, der die Daten nach den letzten 2 Jahren und zum Yucca Valley Airport filtert.

Der Parameter dev_filters wirkt 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 Vorrang vor der 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 verschiedenen Optionen für die 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.

So erstellt Looker PDTs

Nachdem ein PDT definiert wurde und entweder zum ersten Mal ausgeführt oder vom Regenerator gemäß seiner Persistenzstrategie für die Neuerstellung ausgelöst wurde, führt Looker die folgenden Schritte aus:

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

Dies hat einige wichtige Auswirkungen:

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

Der Looker-Regenerator

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

  • Bei Tabellen, die sql_trigger_value verwenden, ist der Trigger eine Abfrage, die im Parameter sql_trigger_value der Tabelle angegeben ist. Der Looker-Regenerator löst die Wiedererstellung der Tabelle auf, wenn sich das Ergebnis der letzten Auslöser-Abfrageprüfung von dem Ergebnis der vorherigen Prüfung unterscheidet. Wenn die abgeleitete Tabelle beispielsweise in der SQL-Abfrage SELECT CURDATE() beibehalten wird, erstellt der Looker-Regenerator die Tabelle neu, wenn der Regenerator den Trigger das nächste Mal nach der Datumsänderung prüft. Standardmäßig führen die Regenerator-Prüfungen von Looker alle fünf Minuten Abfragen aus, um festzustellen, ob die beibehaltene Tabelle ausgelöst und neu erstellt werden sollte. Andere Faktoren können jedoch die Zeit beeinflussen, die für die Neuerstellung Ihrer Tabellen erforderlich ist. Weitere Informationen finden Sie im Abschnitt Wichtige Hinweise zur Implementierung von beibehaltenen Tabellen auf dieser Seite.
  • Bei Tabellen, die interval_trigger verwenden, ist der Trigger eine Zeitdauer, die im Parameter interval_trigger der Tabelle angegeben ist. Der Looker-Regenerator löst die Wiedererstellung der Tabelle nach Ablauf der angegebenen Zeit aus.
  • Für Tabellen, die datagroup_trigger verwenden, kann der Trigger eine Abfrage sein, die im Parameter sql_trigger der zugehörigen Datengruppe angegeben wurde, oder der Trigger kann eine im Parameter interval_trigger des Datengruppens angegebene Dauer sein.

Der Looker-Regenerator initiiert außerdem Neuerstellungen für persistente Tabellen, die den Parameter persist_for verwenden, jedoch nur dann, wenn die Tabelle persist_for eine Abhängigkeits-Kaskade einer per Trigger- beibehaltenen Tabelle ist. In diesem Fall initiiert der Looker-Regenerator eine Neuerstellung der Tabelle persist_for, da die Tabelle zum Neuerstellen der anderen Tabellen in der Kaskade benötigt wird. Andernfalls werden beibehaltene Tabellen, die die Strategie persist_for verwenden, vom Regenerator nicht überwacht.

Wenn ein PDT nicht erstellt werden kann, versucht der Regenerator, die Tabelle im nächsten Regeneratorzyklus neu zu erstellen:

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

Wenn ein Nutzer während der Erstellung Daten aus der persistenten Tabelle anfordert und die Abfrageergebnisse nicht im Cache gespeichert werden, 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

In Anbetracht der Nützlichkeit von beibehaltenen Tabellen (PDTs und zusammengefasste Tabellen) lassen sich viele von ihnen auf Ihrer Looker-Instanz zusammenfassen. Es ist möglich, ein Szenario zu erstellen, bei dem der Looker-Regenerator viele Tabellen gleichzeitig erstellen muss. Insbesondere bei kaskadenförmigen Tabellen oder Tabellen mit langer Ausführungszeit können Sie ein Szenario erstellen, bei dem die Tabellen vor der Neuerstellung eine lange Verzögerung haben oder bei denen die Abfrageergebnisse aus einer Tabelle verzögert werden, während die Datenbank intensiv daran arbeitet, die Tabelle zu generieren.

Standardmäßig führt der Regenerator von Looker alle fünf Minuten eine Prüfung von PDT-Triggern durch, um festzustellen, ob er per Trigger beibehaltene Tabellen (PDTs und zusammengefasste Tabellen, die die Persistenzstrategie datagroup_trigger, interval_trigger oder sql_trigger_value verwenden) erstellen soll.

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

  • Möglicherweise hat Ihr Looker-Administrator das Intervall der Trigger-Prüfungen für den Regenerator geändert, indem er die Einstellung PDT und Datagroup-Wartungsplan für Ihre Datenbankverbindung verwendet hat.
  • Standardmäßig kann der Regenerator die Neuerstellung von jeweils einer PDT oder aggregierten Tabelle über eine Verbindung starten. Ein Looker-Administrator kann die Anzahl der gleichzeitigen Neuerstellungen des Regenerators über das Feld Max PDT Builder Connections in den Verbindungseinstellungen anpassen.
  • Alle PDTs und aggregierten Tabellen, die von demselben datagroup ausgelöst werden, werden bei der Erneuerung neu erstellt. Das kann eine hohe Auslastung sein, wenn Sie viele Tabellen mit der Datengruppe verwenden, entweder direkt oder als Ergebnis kaskadierender Abhängigkeiten.

Zusätzlich zu den vorherigen Überlegungen gibt es auch einige Situationen, in denen Sie die Persistenz einer abgeleiteten Tabelle vermeiden sollten:

  • Wenn abgeleitete Tabellen erweitert werden, wird mit jeder Erweiterung einer PDT eine neue Kopie der Tabelle in Ihrer Datenbank erstellt.
  • Wenn abgeleitete Tabellen Vorlagenfilter oder Flüssigkeitsparameter verwenden: Die Persistenz wird für abgeleitete Tabellen, die Vorlagenfilter oder Flüssigkeitsparameter verwenden, nicht unterstützt.
  • Wenn native abgeleitete Tabellen aus „Erkunden“ erstellt werden, die Nutzerattribute mit access_filters oder mit sql_always_where verwenden, werden Kopien der Tabelle für jeden möglichen Nutzerattributwert in Ihrer Datenbank erstellt.
  • Wenn sich die zugrunde liegenden Daten häufig ändern und Ihr Datenbankdialekt keine inkrementellen PDTs unterstützt.
  • Die Kosten und der Zeitaufwand für das Erstellen von PDTs sind zu hoch.

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 mit API in großem Maßstab verwalten

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

PDTs überwachen und Fehler beheben

Wenn Sie PDTs verwenden, insbesondere kaskadierende, sollten Sie sich ihren Status ansehen. Auf der Verwaltungsseite Persistente abgeleitete Tabellen von Looker können Sie den Status Ihrer PDTs sehen. Weitere Informationen finden Sie in der Dokumentation zu Administratoreinstellungen – Persistente abgeleitete Tabellen.

Bei der Fehlerbehebung von PDTs:

  • Achten Sie beim Untersuchen des PDT-Ereignisprotokolls insbesondere auf den Unterschied zwischen Entwicklungstabellen und Produktionstabellen.
  • Vergewissern Sie sich, dass keine Änderungen am Scratch-Schema vorgenommen wurden, in dem Looker persistente abgeleitete Tabellen speichert. Wenn Änderungen vorgenommen wurden, müssen Sie möglicherweise die Einstellungen für Connection (Verbindung) im Abschnitt Admin von Looker aktualisieren und möglicherweise Looker 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.
  • Prüfen Sie, ob alle sql_trigger_value-Abfragen erfolgreich ausgewertet wurden, und geben Sie nur eine Zeile und Spalte zurück. Für SQL-basierte PDTs können Sie dies mit dem SQL-Runner tun. (Ein LIMIT schützt vor unkontrollierten Abfragen.) Weitere Informationen zur Fehlerbehebung mit abgeleiteten Tabellen mit SQL Runner finden Sie in diesem Community-Thema.
  • Überprüfen Sie bei SQL-basierten PDTs mithilfe von SQL Runner, ob der SQL-Code der PDT fehlerfrei ausgeführt wird. Achten Sie darauf, ein LIMIT in SQL Runner anzuwenden, um die Abfragezeiten angemessen zu halten.
  • Vermeiden Sie bei SQL-basierten abgeleiteten Tabellen die Verwendung von allgemeinen Tabellenausdrücken (Common Table Expressions, CTEs). Wenn Sie CTEs mit DTs verwenden, 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 dem Syntax ${derived_table_or_view_name.SQL_TABLE_NAME} aus Ihrem ersten DT zu referenzieren.
  • Prüfen Sie, ob alle Tabellen vorhanden sind, von denen das problematische PDT abhängt, ob normale Tabellen oder PDTs selbst 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 auf der Tabelle, von denen Looker eine PDT erstellt. Wenn auf einer Tabelle eine exklusive Sperre vorhanden ist, kann Looker keine gemeinsame Sperre zum Ausführen von Abfragen erwerben, bis die exklusive Sperre gelöscht wird.
  • Verwenden Sie die Schaltfläche Prozesse anzeigen im SQL-Runner. Wenn viele Prozesse aktiv sind, kann die Abfragedauer zunehmen.
  • Überwachen Sie Kommentare in der Abfrage. Weitere Informationen finden Sie im Abschnitt Kommentare zur PDT abfragen auf dieser Seite.

Abfragekommentare für PDTs

Datenbankadministratoren können leicht zwischen normalen Abfragen und Abfragen unterscheiden, die PDTs generieren. 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 die PDT im Namen eines Nutzers im Entwicklungsmodus generiert, wird in den Kommentaren die ID des Nutzers angegeben. Die Kommentare zur PDT-Generierung werden nach diesem Muster erstellt:

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

Der Kommentar zur PDT-Generierung wird auf dem SQL-Tab „Entdecken“ angezeigt, wenn Looker eine PDT für die Abfrage „Erkunden“ generieren muss. Der Kommentar wird oben in der SQL-Anweisung angezeigt.

Außerdem wird der Kommentar zur PDT-Generierung im Feld Nachricht auf dem Tab Info des Pop-up-Fensters Abfragedetails für jede Abfrage auf der Seite Abfragen angezeigt.

PDTs nach einem Fehler neu erstellen

Wenn eine PDT einen Fehler aufweist, geschieht Folgendes beim Abfragen dieser PDT:

  • Looker prüft anhand der Ergebnisse im Cache, ob dieselbe Abfrage bereits ausgeführt wurde. Informationen zur Funktionsweise finden Sie auf der Dokumentationsseite Caching von Abfragen und Neuerstellung von PDTs mit Datengruppen.
  • Wenn die Ergebnisse nicht im Cache gespeichert sind, ruft Looker Ergebnisse vom PDT in der Datenbank ab, sofern eine gültige Version des PDT vorhanden ist.
  • Wenn die Datenbank keine gültige PDT enthält, versucht Looker, die PDT neu zu erstellen.
  • Wenn der PDT nicht neu erstellt werden kann, gibt Looker einen Fehler für eine Abfrage zurück. Der Looker-Regenerator versucht, die PDT beim nächsten Abfragen der PDT oder bei der nächsten Persistenzstrategie der PDT neu zu erstellen.

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

  • Wenn eine Tabelle nicht erstellt werden kann, können auch die nachfolgenden PDTs in der Abhängigkeitskette nicht erstellt werden.
  • Ein abhängiger PDT fragt im Wesentlichen den PDT ab, auf den er sich stützt, sodass die Persistenzstrategie einer Tabelle die Neuerstellung von PDTs auslösen kann, die bis zur nächsten Kette gehen.

Wir rufen noch einmal das vorherige Beispiel für kaskadierende Tabellen auf, bei denen TABLE_D von TABLE_C abhängig ist. Diese ist abhängig von TABLE_B, die von TABLE_A abhängt:

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

Dasselbe gilt für die Abhängigkeiten von TABLE_B. Wenn TABLE_B also nicht erstellt werden kann und eine Abfrage von TABLE_C vorliegt:

  • Looker versucht, den Cache für die Abfrage in TABLE_C zu verwenden.
  • Wenn die Ergebnisse nicht im Cache gespeichert sind, 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, wodurch eine Abfrage für TABLE_B erstellt wird.
  • Looker versucht dann, TABLE_B neu zu erstellen. Dieser Vorgang schlägt fehl, wenn TABLE_B nicht behoben wurde.
  • Wenn TABLE_B nicht neu erstellt werden kann, kann TABLE_C auch nicht neu erstellt werden, sodass Looker einen Fehler für die Abfrage am TABLE_C zurückgibt.
  • Looker versucht dann, TABLE_C gemäß seiner üblichen Persistenzstrategie oder beim nächsten Abfragen der PDT neu zu erstellen. Dazu gehört auch der nächste Versuch, TABLE_D zu erstellen, da TABLE_D von TABLE_C abhängt.

Wenn Sie das Problem mit TABLE_B beheben, versuchen TABLE_B und jede der abhängigen Tabellen, die im Rahmen ihrer Persistenzstrategien oder beim nächsten Abfragevorgang neu zu erstellen (einschließlich der nächsten Neuerstellung einer abhängigen PDT). Wenn eine Entwicklungsversion der PDTs in der Kaskade im Entwicklungsmodus erstellt wurde, können die Entwicklungsversionen als die neuen Produktions-PDTs verwendet werden. Informationen zur Funktionsweise finden Sie im Abschnitt Festgelegte Tabellen im Entwicklungsmodus auf dieser Seite. Alternativ können Sie mit der Funktion „Erkunden“ eine Abfrage für TABLE_D ausführen und dann die PDT für die Abfrage manuell neu erstellen. Dadurch wird eine Neuerstellung aller PDTs erzwungen, die die Abhängigkeitskaskade ansteigen.

PDT-Leistung verbessern

Wenn Sie PDTs erstellen, kann die Leistung ein Problem sein. Besonders bei sehr großen Tabellen kann die Abfrage der Tabelle langsam sein, genau wie für jede große Tabelle in Ihrer Datenbank.

Sie können die Leistung verbessern, indem Sie die Daten filtern oder die Daten im PDT sortieren und indexieren.

Filter hinzufügen, um das Dataset einzuschränken

Wenn Sie sehr große Datasets haben, verlangsamen viele Zeilen Abfragen auf einer PDT. Wenn Sie in der Regel nur aktuelle Daten abfragen, können Sie der Klausel WHERE Ihrer PDT einen Filter hinzufügen, der die Tabelle auf maximal 90 Tage begrenzt. Auf diese Weise werden der Tabelle bei jeder Neuerstellung nur relevante Daten hinzugefügt, sodass die Ausführung von Abfragen viel schneller erfolgt. Anschließend können Sie eine separate, größere PDT für die historische Analyse erstellen, um sowohl schnelle Abfragen für aktuelle Daten als auch die Möglichkeit zur Abfrage von alten Daten zu ermöglichen.

Mit indexes oder sortkeys und distribution

Beim Erstellen einer großen PDT kann die Indexierung der Tabelle (für Dialekte wie MySQL oder Postgres) oder das Hinzufügen von Sortierschlüsseln und Distributionen (für Redshift) hilfreich sein.

In der Regel ist es am besten, den Parameter indexes in die Felder „ID“ oder „Datum“ einzufügen.

Bei Redshift fügen Sie in den meisten Fällen den Parameter sortkeys in den ID- oder Datumsfeldern und den Parameter distribution in das Feld ein, das für die Zusammenführung verwendet wird.

Die folgenden Einstellungen steuern, wie die Daten in der 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 wird. Wenn zwei Tabellen durch die im Parameter distribution angegebene Spalte verknüpft werden, kann die Datenbank die Join-Daten auf demselben Knoten finden, sodass die E/A zwischen den Knoten minimiert wird.
  • Setzen Sie für Redshift den Parameter distribution_style auf all, damit die Datenbank angewiesen wird, eine vollständige Kopie der Daten auf jedem Knoten zu speichern. Dies wird häufig verwendet, um E/A-Interaktionen zwischen Knoten zu minimieren, wenn relativ kleine Tabellen verknüpft werden. Setzen Sie diesen Wert auf even, um die Datenbank anzuweisen, die Daten gleichmäßig über den Cluster zu verteilen, ohne eine Verteilungsspalte zu verwenden. Dieser Wert kann nur angegeben werden, wenn distribution nicht angegeben ist.
  • Verwenden Sie für Redshift den Parameter sortkeys. Die Werte geben an, mit welchen Spalten der PDT die Daten auf dem Laufwerk sortiert werden, um die Suche zu vereinfachen. In Redshift können Sie entweder sortkeys oder indexes verwenden, aber nicht beides. Beispiel:
* On most databases, use the [`indexes`](/reference/view-params/indexes) parameter. The values specify which columns of the PDT are indexed. (On Redshift, indexes are used to generate interleaved sort keys.)