Il s'agit d'une rubrique avancée qui s'adresse aux utilisateurs qui possèdent une bonne connaissance préexistante de SQL et de LookML.
Looker permet automatiquement aux utilisateurs de manipuler leurs requêtes en créant des filtres basés sur des dimensions et des mesures. Bien que cette méthode réponde à de nombreux cas d'utilisation, elle ne peut pas répondre à tous les besoins analytiques. Les filtres basés sur un modèle et les paramètres Liquid étendent considérablement les possibilités qui s'offrent à vous.
D'un point de vue SQL, les dimensions et les mesures ne peuvent modifier que les clauses WHERE
ou HAVING
les plus externes de votre requête. Vous pouvez néanmoins autoriser les utilisateurs à manipuler d'autres parties d'une requête SQL. Ajuster une partie d'une table dérivée, ajuster la table de base de données interrogée ou créer des dimensions et des filtres polyvalents ne sont que quelques exemples des fonctionnalités que vous pouvez activer avec les filtres basés sur un modèle et les paramètres Liquid.
Les filtres basés sur un modèle et les paramètres Liquid font appel au langage de création de modèles Liquid pour insérer les valeurs saisies par l'utilisateur dans des requêtes SQL. Vous commencez par utiliser un paramètre LookML pour créer un champ avec lequel les utilisateurs peuvent interagir. Ensuite, vous utilisez une variable Liquid pour injecter les entrées utilisateur dans des requêtes SQL.
Examples
Examinons quelques exemples illustrant l'intérêt des filtres basés sur un modèle et des paramètres Liquid.
Création d'une table dérivée dynamique avec un filtre basé sur un modèle
Prenons l'exemple d'une table dérivée qui calcule les dépenses sur la durée de vie d'un client, dans la région 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
;;
}
}
Dans cette requête, vous pouvez créer des dimensions à partir de customer_id
et lifetime_spend
. Cependant, supposons que vous souhaitiez que l'utilisateur puisse spécifier le region
, au lieu de le coder en dur en "northeast". Impossible d'afficher l'élément region
en tant que dimension. L'utilisateur ne peut donc pas l'utiliser comme d'habitude.
L'une des solutions serait d'utiliser un filtre basé sur un modèle, qui ressemblerait à ceci :
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
}
}
Pour obtenir des instructions détaillées, consultez la section Utilisation de base.
Création d'une mesure dynamique avec un paramètre Liquid
Prenons l'exemple d'une mesure filtrée calculant la somme des pantalons (« pants ») vendus :
measure: pants_count {
filters: [category: "pants"]
}
Le principe est simple, mais en présence de dizaines de catégories, il serait fastidieux de créer une mesure pour chacune d'elles. En outre, l'utilisation des explorations n'en serait que plus confuse.
Une autre solution consisterait à créer une mesure dynamique comparable à celle-ci :
measure: category_count {
type: sum
sql:
CASE
WHEN ${category} = '{% parameter category_to_count %}'
THEN 1
ELSE 0
END
;;
}
parameter: category_to_count {
type: string
}
Pour obtenir des instructions détaillées, consultez la section Utilisation de base.
Utilisation de base
Étape 1: Créez un élément avec lequel l'utilisateur pourra interagir
- Pour les filtres basés sur un modèle, ajoutez un élément
filter
. - Pour les paramètres Liquid, ajoutez un
parameter
.
Dans les deux cas, ces champs seront présentés à l'utilisateur dans la section Champs de filtre uniquement du sélecteur de champs.
Les champs filter
et parameter
peuvent tous deux accepter une série de paramètres enfants, ce qui vous permet de personnaliser leur fonctionnement. Consultez la page de documentation Paramètres de champ pour obtenir la liste complète. Les champs parameter
comportent une mention spéciale.
Tout d'abord, les champs parameter
peuvent avoir un type spécial appelé sans guillemets:
parameter: table_name {
type: unquoted
}
Ce type de champ permet d'insérer des valeurs dans une requête SQL sans les mettre entre guillemets — comme c'est le cas des chaînes —, ce qui peut être utile pour insérer des valeurs SQL telles que des noms de tables.
Deuxièmement, les champs parameter
comportent une option appelée valeurs autorisées, qui vous permet d'associer un nom convivial à la valeur que vous souhaitez insérer. Exemple :
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"
}
}
Étape 2: Appliquez l'entrée utilisateur
La deuxième étape consiste à ajouter le filtre basé sur un modèle ou le paramètre Liquid à l'aide de Liquid.
Filtres basés sur un modèle
La syntaxe des filtres basés sur un modèle se décompose de la manière suivante :
{% condition filter_name %} sql_or_lookml_reference {% endcondition %}
- Les mots
condition
etendcondition
ne changent jamais. - Remplacez
filter_name
par le nom du filtre que vous avez créé à la première étape. Si vous n'avez pas créé de champ réservé au filtrage, vous pouvez également utiliser une dimension. - Remplacez
sql_or_lookml_reference
par le code SQL ou LookML qui doit être défini sur "égal". à l'entrée utilisateur (décrit plus en détail dans la suite de cette section). Si vous vous servez de LookML, utilisez la syntaxe LookML${view_name.field_name}
.
Dans l'exemple précédent, Créer une table dérivée dynamique avec un filtre basé sur un modèle, nous avons utilisé les éléments suivants:
{% condition order_region %} order.region {% endcondition %}
Il est important de comprendre l'interaction entre les balises Liquid et le code SQL que vous écrivez entre les balises. Ces balises de filtre modélisées sont toujours transformées en expression logique. Par exemple, si l'utilisateur saisit "Nord-Est" dans le filtre order_region
, Looker transforme ces tags comme suit:
order.region = 'Northeast'
En d'autres termes, Looker interprète l'entrée utilisateur et génère l'expression logique appropriée.
Étant donné que les filtres basés sur un modèle renvoient une expression logique, vous pouvez les utiliser avec d'autres opérateurs logiques et expressions logiques valides dans l'instruction SQL WHERE
. Dans l'exemple précédent, si vous souhaitez renvoyer toutes les valeurs sauf la région sélectionnée par l'utilisateur, vous pouvez utiliser la commande suivante dans l'instruction WHERE
:
NOT ({% condition order_region %} order.region {% endcondition %})
Il est également possible d'utiliser un champ LookML comme condition de filtre. Tous les filtres appliqués directement au champ LookML détermineront la valeur de l'instruction 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 ;;
}
Paramètres Liquid
La syntaxe des paramètres Liquid se décompose de la manière suivante :
{% parameter parameter_name %}
- Le mot
parameter
ne change jamais. - Remplacez
parameter_name
par le nomparameter
que vous avez créé à la première étape.
Par exemple, pour appliquer l'entrée du champ parameter
à l'étape 1, vous pouvez créer une mesure comme celle-ci:
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
}
Choix entre les filtres basés sur un modèle et les paramètres Liquid
Malgré leurs similitudes, les filtres basés sur un modèle et les paramètres Liquid présentent une différence de taille :
- Les paramètres Liquid insèrent directement les entrées utilisateur (ou en utilisant les valeurs que vous définissez avec les valeurs autorisées).
- Les filtres basés sur un modèle insèrent des valeurs sous forme d'instructions logiques, comme décrit dans la section Filtres basés sur un modèle.
Lorsque vous voulez proposer aux utilisateurs un mode de saisie plus souple (différents types de plages de dates ou modes de recherche de chaînes, par exemple), privilégiez si possible les filtres basés sur un modèle. Looker peut interpréter l'entrée utilisateur et écrire le code SQL approprié en arrière-plan, ce qui vous évite de prévoir tous les types d'entrées utilisateur possibles.
Lorsqu'il est impossible d'insérer une instruction logique ou si vous connaissez un ensemble limité d'options que l'utilisateur peut saisir, utilisez les paramètres Liquid.