Schlüssel erhöhen

Nutzung

view: my_view {
derived_table: {
inkrementeller: ["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 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 erstellt wird, indem neue Daten an die Tabelle angehängt werden, anstatt die Tabelle vollständig neu zu erstellen. Weitere Informationen finden Sie auf der Dokumentationsseite Inkrementelle PDTs.

increment_key ist der Parameter, der ein PDT in einen inkrementellen PDT umwandelt. Dazu wird das Zeitintervall angegeben, für das aktuelle Daten abgefragt und an das PDT angehängt werden sollen. Zusätzlich zu increment_key können Sie optional ein increment_offset angeben, um die Anzahl vorheriger Zeiträume (mit dem Detaillierungsgrad) anzugeben, die für spät ankommende Daten neu erstellt werden.

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

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 von PDT sind).

increment_key muss eine zeitbasierte LookML-Dimension angeben:

Darüber hinaus muss increment_key Folgendes sein:

  • Eine gekürzte absolute Zeit wie Tag, Monat, Jahr, Geschäftsquartal usw. Zeiträume wie der Wochentag werden nicht unterstützt.
  • Ein Zeitstempel, der mit neuen Daten wie dem Erstellungsdatum der Bestellung vorhersagbar ansteigt. Mit anderen Worten: Ein Zeitstempel sollte nur dann als inkrementeller Schlüssel verwendet werden, wenn die neuesten Daten, die der Tabelle hinzugefügt wurden, auch den neuesten Zeitstempel haben. Ein Zeitstempel, z. B. der Geburtstag eines Nutzers, funktioniert nicht als inkrementeller Schlüssel, da der Zeitstempel eines Geburtsdatums nicht zuverlässig zunimmt, wenn der Tabelle neue Nutzer hinzugefügt werden.

inkrementellen LookML-basierten PDT erstellen

Um eine LookML-basierte (native) PDT in eine inkrementelle PDT umzuwandeln, verwenden Sie den Parameter increment_key, um den Namen einer zeitbasierten LookML-Dimension anzugeben. Die Dimension muss in der Ansicht definiert werden, auf der die explore_source des PDT basiert.

Hier ist beispielsweise eine Ansichtsdatei für eine PDT, die auf LookML basiert und den LookML-Parameter explore_source verwendet. Das PDT wird aus dem flights-Erkunden erstellt, der in diesem Fall auf der flights-Ansicht 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 Schritten von einem Tag (increment_key: departure_date) in drei Tagen (increment_offset: 3) wieder erstellt.

Die Dimension departure_date ist eigentlich der Zeitraum date aus der Dimensionsgruppe departure. Eine Übersicht der Funktionsweise von Dimensionsgruppen finden Sie auf der Dokumentationsseite zum Parameter dimension_group. Dimensionsgruppe und Zeitraum sind in der Ansicht flights definiert, also in der explore_source für diese PDT. 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 die Verwendung von LookML-basierten (nativen) abgeleiteten Tabellen als Grundlage für inkrementelle PDTs anstelle von SQL-basierten abgeleiteten Tabellen. Native abgeleitete Tabellen enthalten die komplexe Logik, die für inkrementelle PDTs erforderlich ist. SQL-basierte PDTs basieren auf manuell erstellter Logik, die bei hochkomplexer Funktionalität fehleranfällig ist.

Verwenden Sie zum Definieren eines inkrementellen SQL-basierten PDT increment_key und (optional) increment_offset wie bei einem LookML-basierten PDT. Da SQL-basierte PDT-Dateien jedoch nicht auf LookML-Ansichtsdateien basieren, gelten zusätzliche Anforderungen für die Umwandlung einer SQL-basierten PDT in eine inkrementelle PDT:

  • Der inkrementelle Schlüssel muss auf einer zeitbasierten LookML-Dimension basieren, die Sie in der Ansichtsdatei des PDT definieren.
  • Sie müssen im PDT einen Liquid-Filter vom Typ {% incrementcondition %} angeben, um den Inkrementschlüssel mit der Datenbankzeitspalte zu verbinden, auf der der Inkrementschlüssel basiert. Der Filter {% incrementcondition %} 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 sehen Sie beispielsweise die Ansichtsdatei für eine SQL-basierte PDT, die in Schritten von einem Tag (increment_key: "dep_date") neu erstellt wird. Dabei werden Daten aus den letzten drei Tagen in die Tabelle aufgenommen, 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: [raw, date, week, month, year]
    datatype: timestamp
    sql:  ${TABLE}.departure
    ;;
  }
  dimension: id {
      type: number
    }
    dimension: origin {
      type: string
  }
}

Hinweise 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 ist 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. Sie basiert auf dem date-Zeitraum der Dimensionsgruppe dep. Eine Übersicht der Funktionsweise von Dimensionsgruppen finden Sie auf der Dokumentationsseite zum Parameter dimension_group.
  • Mit dem Liquid-Filter {% incrementcondition %} wird der Inkrementschlüssel mit der Spalte flights.leaving_time in der Datenbank verbunden.
    • Der {% incrementcondition %} muss den Namen einer TIMESTAMP-Spalte in Ihrer Datenbank angeben (oder mit einer TIMESTAMP-Spalte in Ihrer Datenbank auswerten).
    • Der {% incrementcondition %} muss anhand der verfügbaren Elemente in der FROM-Klausel ausgewertet werden, die Ihr PDT definiert, z. B. Spalten aus der Tabelle, die in der FROM-Klausel angegeben ist. {% 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. Im Beispiel oben ist {% incrementcondition %} flights.leaving_time. Da die Klausel FROM die Tabelle flights angibt, kann sich der {% incrementcondition %} auf Spalten aus der Tabelle flights beziehen.
    • Der {% incrementcondition %} muss auf dieselbe Datenbankspalte verweisen, die für den inkrementellen Schlüssel verwendet wird. In diesem Beispiel ist der inkrementelle-Schlüssel dep_date, eine Dimension, die durch die Spalte departure im PDT definiert wird. Das 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 hinzufügen, um andere Filter zu erstellen. Wenn die Datenbanktabelle beispielsweise viele Jahre zurückreicht, können Sie einen Filter erstellen, damit der ursprüngliche Build der PDT nur nach einem bestimmten Datum verwendet. Für 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 ihr einen Alias zuzuweisen. Der folgende inkrementelle PDT verwendet beispielsweise ein Inkrement von 15 Minuten, das auf text_column basiert. Das sind 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 SQL in der Dimensionsgruppe sql verwenden, müssen dazu aber den SQL-Ausdruck in der WHERE-Klausel verwenden. Da dann minute15 als Zeitraum in der Dimensionsgruppe event festgelegt wurde, können Sie dann event_minute15 als inkrementellen Schlüssel verwenden, um den PDT um 15 Minuten zu erhöhen.

Inkrementelle zusammengefasste Tabelle erstellen

Wenn Sie eine inkrementelle zusammengefasste Tabelle erstellen möchten, fügen Sie unter dem Parameter materialization des Parameters aggregate_table increment_key und (optional) increment_offset hinzu. Verwenden Sie den Parameter increment_key, um den Namen einer zeitbasierten LookML-Dimension anzugeben. Die Dimension muss in der Ansicht definiert werden, auf der die „Erkunden“-Tabelle basiert.

Diese zusammengefasste Tabelle basiert beispielsweise auf dem explorativen Analysetool accidents, das in diesem Fall auf der Ansicht accidents basiert. Die zusammengefasste Tabelle wird in Schritten von einer Woche (increment_key: event_week) in zwei Wochen neu erstellt (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 Schlüssel für die Erhöhung wird die Dimension event_week verwendet. Sie basiert auf dem Zeitraum week aus der Dimensionsgruppe event. Eine Übersicht der Funktionsweise von Dimensionsgruppen finden Sie auf der Dokumentationsseite zum Parameter dimension_group. Dimensionsgruppe und Zeitraum sind 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 des inkrementellen PDT für zeitbasierte Abfragen optimiert ist. 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. 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 nicht für diese Abfragen optimiert ist, kann die Abfrage der neuesten Werte von Looker langsam und teuer sein.

Unterstützte Datenbankdialekte für inkrementelle PDTs

Damit Looker inkrementelle PDTs in Ihrem Looker-Projekt unterstützen kann, muss Ihr Datenbankdialekt DDL-Befehle unterstützen, mit denen Zeilen gelöscht und eingefügt werden können.

Die folgende Tabelle zeigt, welche Dialekte in der neuesten Version von Looker inkrementelle PDTs unterstützen: