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

Sonderregeln
increment_key wird nur mit persistenten 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 zu inkrementellen PDTs.

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

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

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

Für increment_key muss eine zeitbasierte LookML-Dimension angegeben werden:

Außerdem muss increment_key Folgendes sein:

  • Eine gekürzte absolute Zeit, z. B. Tag, Monat, Jahr, Quartal usw. Zeiträume wie Wochentag werden nicht unterstützt.
  • Ein Zeitstempel, der mit neuen Daten vorhersagbar zunimmt, z. B. das Datum, an dem eine Bestellung erstellt wurde. Mit anderen Worten: Ein Zeitstempel sollte 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 Inkrementschlüssel funktionieren, da der Zeitstempel des Geburtstags nicht zuverlässig mit neuen Nutzern zunimmt, die der Tabelle hinzugefügt werden.

Inkrementelle LookML-basierte PDT erstellen

Wenn Sie eine LookML-basierte (native) PDT in eine inkrementelle PDT umwandeln möchten, geben Sie mit dem increment_key Parameter den Namen einer zeitbasierten LookML-Dimension an. 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 explore_source LookML-Parameter 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 timeframe aus der Dimensionsgruppe departure. Eine Übersicht der Funktionsweise von Dimensionsgruppen finden Sie auf der Dokumentationsseite zum Parameter dimension_group. Die Dimensionsgruppe und der Zeitraum werden beide in der Ansicht flights definiert, welche die explore_source für diese PDT ist. So wird die Dimensionsgruppe departure in der Ansichtsdatei flights 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, anstatt SQL-basierte abgeleitete Tabellen. Native abgeleitete Tabellen verarbeiten die komplexe Logik, die für inkrementelle PDTs erforderlich ist. 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, gibt es zusätzliche Anforderungen, um eine SQL-basierte PDT in eine inkrementelle PDT umzuwandeln:

  • 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 Inkrementschlüssel mit der Datenbankzeitspalte zu verbinden, auf der der Inkrementschlüssel basiert. Der {% incrementcondition %} Filter muss den Namen der Spalte in Ihrer Datenbank angeben, nicht einen SQL-Alias oder den Namen einer Dimension, die auf der Spalte basiert (siehe folgendes Beispiel).

Das grundlegende Format für den Liquid-Filter ist:

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

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

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 Folgendes zu diesem Beispiel:

  • Die abgeleitete Tabelle basiert auf einer SQL-Anweisung. Die SQL-Anweisung erstellt eine Spalte in der abgeleiteten Tabelle, 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 namens 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.
  • Der increment_key der abgeleiteten Tabelle verwendet die Dimension dep_date, die auf dem Zeitraum date der Dimensionsgruppe dep basiert. Eine Übersicht der Funktionsweise von Dimensionsgruppen finden Sie auf der Dokumentationsseite zum Parameter dimension_group.
  • Der {% incrementcondition %} Liquid-Filter wird verwendet, um den Inkrementschlüssel mit der flights.leaving_time Spalte in der Datenbank zu verbinden.
    • Für {% incrementcondition %} muss der Name einer TIMESTAMP Spalte in Ihrer Datenbank angegeben werden (oder er muss zu einer TIMESTAMP Spalte in Ihrer Datenbank ausgewertet werden).
    • Der {% incrementcondition %} muss mit dem verglichen werden, was in der FROM Klausel verfügbar ist, die Ihre PDT definiert, z. B. Spalten aus der Tabelle, die in der FROM Klausel angegeben ist. Der {% incrementcondition %} kann nicht auf das Ergebnis der SELECT-Anweisung verweisen, 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 das {% incrementcondition %} gleich flights.leaving_time. Da in der FROM Klausel die flights Tabelle angegeben ist, kann {% incrementcondition %} auf Spalten aus der flights Tabelle verweisen.
    • Der {% incrementcondition %} muss auf dieselbe Datenbankspalte verweisen, die für den Inkrementschlüssel verwendet wird. In diesem Beispiel ist der Inkrementschlüssel dep_date, eine Dimension, die durch die Spalte departure in der PDT definiert wird. Diese 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 der WHERE-Klausel weitere Filter hinzufügen. Wenn die Datenbanktabelle beispielsweise viele Jahre zurückreicht, können Sie einen Filter erstellen, damit beim ersten Erstellen der PDT nur Daten nach einem bestimmten Datum verwendet werden. Diese WHERE-Klausel erstellt eine PDT mit Daten nach dem 1. Januar 2020:

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 der 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 das SQL in der sql-Definition der Dimensionsgruppe verwenden, aber in der WHERE-Klausel müssen Sie den SQL-Ausdruck 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 aggregierte Tabelle erstellen

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

Diese zusammengefasste Tabelle basiert beispielsweise auf dem Explore accidents, das in diesem Fall auf der Ansicht accidents basiert. Die zusammengefasste Tabelle wird in Inkrementen von einer Woche neu erstellt (increment_key: event_week), bis zwei Wochen zurück (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
    }
  }
}

Der Inkrementschlüssel verwendet die event_week Dimension, die auf dem week Zeitrahmen der Dimensionsgruppe event basiert. Eine Übersicht der 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

Stellen Sie sicher, dass die Quelltabelle der inkrementellen PDT für zeitbasierte Abfragen optimiert ist. Insbesondere muss die zeitbasierte Spalte des Inkrementschlüssels eine Optimierungsstrategie haben, wie Partitionierung, Sortierschlüssel, Indizes oder eine beliebige von Ihrem Dialekt unterstützte Optimierungsstrategie. Eine Optimierung der Quelltabelle wird dringend 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. Wurde die Quelltabelle für diese Abfragen nicht optimiert, 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 Data Definition Language (DDL)-Befehle zum Löschen und Einfügen von Zeilen unterstützen.

In der folgenden Tabelle ist zu sehen, welche Dialekte inkrementelle PDTs in der aktuellen Version von Looker 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.x - 0.17.x
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 AlloyDB for PostgreSQL
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
MongoSQL
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