Questa pagina si riferisce al parametro
explore_source
, un parametro secondario diderived_table
.
explore_source
può anche essere un sottoparametro ditest
, descritto nella pagina della documentazione del parametrotest
.
Utilizzo
Gerarchia
explore_source |
Valore predefinito
NessunaAccetta
L'identificatore della funzionalità Esplora da cui deriva la tabella derivata nativa, più sottoparametri che definiscono la tabella derivata nativa.
|
Definizione
Esistono due modi per creare una tabella derivata, che puoi usare come se fosse una tabella normale nel tuo database: le tabelle derivate native, definite mediante parametri LookML, e le tabelle derivate basate su SQL, che vengono definite utilizzando le istruzioni di query SQL.
Il parametro explore_source
viene utilizzato per le tabelle derivate native. In questo parametro definisci le colonne da includere in una tabella derivata nativa, eventuali filtri da applicare alla tabella derivata nativa, se limitare o ordinare le righe della tabella derivata nativa e se convertire i campi della tabella derivata nativa in un fuso orario diverso.
SUGGERIMENTO: il modo più semplice per creare una tabella nativa nativa è utilizzare la funzione Esplora per creare la query desiderata, quindi selezionare l'opzione Ottieni LookML da Esplora. Looker genererà la tabella LookML derivata per la query, che puoi copiare in un file di vista del tuo progetto LookML. Per informazioni dettagliate, consulta la pagina di documentazione Creazione di tabelle native native.
Definizione di una tabella derivata nativa
In una tabella derivata nativa puoi utilizzare una serie di parametri, molti dei quali facoltativi. Di seguito è riportata la sintassi per definire una tabella nativa derivata, seguita da ulteriori informazioni su ciascun parametro.
explore_source: identifier {
bind_all_filters: yes
column: identifier {
field: field_name
}
derived_column: identifier {
sql: SQL expression ;;
}
expression_custom_filter: [custom filter expression]
filters: [field_name_1: "string", field_name_2: "string", ...]
limit: number{
sorts: [field_name_1: asc | desc, field_name_2: asc | desc, ...]
timezone: "string"
}
Dove:
Nome parametro | Descrizione | Esempio |
---|---|---|
bind_filters |
Passa un filtro dalla query Esplora alla sottoquery della tabella derivata nativa. Per configurarlo, utilizza il sottoparametro from_field per specificare un campo definito nella visualizzazione della tabella derivata nativa o accessibile in Esplora a cui viene unita la tabella derivata nativa. In fase di esecuzione, tutti i filtri di from_field in Esplora verranno trasferiti in to_field nella sottoquery di tabella derivata nativa. Per un esempio, consulta questa sezione.
Con bind_filters , tieni presente quanto segue:
• Il filtro di runtime deve essere in una vista che si unisce alla stessa esplorazione della tabella derivata nativa. • La tabella derivata nativa non può essere trasformata in una tabella derivata permanente (PDT). • Il parametro explore_source può avere il sottoparametro bind_all_filters o il sottoparametro bind_filters , ma non entrambi.
|
bind_filters: { |
bind_all_filters |
Passa tutti i filtri dalla query Esplora alla sottoquery della tabella derivata nativa. Per configurare questa opzione, specifica bind_all_filters: yes nella explore_source della tabella derivata nativa. Per un esempio, consulta questa sezione.
Con bind_all_filters: yes , tieni presente quanto segue:
• Il filtro di runtime deve essere in una vista che si unisce alla stessa esplorazione della tabella derivata nativa. • La tabella derivata nativa non può essere trasformata in una PDT. • La tabella derivata nativa può essere unita solo all'Explore specificato nel parametro explore_source della tabella derivata nativa. Questo perché bind_all_filters deve mappare i campi filtrati di Explore (Esplora) ai campi nella tabella nativa derivata.
• Il parametro explore_source può avere il sottoparametro bind_all_filters o il sottoparametro bind_filters , ma non entrambi.
|
bind_all_filters: yes
|
column |
Specifica una colonna da includere in explore_source . Ha un sottoparametro field . |
column: cust_id { |
derived_column |
Specifica una colonna in explore_source con un'espressione nello spazio dei nomi delle colonne interne. Le espressioni SQL aggregate non funzioneranno qui, poiché non è presente alcun raggruppamento SQL in questo passaggio. Le funzioni delle finestre SQL possono essere molto utili in questo parametro. Ha un sottoparametro sql . |
derived_column: average_order { |
dev_filters |
AGGIUNTO 21.12
Specifica i filtri che Looker applica solo alle versioni di sviluppo della tabella derivata. Ciò è utile per gli sviluppatori LookML quando testano tabelle derivate in modalità di sviluppo. Il parametro dev_filters consente a Looker di creare versioni più piccole e filtrate della tabella, in modo che uno sviluppatore LookML possa eseguire l'iterazione e testare la tabella senza dover attendere la creazione della tabella completa dopo ogni modifica. Looker applica dev_filters solo alle versioni di sviluppo della tabella derivata, non alla versione di produzione della tabella su cui viene eseguita la query degli utenti. Consulta la pagina della documentazione Tabelle derivate in Looker per ulteriori informazioni sull'utilizzo delle tabelle derivate in modalità di sviluppo e la sezione Creazione di filtri per la modalità di sviluppo in questa pagina per un esempio. |
dev_filters: [orders.created_date: "90 days", orders.products: "sweaters"] |
expression_custom_filter |
Facoltativamente, puoi specificare un'espressione di filtro personalizzata in una query explore_source . |
expression_custom_filter: |
filters |
Se vuoi, aggiunge un filtro a una query di explore_source . Racchiudi tra parentesi quadre il nome del campo da filtrare, utilizzando il formato view_name.field_name , seguito dal nome : e dai valori in base ai quali il campo deve essere filtrato. I filtri vengono aggiunti alla clausola WHERE dell'SQL generato dalla tabella derivata nativa. |
filters: [products.department: "sweaters"] |
limit |
Facoltativamente, specifica il limite di righe della query. | limit: 10
|
sorts |
Facoltativamente, specifica un ordinamento per questo explore_source . Racchiudi tra parentesi quadre il nome del campo da ordinare, utilizzando il formato view_name.field_name , seguito da : e asc o desc per indicare se il campo deve essere in ordine crescente o decrescente. Puoi ordinare i dati in più campi aggiungendo più coppie di nomi di campo e parole chiave separate da virgole. |
sorts: [products.brand: asc, products.name: asc] |
timezone |
Imposta il fuso orario per la query explore_source . Per le tabelle derivate non persistenti, imposta il fuso orario su "query_timezone" per utilizzare automaticamente il fuso orario della query in esecuzione. Se il fuso orario non è specificato, la query explore_source non eseguirà la conversione del fuso orario, bensì utilizzerà il fuso orario del database. Consulta la pagina dei valori timezone per un elenco dei fusi orari supportati.L'IDE suggerisce automaticamente il valore del fuso orario quando digiti il parametro timezone nell'IDE. L'IDE mostra anche l'elenco dei valori di fuso orario supportati nel riquadro della Guida rapida. |
timezone: "America/Los_Angeles" |
Esempi
Le seguenti definizioni forniscono esempi di base di tabelle derivate native.
Crea una tabella nativa derivata da user_order_facts
:
view: user_order_facts {
derived_table: {
explore_source: order_items {
column: user_id {
field: order_items.user_id
}
column: lifetime_number_of_orders {
field: order_items.order_count
}
column: lifetime_customer_value {
field: order_items.total_revenue
}
}
}
# Define the view's fields as desired
dimension: user_id {
hidden: yes
}
dimension: lifetime_number_of_orders {
type: number
}
dimension: lifetime_customer_value {
type: number
}
}
Puoi aggiungere filtri per creare una tabella derivata nativa user_90_day_facts
:
view: user_90_day_facts {
derived_table: {
explore_source: order_items {
column: user_id {
field: order_items.user_id
}
column: number_of_orders_90_day {
field: order_items.order_count
}
column: customer_value_90_day {
field: order_items.total_revenue
}
filters: [order_items.created_date: "90 days"]
}
}
# Add define view's fields as desired
dimension: user_id {
hidden: yes
}
dimension: number_of_orders_90_day {
type: number
}
dimension: customer_value_90_day {
type: number
}
}
Creare filtri per la modalità di sviluppo
A volte, la generazione della tabella derivata nativa che crei richiede molto tempo, il che può richiedere molto tempo se esegui il test di molte modifiche nella modalità di sviluppo. In questi casi, puoi utilizzare dev_filters
per creare versioni di sviluppo più piccole di una tabella derivata nativa:
view: e_faa_pdt {
derived_table: {
...
datagroup_trigger: e_faa../_shared_datagroup
explore_source: flights {
dev_filters: [flights.event_date: "90 days"]
filters: [flights.event_date: "2 years", flights.airport_name: "Yucca Valley Airport"]
column: id {}
column: airport_name {}
column: event_date {}
}
}
...
}
Questo esempio include un parametro dev_filters
che filtra i dati in base agli ultimi 90 giorni e un parametro filters
che filtra i dati in base agli ultimi 2 anni e in base all'aeroporto di Yucca Valley. Il parametro dev_filters
agisce in combinazione con il parametro filters
in modo che tutti i filtri vengano applicati alla versione di sviluppo della tabella. Se dev_filters
e filters
specificano filtri per la stessa colonna, dev_filters
ha la precedenza per la versione di sviluppo della tabella. In questo esempio, la versione di sviluppo della tabella filtra i dati relativi agli ultimi 90 giorni per l'Aeroporto di Yucca Valley.
Se la tabella nativa derivata ha il parametro
dev_filters
, la tabella di sviluppo non può essere utilizzata come versione di produzione, poiché la versione di sviluppo ha un set di dati abbreviato. In questo caso, dopo aver completato lo sviluppo della tabella e prima di eseguire il deployment delle modifiche, puoi commentare il parametrodev_filters
e poi eseguire una query sulla tabella in modalità di sviluppo. Looker creerà quindi una versione completa della tabella che può essere utilizzata per la produzione quando esegui il deployment delle modifiche. Per ulteriori dettagli sull'utilizzo delle tabelle di sviluppo in produzione, consulta la pagina della documentazione Tabelle derivate in Looker.
Tieni presente che la situazione opposta è vera: se hai una tabella nativa derivata con il parametrodev_filters
e ne esegui una in modalità di sviluppo, Looker può utilizzare la tabella di produzione per rispondere alla query in modalità di sviluppo. Ciò è vero, a meno che non modifichi la definizione della tabella e poi la query in modalità Development (Sviluppo). A quel punto, Looker creerà una tabella di sviluppo per rispondere alla query.
Trasferire i filtri in una tabella derivata nativa
Quando includi una tabella derivata nativa in un'esplorazione, puoi utilizzare i filtri di runtime di Esplora e applicarli alla query della tabella derivata nativa. A tale scopo, aggiungi il parametro bind_all_filters
o bind_filters
a explore_source
della tabella derivata nativa.
Quando trasmetti i filtri di runtime da Esplora a una sottoquery di tabella derivata nativa, il filtro di runtime deve essere in una vista che si unisce alla stessa esplorazione della tabella derivata nativa. Inoltre, poiché la tabella nativa nativa deve essere rigenerata in fase di esecuzione per incorporare i filtri di runtime da Esplora, la tabella derivata nativa non può essere una tabella derivata permanente (PDT).
Uso: bind_all_filters
Il modo più semplice per passare i filtri da una sottoesplorazione a una tabella derivata nativa è specificare bind_all_filters: yes
nel parametro explore_source
della tabella derivata nativa. In questo modo, passerai tutti i filtri di runtime di Explore alla sottoquery della tabella derivata nativa.
Una tabella derivata nativa con bind_all_filters: yes
deve essere inclusa nella stessa esplorazione specificata nel parametro explore_source
della tabella derivata nativa. Se vuoi utilizzare la tabella derivata nativa in un'altra funzione Esplora, utilizza il parametro bind_filters
, come descritto in questa sezione.
Ecco il LookML di una tabella nativa derivata con bind_all_filters: yes
:
view: top_10_simple_item_names {
view_label: "Top 10s"
derived_table: {
explore_source: order_items {
column: total_sale_price {
field: order_items.total_sale_price
}
column: item_name {
field: products.item_name
}
derived_column: rank {
sql: RANK() OVER (ORDER BY total_sale_price DESC) ;;
}
bind_all_filters: yes
sorts: [order_items.total_sale_price: desc]
timezone: "query_timezone"
limit: 10
}
}
dimension: item_name {
group_label: "Simple Example"
}
dimension: rank {
type: number
group_label: "Simple Example"
}
dimension: item_name_ranked {
group_label: "Simple Example"
order_by_field: rank
type: string
sql: ${rank} || ') ' || ${item_name} ;;
}
}
Nella visualizzazione della tabella derivata nativa sopra, explore_source
è order_items
. Ecco il LookML per l'esplorazione order_items
in cui la tabella nativa derivata viene unita all'esplorazione:
explore: order_items {
...
join: top_10_simple_item_names {
type: inner
relationship: many_to_one
sql_on: ${products.item_name} = ${top_10_simple_item_names.item_name} ;;
}
}
Per vedere questo esempio in azione, consulta l'articolo della community [Analytic Block] – Pivot by Top X – Presentazione bind_all_filters: yes
.
Uso: bind_filters
Il sottoparametro bind_filters
di explore_source
trasmette un filtro specifico dalla query Esplora alla sottoquery della tabella derivata nativa:
to_field
è il campo nella tabella nativa derivata a cui viene applicato il filtro.to_field
deve essere un campo dell'elementoexplore_source
sottostante.from_field
specifica il campo in Esplora da cui ottenere il filtro, se l'utente specifica un filtro in fase di esecuzione.
In fase di esecuzione, tutti i filtri di from_field
in Esplora verranno trasferiti in to_field
nella sottoquery di tabella derivata nativa.
La tabella LookML seguente mostra una tabella derivata nativa con bind_filters
. Con questa configurazione, Looker prenderà qualsiasi filtro applicato al campo filtered_lookml_dt.filter_date
in Explore (Esplora) e lo applicherà al campo users.created_date
nella tabella nativa derivata.
derived_table: {
explore_source: order_items {
bind_filters: {
to_field: users.created_date
from_field: filtered_lookml_dt.filter_date
. . .
}
}
}
Aspetti da considerare
Utilizza un solo parametro explore_source
Ogni tabella derivata nativa accetta un solo parametro explore_source
. I parametri explore_source
successivi non comporteranno errori di convalida di LookML, ma sostituiranno i parametri explore_source
precedenti.
Per creare colonne dai campi in visualizzazioni diverse, devi prima unire le diverse visualizzazioni nella stessa esplorazione. Utilizza quindi Esplora per explore_source
.
Utilizza le istruzioni include
per abilitare i campi di riferimento
Quando crei una tabella nativa derivata, devi includere il file contenente la definizione di Esplora. Il modo migliore per farlo è definire l'esplorazione in un file Esplora separato, come descritto nella documentazione Creazione di file di esplorazione.
Se crei un file Esplora separato:
- Il file di visualizzazione della tabella derivata nativa deve includere il file di Explore. Ad esempio:
include: "/explores/order_items.explore.lkml"
- Il file Esplora deve includere i file di visualizzazione necessari. Ad esempio:
include: "/views/order_items.view.lkml"
include: "/views/users.view.lkml"
- Il modello deve includere il file di Explore. Ad esempio:
include: "/explores/order_items.explore.lkml"