Si tratta di un argomento avanzato che presuppone una buona conoscenza preesistente di SQL e LookML.
Looker offre automaticamente agli utenti la possibilità di manipolare le query creando filtri basati su dimensioni e misure. Sebbene questo metodo semplice soddisfi molti casi d'uso, non può soddisfare ogni esigenza di analisi. I filtri basati su modelli e i parametri Liquid ampliano notevolmente i possibili casi d'uso supportati.
Dal punto di vista SQL, le dimensioni e le misure possono alterare solo le clausole WHERE
o HAVING
più esterne nella query. Tuttavia, potresti voler consentire agli utenti di manipolare altre parti del codice SQL. Modificare parte di una tabella derivata, modificare la tabella del database su cui viene eseguita la query oppure creare dimensioni e filtri polivalenti sono solo alcune delle funzionalità che puoi attivare con filtri basati su modelli e parametri Liquid.
I filtri basati su modelli e i parametri Liquid utilizzano il linguaggio di creazione dei modelli Liquid per inserire l'input utente nelle query SQL. Innanzitutto, utilizza un parametro LookML per creare un campo con cui gli utenti possano interagire. Quindi, devi utilizzare una variabile Liquid per inserire l'input utente nelle query SQL.
Esempi
Diamo un'occhiata ad alcuni esempi per dimostrare il valore dei filtri basati su modelli e dei parametri Liquid.
Creare una tabella dinamica derivata con un filtro basato su modelli
Considera una tabella derivata che calcola la spesa complessiva di un cliente, all'interno dell'area geografica 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 region
, invece di codificarlo in modo "northeast". region
non può essere esposto come dimensione e pertanto l'utente non può filtrarlo come di consueto.
Un'opzione potrebbe essere l'utilizzo di un filtro basato su modelli, che avrebbe il seguente 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 istruzioni dettagliate, leggi di seguito.
Se una tabella derivata utilizza un filtro basato su modelli, non puoi rendere la tabella permanente.
Misurare in modo dinamico con un parametro Liquid
Considera una misura filtrata che somma il numero di pantaloni venduti:
measure: pants_count {
filters: [category: "pants"]
}
È una scelta semplice, ma se ci fossero decine di categorie, sarebbe difficile creare una misura per ciascuna. L'esperienza Esplora, inoltre, potrebbe condizionare l'esperienza degli utenti.
Un'alternativa consiste nel 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, leggi di seguito.
Utilizzo di base
Passaggio 1: crea un elemento con cui l'utente possa interagire
- Per i filtri basati su modelli, aggiungi una
filter
. - Per i parametri Liquid, aggiungi un
parameter
.
In entrambi i casi, questi campi saranno visibili all'utente nella sezione Campi solo filtro del selettore campi:
Entrambi i campi filter
e parameter
possono accettare una serie di parametri secondari, consentendoti di personalizzarne il funzionamento. Consulta la pagina Parametri del campo per un elenco completo. Esistono due opzioni che contengono menzioni speciali per i campi parameter
.
Innanzitutto, i campi parameter
possono avere un tipo speciale chiamato senza virgolette:
parameter: table_name {
type: unquoted
}
Questo tipo consente di inserire 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 facile da usare 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 consiste nell'utilizzare Liquid per aggiungere il filtro basato su modelli o il parametro Liquid come preferisci.
Filtri basati su modelli
La sintassi per i 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 anche utilizzare una dimensione se non hai creato un campo solo filtro. - Sostituisci
sql_or_lookml_reference
con il codice SQL o LookML che deve essere impostato "equal" (Input predefinito) all'input utente (leggi ulteriori informazioni di seguito). Se utilizzi LookML, utilizza la sintassi${view_name.field_name}
LookML.
Nell'esempio sopra abbiamo utilizzato:
{% condition order_region %} order.region {% endcondition %}
È importante comprendere l'interazione tra i tag Liquid e il codice SQL che scrivi tra di loro. I tag di filtro basati su modello vengono sempre trasformati in un'espressione logica. Ad esempio, se l'utente ha inserito "Nord-est" nel filtro order_region
, Looker imposterà questi tag in: order.region = 'Northeast'
. In altre parole, Looker comprende l'input utente e genera l'espressione logica appropriata.
Questo è spesso un punto di confusione tra gli sviluppatori di Looker. I filtri basati su modello generano sempre un'espressione logica di qualche tipo e non il singolo valore inserito da un utente.
Poiché i filtri basati su modelli restituiscono un'espressione logica, puoi utilizzarli con altri operatori logici ed espressioni logiche valide nell'istruzione WHERE
SQL. Utilizzando l'esempio precedente, se vuoi restituire tutti i valori tranne l'area geografica selezionata dall'utente, puoi utilizzare quanto segue nell'istruzione WHERE
:
NOT ({% condition order_region %} order.region {% endcondition %})
È anche possibile 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 viene 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 nel campo parameter
nel primo passaggio, puoi creare una misura come questa:
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
}
Scelta tra filtri basati su modello e parametri Liquid
Anche se i filtri basati su modelli e i parametri Liquid sono simili, esiste una differenza importante:
- I parametri liquidi consentono di inserire direttamente l'input utente (o di utilizzare i valori da te definiti con i valori consentiti).
- I filtri basati su modelli inseriscono valori come istruzioni logiche, come descritto sopra.
Nelle situazioni in cui vuoi offrire agli utenti un input più flessibile (ad esempio con vari tipi di intervalli di date o ricerche di stringhe), prova a utilizzare i filtri basati su modello quando possibile. Looker può interpretare l'input utente e scrivere il codice SQL appropriato dietro le quinte. Ciò ti evita di dover tenere conto di ogni possibile tipo di input utente.
Nei casi in cui non è possibile inserire un'istruzione logica o si conosce un insieme finito di opzioni che l'utente potrebbe inserire, utilizzare i parametri Liquid.