In Looker werden persistente abgeleitete Tabellen (PDTs) in das Scratch-Schema der Datenbank geschrieben. Looker bleibt bestehen und erstellt eine PDT basierend auf ihrer Persistenzstrategie neu. Wenn die Neuerstellung einer PDT ausgelöst wird, erstellt Looker standardmäßig die ganze Tabelle neu.
Eine inkrementelle PDT ist eine PDT, die Looker erstellt, indem neue Daten an die Tabelle angehängt werden, anstatt die gesamte Tabelle neu zu erstellen:
Wenn Ihr Dialekt inkrementelle PDTs unterstützt, können Sie die folgenden Arten 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 Folgendes für inkrementelle PDTs:
- Inkrementelle PDTs werden nur für PDTs unterstützt, die eine triggerbasierte Persistenzstrategie verwenden (
datagroup_trigger
,sql_trigger_value
oderinterval_trigger
). Inkrementelle PDTs werden für PDTs mit der Persistenzstrategiepersist_for
nicht unterstützt. - Bei SQL-basierten PDTs muss die Tabellenabfrage mit dem Parameter
sql
definiert werden, damit sie als inkrementelle PDT verwendet werden kann. SQL-basierte PDTs, die mit dem Parametersql_create
oder dem Parametercreate_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 PDT zu erstellen. Die abgeleitete Tabelle kann nicht mit benutzerdefinierten DDL-Anweisungen (Data Definition Language) definiert werden, da Looker nicht in der Lage wäre zu bestimmen, welche DDL-Anweisungen für die Erstellung eines genauen Inkrements erforderlich wären. - Die Quelltabelle der inkrementellen PDT muss für zeitbasierte Abfragen optimiert sein. Insbesondere muss die zeitbasierte Spalte, die für den Inkrementschlüssel verwendet wird, eine Optimierungsstrategie haben, z. B. Partitionierung, Sortierschlüssel, Indexe oder eine andere für Ihren Dialekt unterstützte Optimierungsstrategie. Die Optimierung der Quelltabelle 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 Inkrementschlü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 PDT als inkrementelle PDT zu definieren): Definiert den Zeitraum, für den neue Datensätze abgefragt werden sollen.{% incrementcondition %}
Liquid-Filter (erforderlich, um eine SQL-basierte PDT als inkrementelle PDT zu erstellen; gilt nicht für LookML-basierte PDTs): Verbindet den Inkrementschlüssel mit der Datenbankzeitspalte, auf der der Inkrementschlüssel basiert. Weitere Informationen finden Sie auf der Dokumentationsseite zuincrement_key
.increment_offset
(optional): Eine Ganzzahl, die die Anzahl vorheriger Zeiträume definiert (in der Granularität des Inkrementschlüssels), die für jeden inkrementellen Build neu erstellt werden. Der Parameterincrement_offset
ist bei spät ankommenden Daten nützlich, bei denen frühere Zeiträume möglicherweise neue Daten enthalten, die beim ursprünglichen Erstellen des entsprechenden Inkrements nicht enthalten waren und an die PDT angehängt wurden.
Auf der Dokumentationsseite zum Parameter increment_key
finden Sie Beispiele, die zeigen, wie inkrementelle PDTs aus persistenten nativen abgeleiteten Tabellen, persistenten 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 PDT in Schritten von einem Tag (increment_key: departure_date
) über drei Tage hinweg neu erstellt (increment_offset: 3
).
Der Inkrementschlüssel basiert auf der Dimension departure_date
, bei der es sich tatsächlich um den date
-Zeitraum aus der Dimensionsgruppe departure
handelt. Eine Übersicht über die Funktionsweise von Dimensionsgruppen finden Sie auf der Dokumentationsseite zum Parameter dimension_group
. Die Dimensionsgruppe und der Zeitraum werden in der Ansicht flights
definiert, der explore_source
für diese PDT. 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 für increment_key
und increment_offset
einer PDT sind unabhängig von der Persistenzstrategie der PDT:
- Die Persistenzstrategie der inkrementellen PDT bestimmt nur dann, wenn sich die PDT erhöht. Der PDT-Generator ändert die inkrementelle PDT nur dann, wenn die Persistenzstrategie der Tabelle oder die PDT manuell mit der Funktion Abgeleitete Tabellen neu erstellen und Ausführungsoption in einem Explore zur Verfügung.
- Bei der Erhöhung der PDT ermittelt der PDT-Builder, wann die neuesten Daten zuvor zur Tabelle hinzugefügt wurden, und zwar in Bezug auf das aktuelle Zeitinkrement (der durch den Parameter
increment_key
definierte Zeitraum). 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 PDT einen
increment_offset
-Parameter hat, erstellt der PDT-Builder auch die Anzahl der vorherigen Zeiträume neu, die im Parameterincrement_offset
angegeben wurden. Die vorherigen Zeiträume gehen zurück, beginnend mit dem Beginn des aktuellsten Zeitinkrements, also des Zeitraums, der durch den Parameterincrement_key
definiert wird.
Die folgenden Beispielszenarien veranschaulichen, wie inkrementelle PDTs aktualisiert werden. Sie zeigen die Interaktion von increment_key
, increment_offset
und die Persistenzstrategie.
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.
- Außerdem hat diese PDT 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 zeigt eine schlechte Konfiguration für eine inkrementelle PDT, da es sich um eine täglich auslösende PDT mit einer Verschiebung 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.
- Außerdem hat diese PDT 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 PDT in die Modelldatei aufzunehmen. - Verwenden Sie in derselben Modelldatei den Parameter
explore
, um ein Explore für die Ansicht der inkrementellen PDT zu erstellen.
include: "/views/e_faa_pdt.view" explore: e_faa_pdt {}
- Verwenden Sie in einer verknüpften Modelldatei den Parameter
Öffnen Sie die Explore der PDT. Klicken Sie dazu auf die Schaltfläche Dateiaktionen ansehen und wählen Sie dann einen Explore-Namen aus.
Wählen Sie im Explore einige Dimensionen oder Kennzahlen 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:
- Mit der Berechtigung
see_logs
können Sie im PDT-Ereignisprotokoll prüfen, ob die Tabelle erstellt wurde. Wenn Sie die PDT-Erstellungsereignisse im PDT-Ereignisprotokoll nicht sehen, prüfen Sie die Statusinformationen oben im Explore des PDT-Ereignisprotokolls. Steht dort „aus dem Cache“, wählen Sie Cache leeren und Aktualisieren Sie die Seite, um aktuellere Informationen zu erhalten. - Andernfalls können Sie sich die Kommentare auf dem Tab SQL in der Leiste Daten des Explores ansehen. Auf dem Tab SQL werden die Abfrage und die Aktionen angezeigt, die ausgeführt werden, wenn Sie die Abfrage im Explore ausführen. Wenn beispielsweise in den Kommentaren auf dem Tab SQL
steht, wird diese Aktion ausgeführt,wenn Sie auf Ausführen klicken.-- generate derived table e_incremental_pdt
- Mit der Berechtigung
Nachdem Sie den ersten Build der PDT erstellt haben, fordern Sie mit der Funktion Abgeleitete Tabellen neu erstellen und im explorativen Analysetool die Option „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, umcreate increment complete
-Ereignisse für die inkrementelle PDT zu sehen. Wenn Sie dieses Ereignis nicht im PDT-Ereignisprotokoll sehen und der Abfragestatus „aus Cache“ lautet, wählen Sie Cache leeren und Aktualisieren Sie die Seite, 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 die Berechtigung
Wenn Sie sich vergewissert haben, dass die PDT erstellt wurde und die Inkrementierung korrekt ist, können Sie die
explore
- undinclude
-Parameter der PDT aus Ihrer Modelldatei entfernen oder auskommentieren, wenn Sie das dedizierte Explore für die PDT nicht behalten möchten.
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 PDTs in Ihrem Looker-Projekt unterstützen kann, muss Ihr Datenbankdialekt DDL-Befehle (Data Definition Language) unterstützen, mit denen Zeilen gelöscht und eingefügt werden können.
Die folgende Tabelle zeigt, welche Dialekte inkrementelle PDTs in der neuesten Version von Looker unterstützen (für Databricks werden inkrementelle PDTs nur ab Databricks Version 12.1 unterstützt):
Dialekt | Unterstützt? |
---|---|
Actian Lawine | Nein |
Amazon Athena | Nein |
Amazon Aurora MySQL | Nein |
Amazon Redshift | Ja |
Druid | Nein |
Apache Druid 0.13+ | Nein |
Apache Druid 0.18+ | Nein |
Apache Hive 2.3 und höher | Nein |
Apache Hive 3.1.2 und höher | Nein |
Apache Spark 3 und höher | Nein |
ClickHouse | Nein |
Cloudera Impala 3.1 und höher | Nein |
Cloudera Impala 3.1+ mit nativem Treiber | Nein |
Cloudera Impala mit nativem Treiber | Nein |
DataVirtuality | Nein |
Databricks | Ja |
Denodo 7 | Nein |
Denodo 8 | Nein |
Dremio | Nein |
Dremio 11+ | Nein |
Exasol | Nein |
Firebolt | Nein |
Google BigQuery Legacy-SQL | Nein |
Google BigQuery-Standard-SQL | Ja |
Google Cloud PostgreSQL | Ja |
Google Cloud SQL | Nein |
Google Spanner | Nein |
Greenplum | Ja |
HyperSQL | Nein |
IBM Netezza | Nein |
MariaDB | Nein |
Microsoft Azure PostgreSQL | Ja |
Microsoft Azure SQL-Datenbank | Nein |
Microsoft Azure Synapse-Analyse | Ja |
Microsoft SQL Server 2008 oder höher | Nein |
Microsoft SQL Server 2012 und höher | Nein |
Microsoft SQL Server 2016 | Nein |
Microsoft SQL Server 2017 und höher | Nein |
MongoBI | Nein |
MySQL | Ja |
MySQL 8.0.12 und höher | Ja |
Oracle | Nein |
Oracle ADWC | Nein |
PostgreSQL 9.5+ | Ja |
PostgreSQL vor 9.5 | Ja |
PrestoDB | Nein |
PrestoSQL | Nein |
SAP HANA 2 und höher | Nein |
SingleStore | Nein |
SingleStore 7 und höher | Nein |
Snowflake | Ja |
Teradata | Nein |
Trino | Nein |
Vektor | Nein |
Vertica | Ja |