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.

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.

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, utilizzi 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

Vediamo 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

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". L'elemento region non può essere esposto come dimensione, pertanto l'utente non può applicare un filtro come di consueto.

Un'opzione potrebbe essere quella di utilizzare un filtro basato su modelli, simile al seguente:

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.

Nota: se una tabella derivata utilizza un filtro basato su modelli, non puoi rendere la tabella permanente.

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"]
}

Questo è semplice, ma se ci fossero decine di categorie, sarebbe noioso creare una misura per ognuna. Inoltre, potrebbe complicare l'esperienza di Esplora 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 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 Parametri campo. 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. 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 dell'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 in questo modo:

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

• Le parole condition e endcondition 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 il codice SQL o LookML che deve essere impostato su "uguale" all'input dell'utente (questo aspetto viene spiegato più dettagliatamente più avanti in questa sezione). Se utilizzi LookML, utilizza la ${view_name.field_name} sintassi di 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 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 inserisce "Nordest" nel filtro order_region, Looker trasforma questi tag nel seguente modo:

order.region = 'Northeast'

In altre parole, Looker interpreta l'input dell'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 che siano valide nell'istruzione WHERE di 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. 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 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
  }

Scegliere tra filtri basati su modello 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 dell'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.

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 può interpretare l'input dell'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.