Utilizzo
derived_table: {
increment_key: ["created_date"]
...
}
}
Gerarchia
increment_key - oppure - increment_key |
Valore predefinito
NessunaAccetta
Il nome di una dimensione LookML basata sul tempoRegole speciali
increment_key è supportato solo con tabelle permanenti e solo per dialetti specifici
|
Definizione
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 traincrement_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 laexplore_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
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).{% incrementcondition %}
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 colonnadeparture
nella tabella derivata. - Il parametro
timeframes
del gruppo di dimensioni includedate
come intervallo di tempo.
- Il parametro
- La tabella derivata
increment_key
utilizza la dimensionedep_date
, che è una dimensione basata sul periodo di tempodate
del gruppo di dimensionidep
. Consulta la pagina della documentazione relativa al parametrodimension_group
per una panoramica sul funzionamento dei gruppi di dimensioni. - Il filtro Liquido
viene utilizzato per collegare la chiave di incremento alla colonna{% incrementcondition %}
flights.leaving_time
del database.- La proprietà
deve specificare il nome di una colonna{% incrementcondition %}
TIMESTAMP
nel database oppure deve restituire una colonnaTIMESTAMP
nel database. - La classe
deve effettuare una valutazione in base a ciò che è disponibile nella clausola{% incrementcondition %}
FROM
che definisce la PDT, ad esempio le colonne della tabella specificata nella clausolaFROM
. non può fare riferimento al risultato dell'istruzione{% incrementcondition %}
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 clausolaFROM
specifica la tabellaflights
, può fare riferimento alle colonne della tabella{% incrementcondition %}
flights
. deve fare riferimento alla stessa colonna di database utilizzata per la chiave di incremento. In questo esempio la chiave di incremento è{% incrementcondition %}
dep_date
, una dimensione definita dalla colonnadeparture
nel PDT, che è un alias per la colonnaflights.leaving_time
nel database. Di conseguenza, il filtro rimanda aflights.leaving_time
:
- La proprietà
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: