increment_key

Utilizzo

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

- o -

explore
aggregate_table
materialization
increment_key
Valore predefinito
Nessuno

Accetta
Il nome di una dimensione LookML basata sul tempo

Regole speciali
increment_key è supportato solo con tabelle persistenti e solo per dialetti specifici

Definizione

Puoi creare PDT incrementali nel tuo progetto se il tuo dialetto li supporta. Una PDT incrementale è una tabella derivata persistente (PDT) che Looker crea aggiungendo nuovi dati alla tabella, anziché ricostruirla completamente. Per saperne di più, consulta la pagina della documentazione relativa alle PDT incrementali.

increment_key è il parametro che trasforma una PDT in una PDT incrementale specificando l'incremento di tempo per il quale devono essere eseguite query e aggiunti nuovi dati alla PDT. Oltre a increment_key, puoi fornire facoltativamente un increment_offset per specificare il numero di periodi di tempo precedenti (alla granularità della chiave di incremento) che vengono ricostruiti per tenere conto dei dati in arrivo in ritardo.

increment_key per una PDT è indipendente dal trigger di persistenza della PDT. Per alcuni scenari di esempio che mostrano l'interazione di increment_key, increment_offset e della strategia di persistenza, consulta la pagina della documentazione relativa alle PDT incrementali.

Il parametro increment_key funziona solo con i dialetti supportati e solo con le tabelle che hanno una strategia di persistenza, come le PDT e le tabelle aggregate (che sono un tipo di PDT).

increment_key deve specificare una dimensione LookML basata sul tempo:

Inoltre, increment_key deve essere:

  • Un tempo assoluto troncato, ad esempio giorno, mese, anno, trimestre fiscale e così via. I periodi di tempo come il giorno della settimana non sono supportati.
  • Un timestamp che aumenta in modo prevedibile con i nuovi dati, ad esempio la data di creazione dell'ordine. In altre parole, un timestamp deve essere utilizzato come chiave di incremento solo se i dati più recenti aggiunti alla tabella hanno anche il timestamp più recente. Un timestamp come il compleanno dell'utente non funzionerebbe come chiave di incremento, poiché un timestamp di compleanno non aumenta in modo affidabile con i nuovi utenti aggiunti alla tabella.

Creazione di una PDT incrementale basata su LookML

Per trasformare una PDT basata su LookML (nativa) in una PDT incrementale, utilizza il parametro increment_key per specificare il nome di una dimensione LookML basata sul tempo. La dimensione deve essere definita nella vista su cui si basa explore_source della PDT.

Ad esempio, ecco un file di visualizzazione per una PDT basata su LookML, che utilizza il explore_source parametro LookML. La PDT viene creata dall'esplorazione flights, che in questo caso si basa sulla vista flights:

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
  }
}

Questa tabella verrà creata completamente la prima volta che viene eseguita una query. Dopodiché, la PDT verrà ricostruita con incrementi di un giorno (increment_key: departure_date), risalendo a tre giorni (increment_offset: 3).

La dimensione departure_date è in realtà il date periodo di tempo del gruppo di dimensioni departure. (Per una panoramica del funzionamento dei gruppi di dimensioni, consulta la pagina della documentazione relativa al parametro dimension_group.) Il gruppo di dimensioni e il periodo di tempo sono entrambi definiti nella vista flights, che è explore_source per questa PDT. Ecco come viene definito il gruppo di dimensioni departure nel file di vista flights:

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

Creazione di una PDT incrementale basata su SQL

Looker suggerisce di utilizzare le tabelle derivate basate su LookML (native) come base per le PDT incrementali, anziché utilizzare le tabelle derivate basate su SQL. Le tabelle derivate native gestiscono intrinsecamente la logica complessa richiesta per le PDT incrementali. Le PDT basate su SQL si basano su una logica creata manualmente, soggetta a errori se utilizzata con funzionalità molto complesse.

Per definire una PDT incrementale basata su SQL, utilizza increment_key e (facoltativamente) increment_offset come faresti con una PDT basata su LookML. Tuttavia, poiché le PDT basate su SQL non si basano su file di visualizzazione LookML, esistono requisiti aggiuntivi per trasformare una PDT basata su SQL in una PDT incrementale:

  • Devi basare la chiave di incremento su una dimensione LookML basata sul tempo definita nel file di visualizzazione della PDT.
  • Devi fornire un {% incrementcondition %} filtro Liquid nella PDT per collegare la chiave di incremento alla colonna di tempo del database su cui si basa la chiave di incremento. Il filtro {% incrementcondition %} deve specificare il nome della colonna nel database, non un alias SQL né il nome di una dimensione basata sulla colonna (vedi l'esempio seguente).

Il formato di base per il filtro Liquid è:

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

Ad esempio, ecco il file di visualizzazione per una PDT basata su SQL che viene ricostruita con incrementi di un giorno (increment_key: "dep_date"), in cui i dati degli ultimi tre giorni verranno aggiunti alla tabella quando viene ricostruita (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
  }
}

Tieni presente quanto segue in merito a questo esempio:

  • La tabella derivata si basa su un'istruzione SQL. L'istruzione SQL crea una colonna nella tabella derivata basata sulla colonna flights.leaving_time nel database. Alla colonna viene assegnato l'alias departure.
  • Il file di visualizzazione della PDT definisce un gruppo di dimensioni denominato dep.
    • Il parametro sql del gruppo di dimensioni indica che il gruppo di dimensioni si basa sulla colonna departure nella tabella derivata.
    • Il parametro timeframes del gruppo di dimensioni include date come periodo di tempo.
  • increment_key della tabella derivata utilizza la dimensione dep_date, che è una dimensione basata sul periodo di tempo date del gruppo di dimensioni dep. (Per una panoramica del funzionamento dei gruppi di dimensioni, consulta la pagina della documentazione relativa al parametro dimension_group.)
  • Il filtro Liquid {% incrementcondition %} viene utilizzato per collegare la chiave di incremento alla colonna flights.leaving_time nel database.
    • Il {% incrementcondition %} deve specificare il nome di una colonna TIMESTAMP nel database (o deve restituire una colonna TIMESTAMP nel database).
    • The {% incrementcondition %} deve essere valutato in base a ciò che è disponibile nella clausola FROM che definisce la PDT, ad esempio le colonne della tabella specificata nella clausola FROM. The {% incrementcondition %} non può fare riferimento al risultato dell'istruzione SELECT, ad esempio un alias assegnato a una colonna nell'istruzione SQL o il nome di una dimensione basata sulla colonna. In questo esempio, {% incrementcondition %} è flights.leaving_time. Poiché la clausola FROM specifica la tabella flights, {% incrementcondition %} può fare riferimento alle colonne della tabella flights.
    • The {% incrementcondition %} deve puntare alla stessa colonna del database utilizzata per la chiave di incremento. In questo esempio, la chiave di incremento è dep_date, una dimensione definita dalla colonna departure nella PDT, che è un alias per la colonna flights.leaving_time nel database. Pertanto, il filtro punta a flights.leaving_time:
WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}

Puoi aggiungere alla clausola WHERE per creare altri filtri. Ad esempio, se la tabella del database risale a molti anni fa, puoi creare un filtro in modo che la creazione iniziale della PDT utilizzi solo i dati successivi a una determinata data. Questo WHERE crea una PDT con i dati successivi al 1° gennaio 2020:

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

Puoi anche utilizzare la clausola WHERE per analizzare i dati in SQL in un timestamp e poi assegnargli un alias. Ad esempio, la seguente PDT incrementale utilizza un incremento di 15 minuti basato su text_column, che sono dati stringa analizzati in dati timestamp:

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
  }
}

Puoi utilizzare l'alias per SQL nella definizione sql del gruppo di dimensioni, ma devi utilizzare l'espressione SQL nella clausola WHERE. Dopodiché, poiché minute15 è stato configurato come periodo di tempo nel gruppo di dimensioni event, puoi utilizzare event_minute15 come chiave di incremento per ottenere un incremento di 15 minuti per la PDT.

Creazione di una tabella aggregata incrementale

Per creare una tabella aggregata incrementale, aggiungi increment_key e (facoltativamente) increment_offset nel parametro materialization del parametro aggregate_table. Utilizza il parametro increment_key per specificare il nome di una dimensione LookML basata sul tempo. La dimensione deve essere definita nella vista su cui si basa l'esplorazione della tabella aggregata.

Ad esempio, questa tabella aggregata si basa sull'esplorazione accidents, che in questo caso si basa sulla vista accidents. La tabella aggregata viene ricostruita con incrementi di una settimana (increment_key: event_week), risalendo a due settimane (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
    }
  }
}

La chiave di incremento utilizza la dimensione event_week, che si basa sul week periodo di tempo del gruppo di dimensioni event. (Per una panoramica del funzionamento dei gruppi di dimensioni, consulta la pagina della documentazione relativa al parametro dimension_group.) Il gruppo di dimensioni e il periodo di tempo sono entrambi definiti nella vista accidents:

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

Aspetti da considerare

Ottimizzare la tabella di origine per le query basate sul tempo

Assicurati che la tabella di origine della PDT incrementale sia ottimizzata per le query basate sul tempo. In particolare, la colonna basata sul tempo utilizzata per la chiave di incremento deve avere una strategia di ottimizzazione, come partizionamento, chiavi di ordinamento, indici o qualsiasi strategia di ottimizzazione supportata per il tuo dialetto. L'ottimizzazione della tabella di origine è vivamente consigliata perché ogni volta che la tabella incrementale viene aggiornata, Looker esegue una query sulla tabella di origine per determinare i valori più recenti della colonna basata sul tempo utilizzata per la chiave di incremento. Se la tabella di origine non è ottimizzata per queste query, la query di Looker per i valori più recenti potrebbe essere lenta e costosa.

Dialetti di database supportati per le PDT incrementali

Affinché Looker supporti le PDT incrementali nel tuo progetto Looker, il dialetto del database deve supportare i comandi DDL (Data Definition Language) che consentono di eliminare e inserire righe.

La tabella seguente mostra quali dialetti supportano le PDT incrementali nell'ultima release di Looker:

Dialetto Supportata?
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