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 le 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 interamente. Per ulteriori informazioni, 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 cui devono essere eseguite query sui dati aggiornati e aggiunti alla PDT. Oltre a increment_key, puoi fornire facoltativamente un increment_offset per specificare il numero di periodi di tempo precedenti (in base alla granularità della chiave di incremento) che vengono ricostruiti per tenere conto dei dati in arrivo in ritardo.

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

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, il increment_key deve:

  • Un periodo di tempo assoluto troncato, ad esempio giorno, mese, anno, trimestre fiscale e così via. I periodi di tempo, ad esempio 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 incrementale solo se i dati più recenti aggiunti alla tabella hanno anche il timestamp più recente. Un timestamp come la data di nascita dell'utente non funzionerebbe come chiave di incremento, poiché il timestamp della data di nascita non aumenta in modo affidabile con l'aggiunta di nuovi utenti 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 del PDT.

Ad esempio, ecco un file di visualizzazione per una PDT basata su LookML, che utilizza il parametro LookML explore_source. 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 per intero la prima volta che viene eseguita una query. Dopodiché, il PDT verrà ricreato con incrementi di un giorno (increment_key: departure_date), tornando indietro di 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 del parametro dimension_group. Il gruppo di dimensioni e l'intervallo di tempo sono entrambi definiti nella visualizzazione flights, che è explore_source per questa PDT. Ecco come viene definito il gruppo di dimensioni departure nel file di visualizzazione 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 consiglia di utilizzare le tabelle derivate basate su LookML (native) come base per le PDT incrementali, anziché le tabelle derivate basate su SQL. Le tabelle derivate native gestiscono intrinsecamente la logica complessa richiesta per le PDT incrementali. I PDT basati su SQL si basano su una logica creata manualmente, che è soggetta a errori se utilizzata con funzionalità molto complesse.

Per definire un PDT basato su SQL incrementale, utilizza increment_key e (facoltativamente) increment_offset come faresti con un PDT basato 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 che definisci nel file di visualizzazione del PDT.
  • Devi fornire un filtro Liquid {% incrementcondition %} nella PDT per collegare la chiave di incremento alla colonna temporale 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 della vista per un PDT basato su SQL che viene ricreato con incrementi di un giorno (increment_key: "dep_date"), in cui i dati degli ultimi tre giorni verranno aggiunti alla tabella quando viene ricreata (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 del database. Alla colonna viene assegnato l'alias departure.
  • Il file di visualizzazione del 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 della tabella derivata.
    • Il parametro timeframes del gruppo di dimensioni include date come intervallo 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 del parametro dimension_group.
  • Il filtro Liquid {% incrementcondition %} viene utilizzato per collegare la chiave di incremento alla colonna flights.leaving_time nel database.
    • {% incrementcondition %} deve specificare il nome di una colonna TIMESTAMP nel database (o deve restituire come risultato una colonna TIMESTAMP nel database).
    • L'{% incrementcondition %} deve essere valutato in base a ciò che è disponibile nella clausola FROM che definisce il PDT, ad esempio le colonne della tabella specificata nella clausola FROM. {% 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.
    • {% 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 tabella derivata, che è un alias della 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 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 un PDT con 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, ovvero 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 l'SQL nella definizione del gruppo di dimensioni sql, ma devi utilizzare l'espressione SQL nella clausola WHERE. 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 al 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 visualizzazione accidents. La tabella aggregata viene ricostruita a incrementi di una settimana (increment_key: event_week), a partire da due settimane prima (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 periodo di tempo del gruppo di dimensioni event.week Per una panoramica del funzionamento dei gruppi di dimensioni, consulta la pagina della documentazione del parametro dimension_group. Il gruppo di dimensioni e l'intervallo di tempo sono entrambi definiti nella visualizzazione 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 del PDT incrementale sia ottimizzata per le query basate sul tempo. Nello specifico, la colonna basata sul tempo utilizzata per la chiave di incremento deve avere una strategia di ottimizzazione, ad esempio 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 query sulla tabella di origine per determinare i valori più recenti della colonna basata sul tempo utilizzata per la chiave incrementale. 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 del linguaggio DDL (Data Definition Language) che consentono l'eliminazione e l'inserimento di 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+
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