Filtri basati su modelli e parametri Liquid

Si tratta di 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 tutte le esigenze analitiche. I filtri basati su modelli e i parametri Liquid ampliano notevolmente i possibili casi d'uso che puoi supportare.

Dal punto di vista SQL, le dimensioni e le misure possono modificare solo le clausole WHERE o HAVING più esterne della query. Tuttavia, potresti voler consentire agli utenti di manipolare altre parti di SQL. La modifica di una parte di una tabella derivata, la modifica della tabella di database su cui viene eseguita la query o la creazione di dimensioni e filtri multiuso sono solo alcune delle funzionalità che puoi attivare 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, utilizzi un parametro LookML per creare un campo con cui gli utenti possono interagire. Successivamente, utilizzi 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 un modello

Prendi in considerazione una tabella derivata che calcola la spesa totale 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é codificarlo come "nord-est". region non può essere esposto come dimensione, pertanto l'utente non può applicare un filtro in base a questa dimensione come di consueto.

Un'opzione è utilizzare un filtro basato su un modello, 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 passo passo, consulta la sezione Utilizzo di base.

Creare una misura dinamica con un parametro Liquid

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

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

Questa operazione è semplice, ma se ci fossero decine di categorie, sarebbe noioso creare una misura per ciascuna. Inoltre, potrebbe rendere l'esperienza Esplora più caotica per gli utenti.

Un'alternativa potrebbe essere 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 passo passo, 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 dall'utente nella sezione Campi solo con filtri del selettore di 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 di documentazione Parametri campo. Esistono due opzioni che meritano 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 essere racchiusi tra virgolette, come 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 chiamata valori consentiti che ti consente di associare un nome intuitivo 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 modello o il parametro Liquid in base alle tue esigenze.

Filtri basati su modelli

La sintassi dei filtri basati su modelli è la seguente:

{% 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 l'SQL o LookML che deve essere impostato su "uguale" all'input utente (questo argomento viene spiegato in modo più dettagliato più avanti in questa sezione). Se utilizzi LookML, usa la sintassi LookML ${view_name.field_name}.

Nell'esempio precedente, Creazione di una tabella derivata dinamica con un filtro basato su un 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 ha inserito "Nord-est" nel filtro order_region, Looker trasformerà questi tag in:

order.region = 'Northeast'

In altre parole, Looker interpreta l'input utente'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 validi nell'istruzione SQL WHERE. 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 %})

È anche valido 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 dei parametri Liquid è suddivisa come segue:

{% 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 passaggio 1, 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 utilizzando 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 in cui conosci un insieme finito di opzioni che l'utente potrebbe inserire, utilizza i parametri Liquid.