increment_key

Nutzung

view: my_view {
  derived_table: {
    increment_key: "created_date"
    ...
  }
}
Hierarchie
view
derived_table
increment_key

– oder –

explore
aggregate_table
materialization
increment_key
Standardwert
Keine

Akzeptiert
Der Name einer zeitbasierten LookML-Dimension

Besondere Regeln
increment_key wird nur für persistente Tabellen und nur für bestimmte Dialekte unterstützt.

Definition

Sie können inkrementelle PDTs in Ihrem Projekt erstellen, wenn Ihr Dialekt sie unterstützt. Eine inkrementelle PDT ist eine persistente abgeleitete Tabelle (PDT), die von Looker aufgebaut wird. Dabei werden neue Daten an die Tabelle angehängt, anstatt dass die ganze Tabelle neu erstellt wird. Weitere Informationen finden Sie auf der Dokumentationsseite Inkrementelle persistente abgeleitete Tabellen.

increment_key ist der Parameter, der eine PDT in eine inkrementelle PDT umwandelt, indem er das Zeitinkrement angibt, für das neue Daten abgefragt und an die PDT angehängt werden sollen. Zusätzlich zum increment_key können Sie optional ein increment_offset angeben, um die Anzahl der vorherigen Zeiträume (in der Granularität des Inkrementschlüssels) festzulegen, die neu erstellt werden, um spät eintreffende Daten zu berücksichtigen.

Die increment_key für eine PDT ist unabhängig vom Persistenztrigger der PDT. Auf der Dokumentationsseite Inkrementelle PDTs finden Sie einige Beispielszenarien, die die Interaktion von increment_key, increment_offset und der Persistenzstrategie veranschaulichen.

Der Parameter increment_key funktioniert nur mit unterstützten Dialekten und nur mit Tabellen, die eine Persistenzstrategie haben, z. B. PDTs und zusammengefasste Tabellen (die eine Art PDT sind).

Im increment_key muss eine zeitbasierte LookML-Dimension angegeben werden:

Außerdem muss increment_key Folgendes erfüllen:

  • Eine gekürzte absolute Zeit, z. B. Tag, Monat, Jahr, Quartal usw. Zeiträume wie Wochentage werden nicht unterstützt.
  • Ein Zeitstempel, der mit neuen Daten vorhersagbar ansteigt, z. B. das Erstellungsdatum der Bestellung. Ein Zeitstempel sollte also nur dann als Inkrementschlüssel verwendet werden, wenn die neuesten Daten, die der Tabelle hinzugefügt wurden, auch den neuesten Zeitstempel haben. Ein Zeitstempel wie der Geburtstag eines Nutzers würde nicht als inkrementeller Schlüssel funktionieren, da er nicht zuverlässig mit neuen Nutzern in der Tabelle ansteigt.

Inkrementelle LookML-basierte PDT erstellen

Wenn Sie eine LookML-basierte (native) PDT in eine inkrementelle PDT umwandeln möchten, verwenden Sie den Parameter increment_key, um den Namen einer zeitbasierten LookML-Dimension anzugeben. Die Dimension muss in der Ansicht definiert sein, auf der die explore_source der PDT basiert.

Hier ist beispielsweise eine Ansichtsdatei für eine PDT, die auf LookML basiert und den LookML-Parameter explore_source verwendet. Die PDT wird aus dem Explore flights erstellt, das in diesem Fall auf der Ansicht flights basiert:

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 Inkrementen von einem Tag (increment_key: departure_date) neu erstellt, bis drei Tage zurück (increment_offset: 3).

Die Dimension departure_date ist eigentlich der Zeitraum date aus der Dimensionsgruppe departure. Eine Übersicht über die Funktionsweise von Dimensionsgruppen finden Sie auf der Dokumentationsseite zum Parameter dimension_group. Die Dimensionsgruppe und der Zeitrahmen werden beide in der flights-Ansicht definiert, welche die explore_source für diese PDT ist. So wird die departure-Dimensionsgruppe in der flights-Ansichtsdatei definiert:

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

Inkrementelle SQL-basierte PDT erstellen

Looker empfiehlt, LookML-basierte (native) abgeleitete Tabellen als Grundlage für inkrementelle PDTs zu verwenden und nicht SQL-basierte abgeleitete Tabellen. Bei nativen abgeleiteten Tabellen wird die komplexe Logik, die für inkrementelle PDTs erforderlich ist, automatisch berücksichtigt. SQL-basierte PDTs basieren auf manuell erstellter Logik, die bei Verwendung mit hochkomplexen Funktionen fehleranfällig ist.

Wenn Sie eine inkrementelle SQL-basierte PDT definieren möchten, verwenden Sie increment_key und optional increment_offset wie bei einer LookML-basierten PDT. Da SQL-basierte PDTs jedoch nicht auf LookML-Ansichtsdateien basieren, gelten zusätzliche Anforderungen, wenn Sie eine SQL-basierte PDT in eine inkrementelle PDT umwandeln möchten:

  • Sie müssen den Inkrementschlüssel auf einer zeitbasierten LookML-Dimension basieren, die Sie in der Ansichtsdatei der PDT definieren.
  • Sie müssen einen {% incrementcondition %}-Liquid-Filter in der PDT angeben, um den inkrementellen Schlüssel mit der Datenbankzeitspalte zu verbinden, auf der der inkrementelle Schlüssel basiert. Im Filter {% incrementcondition %} muss der Name der Spalte in Ihrer Datenbank angegeben werden, nicht ein SQL-Alias oder der Name einer Dimension, die auf der Spalte basiert (siehe Beispiel unten).

Das Grundformat für den Liquid-Filter lautet:

   WHERE {% incrementcondition %} database_table_name.database_time_column {% endincrementcondition %}

Hier ist beispielsweise die Ansichtsdatei für eine SQL-basierte PDT, die in Schritten von einem Tag (increment_key: "dep_date") neu erstellt wird. Dabei werden der Tabelle bei der Neuerstellung Daten der letzten drei Tage (increment_offset: 3) hinzugefügt:

view: sql_based_incremental_date_pdt {
  derived_table: {
    datagroup_trigger: flights_default_datagroup
    increment_key: "dep_date"
    increment_offset: 3
    distribution_style: all
    sql: SELECT
        flights.id2  AS "id",
        flights.origin  AS "origin",
        DATE(flights.leaving_time )  AS "departure"
      FROM public.flights  AS flights
      WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}
          ;;
  }

  dimension_group: dep {
    type: time
    timeframes: [date, week, month, year]
    datatype: date
    sql:  ${TABLE}.departure
    ;;
  }
  dimension: id {
      type: number
    }
    dimension: origin {
      type: string
  }
}

Beachten Sie bei diesem Beispiel Folgendes:

  • Die abgeleitete Tabelle basiert auf einer SQL-Anweisung. Mit der SQL-Anweisung wird eine Spalte in der abgeleiteten Tabelle erstellt, die auf der Spalte flights.leaving_time in der Datenbank basiert. Die Spalte erhält den Alias departure.
  • In der Ansichtsdatei der PDT wird eine Dimensionsgruppe mit dem Namen dep definiert.
    • Der Parameter sql der Dimensionsgruppe gibt an, dass die Dimensionsgruppe auf der Spalte departure in der abgeleiteten Tabelle basiert.
    • Der Parameter timeframes der Dimensionsgruppe enthält date als Zeitraum.
  • Für die increment_key der abgeleiteten Tabelle wird die Dimension dep_date verwendet. Das ist eine Dimension, die auf dem date-Zeitraum der Dimensionsgruppe dep basiert. Eine Übersicht über die Funktionsweise von Dimensionsgruppen finden Sie auf der Dokumentationsseite zum Parameter dimension_group.
  • Mit dem Liquid-Filter {% incrementcondition %} wird der inkrementelle Schlüssel mit der Spalte flights.leaving_time in der Datenbank verknüpft.
    • Im {% incrementcondition %} muss der Name einer TIMESTAMP-Spalte in Ihrer Datenbank angegeben werden (oder es muss zu einer TIMESTAMP-Spalte in Ihrer Datenbank ausgewertet werden).
    • Die {% incrementcondition %} muss anhand der Elemente ausgewertet werden, die in der FROM-Klausel verfügbar sind, mit der Ihr PDT definiert wird, z. B. Spalten aus der Tabelle, die in der FROM-Klausel angegeben ist. In der {% incrementcondition %} kann nicht auf das Ergebnis der SELECT-Anweisung verwiesen werden, z. B. auf einen Alias, der einer Spalte in der SQL-Anweisung zugewiesen wurde, oder auf den Namen einer Dimension, die auf der Spalte basiert. In diesem Beispiel ist {% incrementcondition %} flights.leaving_time. Da in der FROM-Klausel die Tabelle flights angegeben ist, kann sich {% incrementcondition %} auf Spalten aus der Tabelle flights beziehen.
    • Das {% incrementcondition %} muss auf dieselbe Datenbankspalte verweisen, die für den Steigerungsschlüssel verwendet wird. In diesem Beispiel ist der Steigerungsschlüssel dep_date, eine Dimension, die durch die Spalte departure im PDT definiert wird. Diese Spalte ist ein Alias für die Spalte flights.leaving_time in der Datenbank. Daher verweist der Filter auf flights.leaving_time:
WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}

Sie können die WHERE-Klausel ergänzen, um andere Filter zu erstellen. Wenn die Datenbanktabelle beispielsweise viele Jahre umfasst, können Sie einen Filter erstellen, damit beim ersten Erstellen des PDT nur Daten nach einem bestimmten Datum verwendet werden. Mit diesem WHERE wird ein PDT mit Daten ab dem 1. Januar 2020 erstellt:

WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}
  AND flights.leaving_time > '2020-01-01'

Sie können die WHERE-Klausel auch verwenden, um Daten in SQL in einen Zeitstempel zu parsen und ihm dann einen Alias zu geben. Die folgende inkrementelle PDT verwendet beispielsweise ein 15-Minuten-Inkrement, das auf text_column basiert. Dabei handelt es sich um Stringdaten, die in Zeitstempeldaten geparst wurden:

view: sql_based_incremental_15min_pdt {
  derived_table: {
    datagroup_trigger: flights_default_datagroup
    increment_key: "event_minute15"
    increment_offset: 1
    sql: SELECT PARSE_TIMESTAMP("%c", flights.text_column) as parsed_timestamp_column,
        flights.id2  AS "id",
        flights.origin  AS "origin",
      FROM public.flights  AS flights
      WHERE {% incrementcondition %} PARSE_TIMESTAMP("%c", flights.text_column)
          {% endincrementcondition %} ;;
  }

  dimension_group: event {
    type: time
    timeframes: [raw, minute15, hour, date, week, month, year]
    datatype: timestamp
    sql:  ${TABLE}.parsed_timestamp_column ;;
  }
  dimension: id {
    type: number
  }
  dimension: origin {
    type: string
  }
}

Sie können den Alias für den SQL-Code in der Definition der Dimensionsgruppe sql verwenden, müssen aber den SQL-Ausdruck in der WHERE-Klausel verwenden. Da minute15 als Zeitraum in der Dimensionsgruppe event eingerichtet wurde, können Sie event_minute15 als Inkrementschlüssel verwenden, um ein 15-Minuten-Inkrement für die PDT zu erhalten.

Inkrementelle zusammengefasste Tabelle erstellen

Wenn Sie eine inkrementelle Aggregattabelle erstellen möchten, fügen Sie increment_key und optional increment_offset unter dem Parameter materialization des Parameters aggregate_table hinzu. Mit dem Parameter increment_key geben Sie den Namen einer zeitbasierten LookML-Dimension an. Die Dimension muss in der Ansicht definiert sein, auf der das Explore der aggregierten Tabelle basiert.

Diese aggregierte Tabelle basiert beispielsweise auf dem Explore accidents, das in diesem Fall auf der Ansicht accidents basiert. Die zusammengefasste Tabelle wird in Schritten von einer Woche (increment_key: event_week) neu erstellt, wobei zwei Wochen zurückgegangen wird (increment_offset: 2):

explore: accidents {
  . . .
  aggregate_table: accidents_daily {
    query: {
      dimensions: [event_date, id, weather_condition]
      measures: [count]
    }
    materialization: {
      datagroup_trigger: flights_default_datagroup
      increment_key: "event_week"
      increment_offset: 2
    }
  }
}

Für den Inkrementschlüssel wird die Dimension event_week verwendet, die auf dem Zeitrahmen week aus der Dimensionsgruppe event basiert. Eine Übersicht über die Funktionsweise von Dimensionsgruppen finden Sie auf der Dokumentationsseite zum Parameter dimension_group. Die Dimensionsgruppe und der Zeitraum werden beide in der Ansicht accidents definiert:

. . .
view: accidents {
  . . .
  dimension_group: event {
      type: time
      timeframes: [
        raw,
        date,
        week,
        year
      ]
      sql: ${TABLE}.event_date ;;
  }
  . . .
}

Wichtige Punkte

Quelltabelle für zeitbasierte Abfragen optimieren

Achten Sie darauf, dass die Quelltabelle der inkrementellen PDT für zeitbasierte Abfragen optimiert ist. Die zeitbasierte Spalte, die für den Inkrementschlüssel verwendet wird, muss eine Optimierungsstrategie haben, z. B. Partitionierung, Sortierschlüssel, Indizes oder eine andere Optimierungsstrategie, die für Ihren Dialekt unterstützt wird. Eine Optimierung der Quelltabelle wird stark empfohlen. Mit jeder Aktualisierung der inkrementellen Tabelle fragt Looker die Quelltabelle ab, um die neuesten Werte der zeitbasierten Spalte zu bestimmen, die für den Inkrementschlüssel verwendet wird. Wenn die Quelltabelle für diese Abfragen nicht optimiert ist, kann die Abfrage der neuesten Werte durch Looker langsam und teuer ausfallen.

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.

In der folgenden Tabelle ist zu sehen, welche Dialekte inkrementelle PDTs in der aktuellen Looker-Version unterstützen:

Dialekt Unterstützt?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13+
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica