Présentation
Grâce aux améliorations de LookML, vous pouvez adapter une vue ou une exploration existante sans modifier le fichier LookML qui la contient. C'est la solution idéale pour:
- Les projets avec des blocs Looker, qui utilisent des éléments de code LookML prédéfinis
- Projets qui importent des fichiers à partir d'autres projets
- Projets dans lesquels vous devez souvent générer des fichiers à partir de tables de votre base de données
- Situations dans lesquelles vous souhaitez partager du code LookML entre des modèles ou des projets tout en effectuant des personnalisations à chaque emplacement (configurations en étoile)
Par exemple, si le fichier de vue suivant est présent dans votre projet :
view: flights {
sql_table_name: flightstats.accidents ;;
dimension: id {
label: "id"
primary_key: yes
type: number
sql: ${TABLE}.id ;;
}
}
Vous pouvez affiner la vue flights
comme illustré dans l'exemple suivant : utilisez le paramètre view
avec le même nom de vue, mais ajoutez un signe plus (+
) devant le nom pour indiquer qu'il s'agit d'un affinement d'une vue existante.
Cet affinement ajoute une dimension air_carrier
à la vue flights
existante :
view: +flights {
dimension: air_carrier {
type: string
sql: ${TABLE}.air_carrier ;;
}
}
Cette amélioration peut être appliquée à n'importe quel fichier LookML du projet, tel qu'un fichier de modèle ou de vue, ou dans son propre fichier LookML dédié. Pour en savoir plus, consultez la section Utiliser des perfectionnements dans votre projet LookML.
Le raffinement combiné au code LookML d'origine donne le résultat final comme s'il s'agissait du code LookML d'origine de la vue :
view: flights {
sql_table_name: flightstats.accidents ;;
dimension: id {
label: "id"
primary_key: yes
type: number
sql: ${TABLE}.id ;;
}
dimension: air_carrier {
type: string
sql: ${TABLE}.air_carrier ;;
}
}
Dans l'interface utilisateur de Looker, les utilisateurs verront la dimension Compagnie aérienne, comme si vous l'aviez ajoutée au fichier de vue d'origine.
Pour obtenir des informations plus détaillées sur l'implémentation, consultez la section Exemple.
Améliorations par rapport aux extensions
Looker permet également d'étendre des objets LookML. L'extension est utile lorsque vous souhaitez créer une copie d'une vue ou d'une exploration existante afin d'y ajouter de nouveaux objets. Par exemple, vous pouvez créer une vue de base qui définit tous vos champs, puis plusieurs vues qui l'étendent. Ces nouvelles vues peuvent ensuite être modifiées pour masquer certains champs dans la vue de base, ou pour modifier les définitions ou libellés des champs dans la vue de base.
Les filtres sont utiles lorsque vous souhaitez modifier une vue ou une exploration existante en y apportant quelques ajustements ou ajustements sur certains objets, sans créer de copies de la vue ou d'une exploration. Les raffinements sont idéaux lorsque vous ne pouvez pas ou ne souhaitez pas modifier la vue de base ou l'exploration, ou lorsque la création d'une vue ou d'une exploration nécessiterait d'apporter des modifications importantes à d'autres références LookML. Pour voir un exemple de ce cas d'utilisation, consultez la section Exemple de cette page.
Dans la plupart des cas, les raffinements constituent une alternative plus simple et plus claire à extends
.
Les développeurs LookML avancés peuvent utiliser le paramètre extends
dans un affinement LookML. Pour en savoir plus, consultez la section Les raffinements peuvent contenir des extensions sur cette page.
Les filtres remplacent la plupart des paramètres
Notez que, dans la plupart des cas, un affinement remplace les paramètres d'origine d'un objet. Dans l'exemple suivant, la vue d'origine comporte une dimension masquée (hidden: yes
) :
view: faa_flights {
dimension: carrier {
hidden: yes
}
}
Dans un autre fichier, cette dimension est affinée avec hidden: no
:
include: "/views/faa_flights.view.lkml"
view: +faa_flights {
dimension: carrier {
hidden: no
}
}
Le dernier affinement a la priorité. hidden: no
est donc appliqué et la dimension s'affiche dans la vue finale.
Dans certains cas, les filtres sont additifs au lieu de remplacer. Pour en savoir plus, consultez la section Certains paramètres s'ajoutent les uns aux autres de cette page.
Certains paramètres s'ajoutent les uns aux autres
Dans de nombreux cas, si le filtre contient le même paramètre que l'objet affiné, le raffinement remplace les valeurs de paramètre de l'objet affiné.
Toutefois, les raffinements peuvent être additifs pour certains paramètres, ce qui signifie que les valeurs de l'objet de base sont utilisées conjointement avec celles de l'objet affiné.
Les paramètres suivants sont additifs :
Pour les dimensions et les mesures:
Pour les paramètres :
Pour les tables dérivées:
Pour les vues:
extends
(Pour en savoir plus, consultez la section Lesextends
s'ajoutent les unes aux autres sur cette page.)
Pour les explorations :
access_filter
aggregate_table
extends
(pour en savoir plus, consultez la section Lesextends
de raffinement sont additifs de cette page.)join
query
Voici un exemple de vue avec une dimension name
et un paramètre link
:
view: carriers {
sql_table_name: flightstats.carriers ;;
dimension: name {
sql: ${TABLE}.name ;;
type: string
link: {
label: "Google {{ value }}"
url: "http://www.google.com/search?q={{ value }}"
icon_url: "http://google.com/favicon.ico"
}
}
}
Voici une amélioration de la vue carriers
, avec une dimension name
qui a des valeurs différentes pour le paramètre link
:
include: "/views/carriers.view.lkml"
view: +carriers {
label: "Refined carriers"
dimension: name {
sql: ${TABLE}.name ;;
type: string
link: {
label: "Dashboard for {{ value }}"
url: "https://docsexamples.dev.looker.com/dashboards/307?Carrier={{ value }}"
icon_url: "https://www.looker.com/favicon.ico"
}
}
}
Dans la vue carriers
affinée, les deux paramètres link
sont additifs. La dimension name
affiche donc les deux liens.
Les suggestions sont appliquées dans l'ordre
Un objet peut être affiné plusieurs fois et à plusieurs endroits, ce qui permet aux développeurs Looker d'utiliser les affinages de manière très créative. Cela signifie également que les développeurs doivent être très attentifs à l'ordre dans lequel les améliorations sont appliquées :
- Dans un projet, les améliorations sont appliquées dans l'ordre dans lequel leurs fichiers sont inclus. Les suggestions basées sur les fichiers inclus en dernier remplacent les suggestions des fichiers inclus précédemment.
- Dans un même fichier, les filtres sont appliqués ligne par ligne, en partant du bas. Les filtres associés au numéro de ligne le plus élevé sont appliqués en dernier et remplacent les filtres antérieurs en cas de conflit.
Par exemple, dans le fichier de vue suivant, il existe deux affinements de la vue faa_flights
. Le premier filtre masque une dimension (hidden: yes
), tandis que le second affiche la dimension (hidden: no
). Dans ce type de conflit, le filtre situé tout en bas du fichier prévaut:
include: "//e_faa_original/views/faa_flights.view.lkml"
view: +faa_flights {
dimension: carrier {
hidden: yes
}
}
view: +faa_flights {
dimension: carrier {
hidden: no
}
}
La logique est la même pour inclure plusieurs fichiers dans un projet: les affinements du dernier fichier listé dans l'inclusion prévalent. Par exemple, si un fichier de modèle inclut les fichiers suivants:
include: "/refinements/distance_analysis.lkml"
include: "/refinements/finishing_touches.lkml"
Les améliorations apportées au fichier distance_analysis.lkml
sont appliquées en premier, puis celles du fichier finishing_touches.lkml
. En cas de conflit, les filtres du dernier fichier (finishing_touches.lkml
) sont prioritaires.
Utiliser final: yes
pour empêcher d'autres affinements
Comme décrit précédemment, un même objet peut être affiné plusieurs fois à plusieurs endroits, et le dernier affinement remplace tous les affinements précédents.
Si vous souhaitez qu'un affinement soit considéré comme l'affinement final pour la vue ou l'exploration, vous pouvez ajouter l'indicateur final: yes
à l'affinement. L'IDE Looker renvoie une erreur LookML si des améliorations existantes sont appliquées après ce raffinement final ou si un développeur tente d'ajouter un raffinement qui sera appliqué après ce raffinement final. Par exemple, le deuxième raffinement de ce fichier de vue créerait une erreur LookML, car le raffinement précédent comporte l'indicateur final: yes
:
include: "//e_faa_original/views/faa_flights.view.lkml"
view: +faa_flights {
final: yes
dimension: carrier {
hidden: yes
}
}
view: +faa_flights {
dimension: carrier {
hidden: no
}
}
Ajouter l'indicateur final: yes
à un affinement est un bon moyen de vérifier que vos affinements sont appliqués dans l'ordre prévu.
Les raffinements peuvent contenir des extensions
Les développeurs LookML avancés peuvent utiliser un paramètre extends
dans un raffinement LookML, qui ajoute l'objet étendu à l'objet en cours d'affinage.
Pour résumer le comportement de extends
et les améliorations :
- L'extension d'un objet crée une nouvelle copie de l'objet, puis s'appuie dessus. Par exemple, vous pouvez créer une vue de base qui définit tous vos champs, puis plusieurs vues qui l'étendent. Chacune de ces nouvelles vues intègre une copie de la vue de base. À partir de là, un développeur peut ajouter différents champs, filtres ou autres propriétés pour modifier ce qui se trouve dans la vue de base. L'idée est de commencer par un objet de base, puis de l'utiliser de différentes manières dans plusieurs autres objets. Pour en savoir plus sur l'utilisation des extensions, consultez la page de documentation Réutiliser du code avec des extensions.
- Le raffinement d'un objet ajoute une couche de modifications à l'objet, mais contrairement à l'extension, il ne crée pas plusieurs copies de l'objet. L'idée est de créer un objet de base sans modifier son code LookML d'origine.
Voici un exemple d'utilisation standard des raffinements : une exploration appelée orders
et l'exploration +orders
qui la raffine :
explore: orders {
view_name: orders
# other Explore parameters
}
explore: +orders {
label: "Orders Information"
# other Explore parameters to build on the original Explore
}
De plus, vous pouvez ajouter un affinement qui inclut un extends
. Sur la base de cet exemple, voici la même exploration orders
. En outre, il existe une exploration de base appelée users_base
, et le raffinement +orders
comporte désormais un paramètre extends
qui intègre users_base
:
explore: users_base {
view_name: users
extension: required
# other Explore parameters
}
explore: orders {
view_name: orders
# other Explore parameters
}
explore: +orders {
label: "Orders Information"
extends: [users_base]
# other Explore parameters to build on the original Explore
}
La spécificité du raffinement +orders
est qu'il contient un extends
. Résultat : la vue +orders
étend désormais l'exploration users_base
.
Comment Looker implémente extends
dans les filtres
L'extension d'un objet à l'intérieur d'un raffinement est un concept LookML avancé. Avant d'utiliser extends
dans un filtre, vous devez connaître parfaitement les points suivants:
- Comment Looker implémente
extends
: si un élément LookML est défini à la fois dans l'objet extensé et dans l'objet d'extension, la version de l'objet d'extension est utilisée, sauf si le paramètre est additif. Pour en savoir plus, consultez la page de documentation Réutiliser du code avec des extensions. - Comment Looker implémente les perfectionnements : si un élément LookML est défini dans plusieurs perfectionnements, le dernier perfectionnement remplace les précédents. Pour en savoir plus, consultez la section Les filtres sont appliqués dans l'ordre de cette page.
Enfin, vous devez comprendre comment Looker combine ces principes pour implémenter extends
utilisé dans les améliorations. Voici l'ordre que Looker implémente, chaque étape prévalant sur la précédente en cas de conflit:
- Valeurs de la règle
extends
spécifiée dans l'objet - Valeurs de
extends
spécifiées dans les améliorations de l'objet - Valeurs de l'objet
- Valeurs des raffinements de l'objet
Voici un exemple qui suit la valeur du paramètre label
à chaque étape de l'implémentation:
explore: orders_base {
label: "Orders Base"
view_name: orders
extension: required
}
explore: users_base {
label: "Users Base"
view_name: users
extension: required
}
explore: orders {
label: "Orders"
extends: [orders_base]
}
explore: +orders {
label: "Orders Refined"
extends: [users_base]
}
Voici comment Looker implémente la valeur de label
pour l'exploration orders
dans cet exemple:
- Valeurs du
extends
spécifié dans l'objet. Étant donné que l'explorationorders
comporte un paramètreextends
, Looker commence par les éléments LookML de l'objet étendu, qui est ici l'explorationorders_base
. À ce stade, la valeurlabel
est "Orders Base". - Valeurs de l'
extends
spécifiées dans les raffinements de l'objet. Commeorders
comporte un filtre et que celui-ci comporte un paramètreextends
, Looker applique ensuite les éléments LookML de l'extension du filtre, qui est dans ce cas l'explorationusers_base
. À ce stade, la valeurlabel
est "Users Base" (Base d'utilisateurs). - Valeurs de l'objet. Maintenant que toutes les extensions ont été traitées, Looker applique les éléments de l'objet d'extension, qui est ici l'exploration
orders
. En cas de conflit, l'objet d'extension l'emporte. La valeurlabel
correspond désormais à "Orders". - Valeurs issues des filtres de l'objet. Enfin, Looker applique les éléments de tous les raffinements de l'exploration
orders
. En cas de conflit, l'objet de précision l'emporte. La valeurlabel
est donc "Orders Refined" (Commandes affinées).
Les filtres extends
sont cumulables
Comme décrit dans la section Les paramètres de forçage des raffinements de cette page, les raffinements remplacent généralement les paramètres d'origine d'un objet. Ce n'est pas le cas pour le paramètre extends
. Lorsque extends
est utilisé dans un affinement, la valeur du paramètre extends
est ajoutée à la liste des éléments étendus dans l'objet d'origine ou dans les affinements précédents, le cas échéant. Ensuite, en cas de conflit, la priorité est donnée au dernier élément de la chaîne d'extension.
Par exemple, voici une exploration de base appelée orders_base
et une exploration orders
qui étend la base. Il existe également une exploration users_base
et le filtre +orders
qui étend users_base
:
explore: orders_base {
view_name: orders
extension: required
# other Explore parameters
}
explore: users_base {
view_name: users
extension: required
# other Explore parameters
}
explore: orders {
extends: [orders_base]
# other Explore parameters to build on the base Explore
}
explore: +orders {
extends: [users_base]
# other Explore parameters to build on the base Explores
}
L'exploration orders
étend orders_base
, puis les raffinements +orders
ajoutent users_base
à la liste extends
. Résultat : l'exploration +orders
étend désormais orders_base
et users_base
, comme s'il s'agissait du code LookML d'origine de l'exploration :
explore: orders {
extends: [orders_base, users_base]
}
Ensuite, en cas de conflit, la priorité est donnée au dernier élément de la chaîne d'extension. Dans cet exemple, les éléments de users_base
remplaceraient les éléments en conflit de orders_base
.
Le concept d'extension de plusieurs objets à la fois est abordé dans la page de documentation Réutiliser du code avec des extensions.
Une dernière chose à noter: dans cet exemple, l'ordre des paramètres explore
n'a pas d'importance. Toutefois, si vous affinez plusieurs fois le même objet, l'ordre des raffinements a son importance. Comme décrit dans la section Les raffinements sont appliqués dans l'ordre de cette page, le dernier raffinement d'un fichier remplace les précédents.
Utiliser des perfectionnements dans votre projet LookML
Voici les principales étapes à suivre pour affiner les vues et les explorations dans votre projet:
- Identifiez la vue ou l'exploration que vous souhaitez affiner.
- Déterminez où vous souhaitez héberger vos améliorations. Vous pouvez ajouter des raffinements dans n'importe quel fichier LookML existant ou créer des fichiers LookML distincts pour vos raffinements. (Consultez la procédure de création d'un fichier de test de données sur la page de documentation Comprendre d'autres fichiers de projet pour obtenir un exemple de création de fichiers LookML génériques.)
- Utilisez le paramètre
include
pour intégrer vos améliorations à votre modèle :- Dans le fichier dans lequel vous écrivez vos améliorations, vous devez inclure les fichiers du LookML que vous affinez. L'IDE Looker affichera des avertissements si vous essayez d'affiner un objet qui n'est pas inclus.
- Dans votre fichier de modèle, incluez les fichiers dans lesquels vos améliorations sont définies. Vous pouvez combiner des fichiers et utiliser des inclusions de manière très créative. Pour en savoir plus, consultez la section Utiliser des filtres pour ajouter des calques à votre modèle sur cette page.
Exemple
Affiner les objets LookML permet d'adapter facilement les vues et les explorations sans avoir à modifier le code LookML d'origine. Cette fonctionnalité est particulièrement utile lorsque vos vues et explorations sont en lecture seule dans votre projet, par exemple avec les fichiers importés depuis d'autres projets. Voici un exemple d'affinage d'une exploration.
Voici le code LookML de l'exploration aircraft
:
explore: aircraft {
join: aircraft_types {
type: left_outer
sql_on: ${aircraft.id} = ${aircraft_types.id} ;;
relationship: many_to_one
}
join: aircraft_engine_types {
type: left_outer
sql_on: ${aircraft.id} = ${aircraft_engine_types.id} ;;
relationship: many_to_one
}
}
Cette exploration comporte plusieurs vues, chacune ayant de nombreuses dimensions.
Un autre projet LookML appelé e_faa_refined
importe le fichier d'exploration aircraft
. Dans le projet e_faa_refined
, vous pouvez utiliser un affinement pour simplifier considérablement l'exploration aircraft
.
Étant donné que l'exploration aircraft
est un fichier importé, vous ne pouvez pas la modifier directement. À la place, vous pouvez ajouter un filtre. Voici un exemple de fichier distinct appelé refinements.lkml
contenant ce LookML:
include: "//e_faa_original/Explores/aircraft.explore.lkml"
explore: +aircraft {
label: "Aircraft Simplified"
fields: [aircraft.aircraft_serial, aircraft.name, aircraft.count]
}
Le fichier refinements.lkml
contient les éléments suivants :
- Le paramètre
include
pour récupérer le fichieraircraft.explore.lkml
d'origine à partir du projet importé (consultez la page de documentation Importer des fichiers d'autres projets pour savoir comment faire référence aux fichiers de projet importés). - Améliorations apportées à l'exploration
aircraft
:
Le résultat final est comme si vous utilisiez la vue aircraft
Explorer et aircraft
d'origine :
explore: aircraft {
label: "Aircraft Simplified"
}
view: aircraft {
sql_table_name: flightstats.aircraft ;;
dimension: aircraft_serial {
type: string
sql: ${TABLE}.aircraft_serial ;;
}
dimension: name {
type: string
sql: ${TABLE}.name ;;
}
measure: count {
type: count
}
}
Pour obtenir un exemple d'utilisation de filtres afin de personnaliser une vue unique pour plusieurs cas d'utilisation, consultez la recette du livre de recettes Optimiser la réutilisabilité du code avec DRY LookML: Personnaliser une vue de base unique pour plusieurs cas d'utilisation.
Autres cas d'utilisation de perfectionnement
Comme indiqué précédemment, les améliorations sont idéales pour adapter les objets LookML en lecture seule, tels que les blocs Looker ou les fichiers importés.
Mais une fois que vous aurez compris comment ajouter des améliorations et les inclure dans vos modèles, vous pourrez réaliser des choses très intéressantes avec vos projets, comme décrit dans les exemples suivants.
Utiliser des filtres pour ajouter des analyses
Vous pouvez utiliser des filtres pour ajouter des analyses à votre modèle sans toucher aux fichiers LookML d'origine. Par exemple, s'il existe un projet dans lequel les vues et les explorations sont générées à partir de tables de votre base de données et stockées dans un fichier LookML appelé faa_basic.lkml
, vous pouvez créer un fichier faa_analysis.lkml
dans lequel vous utilisez des filtres pour ajouter des analyses. Voici un exemple de nouvelle table dérivée appelée distance_stats
avec une analyse de distance. Cet exemple montre des améliorations de l'exploration flights
existante à partir du fichier faa_basic.lkml
qui joint la table dérivée distance_stats
à l'exploration flights
. En bas de l'exemple, la vue flights
existante est affinée pour ajouter de nouveaux champs à partir de l'analyse :
include: "faa_basic.lkml"
explore: +flights {
join: distance_stats {
relationship: one_to_one
type: cross
}
}
view: distance_stats {
derived_table: {
explore_source: flights {
bind_all_filters: yes
column: distance_avg {field:flights.distance_avg}
column: distance_stddev {field:flights.distance_stddev}
}
}
dimension: avg {
type:number
sql: CAST(${TABLE}.distance_avg as INT64) ;;
}
dimension: stddev {
type:number
sql: CAST(${TABLE}.distance_stddev as INT64) ;;
}
}
view: +flights {
measure: distance_avg {
type: average
sql: ${distance} ;;
}
measure: distance_stddev {
type: number
sql: STDDEV(${distance}) ;;
}
dimension: distance_tiered2 {
type: tier
sql: ${distance} ;;
tiers: [500,1300]
}
}
Utiliser des filtres pour ajouter des couches à votre modèle
Un autre cas d'utilisation intéressant des améliorations consiste à ajouter des calques à votre projet. Vous pouvez créer plusieurs fichiers d'affinage, puis les inclure de manière stratégique pour ajouter des calques.
Par exemple, dans le projet FAA, un fichier faa_raw.lkml
contient toutes les vues et explorations générées à partir des tables de votre base de données. Ce fichier contient une vue pour chaque tableau de la base de données, chacun avec une dimension pour chaque colonne de la base de données.
En plus du fichier brut, vous pouvez créer un fichier faa_basic.lkml
pour ajouter un calque avec des filtres de base, tels que l'ajout de jointures à vos explorations ou l'ajout de mesures à vos vues, comme suit:
include: "faa_raw.lkml"
explore: +flights {
join: carriers {
sql_on: ${flights.carrier} = ${carriers.name} ;;
}
}
view: +flights {
measure: total_seats {
type: sum
sql: ${aircraft_models.seats} ;;
}
}
Vous pouvez ensuite ajouter un fichier faa_analysis.layer.lkml
pour ajouter un calque avec des analyses (voir la sous-section Utiliser des raffinements pour ajouter des analyses pour obtenir un exemple de fichier d'analyse).
Il vous suffit ensuite d'inclure tous les fichiers de perfectionnement dans le fichier de modèle. Vous pouvez également utiliser le fichier de modèle pour ajouter des filtres et pointer vos vues vers les tables de base de données que vous souhaitez référencer:
connection: "publicdata_standard_sql"
include: "faa_raw.lkml"
include: "faa_basic.lkml"
include: "faa_analysis.lkml"
view: +flights {
sql_table_name: lookerdata.faa.flights;;
}
view: +airports {
sql_table_name: lookerdata.faa.airports;;
}
view: +aircraft {
sql_table_name: lookerdata.faa.aircraft;;
}
view: +aircraft_models{
sql_table_name: lookerdata.faa.aircraft_models;;
}
view: +carriers {
sql_table_name: lookerdata.faa.carriers;;
}
Vous pouvez dupliquer ce fichier de modèle et pointer vers différentes tables de base de données, ou inclure différents fichiers de perfectionnement que vous avez créés pour définir les autres calques que vous souhaitez inclure dans votre modèle.
Utilisation des filtres pour les tables PDT
Comme décrit dans la section Filtres et extensions de cette page, une extension crée une copie de l'objet qui est étendu. Dans le cas de tables dérivées persistantes (PDT), il est déconseillé d'utiliser des extensions, car chaque extension d'une table PDT créera une nouvelle copie de la table dans votre base de données.
Toutefois, vous pouvez ajouter des filtres à la vue de la table PDT, car ils ne créent pas de nouvelle copie de l'objet affiné.
Utiliser des métadonnées pour afficher les précisions d'un objet
Vous pouvez cliquer sur un paramètre explore
ou view
dans l'IDE Looker et utiliser le panneau des métadonnées pour voir les améliorations apportées à l'objet. Pour en savoir plus, consultez la page de documentation Métadonnées des objets LookML.
Éléments à prendre en compte
Projets avec localisation
Lorsque vous affinez un objet, n'oubliez pas que les règles de localisation s'appliquent également à vos suggestions. Si vous affinez un objet et que vous définissez de nouveaux libellés ou descriptions, vous devez fournir des définitions de localisation dans les fichiers de chaînes de paramètres régionaux de votre projet. Pour en savoir plus, consultez la page de documentation Localiser votre modèle LookML.