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'UI 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) s'affichera dans l'UI sous la forme Orders Amount (Commandes Montant). Sur cette page, les deux noms de champs sont en gras et le nom de la vue est 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 associer 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 les données par dimension et compter les entités. Par exemple, en regroupant les données par Pays des UTILISATEURS et en comptant les COMMANDES, vous saurez d'où proviennent 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 et la nommer 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 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

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 suivant. 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'UI, Looker crée une requête pour localiser l'ensemble de données qui compose la mesure. Chaque valeur de chaque dimension de la ligne du tableau est ajoutée à

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, l'outil de génération crée habituellement quelques champs d'exploration détaillée de départ, auxquels vous pouvez ajouter les vôtres. Par exemple, supposons que vous mesuriez le nombre de commandes par état des utilisateurs au cours de la semaine dernière. Dans Looker, la requête se présenterait comme suit :

USERS StateORDERS Count
Californie24
Texas5
Colorado4
Floride4
Illinois4

Si vous cliquez sur 24 dans la ligne Californie, vous vous attendez peut-être à voir les 24 commandes passées en Californie. Bien que Looker ajoute le filtre USERS State: California, il ne sait pas quels champs vous voulez afficher, ni dans quel ordre. Vous devez 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 vous 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 ;
  • Champs que vous souhaitez indexer dans une exploration

Le même ensemble peut être utilisé à plusieurs endroits d'un modèle. C'est pourquoi Looker propose plusieurs 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. créé en déclarant l'ensemble en tant que tableau. Vous pouvez déclarer des ensembles littéraux à l'aide de [].

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 vue customers : count et in_california_count. Lorsqu'un utilisateur détaille le champ Nombre ou Nombre en Californie dans une exploration, vous souhaitez afficher les champs id, name et city.

Au début, il peut sembler suffisant de déclarer littéralement ces champs :

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 saisissant le nom de l'ensemble cible, suivi d'un astérisque, par exemple setname*.
  • 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é expérimentale Exploration visuelle, les visualisations d'analyse et d'exploration 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 indiqué sur la page de documentation du paramètre link et sur la page des bonnes pratiques Exploration des données plus efficace.

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é expérimentale 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 sur l'exploration

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 retirer les données indésirables. Par exemple, supposons que vous ne vouliez afficher dans l'exploration Orders 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 dans l'interface.

sql_always_where sur 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. Les conditions sql_always_where ne sont pas visibles 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 sur 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 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'apportera aucune modification à la requête de l'utilisateur si celui-ci 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 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]
}