Présentation
Les améliorations LookML vous permettent d'adapter une vue ou une exploration existante sans modifier le fichier LookML qui la contient. C'est la solution idéale pour:
- Des projets avec des blocs Looker, qui utilisent des éléments LookML prédéfinis
- Les projets qui importent des fichiers d'autres projets
- Projets dans lesquels vous devez souvent générer des fichiers à partir des 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 endroit (configurations en étoile)
Par exemple, si votre projet contient le fichier de vue suivant:
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'affinement d'une vue existante.
Ce filtre ajoute une dimension air_carrier
à la vue flights
existante:
view: +flights {
dimension: air_carrier {
type: string
sql: ${TABLE}.air_carrier ;;
}
}
Ce perfectionnement peut figurer dans n'importe quel fichier LookML du projet, tel qu'un fichier de modèle, un fichier de vue, ou dans son propre fichier LookML dédié. Consultez la section Utiliser des filtres dans votre projet LookML pour en savoir plus.
Cette amélioration combinée au code LookML d'origine produit 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 Transporteur aérien, 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 l'exemple ci-dessous.
Améliorations par rapport aux extensions
Looker prend également en charge l'extending d'objets LookML. L'extension est utile lorsque vous souhaitez créer une copie d'une vue ou d'une exploration existante afin de pouvoir y ajouter de nouveaux objets. Par exemple, vous pouvez créer une vue de base qui définit tous vos champs, puis créer plusieurs vues qui étendent la vue de base. Ces nouvelles vues peuvent ensuite être modifiées pour masquer certains champs de la vue de base, ou pour modifier les définitions ou les libellés des champs depuis la vue de base.
Les raffinements sont utiles lorsque vous souhaitez modifier une vue ou une exploration existante en apportant des ajustements ou des ajustements à certains objets, mais que vous ne voulez pas créer de copies de la vue ou de l'exploration. Les améliorations sont idéales lorsque vous ne pouvez pas ou ne souhaitez pas modifier la vue de base ou l'exploration, et lorsque la création d'une nouvelle vue ou exploration nécessite des modifications importantes d'autres références LookML. Consultez la section Exemple de cette page pour voir un exemple de ce cas d'utilisation.
Dans la plupart des cas d'utilisation, les filtres constituent une alternative plus simple et plus claire à extends
.
Les développeurs LookML avancés peuvent utiliser le paramètre extends
dans un perfectionnement LookML. Pour en savoir plus, consultez la section Les filtres peuvent contenir des extensions sur cette page.
Les filtres remplacent la plupart des paramètres
Il est important de noter que, dans la plupart des cas, un filtre 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, un filtre est appliqué à cette dimension avec hidden: no
:
include: "/views/faa_flights.view.lkml"
view: +faa_flights {
dimension: carrier {
hidden: no
}
}
La dernière suggestion prévaut. Par conséquent, hidden: no
est appliqué et la dimension sera affichée dans la vue finale.
Dans certains cas, les filtres sont additifs au lieu d'être remplacés. Pour en savoir plus, consultez la section Certains paramètres sont additifs.
Certains paramètres se cumulent
Dans de nombreux cas, si le filtre contient le même paramètre que l'objet affiné, il remplace les valeurs de paramètre de l'objet affiné.
Toutefois, les améliorations peuvent être additives pour certains paramètres. En d'autres termes, 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 Les filtresextends
sont cumulatifs sur cette page.)
Pour les explorations:
access_filter
aggregate_table
extends
(Pour en savoir plus, consultez la section Les filtresextends
sont cumulatifs sur cette page.)join
query
Par exemple, voici une vue comportant une dimension name
avec 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 un affinement de la vue carriers
, avec une dimension name
dont les valeurs sont 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 améliorations 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 améliorations de nombreuses façons créatives. Mais 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 filtres issus des fichiers inclus en dernier remplacent ceux issus des fichiers inclus précédemment.
- Dans un même fichier, les filtres sont appliqués ligne par ligne dans le sens descendant. Les filtres ayant le numéro de ligne le plus élevé sont appliqués en dernier et remplacent les suggestions précédentes en cas de conflit.
Par exemple, dans le fichier de vue suivant, il existe deux améliorations de la vue faa_flights
. Le premier filtre masque une dimension (hidden: yes
) et le second filtre la dimension (hidden: no
). En cas de conflit de ce type, le filtre le plus bas dans le fichier est prioritaire :
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 filtres du dernier fichier listé dans les inclusions prévalent. Par exemple, si un fichier de modèle contient les fichiers suivants:
include: "/refinements/distance_analysis.lkml"
include: "/refinements/finishing_touches.lkml"
Les filtres du fichier distance_analysis.lkml
sont appliqués en premier, puis ceux du fichier finishing_touches.lkml
le sont. En cas de conflit, les filtres du dernier fichier, finishing_touches.lkml
, prévalent.
Utiliser final: yes
pour éviter d'autres améliorations
Comme décrit précédemment, le même objet peut être affiné plusieurs fois à plusieurs endroits, et le dernier filtre remplacera tous les filtres précédents.
Si vous souhaitez appliquer un filtre à la vue ou à l'exploration, vous pouvez y ajouter l'indicateur final: yes
. L'IDE Looker renvoie une erreur LookML si des améliorations existantes sont appliquées après ce perfectionnement, ou si un développeur tente d'ajouter un affinement qui serait appliqué après ce perfectionnement final. Par exemple, le second filtre de ce fichier de vue crée une erreur LookML, car le filtre 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
}
}
L'ajout de l'indicateur final: yes
à un filtre est un bon moyen de vérifier que vos suggestions sont appliquées dans l'ordre souhaité.
Les raffinements peuvent contenir des extensions
Les développeurs LookML avancés peuvent utiliser un paramètre extends
dans un perfectionnement LookML, ce qui ajoute l'objet étendu à l'objet en cours d'affinement.
Pour résumer le comportement de extends
et les améliorations:
- L'extension d'un objet crée une copie de celui-ci, puis s'appuie sur celle-ci. Par exemple, vous pouvez créer une vue de base qui définit tous vos champs, puis créer plusieurs vues qui étendent la vue de base. Chacune de ces nouvelles vues incorporera une copie de la vue de base à partir de laquelle un développeur peut ajouter différents champs, filtres ou autres propriétés pour modifier le contenu de la vue de base. L'idée est de commencer avec un objet de base, puis de l'utiliser de différentes manières dans plusieurs autres objets. Pour en savoir plus sur l'utilisation d'extensions, consultez la page de documentation Réutiliser du code avec des extensions.
- L'affinage d'un objet ajoute une couche de modifications à celui-ci, mais contrairement à l'extension, l'affinage ne crée pas plusieurs copies de l'objet. L'idée est de s'appuyer sur un objet de base sans modifier son code LookML d'origine.
Pour illustrer l'utilisation standard des améliorations, voici une exploration appelée orders
et l'exploration +orders
qui l'affinent:
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 filtre qui inclut un extends
. Sur la base de l'exemple, voici la même exploration orders
. Il existe également une exploration de base appelée users_base
, et le raffinement +orders
comporte désormais un paramètre extends
qui apporte 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 particularité ici est que le raffinement +orders
comporte 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 perfectionnement est un concept LookML avancé. Avant d'utiliser extends
dans un filtre, vous devez maîtriser les points suivants:
- Comment Looker implémente
extends
: si un élément LookML est défini à la fois dans l'objet d'extensioned 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 des améliorations: si un élément LookML est défini dans plusieurs améliorations, la dernière suggestion remplace les améliorations précédentes. Pour en savoir plus, consultez la section Les filtres sont appliqués dans l'ordre sur cette page.
Enfin, vous devez comprendre comment Looker combine ces principes pour implémenter les extends
utilisées dans les améliorations. Voici l'ordre que Looker implémente, chaque étape remplaçant la précédente en cas de conflit:
- Valeurs des
extends
spécifiées dans l'objet - Valeurs des
extends
spécifiées dans les améliorations de l'objet - Valeurs de l'objet
- Valeurs issues des améliorations 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. Comme l'explorationorders
comporte un paramètreextends
, Looker commence par les éléments LookML de l'objet étendu, qui dans ce cas est l'explorationorders_base
. À ce stade, la valeurlabel
est "Orders Base". - Valeurs des
extends
spécifiées dans les améliorations de l'objet. Étant donné que le filtreorders
comporte un filtre et qu'il comporte un paramètreextends
, Looker applique ensuite les éléments LookML de l'extension du perfectionnement, qui dans ce cas est l'explorationusers_base
. À ce stade, la valeurlabel
correspond à "Users Base". - Valeurs de l'objet. Maintenant que toutes les extensions ont été traitées, Looker applique les éléments de l'objet d'extension, qui dans ce cas est l'exploration
orders
. En cas de conflit, l'objet étendu l'emporte. Maintenant, la valeurlabel
est "Orders". - Valeurs issues des améliorations apportées à l'objet. Enfin, Looker applique des éléments de toutes les optimisations de l'exploration
orders
. En cas de conflit, l'objet de suggestion l'emporte. La valeur du champlabel
est donc maintenant "Orders sophistiqué" (Commandes affinées).
Les extends
de raffinement sont cumulatifs
Comme indiqué dans la section Paramètres de remplacement des filtres de cette page, les filtres 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 filtre, la valeur du paramètre extends
est ajoutée à la liste des éléments étendus dans l'objet d'origine ou dans les améliorations précédentes, le cas échéant. Ensuite, en cas de conflit, la priorité est donnée au dernier élément de la chaîne d'extensions.
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 la orders_base
, puis les améliorations +orders
ajoute le 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'extensions. Dans cet exemple, les éléments de users_base
remplacent tous les éléments en conflit dans orders_base
.
Le concept d'extension de plusieurs objets à la fois est abordé sur 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, dans le cas de plusieurs améliorations du même objet, l'ordre des améliorations est important. Comme indiqué dans la section Les filtres sont appliqués dans l'ordre de cette page, la dernière suggestion d'un fichier remplace les suggestions précédentes.
Utiliser des améliorations dans votre projet LookML
Voici les grandes étapes à suivre pour affiner les vues et les explorations dans votre projet:
- Identifiez la vue ou l'exploration que vous souhaitez affiner.
- Choisissez l'emplacement où vous souhaitez placer vos filtres. Vous pouvez ajouter des perfectionnements dans n'importe quel fichier LookML existant ou créer des fichiers LookML distincts pour vos perfectionnements. Pour obtenir un exemple de création de fichiers LookML génériques, reportez-vous à la procédure de création d'un fichier de test de données sur la page Comprendre les autres fichiers de projet de la documentation.
- Utilisez le paramètre
include
pour intégrer vos améliorations dans votre modèle :- Dans le fichier dans lequel vous écrivez vos améliorations, vous devez inclure les fichiers du code 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 filtres sont définis. 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
Le raffinement des objets LookML est un moyen simple d'adapter des vues et des explorations sans avoir à modifier le code LookML d'origine. Cela s'avère particulièrement utile lorsque les vues et les explorations sont en lecture seule dans votre projet, comme avec des fichiers importés 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 contient plusieurs vues, chacune comportant de nombreuses dimensions.
Un autre projet LookML appelé e_faa_refined
importe maintenant le fichier d'exploration aircraft
. Dans le projet e_faa_refined
, vous pouvez utiliser un affinement pour simplifier considérablement l'exploration aircraft
.
Vous ne pouvez pas modifier directement l'exploration aircraft
, car il s'agit d'un fichier importé. À la place, vous pouvez lui ajouter un filtre. Voici un exemple de fichier distinct nommé refinements.lkml
qui contient ce code 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
à importer dans le fichieraircraft.explore.lkml
d'origine du projet importé (consultez la page de documentation Importer des fichiers à partir 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 semblable à l'exploration aircraft
et à la vue 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 des améliorations permettant de personnaliser une vue unique pour plusieurs cas d'utilisation, consultez le livre de recettes Maximiser la réutilisabilité du code avec DRY LookML: Personnaliser une vue de base unique pour plusieurs cas d'utilisation.
Autres cas d'utilisation des améliorations
Comme indiqué précédemment, les améliorations sont idéales pour adapter des objets LookML en lecture seule, tels que des blocs Looker ou des fichiers importés.
Mais une fois que vous avez compris comment ajouter des améliorations et les inclure dans vos modèles, vous pouvez faire des choses intéressantes avec vos projets, comme décrit dans les exemples suivants.
Utiliser des filtres pour ajouter des analyses
Vous pouvez utiliser des améliorations 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 des 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
qui comporte une analyse des distances. Cet exemple présente 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
. De plus, au bas de l'exemple, la vue flights
existante est affinée pour ajouter de nouveaux champs 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 couches à votre projet. Vous pouvez créer plusieurs fichiers d'affinement et les inclure de manière stratégique pour ajouter des calques.
Par exemple, dans le projet FAA, il existe un fichier faa_raw.lkml
contenant toutes les vues et explorations générées à partir des tables de votre base de données. Ce fichier dispose d'une vue pour chaque tableau de la base de données, chacun avec des dimensions 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 améliorations de base, comme l'ajout de jointures à vos explorations ou l'ajout de mesures à vos vues, comme ceci:
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 une couche avec des analyses (consultez la sous-section Utiliser des filtres pour ajouter des analyses pour obtenir un exemple de fichier d'analyse).
Il vous suffit ensuite d'inclure tous les fichiers d'affinement dans le fichier de modèle. Vous pouvez également utiliser le fichier de modèle pour ajouter des filtres afin de diriger 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 d'affinement que vous avez créés pour définir d'autres calques que vous souhaitez intégrer au modèle.
Utiliser des filtres pour les PDT
Comme indiqué dans la section Filtres par rapport aux extensions de cette page, une extension crée une copie de l'objet étendu. Dans le cas de tables dérivées persistantes (PDT), vous ne devez pas utiliser d'extensions, car chaque extension d'une PDT crée une copie de la table dans votre base de données.
Toutefois, vous pouvez ajouter des filtres à la vue de la PDT, car ils ne créent pas de nouvelle copie de l'objet en cours d'affinement.
Utiliser des métadonnées pour afficher les améliorations apportées à 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 afficher 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, gardez à l'esprit que les règles de localisation s'appliquent également à vos suggestions. Si vous affinez un objet, puis 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.