Filtri basati su modelli e parametri Liquid

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 query creando filtri basati su dimensioni e misure. Sebbene questo metodo 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 che puoi supportare.

Dal punto di vista di 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 di SQL. Modificare parte di una tabella derivata, modificare la tabella di database su cui viene eseguita la query o creare dimensioni e filtri multifunzionali sono solo alcune delle funzionalità che puoi attivare con i filtri basati su modelli e i parametri Liquid.

Avviso: la persistenza non è supportata per le tabelle derivate che utilizzano filtri basati su modelli o parametri Liquid.

I filtri basati su modelli e i parametri Liquid utilizzano il linguaggio di creazione di modelli Liquid per inserire l'input utente nelle query SQL. Innanzitutto, utilizza un parametro LookML per creare un campo con cui gli utenti possono interagire. Successivamente, utilizza una variabile Liquid per inserire l'input utente nelle query SQL.

Esempi

Vediamo alcuni esempi per dimostrare il valore dei filtri basati su modelli e dei parametri Liquid.

Creazione di una tabella derivata dinamica con un filtro basato su modello

Considera una tabella derivata che calcola la spesa lifetime di un cliente nella regione nord-est:

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 possa specificare region, anziché impostarlo come "nord-est". region non può essere visualizzato come dimensione e, pertanto, l'utente non può filtrare in base a questo valore come di consueto.

Un'opzione potrebbe essere utilizzare un filtro basato su modello, che avrà 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, consulta la sezione Utilizzo di base.

Nota: se una tabella derivata utilizza un filtro basato su modello, non puoi renderla persistente.

Creare una misura dinamica con un parametro Liquid

Prendi in considerazione una misura filtrata che somma il numero di pantaloni venduti:

measure: pants_count {
  filters: [category: "pants"]
}

È un approccio semplice, ma se ci fossero dozzine di categorie, sarebbe noioso creare una misura per ciascuna. Inoltre, potrebbe complicare l'esperienza di Esplora per gli utenti.

Un'alternativa sarebbe creare una misura dinamica come questa:

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 1: 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 verranno visualizzati all'utente nella sezione Campi solo con filtri del selettore di campi.

Entrambi i campi filter e parameter possono accettare una serie di parametri secondari, che ti consentono di personalizzare il loro funzionamento. Per un elenco completo, consulta la pagina della documentazione relativa ai parametri di campo. Esistono due opzioni che richiedono una menzione speciale 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 che siano racchiusi tra virgolette, come avviene per una stringa. Ciò 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 in base alle tue esigenze.

Filtri basati su modelli

La sintassi dei filtri basati su modelli è suddivisa come segue:

{% condition filter_name %} sql_or_lookml_reference {% endcondition %}

• Le parole condition e endcondition non cambiano mai.
• Sostituisci filter_name con il nome del filtro creato nel primo passaggio. Puoi anche utilizzare una dimensione se non hai creato un campo solo per i filtri.
• Sostituisci sql_or_lookml_reference con il codice SQL o LookML che deve essere impostato su "uguale" all'input dell'utente (questo viene spiegato più dettagliatamente più avanti in questa sezione). Se utilizzi LookML, utilizza la sintassi ${view_name.field_name} LookML.

Nell'esempio precedente, Creazione di una tabella derivata dinamica con un filtro basato su modello, abbiamo utilizzato:

{% condition order_region %} order.region {% endcondition %}

È importante comprendere l'interazione tra i tag Liquid e il codice SQL scritto tra i tag. Questi tag di filtro basati su modelli vengono sempre trasformati in un'espressione logica. Ad esempio, se l'utente inserisce "Nordest" nel filtro order_region, Looker trasforma questi tag nel seguente modo:

order.region = 'Northeast'

In altre parole, Looker interpreta l'input utente'utente e genera l'espressione logica appropriata.

Nota: questo è spesso un punto di confusione tra gli sviluppatori di Looker. I filtri basati su modelli 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 validi nell'istruzione WHERE SQL. Utilizzando l'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 %})

È valido anche utilizzare un campo LookML come condizione di filtro. Tutti i 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 Liquid

La sintassi per i parametri Liquid è la seguente:

{% parameter parameter_name %}

• La parola parameter non cambia mai.
• Sostituisci parameter_name con il nome parameter che hai creato nel primo passaggio.

Ad esempio, per applicare l'input del 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 modelli e parametri Liquid

Sebbene i filtri basati su modelli e i parametri Liquid siano simili, esiste una differenza importante tra loro:

• I parametri Liquid inseriscono direttamente l'input utente (o utilizzano i valori definiti con i valori consentiti).
• I filtri basati su modelli inseriscono i valori come istruzioni logiche, come descritto nella sezione Filtri basati su modelli.

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 modelli, se possibile. Looker può interpretare l'input utente'utente e scrivere il codice SQL appropriato in background. In questo modo non dovrai tenere conto di ogni possibile tipo di input utente.

Nelle situazioni in cui non è possibile inserire un'istruzione logica o quando conosci un insieme finito di opzioni che l'utente potrebbe inserire, utilizza i parametri Liquid.