Puoi creare PDT incrementali nel tuo progetto se il linguaggio le supporta. Una PDT incrementale è una tabella derivata permanente (PDT) che Looker crea aggiungendo alla tabella dati aggiornati, anziché ricreare la tabella nella sua interezza. Per ulteriori informazioni, consulta la pagina Documentazione sulle PDT incrementali.

increment_key è il parametro che trasforma una PDT in una PDT incrementale specificando l'incremento di tempo per il quale eseguire query e aggiungere dati nuovi alla PDT. In aggiunta all'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 ricreati per tenere conto dei dati in arrivo.

L'increment_key per una PDT è indipendente dall'attivatore di persistenza della PDT. Consulta la pagina della documentazione sulle PDT incrementali per consultare alcuni scenari di esempio che mostrano l'interazione tra increment_key, increment_offset e la strategia di persistenza.

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

increment_key deve specificare una dimensione LookML basata sul tempo:

Per le PDT basate su LookML, increment_key deve essere basato su una dimensione LookML definita nella vista su cui si basa la explore_source della PDT. Per un esempio, consulta la sezione Creazione di una PDT basata su LookML incrementale di questa pagina.
Per le tabelle aggregate, increment_key deve essere basato su una dimensione LookML definita nella vista su cui si basa l'esplorazione della tabella aggregata. Per un esempio, consulta la sezione Creazione di una tabella aggregata incrementale in questa pagina.
Per le PDT basate su SQL, increment_key deve essere basato su una dimensione LookML definita all'interno del file View di PDT. Per un esempio, consulta Creazione di una PDT basata su SQL incrementale in questa pagina.

Inoltre, increment_key deve essere:

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

Creazione di una PDT incrementale basata su LookML

Per effettuare una PDT basata su LookML (native) 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 l'explore_source della PDT.

Di seguito è riportato un esempio di file di vista per una PDT basata su LookML utilizzando il parametro LookML di explore_source. La PDT viene creata dall'esplorazione di flights, che in questo caso si basa sulla visualizzazione di 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à compilata per intero la prima volta che viene eseguita una query. In seguito, la PDT verrà ricreata in incrementi di un giorno (increment_key: departure_date), cioè fino a tre giorni (increment_offset: 3).

La dimensione departure_date è in realtà il periodo di tempo date del gruppo di dimensioni departure. Consulta la pagina della documentazione relativa al parametro dimension_group per una panoramica sul funzionamento dei gruppi di dimensioni. Il gruppo di dimensioni e il periodo di tempo sono definiti nella vista flights, ovvero l'explore_source per questa PDT. Ecco come viene definito il gruppo di dimensioni departure nel file 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 tabelle derivate basate su LookML (native) come base per le PDT incrementali, anziché utilizzare le tabelle derivate basate su SQL. Le tabelle native native gestiscono intrinsecamente la logica complessa richiesta per le PDT incrementali. Le PDT basate su SQL si basano su logiche create manualmente, soggette a errori quando utilizzate con funzionalità estremamente complesse.

Per definire una PDT basata su SQL incrementale, 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 sui file di visualizzazione LookML, esistono ulteriori requisiti per trasformare una PDT basata su SQL in una PDT incrementale:

La chiave di incremento deve essere basata su una dimensione LookML basata sul tempo che definisci nel file di vista PDT.
Devi fornire un filtro Liquid di {% incrementcondition %} nel 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 il seguente esempio).

Il formato di base per il filtro Liquid è:

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

Ad esempio, qui è riportato il file vista per una PDT basata su SQL che viene ricreata in 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: [raw, date, week, month, year]
    datatype: timestamp
    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. L'alias della colonna è departure.
Il file di visualizzazione delle 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 intervallo di tempo.
La tabella derivata increment_key utilizza la dimensione dep_date, che è una dimensione basata sul periodo di tempo date del gruppo di dimensioni dep. Consulta la pagina della documentazione relativa al parametro dimension_group per una panoramica sul funzionamento dei gruppi di dimensioni.
Il filtro Liquido {% incrementcondition %} viene utilizzato per collegare la chiave di incremento alla colonna flights.leaving_time del database.
- La proprietà {% incrementcondition %} deve specificare il nome di una colonna TIMESTAMP nel database oppure deve restituire una colonna TIMESTAMP nel database.
- La classe {% incrementcondition %} deve effettuare una valutazione in base a ciò che è disponibile nella clausola FROM che definisce la 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 dell'istruzione SQL o al nome di una dimensione basata sulla colonna. Nell'esempio precedente, {% incrementcondition %} è flights.leaving_time. Poiché la clausola FROM specifica la tabella flights, {% incrementcondition %} può fare riferimento alle colonne della tabella flights.
- {% incrementcondition %} deve fare riferimento alla stessa colonna di database utilizzata per la chiave di incremento. In questo esempio la chiave di incremento è dep_date, una dimensione definita dalla colonna departure nel PDT, che è un alias per la colonna flights.leaving_time nel database. Di conseguenza, il filtro rimanda a flights.leaving_time:

WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}

Puoi aggiungere la clausola WHERE per creare altri filtri. Ad esempio, se la tabella del database risale a molti anni prima, puoi creare un filtro in modo che la build iniziale della PDT utilizzi solo i dati dopo una determinata data. Questo WHERE crea una PDT con dati a partire dal 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 sul text_column, dato che sono i dati di stringa che sono stati analizzati in dati di 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 del gruppo di dimensioni sql, ma devi utilizzare l'espressione SQL nella clausola WHERE. Inoltre, poiché minute15 è stato impostato 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 è basata sulla vista accidents. La tabella aggregata viene ricreata in incrementi di una settimana (increment_key: event_week), che risalgono a 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 week del gruppo di dimensioni event. Consulta la pagina della documentazione relativa al parametro dimension_group per una panoramica sul funzionamento dei gruppi di dimensioni. Il gruppo di dimensioni e il periodo di tempo sono 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, ad esempio partizionamento, ordinamento, indici o qualsiasi strategia di ottimizzazione supportata per il dialetto. L'ottimizzazione delle tabelle 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 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 tuo dialetto del database deve supportare i comandi 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: