Beachten Sie, dass Sie sich die Looker-Dokumentation ansehen. Dokumentation zu Looker Studio finden Sie unter https://support.google.com/looker-studio.

Inkrementelle PDTs

In Looker werden nichtflüchtige abgeleitete Tabellen (PDTs) in das Scratch-Schema Ihrer Datenbank geschrieben. Looker behält eine PAT auf der Grundlage seiner Persistenzstrategie bei und erstellt sie neu. Wenn die Neuerstellung einer PDT ausgelöst wird, erstellt Looker standardmäßig die ganze Tabelle neu.

Eine inkrementelle PAT ist eine von Looker erstellte PDT, indem neue Daten an die Tabelle angehängt werden, anstatt die gesamte Tabelle neu zu erstellen:

Eine große Tabelle, in der die drei unteren Zeilen hervorgehoben sind, um zu zeigen, dass eine geringe Anzahl neuer Zeilen in die Tabelle eingefügt wird.

Wenn Ihr Dialekt inkrementelle PDTs unterstützt, können Sie die folgenden Typen von PDTs in inkrementelle PDTs umwandeln:

Wenn Sie zum ersten Mal eine Abfrage mit einer inkrementellen PDT ausführen, erstellt Looker die ganze PDT, um die ersten Daten abzurufen. Bei einer großen Tabelle kann diese erste Erstellung sehr viel Zeit in Anspruch nehmen, wie im Falle jeder großen Tabelle. Nach dem Erstellen der ersten Tabelle sind weitere Erstellungen inkrementell und nehmen weniger Zeit in Anspruch, wenn die inkrementelle PDT strategisch eingestellt wurde.

Beachten Sie bei inkrementellen PDTs Folgendes:

Inkrementelle PDTs werden nur für PDTs unterstützt, die eine triggerbasierte Persistenzstrategie (datagroup_trigger, sql_trigger_value oder interval_trigger) verwenden. Inkrementelle PDTs werden für PDTs mit der persist_for Persistenzstrategie nicht unterstützt.
Bei SQL-basierten PDTs muss die Tabellenabfrage mit dem Parameter sql definiert werden, um als inkrementelle PDT verwendet zu werden. SQL-basierte PDTs, die mit dem Parameter sql_create oder dem Parameter create_process definiert werden, können nicht inkrementell erstellt werden. Wie Sie in Beispiel 1 auf dieser Seite sehen können, verwendet Looker einen INSERT- oder MERGE-Befehl, um die Inkremente für eine inkrementelle PAT zu erstellen. Die abgeleitete Tabelle kann nicht mit benutzerdefinierten DDL-Anweisungen (Data Definition Language) definiert werden, da Looker nicht ermitteln kann, welche DDL-Anweisungen zum Erstellen eines genauen Inkrements erforderlich sind.
Die Quelltabelle der inkrementellen PAT muss für zeitbasierte Abfragen optimiert werden. Insbesondere muss die zeitbasierte Spalte, die für den inkrementellen Schlüssel verwendet wird, eine Optimierungsstrategie wie Partitionierung, Sortierschlüssel, Indexe oder eine andere für Ihren Dialekt unterstützte Optimierungsstrategie haben. Die Optimierung der Quelltabellen wird dringend empfohlen, da Looker bei jeder Aktualisierung der inkrementellen Tabelle die Quelltabelle abfragt, um die neuesten Werte der zeitbasierten Spalte zu ermitteln, die für den inkrementellen Schlüssel verwendet wird. Wenn die Quelltabelle nicht für diese Abfragen optimiert ist, kann die Abfrage der neuesten Werte durch Looker langsam und teuer sein.

Inkrementelle PDT definieren

Mit den folgenden Parametern können Sie eine PDT in eine inkrementelle PDT umwandeln:

increment_key (erforderlich, um die PAT zu einer inkrementellen PAT zu machen): Definiert den Zeitraum, für den neue Datensätze abgefragt werden sollen.
{% incrementcondition %} Liquid-Filter (erforderlich, um eine SQL-basierte PAT als inkrementelle PDT zu erstellen; nicht anwendbar auf LookML-basierte PDTs): Verbindet den Inkrementschlüssel mit der Datenbankzeitspalte, auf der der inkrementelle Schlüssel basiert. Weitere Informationen finden Sie auf der Dokumentationsseite zu increment_key.
increment_offset (optional): Eine Ganzzahl, die die Anzahl der vorherigen Zeiträume (in der Granularität des Inkrementschlüssels) definiert, die für jeden inkrementellen Build neu erstellt werden. Der Parameter increment_offset ist nützlich bei spät eintreffenden Daten, bei denen vorherige Zeiträume neue Daten enthalten können, die beim ursprünglichen Erstellen und Anhängen des entsprechenden Inkrements an die PAT nicht enthalten waren.

Auf der Dokumentationsseite zum Parameter increment_key finden Sie Beispiele, die zeigen, wie inkrementelle PATs aus nichtflüchtigen nativen abgeleiteten Tabellen, nichtflüchtigen SQL-basierten abgeleiteten Tabellen und aggregierten Tabellen erstellt werden.

Hier ist ein einfaches Beispiel einer inkrementellen LookML-basierten PDT:

view: flights_lookml_incremental_pdt {
  derived_table: {
    indexes: ["id"]
    increment_key: "departure_date"
    increment_offset: 3
    datagroup_trigger: flights_default_datagroup
    distribution_style: all
    explore_source: flights {
      column: id {}
      column: carrier {}
      column: departure_date {}
    }
  }

  dimension: id {
    type: number
  }
  dimension: carrier {
    type: string
  }
   dimension: departure_date {
    type: date
  }
}

Diese Tabelle wird vollständig erstellt, wenn zum ersten Mal eine Abfrage darin erfolgt. Danach wird die PAT in Schritten von einem Tag (increment_key: departure_date) innerhalb von drei Tagen (increment_offset: 3) neu erstellt.

Der inkrementelle Schlüssel basiert auf der Dimension departure_date, bei der es sich tatsächlich um den Zeitraum date aus der Dimensionsgruppe departure handelt. Auf der Dokumentationsseite für Parameter dimension_group finden Sie eine Übersicht über die Funktionsweise von Dimensionsgruppen. Sowohl die Dimensionsgruppe als auch der Zeitraum werden in der Ansicht flights definiert, was der explore_source für diese PDT entspricht. So ist die Dimensionsgruppe „departure“ in der Ansichtsdatei „flights“ definiert:

...
  dimension_group: departure {
    type: time
    timeframes: [
      raw,
      date,
      week,
      month,
      year
    ]
    sql: ${TABLE}.dep_time ;;
  }
...

Interaktion von Inkrementparametern und Persistenzstrategie

Die Einstellungen increment_key und increment_offset einer PDT sind unabhängig von der Persistenzstrategie der PDT:

Die Persistenzstrategie der inkrementellen PAT bestimmt nur, wann die PAT inkrementiert. Der PAT-Builder ändert die inkrementelle PDT nur, wenn die Persistenzstrategie der Tabelle ausgelöst wird oder die PDT manuell mit der Option Abgeleitete Tabellen neu erstellen und ausführen in einem Explore ausgelöst wird.
Wenn die PAT inkrementiert, bestimmt der PDT-Generator, wann die neuesten Daten zuvor der Tabelle hinzugefügt wurden, und zwar in Bezug auf das aktuellste Zeitinkrement (der Zeitraum, der durch den Parameter increment_key definiert wird). Basierend darauf kürzt der PDT-Generator die Daten zum Beginn des jüngsten Zeitinkrements in der Tabelle und erstellt dann das neueste Inkrement von dort.
Wenn die PAT einen increment_offset-Parameter hat, erstellt der PDT-Builder auch die Anzahl der vorherigen Zeiträume neu, die im Parameter increment_offset angegeben wurden. Die vorherigen Zeiträume beginnend mit dem Beginn des aktuellen Zeitinkrements (der Zeitraum, der durch den Parameter increment_key definiert wird).

Die folgenden Beispielszenarien veranschaulichen, wie inkrementelle PDTs aktualisiert werden, indem die Interaktion von increment_key, increment_offset und die Persistenzstrategie dargestellt werden.

Beispiel 1

Dieses Beispiel verwendet eine PDT mit diesen Eigenschaften:

Inkrementschlüssel: Datum
Inkrementeller Offset: 3
Persistenzstrategie: wird einmal im Monat am ersten Tag des Monats ausgelöst

So wird diese Tabelle aktualisiert:

Bei einer monatlichen Persistenzstrategie wird die Tabelle automatisch ein Mal im Monat erstellt. Das bedeutet, dass etwa am 1. Juni die letzte Zeile der Tabelle am 1. Mai hinzugefügt worden ist.
Da diese Tabelle einen auf dem Datum basierten Inkrementschlüssel verwendet, kürzt der PDT-Generator den 1. Mai zurück zum Beginn des Tages und erstellt die Daten für den 1. Mai neu bis zum aktuellen Tag, dem 1. Juni.
Darüber hinaus hat diese PAT einen inkrementellen Offset von 3. Der PDT-Generator erstellt also auch die Daten der vorherigen drei Zeiträume (Tage) vor dem 1. Mai neu. Es werden also Daten neu erstellt für den 28., 29. und 30. Mai und bis zum 1. Juni, dem aktuellen Tag.

Diesen SQL-Befehl führt der PDT-Generator am 1. Juni aus, um die Reihen der vorhandenen PDT zu bestimmen, die neu erstellt werden müssen:

## Example SQL for BigQuery:
SELECT FORMAT_TIMESTAMP('%F %T',TIMESTAMP_ADD(MAX(pdt_name),INTERVAL -3 DAY))

## Example SQL for other dialects:
SELECT CAST(DATE_ADD(MAX(pdt_name),INTERVAL -3 DAY) AS CHAR)

Und diesen SQL-Befehl führt der PDT-Generator am 1. Juni aus, um das neueste Inkrement zu erstellen:

## Example SQL for BigQuery:

MERGE INTO [pdt_name] USING (SELECT [columns]
   WHERE created_at >= TIMESTAMP('4/28/21 12:00:00 AM'))
   AS tmp_name ON FALSE
WHEN NOT MATCHED BY SOURCE AND created_date >= TIMESTAMP('4/28/21 12:00:00 AM')
   THEN DELETE
WHEN NOT MATCHED THEN INSERT [columns]

## Example SQL for other dialects:

START TRANSACTION;
DELETE FROM [pdt_name]
   WHERE created_date >= TIMESTAMP('4/28/21 12:00:00 AM');
INSERT INTO [pdt_name]
   SELECT [columns]
   FROM [source_table]
   WHERE created_at >= TIMESTAMP('4/28/21 12:00:00 AM');
COMMIT;

Beispiel 2

Dieses Beispiel verwendet eine PDT mit diesen Eigenschaften:

Persistenzstrategie: wird einmal täglich ausgelöst
Inkrementschlüssel: Monat
Inkrementeller Offset: 0

So wird diese Tabelle am 1. Juni aktualisiert:

Bei einer täglichen Persistenzstrategie wird die Tabelle automatisch ein Mal im Tag erstellt. Am 1. Juni wird die letzte Zeile der Tabelle am 31. Mai hinzugefügt worden sein.
Da diese Tabelle einen auf dem Monat basierten Inkrementschlüssel verwendet, kürzt der PDT-Generator den 31. Mai zurück zum Beginn des Monats und erstellt die Daten für den gesamten Mai neu bis zum aktuellen Tag, einschließlich des 1. Junis.
Da diese PDT keinen inkrementellen Offset hat, werden keine vorherigen Zeiträume neu erstellt.

So wird diese Tabelle am 2. Juni aktualisiert:

Am 2. Juni wird die letzte Zeile der Tabelle am 1. Juni hinzugefügt worden sein.
Da der PDT-Generator bis zum Anfang des Monats Juni zurück kürzt und dann die Daten beginnend mit dem 1. Juni bis zum aktuellen Tag neu erstellt, werden nur die Daten für den 1. und 2. Juni neu erstellt.
Da diese PDT keinen inkrementellen Offset hat, werden keine vorherigen Zeiträume neu erstellt.

Beispiel 3

Dieses Beispiel verwendet eine PDT mit diesen Eigenschaften:

Inkrementschlüssel: Monat
Inkrementeller Offset: 3
Persistenzstrategie: wird einmal täglich ausgelöst

Dieses Szenario veranschaulicht eine schlechte Konfiguration für eine inkrementelle PDT, da es sich um eine täglich auslösende PDT mit einem Offset von drei Monaten handelt. Jeden Tag werden die Daten von mindestens drei Monaten neu erstellt, was eine sehr ineffiziente Nutzung einer inkrementellen PDT darstellt. Die Untersuchung dieses Szenarios ist jedoch interessant, um die Funktionsweise einer inkrementellen PDT zu verstehen.

So wird diese Tabelle am 1. Juni aktualisiert:

Bei einer täglichen Persistenzstrategie wird die Tabelle automatisch ein Mal im Tag erstellt. Am 1. Juni etwa wird die letzte Zeile der Tabelle am 31. Mai hinzugefügt worden sein.
Da diese Tabelle einen auf dem Monat basierten Inkrementschlüssel verwendet, kürzt der PDT-Generator den 31. Mai zurück zum Beginn des Monats und erstellt die Daten für den gesamten Mai neu bis zum aktuellen Tag, einschließlich des 1. Junis.
Darüber hinaus hat diese PAT einen inkrementellen Offset von 3. Das bedeutet, dass der PDT-Builder auch die Daten der vorherigen drei Zeiträume (Monate) vor Mai neu erstellt. Das Ergebnis ist, dass die Daten von Februar, März, April und bis zum aktuellen Tag, dem 1. Juni, neu erstellt werden.

So wird diese Tabelle am 2. Juni aktualisiert:

Am 2. Juni wird die letzte Zeile der Tabelle am 1. Juni hinzugefügt worden sein.
Der PDT-Generator kürzt den Monat zurück zum 1. Juni und erstellt die Daten für den Monat Juni neu, einschließlich des 2. Junis.
Durch den inkrementellen Offset werden außerdem die Daten der drei Monate vor Juni neu erstellt. Das Ergebnis ist die Neuerstellung der Daten von März, April, Mai und bis zum aktuellen Tag, dem 2. Juni.

Test einer inkrementellen PDT im Entwicklungsmodus

Bevor Sie eine neue inkrementelle PDT für Ihre Produktionsumgebung entwickeln, können Sie die PDT testen und sicherstellen, dass sie erstellt und inkrementiert. Für den Test einer inkrementellen PDT im Entwicklungsmodus:

Erstellen Sie ein Explore für die PDT:
- Verwenden Sie in einer verknüpften Modelldatei den Parameter include, um die Ansichtsdatei der PAT in die Modelldatei aufzunehmen.
- Verwenden Sie in derselben Modelldatei den Parameter explore, um ein Explore für die Ansicht der inkrementellen PAT zu erstellen.
```
 include: "/views/e_faa_pdt.view"
 explore: e_faa_pdt {}
```
Öffnen Sie die Explore der PDT. Klicken Sie dazu auf die Schaltfläche Dateiaktionen anzeigen und wählen Sie einen Explore-Namen aus.

Wählen Sie im Explore einige Dimensionen oder Messungen aus und klicken Sie auf Ausführen. Looker erstellt dann die gesamte PDT. Ist dies die erste Abfrage mit einer inkrementellen PDT, erstellt der PDT-Generator die gesamte PDT, um die ersten Daten abzurufen. Bei einer großen Tabelle kann diese erste Erstellung sehr viel Zeit in Anspruch nehmen, wie im Falle jeder großen Tabelle.
Mit den folgenden Möglichkeiten können Sie die Erstellung der ersten PDT bestätigen:
- Wenn Sie die Berechtigung see_logs haben, können Sie im PDT-Ereignisprotokoll prüfen, ob die Tabelle erstellt wurde. Wenn im PDT-Ereignisprotokoll keine Ereignisse zum Erstellen von PAT-Ereignissen angezeigt werden, prüfen Sie die Statusinformationen oben im Explore des PAT-Ereignisprotokolls. Wird „Aus Cache“ angezeigt, können Sie Cache leeren und aktualisieren auswählen, um aktuellere Informationen zu erhalten.
- Sehen Sie sich auch die Kommentare auf dem Tab SQL in der Leiste Daten des Explores an. Auf dem Tab SQL werden die Abfrage und die Aktionen angezeigt, die ausgeführt werden, wenn Sie die Abfrage im Explore ausführen. Wenn auf dem Tab SQL beispielsweise -- generate derived table e_incremental_pdt steht, wird diese Aktion ausgeführt,wenn Sie auf Ausführen klicken.
Fordern Sie nach dem Erstellen des ersten Builds der PDT einen inkrementellen Build der PDT an. Verwenden Sie dazu im Explore die Option Abgeleitete Tabellen neu erstellen und ausführen.
Sie können mit denselben Methoden wie zuvor die inkrementelle Erstellung der PDT bestätigen:
- Wenn Sie die Berechtigung see_logs haben, können Sie das PDT-Ereignisprotokoll verwenden, um create increment complete-Ereignisse für die inkrementelle PAT zu sehen. Wenn Sie dieses Ereignis nicht im PAT-Ereignisprotokoll sehen und der Abfragestatus „Aus Cache“ lautet, wählen Sie Cache leeren und aktualisieren aus, um aktuellere Informationen zu erhalten.
- Sehen Sie sich die Kommentare auf dem Tab SQL in der Leiste Daten des Explores an. In diesem Fall zeigen die Kommentare, dass die PDT inkrementiert wurde. Beispiel: -- increment persistent derived table e_incremental_pdt to generation 2
Wenn Sie bestätigt haben, dass die PDT erstellt und korrekt inkrementiert wurde und Sie das dedizierte Explore für die PDT nicht behalten möchten, können Sie die explore- und include-Parameter der PDT aus der Modelldatei entfernen oder auskommentieren.

Nachdem die PDT im Entwicklungsmodus erstellt wurde, wird dieselbe Tabelle für die Produktion verwendet, sobald Sie Ihre Änderungen bereitstellen, sofern Sie keine weiteren Änderungen an der Definition der Tabelle vornehmen. Weitere Informationen finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker im Abschnitt Persistente Tabellen im Entwicklungsmodus.

Unterstützte Datenbankdialekte für inkrementelle PDTs

Damit Looker inkrementelle PATs in Ihrem Looker-Projekt unterstützen kann, muss Ihr Datenbankdialekt DDL-Befehle (Data Definition Language) unterstützen, die das Löschen und Einfügen von Zeilen ermöglichen.

In der folgenden Tabelle sehen Sie, welche Dialekte inkrementelle PATs in der neuesten Version von Looker unterstützen (für Databricks werden inkrementelle PATs nur ab Databricks-Version 12.1 unterstützt):

Dialekt	Unterstützt?
Lawine Actian	Nein
Amazon Athena	Nein
Amazon Aurora MySQL	Nein
Amazon Redshift	Ja
Apache Druid	Nein
Apache Druid 0.13 und höher	Nein
Apache Druid 0.18 und höher	Nein
Apache Hive 2.3+	Nein
Apache Hive 3.1.2+	Nein
Apache Spark 3 und höher	Nein
ClickHouse	Nein
Cloudera Impala 3.1+	Nein
Cloudera Impala 3.1+ mit nativem Treiber	Nein
Cloudera Impala mit nativem Fahrer	Nein
DataVirtuality	Nein
Databricks	Ja
Denodo 7	Nein
Denodo 8	Nein
Dremio	Nein
Dremio 11+	Nein
Exasol	Nein
Firebolt	Nein
Legacy-SQL von Google BigQuery	Nein
Google BigQuery-Standard-SQL	Ja
Google Cloud PostgreSQL	Ja
Google Cloud SQL	Nein
Google Spanner	Nein
Grünpflaumen	Ja
HyperSQL	Nein
IBM Netezza	Nein
MariaDB	Nein
Microsoft Azure PostgreSQL	Ja
Microsoft Azure SQL-Datenbank	Nein
Microsoft Azure Synapse-Analyse	Ja
Microsoft SQL Server 2008 und höher	Nein
Microsoft SQL Server 2012 und höher	Nein
Microsoft SQL Server 2016	Nein
Microsoft SQL Server 2017 und höher	Nein
MongoBI	Nein
MySQL	Ja
MySQL 8.0.12 oder höher	Ja
Oracle	Nein
Oracle ADWC	Nein
PostgreSQL 9.5 oder höher	Ja
PostgreSQL vor Version 9.5	Ja
PrestoDB	Nein
PrestoSQL	Nein
SAP HANA	Nein
SAP HANA 2+	Nein
SingleStore	Nein
SingleStore 7+	Nein
Snowflake	Ja
Teradata	Nein
Trino	Nein
Vektor	Nein
Vertica	Ja