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 in Ihrem Projekt inkrementelle PDTs 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 zum 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 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 (eine Art von PDT).

In increment_key muss eine zeitbasierte LookML-Dimension angegeben werden:

Außerdem muss der increment_key Folgendes sein:

  • Eine gekürzte absolute Zeit, z. B. Tag, Monat, Jahr oder Geschäftsquartal. Zeiträume wie Wochentage werden nicht unterstützt.
  • Ein Zeitstempel, der mit neuen Daten vorhersehbar zunimmt, z. B. das Erstellungsdatum der Bestellung. Anders ausgedrückt: Ein Zeitstempel sollte nur dann als Inkrementschlüssel verwendet werden, wenn die neuesten Daten, die der Tabelle hinzugefügt werden, auch den neuesten Zeitstempel haben. Ein Zeitstempel wie der Geburtstag eines Nutzers eignet sich nicht als Inkrementschlüssel, da ein Zeitstempel für den Geburtstag nicht zuverlässig steigt, wenn der Tabelle neue Nutzer hinzugefügt werden.

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 Zeitraum werden beide in der flights-Ansicht 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 zu verwenden. Native abgeleitete Tabellen verarbeiten die komplexe Logik, die für inkrementelle PDTs erforderlich ist, von Natur aus. 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, um eine SQL-basierte PDT in eine inkrementelle PDT umzuwandeln:

  • Der inkrementelle Schlüssel muss auf einer zeitbasierten LookML-Dimension basieren, die Sie in der Ansichtsdatei der PDT definieren.
  • Sie müssen in der PAT einen Liquid-Filter {% incrementcondition %} 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 das folgende 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 Schritten von einem Tag (increment_key: "dep_date") neu erstellt wird. Dabei werden die Daten der letzten drei Tage der Tabelle hinzugefügt, wenn sie neu erstellt wird (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 bei diesem Beispiel Folgendes:

  • 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.
  • Die increment_key der abgeleiteten Tabelle verwendet die Dimension dep_date, die auf dem Zeitraum date der Dimensionsgruppe dep basiert. (Eine Übersicht über die Funktionsweise von Dimensionsgruppen finden Sie auf der Dokumentationsseite zum Parameter dimension_group.)
  • Der Liquid-Filter {% incrementcondition %} wird verwendet, um den inkrementellen Schlüssel mit der Spalte flights.leaving_time in der Datenbank zu verbinden.
    • Der {% incrementcondition %} muss den Namen einer TIMESTAMP-Spalte in Ihrer Datenbank angeben (oder zu einer TIMESTAMP-Spalte in Ihrer Datenbank ausgewertet werden).
    • Der {% incrementcondition %} muss mit den Elementen abgeglichen werden, die in der FROM-Klausel verfügbar sind, 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 der {% incrementcondition %} flights.leaving_time. Da in der FROM-Klausel die Tabelle flights angegeben ist, kann die {% incrementcondition %} auf Spalten aus der Tabelle flights verweisen.
    • Der {% incrementcondition %} muss auf dieselbe Datenbankspalte verweisen, die für den inkrementellen Schlüssel verwendet wird. In diesem Beispiel ist der Inkrementschlüssel dep_date, eine Dimension, die durch die Spalte departure in der PDT definiert wird, die ein Alias für die Spalte flights.leaving_time in der Datenbank ist. Daher verweist der Filter auf flights.leaving_time:
WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}

Sie können die WHERE-Klausel erweitern, um weitere Filter zu erstellen. Wenn die Datenbanktabelle beispielsweise viele Jahre zurückreicht, können Sie einen Filter erstellen, sodass für die erste Erstellung der PDT nur Daten nach einem bestimmten Datum verwendet werden. Mit diesem WHERE wird eine PDT mit Daten nach dem 1. Januar 2020 erstellt:

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

Sie können auch die WHERE-Klausel verwenden, um Daten in SQL in einen Zeitstempel zu parsen und ihnen dann einen Alias zuzuweisen. Die folgende inkrementelle PDT verwendet beispielsweise ein 15-minütiges 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 das SQL 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 zusammengefasste Tabelle erstellen möchten, fügen Sie increment_key und (optional) increment_offset unter dem Parameter materialization des Parameters aggregate_table hinzu. Verwenden Sie den Parameter increment_key, um den Namen einer zeitbasierten LookML-Dimension anzugeben. Die Dimension muss in der Ansicht definiert sein, auf der das Explore der zusammengefassten 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 Schritten von einer Woche (increment_key: event_week) neu erstellt, wobei zwei Wochen (increment_offset: 2) zurückgegangen wird:

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 Dimension event_week, die auf dem Zeitraum 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

Stellen Sie sicher, dass die Quelltabelle der inkrementellen PDT für zeitbasierte Abfragen optimiert ist. 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 Optimierungsstrategie, die für Ihren Dialekt unterstützt wird. 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 Datendefinitionssprache (DDL)-Befehle 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.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
ClickHouse 26+
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+
Dremio 26+ with Arrow Flight SQL
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