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 proprie query creando filtri, che si basano su dimensioni e misure. Sebbene questo 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 enormemente i possibili casi d'uso supportati.

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 modelli Liquid per inserire l'input utente nelle query SQL. Innanzitutto, devi utilizzare 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

Esaminiamo 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 nella regione 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 il region, invece di impostare come hardcoded su "northeast". region non può essere esposto come dimensione e, di conseguenza, l'utente non può applicare un filtro come di consueto.

Un'opzione consiste nell'utilizzare un filtro basato su modelli, che avrebbe questo 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 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

Considera l'utilizzo di 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 ingombrare l'esperienza di esplorazione 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 uno: 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 saranno visibili all'utente nella sezione Campi solo con 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 Parametri dei campi. 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. 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 semplice 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 prevede l'utilizzo di 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 è 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 l'SQL o il LookML che deve essere impostato su "uguale" all'input utente (questa procedura viene spiegata in modo più dettagliato più avanti in questa sezione). Se usi LookML, utilizza 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 %}

È 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 convertirà questi tag nel seguente modo:

order.region = 'Northeast'

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

Nota: spesso questo è un motivo 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. Nell'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 %})

Inoltre, è valido 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 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
  }

Scegliere tra filtri basati su modello e parametri Liquid

Sebbene i filtri basati su modello e i parametri Liquid siano simili, c'è una differenza importante tra loro:

• I parametri liquidi inseriscono direttamente l'input utente (o utilizzano i valori definiti con 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 è in grado di interpretare l'input utente'utente e scrivere in background l'SQL appropriato. In questo modo non dovrai tenere conto di ogni possibile tipo di input utente.

Nei casi in cui non è possibile inserire un'istruzione logica o se conosci un insieme limitato di opzioni che l'utente può inserire, utilizza i parametri Liquid.