Termes et concepts LookML

Les sections Opérateur de substitution ($), Portée et appellation, Dialecte SQL et Bloc SQL ont été transférées vers une nouvelle page, Intégration de SQL et référence aux objets LookML.

Présentation

Cette page définit les termes et concepts omniprésents dans le développement LookML. Le diagramme ci-dessous illustre les relations entre les éléments faisant partie d’autres éléments. Tous les termes figurant dans ce diagramme sont définis dans les sections suivantes.

Relations entre éléments LookML

Les présentations et les tableaux de bord définis par l’utilisateur sont absents de ce diagramme, car ils sont créés sans utiliser de code LookML. En revanche, leurs requêtes reposent sur les éléments LookML sous-jacents illustrés ci-dessus.

Projet LookML

Un projet LookML est un ensemble de fichiers LookML décrivant un jeu de modèles, de vues, d’explorations et éventuellement de tableaux de bord LookML liés.

Un projet LookML se compose généralement des structures suivantes :

Un modèle contient des informations sur les tables à utiliser et la manière de les joindre. En principe, c’est à ce niveau que vous définissez le modèle, ses explorations et ses jointures.
Une vue contient des renseignements sur la manière d’accéder aux informations de chaque table (ou de plusieurs tables jointes) et de les calculer. C’est généralement à ce niveau que vous définissez la vue et ses dimensions, mesures et champs.
Une exploration est généralement définie dans un fichier de modèle, mais vous pouvez parfois avoir besoin d’un fichier d’exploration distinct, par exemple pour une table NDT ou pour étendre ou affiner une exploration sur plusieurs modèles.
Une jointure vous permet de combiner des données de plusieurs vues.
Un fichier manifeste peut contenir des instructions concernant l’utilisation des fichiers importés d’un autre projet ou les paramètres de localisation de votre projet.

Si vous utilisez Git pour gérer les versions de projet, un projet correspond à un référentiel Git unique.

Relations entre les projets, fichiers et connexions de base de données LookML et les référentiels Git

Dans Looker, vos projets sont accessibles via le menu Développer :

Origine des projets et fichiers LookML

Lorsque vous créez un nouveau projet, l’outil de génération de projet de Looker crée un jeu de fichiers de référence que vous utilisez comme modèle pour composer le projet. Vous n’aurez que très rarement besoin d’écrire un code LookML entièrement nouveau, voire jamais.

Lors de la création d’un projet, vous spécifiez une connexion de base de données, et l’outil de génération de projet Looker crée les éléments suivants :

Plusieurs fichiers de vue, à raison d’un fichier par table de la base de données.
Un fichier de modèle. Ce fichier déclare une exploration par vue. Chaque déclaration d’exploration comporte une logique join pour joindre une vue que Looker peut identifier comme étant liée à l’exploration.

À ce stade, vous pouvez améliorer le projet en retirant les vues et explorations inutiles et en ajoutant des dimensions et mesures personnalisées.

Principales structures LookML

Comme illustré dans le diagramme ci-dessus, un projet se compose habituellement d’un ou de plusieurs fichiers de modèle contenant des paramètres qui définissent un modèle, ses explorations et ses jointures. En outre, les projets comportent généralement un ou plusieurs fichiers de vue, contenant chacun des paramètres qui définissent la vue, ses champs (y compris les dimensions et les mesures) et des jeux de champs. Il peut également comporter un fichier manifeste contenant des paramètres d’utilisation des fichiers de vue d’autres projets ou de configuration des valeurs de localisation par défaut. Cette section décrit ces principales structures.

Modèle

Un modèle est un portail personnalisé à l’intérieur de la base de données, conçu pour permettre une exploration intuitive des données par des utilisateurs métier spécifiques. Une même connexion de base de données d’un projet LookML peut comporter plusieurs modèles, chacun d’eux pouvant présenter des données différentes d’un utilisateur à l’autre. Par exemple, les commerciaux n’ont pas besoin des mêmes données que les dirigeants de l’entreprise, et vous devrez probablement développer deux modèles pour présenter des vues de la base de données adaptées à chaque utilisateur.

Dans Looker, les requêtes sont regroupées en fonction du modèle dont elles font partie. Vos utilisateurs voient les modèles répertoriés sous le menu Exploration :

Un fichier de modèle désigne la base de données à laquelle se connecter et définit un ensemble d’explorations pour cette connexion. Par convention, chaque fichier déclare exactement un modèle et, dans le nouveau LookML, son nom se termine par .model.lkml. Le nom du fichier de modèle détermine celui affiché dans Looker.

Le format général des déclarations de modèle LookML est illustré ci-après. Pour plus détails, lisez la page Envoi immédiat de données de la documentation.

connection: connection_name persist_for: timeframe case_sensitive: yes | no include: "filename_pattern" # for example: *.view.lkml # More include declarations explore: explore_name { view_name: view_name join: view_name { # join parameters } # More join declarations } # More explore declarations

Vue

Une déclaration de vue définit une liste de champs (dimensions ou mesures) et leur liaison avec une table sous-jacente ou dérivée. Dans LookML, les vues renvoient généralement à une table de base de données sous-jacente, mais peuvent aussi représenter une table dérivée.

Une vue peut être jointe à d’autres vues. La relation entre les vues est habituellement définie dans le cadre d’une déclaration d’exploration, dans un fichier de modèle.

Dans Looker, les noms des vues sont affichés devant ceux des dimensions et des mesures de la table de données, ce qui permet de voir immédiatement à quelle vue un champ appartient :

Une vue est enregistrée dans un fichier .view.lkml. Le format général des déclarations de vue dans LookML est illustré ci-après. Pour en savoir plus sur leur utilisation, lisez la page Paramètres de vue de la documentation.

view: view_name { dimension: field_name { # dimension_parameters } # more dimension declarations measure: field_name { # measure_parameters } # more measure declarations set: first_set { fields: [field_one, field_two] } }

Lorsque vous utilisez une mesure de type: count (nombre) dans une exploration, la visualisation attribue le nom de la vue aux valeurs obtenues, et non le mot « Count ». Pour éviter toute confusion, nous recommandons de mettre le nom de la vue au pluriel, en sélectionnant Afficher le nom complet de la vue dans l’onglet Série des paramètres de visualisation, ou en utilisant un paramètre view_label contenant le nom de la vue au pluriel.

Exploration

Une exploration est une vue sur laquelle les utilisateurs peuvent lancer une requête. Elle peut être considérée comme le point de départ d’une requête ou, en termes SQL, comme la clause FROM d’une instruction SQL. Toutes les vues ne sont pas des explorations, car elles ne décrivent pas toutes une entité présentant un intérêt. Par exemple, une vue Régions correspondant à une table de recherche des noms de région n’impose pas nécessairement une exploration, car les utilisateurs métier n’ont jamais besoin de l’interroger directement. À l’inverse, ils souhaiteront probablement interroger une vue Commandes, et il est donc pertinent de définir une exploration pour les commandes.

Une déclaration explore spécifie les relations de jointure avec d’autres vues. Si l’on reprend les exemples précédents, la vue Commandes peut être jointe à la vue Régions pour identifier la région où chaque vente a été enregistrée. Pour plus de détails, voir Jointures.

Dans Looker, les explorations sont présentées aux utilisateurs dans le menu Exploration :

Par convention, les explorations sont déclarées dans le fichier de modèle. L’exemple suivant illustre la déclaration d’une exploration orders pour une base de données d’e-commerce. Les vues orders et customers sont définies ailleurs, dans leur fichier de vue respectif.

Exemple de déclaration explore

# ——————————————— # file: ecommercestore.model.lookml # ——————————————— connection: order_database include: "filename_pattern" # include all the views explore: orders { join: customers { sql_on: ${orders.customer_id} = ${customers.id} ;; } }

Pour plus de détails sur les déclarations join, voir Jointures. Pour en savoir plus sur leur utilisation, lisez la page Paramètres de jointure de la documentation.

Champs de dimension et de mesure

Les vues contiennent des champs, essentiellement des dimensions et des mesures, qui sont les composantes fondamentales des requêtes Looker.

Dans Looker, une dimension est un champ pouvant faire partie d’un groupe et utilisable pour filtrer les résultats d’une requête. Il peut s’agir :

d’un attribut, directement associé à une colonne d’une table sous-jacente ;
d’une valeur factuelle ou numérique ;
d’une valeur dérivée, calculée à partir des valeurs d’autres champs sur une ligne unique.

Par exemple, les dimensions d’une vue Produits pourraient être le nom, le modèle, la couleur, le prix, la date de création et la date de fin de vie de chaque produit.

Une mesure est un champ utilisant une fonction d’agrégation SQL telle que COUNT, SUM, AVG, MIN ou MAX. Un champ calculé à partir d’autres valeurs de mesure est également une mesure. Les mesures permettent de filtrer des valeurs groupées. Par exemple, les mesures d’une vue Ventes pourraient être le nombre total d’articles vendus (un nombre), le prix de vente total (une somme) et le prix de vente moyen (une moyenne).

Le comportement et les valeurs attendues d’un champ varient en fonction de son type déclaré, comme string, number ou time. Pour les mesures, les types incluent des fonctions d’agrégation telles que sum et percent_of_previous. Pour plus de détails, reportez-vous aux types de dimensions et aux types de mesures.

Dans Looker, les champs sont répertoriés dans la page Explore lors de la création et de l’exécution de requêtes :

Par convention, les champs sont déclarés dans la vue dont ils font partie, enregistrée dans un fichier de vue. L’exemple ci-dessous illustre plusieurs déclarations de dimension et de mesure. À noter que l’opérateur de substitution ($) permet de faire référence à des champs sans fournir de nom de colonne SQL complet.

Voici quelques exemples de déclarations de dimensions et de mesures :

view: orders { dimension: id { primary_key: yes type: number sql: ${TABLE}.id ;; } dimension: customer_id { sql: ${TABLE}.customer_id ;; } dimension: amount { type: number value_format: "0.00" sql: ${TABLE}.amount ;; } dimension_group: created { type: time timeframes: [date, week] sql: ${TABLE}.created_at ;; } measure: count { type: count # creates sql COUNT(orders.id) sql: ${id} ;; } measure: total_amount { type: sum # creates sql SUM(orders.amount) sql: ${amount} ;; } }

Vous pouvez également définir un paramètre dimension_group pour créer plusieurs dimensions temporelles à la fois, ainsi que des champs filter, qui offrent de nombreuses fonctions avancées, comme les filtres basés sur un modèle.

Pour plus de détails sur la déclaration de champs et les différents paramètres pouvant leur être appliqués, consultez la section Paramètres de champ.

Jointures

Dans une déclaration explore, chaque déclaration join désigne une vue pouvant être jointe au sein de l’exploration. Lorsqu’un utilisateur crée une requête incluant des champs de plusieurs vues, Looker génère automatiquement une logique de jointure SQL pour présenter correctement la totalité de ces champs.

Voici un exemple de déclaration join à l’intérieur d’une déclaration explore :

Pour plus de détails, voir Utilisation de jointures dans LookML.

Fichiers manifestes d’un projet

Votre projet peut contenir un fichier manifeste de projet, utilisé pour les paramètres du projet, comme ceux qui permettent de spécifier d’autres projets à importer dans le projet actuel, de définir les constantes LookML, de spécifier les paramètres de localisation du modèle et d’ajouter des extensions et des visualisations personnalisées à votre projet.

Chaque projet peut contenir un seul fichier manifeste. Il doit être nommé manifest.lkml et être situé à la racine de votre répertoire Git. Lorsque vous utilisez des dossiers dans l’IDE, assurez-vous que le fichier manifest.lkml est enregistré à la racine de l’arborescence de votre projet.

Vous pouvez vous servir du fichier manifeste pour importer un projet ou à des fins de localisation, mais pas pour les deux à la fois.

Pour importer des fichiers LookML d’un autre projet, utilisez le fichier manifeste de celui-ci pour nommer votre projet actuel et indiquer l’emplacement des projets externes, qui peuvent être stockés en local ou à distance. Par exemple :

# This project project_name: "my_project" # The project to import local_dependency: { project: "my_other_project" } remote_dependency: ga_360_block { url: "https://github.com/llooker/google_ga360" ref: "4be130a28f3776c2bf67a9acc637e65c11231bcc" }

Après avoir désigné les projets externes dans le fichier manifeste du projet, vous pouvez vous servir du paramètre include de votre fichier de modèle pour ajouter des fichiers de ces projets externes à votre projet actuel. Par exemple :

include: "//my_other_project/imported_view.view" include: "//ga_360_block/*.view"

Pour en savoir plus, lisez la page Importation de fichiers d’autres projets de la documentation.

Pour ajouter des éléments de localisation à votre modèle, utilisez le fichier manifeste du projet pour définir des paramètres de localisation par défaut. Par exemple :

localization_settings: { default_locale: en localization_level: permissive }

La définition de paramètres de localisation par défaut est l’une des étapes de la localisation d’un modèle. Pour en savoir plus, lisez la page Localisation du modèle LookML de la documentation.

Jeux

Dans Looker, un jeu est une liste définissant un groupe de champs utilisés ensemble. Les jeux sont généralement utilisés pour désigner les champs à afficher lorsqu’un utilisateur détaille des données. Dans ce cas, les jeux sont spécifiés par champ, de sorte que vous maîtrisez totalement les données qui s’affichent lorsqu’un utilisateur clique sur une valeur dans une table ou un tableau de bord. Les jeux peuvent également faire office de fonction de sécurité, pour définir des groupes de champs visibles par certains utilisateurs.

L’exemple qui suit présente une déclaration de jeu dans une vue order_items, qui définit des champs contenant des détails intéressants sur un article acheté. Notez que les jeux font référence à des champs d’autres vues en définissant une portée.

set: order_items_stats_set { fields: [ id, # scope defaults to order_items view orders.created_date, # scope is "orders" view orders.id, users.name, users.history, # show all products this user has purchased products.item_name, products.brand, products.category, total_sale_price ] }

Pour en savoir plus sur leur utilisation, lisez la page set Paramètre.

Détails

Dans Looker, vous pouvez détailler n’importe quel champ configuré à cet effet lors de l’écriture du code LookML. Cette fonction est à la fois compatible avec les tables de résultats de requête et les tableaux de bord. La fonction de détail lance une nouvelle requête, limitée par la valeur sur laquelle l’utilisateur a cliqué.

Le comportement de cette fonction est différent pour les dimensions et les mesures :

Lorsque l’utilisateur détaille une dimension, le filtre de la nouvelle requête porte sur la valeur détaillée. Par exemple, si vous cliquez sur une date donnée dans une requête de commandes client par date, la nouvelle requête affiche uniquement les commandes passées à cette date.
Lorsque l’utilisateur détaille une mesure, la nouvelle requête présente le jeu de données ayant contribué à la mesure. Par exemple, lorsqu’il détaille un nombre, la nouvelle requête présente les lignes utilisées pour calculer ce nombre. Si la mesure détaillée est une valeur maximale, minimale ou moyenne, toutes les lignes ayant contribué à la mesure apparaissent. Par exemple, cela signifie que si une mesure maximale est détaillée, toutes les lignes utilisées pour calculer la valeur maximale sont affichées, et pas simplement la ligne contenant cette valeur.

Les champs à afficher pour la nouvelle requête de détail sont définis par un jeu.

Tables dérivées et tables de faits

Une table dérivée se compose de valeurs d’autres tables ; l’utilisateur y accède comme s’il s’agissait d’une table physique avec ses propres colonnes. Elle est présentée, via le paramètre derived_table, dans une vue spécifique dont les dimensions et mesures sont définies de la même manière que celles des autres vues. Comme n’importe quelle autre vue, celle d’une table dérivée peut faire l’objet de requêtes et être jointe à d’autres vues.

Les tables dérivées sont créées à l’aide du paramètre derived_table, dans une déclaration view. Pour plus de détails, voir Utilisation de tables dérivées.

Utilisation de tables dérivées et de tables de faits

Dans Looker, les tables dérivées sont communément utilisées pour présenter une table de faits, qui calcule des faits concernant une entité à partir des valeurs dérivées d’autres vues. Par exemple, il est courant d’avoir à analyser le profil d’un utilisateur en fonction de ses commandes ou actions passées, puis de générer un rapport sur ce profil et de le trier et filtrer comme n’importe quelle autre facette de l’utilisateur.

Exemple : table dérivée de faits de commande client

Prenons l’exemple d’un jeu de données d’e-commerce comportant une table users contenant des données clients et une table orders contenant des détails sur les commandes client. Il est possible d’utiliser une table dérivée pour créer une table user_orders_facts contenant des faits orientés client, comme le chiffre d’affaires total généré par un client tout au long de sa durée de vie, ce qui n’existe pas physiquement dans les tables sous-jacentes. Le nombre de commandes passées tout au long de la durée de vie, la date de la dernière commande ou le fait que le client ait passé une ou plusieurs commandes sont d’autres exemples de colonnes. Voir le diagramme ci-dessous.

Dans la mesure où la clé primaire de la table de faits est user_id, la vue peut être jointe individuellement à l’exploration users, ce qui ouvre de larges possibilités de requête. En voici un exemple :

Tables dérivées persistantes

Le calcul d’une table dérivée prend souvent beaucoup de temps. Pour éviter de répéter trop souvent ce calcul coûteux, Looker peut mettre les données d’une table dérivée en cache (ou les rendre « persistantes »). Une table dérivée persistante — ou PDT (persistent derived table) — est simplement une table dérivée régénérée automatiquement. Pour en savoir sur la manière de rendre une table dérivée persistante, consultez la page Utilisation de tables dérivées de la documentation.

Les tables dérivées persistantes utilisent une table vide de la base de données pour enregistrer les résultats, ce qui suppose une configuration supplémentaire, selon le type de la base de données.

Connexion de base de données

Looker émet des requêtes portant sur la base de données désignée dans le fichier de modèle LookML. Une connexion Looker indique le serveur hébergeant la base de données et contient des paramètres définissant la manière dont Looker doit se connecter à la base. En général, l’administrateur système ne paramètre qu’une seule fois (ou rarement) la base de données, et il suffit aux modélisateurs de données de choisir parmi les connexions disponibles.

En quoi consiste LookML ?

Modification et validation du code LookML