Questo è un argomento avanzato rivolto agli utenti che hanno una buona conoscenza preesistente di SQL e LookML.
Looker offre automaticamente agli utenti la possibilità di manipolare le proprie query creando filtri, che si basano su dimensioni e misure. Sebbene questo metodo soddisfi molti casi d'uso, non è in grado di soddisfare tutte le esigenze analitiche. I filtri basati su modelli e i parametri Liquid ampliano enormemente i possibili casi d'uso supportati.
Da un punto di vista SQL, le dimensioni e le misure possono modificare solo le clausole WHERE
o HAVING
più esterne nella query. Tuttavia, potresti voler consentire agli utenti di manipolare altre parti dell'SQL. La regolazione di parte di una tabella derivata, la regolazione della tabella di database su cui eseguire query o la creazione di dimensioni e filtri multiuso sono solo alcune delle funzionalità che puoi abilitare con i filtri basati su modelli e i parametri Liquid.
I filtri basati su modelli e i parametri Liquid utilizzano il linguaggio di modelli Liquid per inserire l'input utente nelle query SQL. Innanzitutto, devi utilizzare un parametro LookML per creare un campo con cui gli utenti possono interagire. Quindi, utilizzerai una variabile Liquid per inserire l'input utente nelle query SQL.
Esempi
Esaminiamo alcuni esempi per dimostrare il valore dei filtri basati su modelli e dei parametri Liquid.
Creare una tabella derivata dinamica con un filtro basato su modelli
Prendi in considerazione una tabella derivata che calcola la spesa complessiva di un cliente nella regione nordorientale:
view: customer_facts {
derived_table: {
sql:
SELECT
customer_id, -- Can be made a dimension
SUM(sale_price) AS lifetime_spend -- Can be made a dimension
FROM
order
WHERE
region = 'northeast' -- Can NOT be made a dimension
GROUP BY 1
;;
}
}
In questa query, puoi creare dimensioni da customer_id
e lifetime_spend
. Tuttavia, supponiamo che tu voglia che l'utente sia in grado di specificare il region
, invece di impostare come hardcoded su "northeast". region
non può essere esposto come dimensione e, di conseguenza, l'utente non può applicare un filtro come di consueto.
Un'opzione consiste nell'utilizzare un filtro basato su modelli, che avrebbe questo aspetto:
view: customer_facts {
derived_table: {
sql:
SELECT
customer_id,
SUM(sale_price) AS lifetime_spend
FROM
order
WHERE
{% condition order_region %} order.region {% endcondition %}
GROUP BY 1
;;
}
filter: order_region {
type: string
}
}
Per maggiori informazioni, consulta la sezione Utilizzo di base per istruzioni dettagliate.
Creare una misura dinamica con un parametro Liquid
Considera l'utilizzo di una misura filtrata che somma il numero di pantaloni venduti:
measure: pants_count {
filters: [category: "pants"]
}
Questo è semplice, ma se ci fossero decine di categorie, sarebbe noioso creare una misura per ognuna. Inoltre, potrebbe ingombrare l'esperienza di esplorazione per gli utenti.
In alternativa, puoi creare una misura dinamica come la seguente:
measure: category_count {
type: sum
sql:
CASE
WHEN ${category} = '{% parameter category_to_count %}'
THEN 1
ELSE 0
END
;;
}
parameter: category_to_count {
type: string
}
Per istruzioni dettagliate, consulta la sezione Utilizzo di base.
Utilizzo di base
Passaggio uno: crea qualcosa con cui l'utente possa interagire
- Per i filtri basati su modelli, aggiungi un
filter
. - Per i parametri Liquid, aggiungi un
parameter
.
In entrambi i casi, questi campi saranno visibili all'utente nella sezione Campi solo con filtro del selettore campi.
Entrambi i campi filter
e parameter
possono accettare una serie di parametri secondari, consentendoti di personalizzarne il funzionamento. Per un elenco completo, consulta la pagina della documentazione Parametri dei campi. Esistono due opzioni che richiedono una menzione speciale per i campi parameter
.
Innanzitutto, parameter
campi possono avere un tipo speciale chiamato senza virgolette:
parameter: table_name {
type: unquoted
}
Questo tipo consente di inserire i valori in SQL senza essere racchiusi tra virgolette, come sarebbe una stringa. Questo può essere utile quando devi inserire valori SQL come i nomi delle tabelle.
In secondo luogo, i campi parameter
hanno un'opzione denominata Valori consentiti che ti consente di associare un nome semplice al valore che vuoi inserire. Ad esempio:
parameter: sale_price_metric_picker {
description: "Use with the Sale Price Metric measure"
type: unquoted
allowed_value: {
label: "Total Sale Price"
value: "SUM"
}
allowed_value: {
label: "Average Sale Price"
value: "AVG"
}
allowed_value: {
label: "Maximum Sale Price"
value: "MAX"
}
allowed_value: {
label: "Minimum Sale Price"
value: "MIN"
}
}
Passaggio 2: applica l'input utente
Il secondo passaggio prevede l'utilizzo di Liquid per aggiungere il filtro basato su modello o il parametro Liquid in base alle tue esigenze.
Filtri basati su modelli
La sintassi dei filtri basati su modelli è suddivisa in questo modo:
{% condition filter_name %} sql_or_lookml_reference {% endcondition %}
- Le parole
condition
eendcondition
non cambiano mai. - Sostituisci
filter_name
con il nome del filtro che hai creato nel primo passaggio. Puoi utilizzare una dimensione anche se non hai creato un campo solo filtro. - Sostituisci
sql_or_lookml_reference
con l'SQL o il LookML che deve essere impostato su "uguale" all'input dell'utente (questa procedura viene spiegata in modo più dettagliato più avanti in questa sezione). Se usi LookML, utilizza la sintassi LookML${view_name.field_name}
.
Nell'esempio precedente, Creazione di una tabella derivata dinamica con un filtro basato su modelli, abbiamo utilizzato:
{% condition order_region %} order.region {% endcondition %}
È importante comprendere l'interazione tra i tag Liquid e l'SQL che scrivi tra i tag. Questi tag di filtro basati su modelli vengono sempre trasformati in un'espressione logica. Ad esempio, se l'utente ha inserito "Nord-est" nel filtro order_region
, Looker convertirà questi tag nel seguente modo:
order.region = 'Northeast'
In altre parole, Looker interpreta l'input utente e genera l'espressione logica appropriata.
Poiché i filtri basati su modelli restituiscono un'espressione logica, puoi utilizzarli con altri operatori logici ed espressioni logiche che siano valide nell'istruzione WHERE
di SQL. Nell'esempio precedente, se vuoi restituire tutti i valori tranne la regione selezionata dall'utente, puoi utilizzare quanto segue nell'istruzione WHERE
:
NOT ({% condition order_region %} order.region {% endcondition %})
Inoltre, è valido utilizzare un campo LookML come condizione di filtro. Eventuali filtri applicati direttamente al campo LookML determineranno il valore dell'istruzione WHERE
:
view: customer_facts {
derived_table: {
sql:
SELECT
customer_id,
SUM(sale_price) AS lifetime_spend
FROM
order
WHERE
{% condition region %} order.region {% endcondition %}
GROUP BY 1
;;
}
dimension: region {
type: string
sql: ${TABLE}.region ;;
}
Parametri liquidi
La sintassi per i parametri Liquid è suddivisa in questo modo:
{% parameter parameter_name %}
- La parola
parameter
non cambia mai. - Sostituisci
parameter_name
con il nomeparameter
che hai creato nel primo passaggio.
Ad esempio, per applicare l'input del campo parameter
nel primo passaggio, puoi creare una misura come la seguente:
measure: sale_price_metric {
description: "Use with the Sale Price Metric Picker filter-only field"
type: number
label_from_parameter: sale_price_metric_picker
sql: {% parameter sale_price_metric_picker %}(${sale_price}) ;;
value_format_name: usd
}
Scegliere tra filtri basati su modello e parametri Liquid
Sebbene i filtri basati su modello e i parametri Liquid siano simili, c'è una differenza importante tra loro:
- I parametri liquidi inseriscono direttamente l'input utente (o utilizzano i valori definiti con valori consentiti).
- I filtri basati su modelli inseriscono i valori come istruzioni logiche, come descritto nella sezione Filtri basati su modelli.
Nei casi in cui vuoi offrire agli utenti un input più flessibile (ad esempio con vari tipi di intervalli di date o ricerche per stringa), prova a utilizzare filtri basati su modelli, se possibile. Looker è in grado di interpretare l'input utente e scrivere in background l'SQL appropriato. In questo modo non dovrai tenere conto di ogni possibile tipo di input utente.
Nei casi in cui non è possibile inserire un'istruzione logica o se conosci un insieme limitato di opzioni che l'utente può inserire, utilizza i parametri Liquid.