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'interface utilisateur en combinant le nom de la vue dans une 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 en gras et le nom de la vue est en majuscules (Montant des commandes) pour clarifier la discussion.
Si vous souhaitez que le nom d'un champ soit différent de celui d'une colonne dans une table, modifiez simplement le nom du champ et déclarez son association sql:. Dans l'exemple ci-dessous, il existe 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
}
}
La dimension cntrl_twr sera renommée "intelligible".
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
Elle est assez simple à regrouper par dimension et par nombre d'entités. Le regroupement par Pays des utilisateurs, ou Nombre de COMMANDES vous indique la provenance de vos commandes par pays. Toutefois, il est souvent utile d'établir un décompte filtré par une valeur dimensionnelle. Par exemple, vous pouvez créer une mesure ORDERS France Count:
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 mettre entre guillemets:
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 "Pourcentage d'articles renvoyés", "Pourcentage d'e-mails ayant abouti à une vente" ou d'autres instances de "Pourcentage de X que 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 une valeur nulle, ce qui génère une valeur nulle, ce qui é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'analyse détaillée à 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'analyse initiale. 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 précédente. 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 cliquions sur 24 à la ligne California, les données devraient apparaître pour les 24 commandes provenant de Californie.
Looker gère l'ajout du filtre État des utilisateurs: Californie, mais Looker ne sait pas quels champs vous souhaitez afficher dans la commande. 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 littéraux à l'aide du caractère "[]".
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 décompte: Nombre de clients et Nombre de clients en Californie. Lorsque nous explorons l'un de ces nombres, nous voulons 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 nous voulons ajouter un champ (par exemple, le champ customers.state), nous devons 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 recomposition des ensembles s'additionne : si vous déclarez un ensemble à plusieurs endroits, Looker inclut tous les champs déclarés pour l'ensemble dans toutes les zones géographiques.
- Vous pouvez intégrer des ensembles dans d'autres ensembles en saisissant l'autre ensemble, suivi d'un astérisque, comme
setname*. - Vous pouvez même supprimer des éléments d'un ensemble en plaçant un trait d'union avant le nom du champ, par exemple
-fieldname.
Consulter la documentation de référence sur les ensembles complets
Personnalisation d'une visualisation détaillée
Si votre administrateur Looker a activé la fonctionnalité expérimentale Exploration visuelle, les visualisations d'exploration de la section "Explorer et explorer" ne sont pas toujours des tableaux de données par défaut. 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 du paramètre link et sur la page des bonnes pratiques Plus performante d'exploration de données.
Les tableaux de bord sont compatibles avec l'affichage visuel à l'aide du paramètre link, sans que la fonctionnalité expérimentale Atelier de perçage visuel ne soit activée.
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 toujours appliquer 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 général, ces filtres permettent de supprimer les données que vous ne souhaitez généralement pas inclure. Par exemple, supposons que, dans l'onglet Explorer de Explorer, nous ne souhaitons voir que 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 l'état des commandes 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 visible par l'utilisateur, sauf s'il consulte le 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 de ces champs: created_date, shipped_time, shipped_date, orders.id ou customer.name. Si l'utilisateur n'a filtrer aucun de ces champs, Looker ajoutera 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]
}