Cette page aborde d'autres concepts LookML courants.
Attribution de libellés à des champs (et noms de l'interface utilisateur)
Looker convertit les noms de champs LookML en chaînes affichées dans l'UI en combinant le nom de la vue en police standard avec le nom court du champ en gras. Par exemple, un champ intitulé Montant dans la vue Commandes apparaît dans l'interface utilisateur sous la forme Montant des commandes. Sur cette page, ils sont mis en gras et le nom de la vue est en majuscule (Montant de COMMANDES) pour clarifier la discussion.
Si vous souhaitez qu'un champ soit nommé différemment de son nom de colonne dans une table, modifiez simplement le nom du champ et déclarez son association sql:. L'exemple ci-dessous présente une table airports avec une colonne cntrl_twr. Looker générerait la déclaration suivante :
view: airports {
dimension: cntrl_twr { # full name: airports.cntrl_twr
type: yesno # default name: AIRPORT Cntrl Twr (Yes/No)
sql: ${TABLE}.cntrl_twr ;; # the sql expression for this field
}
}
Nous allons renommer la dimension cntrl_twr pour qu'elle soit plus lisible.
view: airports {
dimension: has_control_tower { # full name: airports.has_control_tower
type: yesno # aliased name: AIRPORTS Has Control Tower (Yes/No)
sql: ${TABLE}.cntrl_twr ;; # the sql expression for this field
}
}
Filtrage de décomptes par dimension
Il est assez simple de regrouper les données par dimension et par entité. Si vous utilisez le regroupement par UTILISATEURS par pays, la colonne Nombre de COMMANDES vous indique l'origine de vos commandes par pays. Toutefois, il est souvent utile d'établir un décompte filtré par une valeur dimensionnelle. Par exemple, vous pouvez effectuer une nouvelle mesure ORDERS France Count (Nombre de COMMANDES en France) :
view: users {
dimension: country {}
}
view: orders {
dimension: id {
primary_key: yes
sql: ${TABLE}.id ;;
}
measure: count {
type: count
drill_fields: [detail]
}
measure: france_count {
type: count # COUNT(CASE WHEN users.country = 'France' THEN 1 ELSE NULL END)
filters: [users.country: "France"]
}
}
Les filtres peuvent utiliser n'importe quelle expression. Si vous vouliez un champ établissant le décompte des utilisateurs de l'UE, vous pourriez utiliser une commande de ce type :
measure: eu_count {
type: count # COUNT(CASE WHEN users.countrycode IN 'UK','FR','ES' THEN 1 ELSE NULL END)
drill_fields: [detail]
filters: [users.countrycode: "UK,FR,ES"]
}
Si vous souhaitez filtrer avec une expression mathématique, veillez à la placer entre guillemets doubles:
measure: total_orders_above_100_dollars {
type: sum # SUM(CASE WHEN order.value > 100 THEN order.value ELSE NULL END)
sql: ${order.value} ;;
drill_fields: [detail]
filters: [order.value: ">100"]
}
Pourcentages
De nombreux indicateurs clés de performance sont exprimés sous forme de pourcentages, tels que le pourcentage d'éléments renvoyés, le pourcentage d'e-mails ayant abouti à une vente ou d'autres instances de pourcentage de l'axe Y. Dans LookML, le modèle de conception consiste à établir un décompte des deux conditions et à créer un troisième champ pour calculer le pourcentage des deux.
dimension: returned {
type: yesno
}
measure: count { # total count of items
type: count_distinct
sql: ${TABLE}.id ;;
drill_fields: [detail]
}
measure: returned_count { # count of returned items
type: count_distinct
sql: ${TABLE}.id ;;
drill_fields: [detail]
filters: [returned: "Yes"]
}
measure: percent_returned {
type: number
sql: 100.0 * ${returned_count} / NULLIF(${count}, 0) ;;
value_format: "0.00"
}
pour calculer des pourcentages, utilisez le format ci-dessous. Dans Postgres, les décomptes sont des entiers et la division d'entiers produit des entiers. Une multiplication par 100,0 convertit le premier décompte en nombre à virgule flottante, et la suite de l'expression est par conséquent convertie en nombre flottant. Pour éviter les erreurs de division par zéro, NULLIF(value, 0) convertit une valeur nulle en null, ce qui rend le résultat null et évite une erreur.
100.0 * ${returned_count} / NULLIF(${count}, 0)
Utilisation d'ensembles pour procéder à une exploration détaillée
L'une des fonctionnalités les plus puissantes de Looker consiste à pouvoir détailler des données pour visualiser les entités sous-jacentes qui composent un décompte ou une autre mesure.
Lorsque l'utilisateur clique sur une mesure dans l'interface Looker, une nouvelle requête est créée en localisant le jeu de données qui compose la mesure. Chaque valeur de chaque dimension de la ligne de la table s'ajoute aux filtres actifs.
Pour afficher les détails, Looker a besoin d'une liste spécifiée de champs d'affichage à afficher lorsque l'utilisateur clique sur la valeur de la mesure. Lorsque vous générez un modèle, le générateur crée généralement des champs d'aperçu initiaux. auxquels vous pouvez ajouter les vôtres. Par exemple, supposons que nous mesurions le nombre de commandes par état des utilisateurs au cours de la semaine passée. Dans Looker, la requête se présenterait comme suit :
| USERS State | ORDERS Count |
|---|---|
| Californie | 24 |
| Texas | 5 |
| Colorado | 4 |
| Floride | 4 |
| Illinois | 4 |
Si nous cliquons sur 24 à la ligne California (Zone californienne), les internautes s'attendaient à voir les 24 commandes provenant de la Californie.
Looker gère l'ajout du filtre État des utilisateurs: Californie, mais Looker ne sait pas quels champs vous souhaitez afficher dans l'ordre. Vous devez utiliser un ensemble pour déclarer ces champs dans votre modèle.
Dans LookML, un ensemble est une liste de noms de champs (dimensions, mesure et filtre). Les ensembles permettent d'indiquer à Looker les champs :
- que vous souhaitez afficher lors de l'exploration détaillée d'un décompte ou d'une autre mesure ;
- à importer lors de la jointure d'une vue ;
- indexés dans une exploration.
Le même ensemble peut être utilisé à plusieurs endroits d'un modèle, de sorte que Looker offre différents moyens de créer des ensembles.
Ensembles littéraux
La forme d'ensemble la plus simple est l'ensemble littéral, créé en déclarant simplement l'ensemble en tant que tableau. Vous pouvez déclarer des ensembles de valeurs littérales à l'aide de '[]'.
Prenons l'exemple suivant :
view: customers {
dimension: id {
primary_key: yes
}
measure: count {
type: count
}
dimension: city {}
dimension: state {}
dimension: name {}
}
Les champs que nous souhaitons afficher sont id, name et city.
Dans la mesure, nous pourrions nous contenter de déclarer un tableau littéral.
measure: count {
type: count
drill_fields: [id, name, city]
}
Pour les ensembles qui ne sont utilisés qu'une seule fois, la déclaration littérale est simple et facile à comprendre.
Ensembles nommés
Supposons que nous ayons deux types de comptes: CUSTOMERS Count (Nombre de clients) et CUSTOMERS In California Count (Nombre de clients en Californie). Lorsque vous examinez en détail l'un de ces nombres, nous souhaitons afficher les champs id, name et city. Si nous déclarions littéralement les champs, nous pourrions écrire ceci :
view: customers {
measure: count {
type: count
drill_fields: [id, name, city]
}
measure: in_california_count {
type: count
filters: [state: "California"]
}
}
Si vous souhaitez ajouter un champ (par exemple, le champ customers.state), vous devez modifier les deux listes. À la place, LookML propose un moyen de créer des ensembles nommés, pouvant être gérés au même endroit et utilisés à plusieurs endroits.
Le code suivant crée un customers.detail défini et pointe les deux dans le même ensemble de champs.
view: customers {
set: detail {
fields: [id, name, city] # creates named set customers.detail
}
measure: count {
type: count
drill_fields: [detail*] # show fields in the set "customers.detail"
}
measure: in_california_count {
type: count
filters: [state: "California"]
}
}
Les ensembles LookML sont relativement puissants :
- La redondance des ensembles est complémentaire : si vous déclarez un ensemble à plusieurs endroits, Looker inclut tous les champs déclarés pour l'ensemble dans tous les emplacements.
- Vous pouvez intégrer des ensembles dans d'autres ensembles en saisissant l'autre nom, suivi d'un astérisque, comme
setname*. - Vous pouvez même supprimer des éléments des ensembles en insérant un trait d'union devant le nom du champ, par exemple
-fieldname.
Lire la documentation de référence complète
Personnalisation d'une visualisation détaillée
Si votre administrateur Looker a activé la fonctionnalité expérimentale Perçage visuel, les visualisations d'exercices ne sont pas toujours définies par défaut dans un tableau de données. Dans ce cas, vous pouvez personnaliser la visualisation qui s'affiche à l'aide de variables Liquid dans le paramètre link, comme indiqué sur la page de documentation sur le paramètre link et dans l'article du centre d'aide Plus puissant.
Le nouveau tableau de bord est compatible avec l'affichage visuel à l'aide du paramètre link sans qu'il soit nécessaire d'activer la fonctionnalité Ateliers de perçage visuel.
Filtrage de jeux de résultats
LookML propose différentes opérations de filtrage applicables aux champs et aux explorations pour filtrer les jeux de résultats avant qu'ils soient renvoyés à l'utilisateur.
always_filter sur la page "Explorer"
Utilisez always_filter pour appliquer systématiquement un ensemble de filtres à toute requête exécutée dans une exploration. Les filtres apparaissent alors dans l'interface Looker, et même si les utilisateurs peuvent en modifier la valeur par défaut, ils ne peuvent pas les retirer. En règle générale, ces filtres sont utilisés pour supprimer les données que vous ne souhaitez généralement pas inclure. Par exemple, supposons que, dans l'onglet Explorer, vous souhaitiez uniquement afficher les commandes terminées ou en attente. Nous pourrions ajouter :
explore: orders {
view_name: order
filters: [status: "complete,pending"]
}
}
Si l'utilisateur souhaite afficher les commandes avec d'autres valeurs d'état, il peut définir ORDERS Status sur % dans l'interface utilisateur.
sql_always_where sur la page"Explorer"
Si vous souhaitez appliquer une restriction de requête que les utilisateurs ne peuvent pas modifier, vous pouvez utiliser sql_always_where. Outre les requêtes exécutées par les humains, la restriction s'applique alors aux tableaux de bord, aux présentations planifiées et aux informations incorporées liées à cette exploration. Une condition sql_always_where n'est pas présentée à l'utilisateur, sauf s'il consulte le code SQL sous-jacent des requêtes qu'il crée.
L'exemple qui suit empêche les utilisateurs de visualiser les commandes antérieures au 2012-01-01 :
# Using Looker references
explore: order {
sql_always_where: ${created_date} >= '2012-01-01' ;;
}
# Using raw SQL
explore: order {
sql_always_where: DATE(created_time) >= '2012-01-01' ;;
}
conditionally_filter sur la page "Explorer"
L'interrogation de tables très volumineuses doit être mûrement réfléchie, car les requêtes illimitées peuvent rapidement devenir trop lourdes pour la base de données. LookML permet de résoudre ce problème sous la forme conditionally_filter.
Le paramètre conditionally_filter permet d'appliquer un filtre à la requête, sauf si l'utilisateur a déjà ajouté un filtre pour l'un des champs répertoriés dans la section unless.
L'exemple suivant ne modifie pas la requête de l'utilisateur s'il a appliqué un filtre sur un ou plusieurs des champs suivants : created_date, shipped_time, shipped_date, orders.id ou customer.name. Si l'utilisateur n'a appliqué aucun filtre à ces champs, Looker ajoute automatiquement un filtre d'une journée sur orders.created_time.
filters: [orders.created_time: "1 day"]
unless: [created_date, shipped_time, shipped_date, orders.id, customer.name]
}