Abgeleitete Tabellen in Looker

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

Angenommen, Sie 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 vorhandenen orders-Ansicht, die in einer separaten Datei definiert ist, die in diesem Beispiel nicht gezeigt wird. Die explore_source-Abfrage in der nativen abgeleiteten Tabelle importiert die Felder customer_id, first_order und total_amount aus der Ansichtsdatei orders.
• Die SQL-basierte abgeleitete Tabelle definiert die Abfrage mithilfe von SQL im Parameter sql. In diesem Beispiel ist die SQL-Abfrage eine direkte Abfrage der Tabelle orders in der Datenbank.

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 Parameter sql für eine PDT verwenden, umschließt Looker im Hintergrund die DDL-Anweisung CREATE 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 Parameter sql erstellen. Stattdessen können Sie den Parameter create_process verwenden, um eine PDT in mehreren Schritten zu erstellen. Informationen und Beispiele finden Sie auf der Dokumentationsseite zum Parameter create_process.
• sql_create: Wenn Ihr Anwendungsfall benutzerdefinierte DDL-Befehle erfordert und Ihr Dialekt DDL unterstützt (z. B. das Vorhersage-Tool BigQuery ML von Google), können Sie mit dem Parameter sql_create anstelle des Parameters sql eine PDT erstellen. Weitere Informationen und Beispiele finden Sie auf der Dokumentationsseite zu sql_create.

Unabhängig davon, ob Sie den Parameter sql, create_process oder sql_create verwenden, definieren Sie die abgeleitete Tabelle in all diesen Fällen mit einer SQL-Abfrage, sodass alle als SQL-basierte abgeleitete Tabellen betrachtet werden.

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

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 leistungsstark 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:

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:

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

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:

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:
  • datagroup_trigger
  • sql_trigger_value
  • interval_trigger
  • persist_for
• Datenbankverwaltete Persistenzparameter:
  • 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) für 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 des persist_for-Zeitraums 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 der Datenbank. Die PDT wird dann neu erstellt, wenn ein Nutzer sie das nächste Mal abfragt. Die Abfrage muss also warten, bis die Neuerstellung abgeschlossen ist.

PDTs, die persist_for verwenden, werden vom Regenerator von Looker nicht automatisch neu erstellt, es sei denn, es handelt sich um eine 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 Ihre Looker-Verbindung mit der Ein/Aus-Schaltfläche PDTs aktivieren konfiguriert ist, können Sie eine materialisierte Ansicht erstellen, indem Sie materialized_view: yes für eine abgeleitete Tabelle angeben. Materialisierte Ansichten werden sowohl für native abgeleitete Tabellen als auch für SQL-basierte abgeleitete Tabellen unterstützt.

Ähnlich wie 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:

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

Wenn Sie beispielsweise der abgeleiteten Tabelle Persistenz hinzufügen möchten, können Sie sie so einstellen, dass sie neu erstellt wird, wenn die Datengruppe orders_datagroup ausgelöst wird, und Indexe sowohl für customer_id als auch für first_order hinzufügen:

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

Wenn Sie keinen Index (oder eine Entsprechung für Ihren Dialekt) hinzufügen, werden Sie von Looker gewarnt, dass Sie dies 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:

• Optimierungen testen
• Daten vorab zusammenführen oder aggregieren

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

PDTs zum Testen von Optimierungen verwenden

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 dann die Ergebnisse 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, ein 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

Benutzer können im Menü eines Explores die Option Abgeleitete Tabellen neu erstellen und ausführen auswählen, 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.

Mit der Option Abgeleitete Tabellen neu erstellen und ausführen werden alle persistenten Tabellen (alle PDTs und aggregierten Tabellen) neu erstellt, die zum Beantworten der Abfrage erforderlich sind, unabhängig von ihrer Persistenzstrategie. 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.

Bei inkrementellen PDTs löst die Option Abgeleitete Tabellen neu erstellen und ausführen 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 den Vorgang Abgeleitete Tabellen neu erstellen und ausführen initiiert, wartet die Abfrage auf die Neuerstellung der Tabellen, bevor Ergebnisse geladen werden. Abfragen anderer Benutzer verwenden weiterhin die vorhandenen Tabellen. Wenn die persistenten Tabellen erneut erstellt wurden, verwenden alle Benutzer die neu erstellten Tabellen. Dieser Prozess soll zwar verhindern, dass Abfragen anderer Benutzer während der Neuerstellung der Tabellen unterbrochen werden, diese Benutzer können jedoch dennoch von der zusätzlichen Belastung Ihrer Datenbank betroffen sein. Wenn das Auslösen einer Neuerstellung während der Arbeitszeit die Datenbank übermäßig belasten würde, müssen Sie möglicherweise die Benutzer informieren, dass bestimmte PDTs oder aggregierte Tabellen nicht während der Geschäftszeiten neu erstellt werden sollten.

• Wenn sich ein Nutzer im Entwicklungsmodus befindet und das Explore auf einer Entwicklungstabelle basiert, wird mit dem Vorgang Abgeleitete Tabellen neu erstellen und ausführen die Entwicklungstabelle für das Explore neu erstellt und 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 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 oder create_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 oder persist_for der Tabelle ändern
• view-Namen einer abgeleiteten Tabelle ändern
• increment_key oder increment_offset einer inkrementellen PDT ändern
• Den connection ändern, der vom verknüpften Modell verwendet wird

Bei Änderungen, die die Daten der Tabelle nicht verändern oder die Art und Weise beeinflussen, wie Looker die Tabelle abfragt, erstellt Looker keine Entwicklungstabelle. Der Parameter publish_as_db_view ist ein gutes Beispiel: Wenn Sie im Entwicklungsmodus nur die 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 entfernt 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.
• Enthält eine persistente Tabelle den Parameter dev_filters (für native abgeleitete Tabellen) oder die bedingte WHERE-Klausel, die die Anweisungen if prod und if dev verwendet (für SQL-basierte abgeleitete Tabellen), kann die Entwicklungstabelle nicht als Produktionsversion verwendet werden, da die Entwicklungsversion ein verkürztes Dataset enthält. In diesem Fall können Sie nach dem Entwickeln der Tabelle und vor dem Bereitstellen der Änderungen den Parameter dev_filters oder die bedingte WHERE-Klausel auskommentieren und dann die Tabelle im Entwicklungsmodus abfragen. Looker erstellt dann eine vollständige Version der Tabelle, die für die Produktion verwendet werden kann, wenn Sie Ihre Änderungen bereitstellen.

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 Was Looker zum Erstellen einer Entwicklungstabelle auffordert 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 im Menü „Explore“ die Option Abgeleitete Tabellen neu erstellen und ausführen. 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.

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, es sei denn, es handelt sich bei der Tabelle um eine SQL-basierte abgeleitete Tabelle, die mit einer bedingten WHERE-Klausel mit if prod- und if dev-Anweisungen definiert wird. Ist die Tabelle mit einer bedingten WHERE-Klausel definiert, erstellt Looker eine Entwicklungstabelle, wenn Sie die Tabelle im Entwicklungsmodus abfragen. Bei nativen abgeleiteten Tabellen mit dem Parameter dev_filters verfügt Looker über die Logik, um die Produktionstabelle zur Beantwortung von Abfragen im Entwicklungsmodus zu verwenden, es sei denn, Sie ändern die Definition der Tabelle und fragen die Tabelle dann im Entwicklungsmodus ab.
• Sollten zwei Entwickler zufällig im Entwicklungsmodus dieselbe Änderung an einer Tabelle vornehmen, verwenden sie gemeinsam dieselbe Entwicklungstabelle.
• Sobald Ihre Änderungen vom Entwicklungsmodus an den Produktionsmodus übergeben wurden, ist die alte Produktionsdefinition nicht mehr vorhanden. Daraufhin wird die alte Produktionstabelle als abgelaufen markiert und verworfen.
• Wenn Sie Ihre Änderungen im Entwicklungsmodus verwerfen, ist diese Tabellendefinition nicht mehr vorhanden. Daher werden die nicht mehr benötigten Entwicklungstabellen als abgelaufen markiert und verworfen.

Schnelleres Arbeiten im Entwicklungsmodus

Es gibt Situationen, in denen das Generieren der persistenten abgeleiteten Tabelle (PDT) 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:

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

Dies hat einige wichtige Auswirkungen:

• Der SQL-Code, aus dem die abgeleitete Tabelle besteht, 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 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 mit 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 überprüft.
• Bei Tabellen mit interval_trigger ist der Trigger eine im Parameter interval_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 Parameter sql_trigger der zugehörigen Datengruppe angegeben ist, oder eine im interval_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 erforderlich ist, 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 (Maximale 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 extended werden: Mit jeder Erweiterung einer PDT wird eine neue Kopie der Tabelle in Ihrer Datenbank erstellt.
• Wenn abgeleitete Tabellen Filtervorlagen oder Liquid-Parameter verwenden, wird Persistenz für abgeleitete Tabellen nicht unterstützt, die Filtervorlagen oder Liquid-Parameter verwenden.
• Wenn native abgeleitete Tabellen aus Explores erstellt werden, die Nutzerattribute mit access_filters oder mit sql_always_where verwenden, werden für jeden angegebenen möglichen Nutzerattributwert in Ihrer Datenbank Kopien der Tabelle erstellt.
• Wenn sich die zugrunde liegenden Daten häufig ändern und Ihr Datenbankdialekt keine inkrementellen PDTs unterstützt.
• Wenn die Kosten und der Zeitaufwand für das Erstellen von PDTs zu hoch sind.

Je nach Anzahl und Komplexität der persistenten Tabellen in Ihrer Looker-Verbindung kann die Warteschlange viele persistente Tabellen enthalten, die in jedem Zyklus geprüft und neu erstellt werden müssen. Daher sollten Sie diese Faktoren beim Implementieren abgeleiteter Tabellen in Ihrer Looker-Instanz unbedingt berücksichtigen.

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

Das Überwachen und Verwalten von 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. (Ein LIMIT schützt vor unkontrollierten Abfragen.) Weitere Informationen zur Verwendung von SQL Runner zum Debuggen von abgeleiteten Tabellen finden Sie im Communitybeitrag SQL Runner zum Testen abgeleiteter Tabellen verwenden .
• Ü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 keine gemeinsame Sperre zum Ausführen von Abfragen erhalten, bis 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ür TABLE_B erstellt.
• 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. In diesem Fall gibt Looker einen Fehler für die Abfrage in TABLE_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 von TABLE_D, da TABLE_D von TABLE_C abhängt).

Nachdem Sie das Problem mit TABLE_B behoben haben, versuchen TABLE_B und jede der abhängigen Tabellen, entsprechend ihren Persistenzstrategien oder bei der nächsten Abfrage (einschließlich des nächsten Neuerstellungsversuchs durch eine abhängige PDT) neu zu erstellen. Wenn eine Entwicklungsversion der PDTs in der Kaskade im Entwicklungsmodus erstellt wurde, können die Entwicklungsversionen als die neuen Produktions-PDTs verwendet werden. Informationen zur Funktionsweise finden Sie im Abschnitt Persistente Tabellen im Entwicklungsmodus auf dieser Seite. Sie können auch 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 wie bei jeder großen Tabelle in Ihrer Datenbank langsam sein.

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, sollten 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 aktuelle 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 Parameter distribution angegebene Spalte verknüpft werden, kann die Datenbank die Join-Daten auf demselben Knoten finden, damit die knotenübergreifende E/A minimiert wird.
• Setzen Sie für Redshift den Parameter distribution_style auf all, um die Datenbank anzuweisen, eine vollständige Kopie der Daten auf jedem Knoten zu speichern. Dies wird häufig verwendet, um die E/A zwischen Knoten zu minimieren, wenn relativ kleine Tabellen verknüpft werden. Legen Sie diesen Wert auf even fest, um die Datenbank anzuweisen, die Daten gleichmäßig auf den Cluster zu verteilen, ohne eine Verteilungsspalte zu verwenden. Dieser Wert kann nur angegeben werden, wenn distribution nicht angegeben ist.
• Verwenden Sie für Redshift den Parameter sortkeys. Die Werte geben an, welche Spalten der PDT zum Sortieren der Daten auf dem Laufwerk verwendet werden, um die Suche zu vereinfachen. In Redshift können Sie entweder sortkeys oder indexes verwenden, aber nicht beides.
• Bei den meisten Datenbanken verwenden Sie den Parameter indexes. Die Werte geben an, welche Spalten der PDT indexiert sind. (In Redshift werden Indizes verwendet, um verschränkte Sortierschlüssel zu generieren.)