Filtri basati su modelli e parametri Liquid

Si tratta di un argomento avanzato che presuppone una buona conoscenza pregressa di SQL e LookML.

Looker fornisce automaticamente agli utenti la possibilità di manipolare le loro query creando filtri basati su dimensioni e misure. Sebbene questo semplice 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 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 nella tua query. Tuttavia, potresti voler consentire agli utenti di modificare altre parti dell'SQL. La modifica di parte di una tabella derivata, la regolazione della tabella di database su cui viene eseguita la query o la creazione di dimensioni e filtri multifunzionali 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 per i 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, utilizzerai 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 derivata dinamica con un filtro basato su modelli

Prendi in considerazione una tabella derivata che calcola la spesa complessiva di un cliente all'interno della regione del 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, supponi di volere che l'utente fosse in grado di specificare il region, invece di impostarlo come hardcoded in "northeast". region non può essere esposto come dimensione, pertanto l'utente non può filtrarlo come di consueto.

Un'opzione potrebbe essere utilizzare 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.

Effettuare una misura dinamica con un parametro Liquid

Considera una misura filtrata che somma il numero di pantaloni venduti:

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

Questo è semplice, ma se fossero disponibili decine di categorie, sarebbe noioso creare una misura per ciascuna di esse. Inoltre, ciò potrebbe rendere complicato l'esperienza di esplorazione degli utenti.

Un'alternativa è 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 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 vengono mostrati all'utente nella sezione Campi solo in modalità 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 sui parametri di 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 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 dispongono di un'opzione chiamata 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 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 che hai creato nel primo passaggio. Puoi utilizzare una dimensione anche se non hai creato un campo con solo filtri.
  • Sostituisci sql_or_lookml_reference con il codice SQL o LookML che dovrebbe essere impostato su "uguale" all'input utente (ulteriori dettagli di seguito). 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 modelli, abbiamo utilizzato:

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

L'interazione tra i tag Liquid e il codice SQL che scrivi è importante da capire. I 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 in order.region = 'Northeast'. In altre parole, Looker comprende l'input utente'utente e genera l'espressione logica appropriata.

Spesso questo crea 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 SQL WHERE. Utilizzando l'esempio precedente, se vuoi restituire tutti i valori eccetto 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 del filtro. Qualsiasi filtro applicato direttamente al campo LookML determinerà 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 come segue:

{% parameter parameter_name %}
  • La parola parameter non cambia mai.
  • Sostituisci parameter_name con il nome parameter che hai creato al 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
  }

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 i due:

  • I parametri liquidi inseriscono l'input utente direttamente (oppure utilizzando i valori che definisci 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 di stringhe), prova a utilizzare i filtri basati su modelli, se possibile. Looker è in grado di interpretare l'input utente e scrivere l'SQL appropriato dietro le quinte. In questo modo eviterai di dover tenere conto di ogni possibile tipo di input utente.

Se non è possibile inserire un'istruzione logica o se conosci un insieme limitato di opzioni che l'utente potrebbe inserire, utilizza i parametri Liquid.