Filtri basati su modelli e parametri Liquid

Si tratta di un argomento avanzato che presuppone 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 semplice 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 supportati.

Dal punto di vista SQL, le dimensioni e le misure possono alterare solo le clausole WHERE o HAVING più esterne nella query. Tuttavia, potresti voler consentire agli utenti di manipolare altre parti del codice SQL. Modificare parte di una tabella derivata, modificare la tabella del database su cui viene eseguita la query oppure creare dimensioni e filtri polivalenti sono solo alcune delle funzionalità che puoi attivare con filtri basati su modelli e parametri Liquid.

I filtri basati su modelli e i parametri Liquid utilizzano il linguaggio di creazione dei modelli Liquid per inserire l'input utente nelle query SQL. Innanzitutto, utilizza un parametro LookML per creare un campo con cui gli utenti possano interagire. Quindi, devi utilizzare 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 dinamica derivata con un filtro basato su modelli

Considera una tabella derivata che calcola la spesa complessiva di un cliente, all'interno dell'area geografica 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 region, invece di codificarlo in modo "northeast". region non può essere esposto come dimensione e pertanto l'utente non può filtrarlo come di consueto.

Un'opzione potrebbe essere l'utilizzo di 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.

Misurare in modo dinamico con un parametro Liquid

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

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

È una scelta semplice, ma se ci fossero decine di categorie, sarebbe difficile creare una misura per ciascuna. L'esperienza Esplora, inoltre, potrebbe condizionare l'esperienza degli utenti.

Un'alternativa consiste nel 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 un elemento con cui l'utente possa interagire

• Per i filtri basati su modelli, aggiungi una filter.
• Per i parametri Liquid, aggiungi un parameter.

In entrambi i casi, questi campi saranno visibili all'utente nella sezione Campi solo filtro del selettore campi:

Entrambi i campi filter e parameter possono accettare una serie di parametri secondari, consentendoti di personalizzarne il funzionamento. Consulta la pagina Parametri del campo per un elenco completo. Esistono due opzioni che contengono menzioni speciali 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 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 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 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 anche utilizzare una dimensione se non hai creato un campo solo filtro.
• Sostituisci sql_or_lookml_reference con il codice SQL o LookML che deve essere impostato "equal" (Input predefinito) all'input utente (leggi ulteriori informazioni di seguito). Se utilizzi LookML, utilizza la sintassi ${view_name.field_name} LookML.

Nell'esempio sopra abbiamo utilizzato:

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

È importante comprendere l'interazione tra i tag Liquid e il codice SQL che scrivi tra di loro. I tag di filtro basati su modello vengono sempre trasformati in un'espressione logica. Ad esempio, se l'utente ha inserito "Nord-est" nel filtro order_region, Looker imposterà questi tag in: order.region = 'Northeast'. In altre parole, Looker comprende l'input utente e genera l'espressione logica appropriata.

Questo è spesso un punto di confusione tra gli sviluppatori di Looker. I filtri basati su modello 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 valide nell'istruzione WHERE SQL. Utilizzando l'esempio precedente, se vuoi restituire tutti i valori tranne l'area geografica selezionata dall'utente, puoi utilizzare quanto segue nell'istruzione WHERE:

NOT ({% condition order_region %} order.region {% endcondition %})

È anche possibile 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 viene 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 nel 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 modello e parametri Liquid

Anche se i filtri basati su modelli e i parametri Liquid sono simili, esiste una differenza importante:

• I parametri liquidi consentono di inserire direttamente l'input utente (o di utilizzare i valori da te definiti con i valori consentiti).
• I filtri basati su modelli inseriscono valori come istruzioni logiche, come descritto sopra.

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 modello quando possibile. Looker può interpretare l'input utente e scrivere il codice SQL appropriato dietro le quinte. Ciò ti evita di dover tenere conto di ogni possibile tipo di input utente.

Nei casi in cui non è possibile inserire un'istruzione logica o si conosce un insieme finito di opzioni che l'utente potrebbe inserire, utilizzare i parametri Liquid.