Modèles LookML courants

Cette page décrit les modèles courants suivants dans LookML :

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, présenté dans une police normale, et le nom abrégé du champ en gras. Par exemple, un champ appelé Amount (Montant) dans la vue Orders (Commandes) apparaît dans l'interface utilisateur sous la forme Orders Amount. Dans cette page, l'un et l'autre sont présentés en gras et le nom de la vue est affiché en majuscules (ORDERS Amount) pour clarifier le propos.

Si vous souhaitez qu'un champ porte un nom différent de celui de sa colonne dans un tableau, modifiez le nom du champ et utilisez le paramètre sql pour lier le champ à la colonne appropriée du tableau. Dans l'exemple suivant, la table airports comporte 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
  }
}

Vous pouvez renommer la dimension cntrl_twr pour la rendre 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

Vous pouvez regrouper des données en fonction d'une dimension et d'entités de décompte. Un regroupement par USERS Country (Pays des utilisateurs), ORDERS Count (Nombre de commandes) permet de savoir de quels pays proviennent les commandes. Toutefois, il est souvent utile d'établir un décompte filtré par une valeur dimensionnelle. Par exemple, vous pourriez créer une nouvelle mesure et la nommer 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"]
}

Pour filtrer des données avec une expression mathématique, n'oubliez pas de placer celle-ci 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

La plupart des indicateurs de performance clés sont exprimés sous forme de pourcentages, comme "pourcentage d'articles retournés", "pourcentage d'e-mails ayant abouti à une vente" ou d'autres occurrences de type "pourcentage de X ayant 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 égale à zéro en valeur null ; le résultat est alors une valeur null, 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 vous cliquez sur une mesure dans l'interface utilisateur, Looker crée une nouvelle requête pour localiser le jeu de données qui compose la mesure. Chaque valeur de chaque dimension de la ligne de la table s'ajoute à

Pour afficher les détails, Looker a besoin d'une liste précise de champs de détails à 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 de détails initiaux pour vous. auxquels vous pouvez ajouter les vôtres. Par exemple, supposons que vous mesuriez le décompte ORDERS Count (Nombre de commandes) de la semaine passée par USERS State (État des utilisateurs). Dans Looker, la requête se présenterait comme suit :

USERS StateORDERS Count
Californie24
Texas5
Colorado4
Floride4
Illinois4

Si vous cliquiez sur la valeur 24 de la ligne California (Californie), vous devriez voir les 24 commandes passées en Californie. Bien que Looker ajoute le filtre USERS State: California (État des utilisateurs : Californie), il ignore quels champs vous voulez afficher, et dans quel ordre. Vous devez donc d'abord utiliser un ensemble pour déclarer ces champs dans votre modèle.

Dans LookML, un ensemble est une liste de noms de champs (dimension, mesure et filtre). Les ensembles permettent de fournir les informations suivantes à Looker :

  • Les champs que vous souhaitez afficher lors de l'exploration détaillée d'un décompte ou d'une autre mesure
  • Les champs que vous souhaitez importer lorsque vous joignez une vue
  • Les champs que vous souhaitez indexer dans une exploration

Le même ensemble peut être utilisé à plusieurs endroits d'un modèle, de sorte que Looker offre différentes méthodes pour créer des ensembles.

Ensembles littéraux

Un ensemble littéral est un moyen simple de définir un ensemble dans LookML, en particulier lorsque l'ensemble n'est utilisé qu'une seule fois. Un ensemble littéral est créé en déclarant l'ensemble en tant que tableau. Vous pouvez déclarer des ensembles littéraux à l'aide des symboles [].

Prenons l'exemple suivant :

view: customers {
  dimension: id {
    primary_key: yes
  }
  measure: count {
    type: count
  }
  dimension: city {}
  dimension: state {}
  dimension: name {}
}

Dans cet exemple, les champs que vous souhaitez afficher sont id, name et city.

Dans la mesure, vous pouvez déclarer un tableau littéral comme suit :

measure: count {
  type: count
  drill_fields: [id, name, city]
}

Ensembles nommés

Supposons que deux décomptes soient définis dans la customers vue : count et in_california_count. Lorsqu'un utilisateur explore le champ Count (Nombre) ou le champ In California Count (Nombre en Californie) dans une exploration, vous souhaitez afficher les champs id, name et city.

Au départ, la déclaration littérale de ces champs peut sembler suffisante :

view: customers {
  measure: count {
    type: count
    drill_fields: [id, name, city]
  }
  measure: in_california_count {
    type: count
    filters: [state: "California"]
    drill_fields: [id, name, city]
  }
}

Toutefois, si vous souhaitez ajouter un champ (tel que customers.state), vous devez modifier les deux listes, sauf si vous utilisez le paramètre set pour créer des ensembles nommés que vous pouvez gérer au même endroit et utiliser à plusieurs endroits.

Le code suivant crée un ensemble customers.detail et renvoie les deux décomptes au 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"]
    drill_fields: [detail*]      # show fields in the set "customers.detail"
  }
}

Les ensembles LookML sont puissants pour les raisons suivantes :

  • La redéclaration des ensembles est additive. Si vous déclarez un ensemble à plusieurs endroits, Looker inclut tous les champs déclarés pour l'ensemble à ces endroits.
  • Vous pouvez imbriquer des ensembles les uns dans les autres en tapant le nom de l'ensemble cible, suivi d'un astérisque (setname*, par exemple).
  • Vous pouvez retirer des éléments d'un ensemble en ajoutant un tiret devant le nom des champs concernés, comme dans l'exemple suivant : -fieldname.

Personnalisation d'une visualisation détaillée

Si votre administrateur Looker a activé la fonctionnalité Visual Drilling (Exploration visuelle), les visualisations détaillées des présentations et des explorations ne seront pas toujours définies par défaut sur un tableau de données. Dans ce cas, vous pouvez personnaliser la visualisation affichée en utilisant des variables Liquid dans le paramètre link, comme expliqué dans la page de documentation du paramètre link et dans la page Bonnes pratiques pour une exploration plus efficace des données More powerful data drilling.

Les tableaux de bord sont compatibles avec l'exploration visuelle à l'aide du paramètre link sans qu'il soit nécessaire d'activer la fonctionnalité Visual Drilling (Exploration visuelle).

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 dans l'exploration

Utilisez always_filter pour appliquer systématiquement une série de filtres à une requête exécutée sur 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 retirer les données indésirables. Par exemple, supposons que vous ne vouliez afficher dans l'exploration Orders (Commandes) que les commandes exécutées (complete) ou en attente (pending). Vous pouvez ajouter le code LookML suivant :

explore: orders {
  view_name: order
    filters: [status: "complete,pending"]
  }
}

SI l'utilisateur voulait consulter les commandes portant un autre statut, il pourrait attribuer la valeur % à ORDERS Status (Statut des commandes) dans l'interface.

sql_always_where dans l'exploration

Pour appliquer une restriction de requête non modifiable par l'utilisateur, 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. La condition sql_always_where n'est pas visible par l'utilisateur, sauf s'il examine le code SQL sous-jacent des requêtes qu'il crée lui-même.

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 dans l'exploration

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 en proposant un paramètre conditionally_filter.

Le paramètre conditionally_filter permet d'appliquer un filtre à la requête, sauf si l'utilisateur en a déjà ajouté un pour l'un des champs répertoriés dans la section unless.

L'exemple suivant n'apporte aucune modification à la requête de l'utilisateur si celui-ci a appliqué un filtre à un ou plusieurs de ces champs : created_date, shipped_time, shipped_date, orders.id ou customer.name. Si l'utilisateur n'a filtré aucun de ces champs, Looker ajoute automatiquement un filtre d'une journée à orders.created_time.

  filters: [orders.created_time: "1 day"]
  unless: [created_date, shipped_time, shipped_date, orders.id, customer.name]
}