Améliorations de LookML

Présentation

Les affinements LookML vous permettent d'adapter une vue ou une exploration existantes sans modifier le fichier LookML qui les contient. Cette option est idéale pour :

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 indiqué 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.

Cette précision ajoute une dimension air_carrier à la vue flights existante :

view: +flights {
  dimension: air_carrier {
    type: string
    sql: ${TABLE}.air_carrier ;;
  }
 }

Ce raffinement peut être placé dans n'importe quel fichier LookML du projet, comme un fichier de modèle, un fichier de vue ou dans son propre fichier LookML dédié. Pour en savoir plus, consultez la section Utiliser les perfectionnements dans votre projet LookML.

Le raffinement combiné au code LookML d'origine donne le même résultat que si le code LookML d'origine était celui 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'UI Looker, les utilisateurs verront la dimension Compagnie aérienne, comme si vous l'aviez ajoutée au fichier de vue d'origine.

Pour en savoir plus sur l'implémentation, consultez la section Exemple.

Différences entre les affinements et les extensions

Looker permet également d'étendre les 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. Vous pouvez ensuite modifier ces nouvelles vues pour masquer certains champs de la vue de base ou pour changer les définitions ou les libellés des champs de la vue de base.

Les affinements sont utiles lorsque vous souhaitez modifier une vue ou un Explore existants en apportant quelques ajustements à certains objets, mais que vous ne voulez pas créer de copies de la vue ou de l'Explore. Les affinements sont idéaux lorsque vous ne pouvez pas ou ne souhaitez pas modifier la vue ou l'exploration de base, et lorsque la création d'une vue ou d'une exploration nécessiterait des modifications importantes d'autres références LookML. Pour obtenir un exemple de ce cas d'utilisation, consultez la section Exemple sur cette page.

Dans la plupart des cas d'utilisation, les affinements constituent une alternative plus simple et plus propre à 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 affinements peuvent contenir des extensions sur cette page.

Les affinements remplacent la plupart des paramètres

Il est important de noter 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, une précision est apportée à cette dimension avec hidden: no :


include: "/views/faa_flights.view.lkml"

view: +faa_flights {
  dimension: carrier {
    hidden: no
  }
}

La dernière précision prévaut. Par conséquent, hidden: no est appliqué et la dimension s'affiche dans la vue finale.

Dans certains cas, les affinements sont additifs au lieu d'être prioritaires. Pour en savoir plus, consultez la section Certains paramètres sont additifs sur cette page.

Certains paramètres sont additifs

Dans de nombreux cas, si l'affinage contient le même paramètre que l'objet affiné, l'affinage remplacera les valeurs de paramètre de l'objet affiné.

Toutefois, les affinements 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 :

Par exemple, voici une vue qui comporte 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 qui présente différentes valeurs 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 affichera 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 affinements de manière très créative. Mais cela signifie également que les développeurs doivent être très attentifs à l'ordre dans lequel les affinements sont appliqués :

  • Dans un projet, les affinements sont appliqués dans l'ordre dans lequel leurs fichiers sont inclus. Les affinements des fichiers inclus en dernier remplacent ceux des fichiers inclus plus tôt.
  • Dans un même fichier, les affinements sont appliqués ligne par ligne, de haut en bas. Les affinements dont le numéro de ligne est le plus élevé sont appliqués en dernier et remplacent les affinements précédents en cas de conflit.

Par exemple, dans le fichier de vue suivant, la vue faa_flights est affinée deux fois. La première affinerie masque une dimension (hidden: yes), tandis que la seconde l'affiche (hidden: no). En cas de conflit comme celui-ci, l'affinerie la 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 similaire pour inclure plusieurs fichiers dans un projet : les affinements du dernier fichier listé dans les inclusions seront prioritaires. Par exemple, si un fichier de modèle inclut les fichiers suivants :

include: "/refinements/distance_analysis.lkml"
include: "/refinements/finishing_touches.lkml"

Les affinements dans distance_analysis.lkml seront appliqués en premier, puis ceux dans le fichier finishing_touches.lkml. En cas de conflit, les affinements du dernier fichier, finishing_touches.lkml, seront prioritaires.

Utiliser final: yes pour empêcher d'autres améliorations

Comme décrit précédemment, le même objet peut être affiné plusieurs fois à plusieurs endroits, et le dernier affinement remplacera 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 renverra une erreur LookML s'il existe des perfectionnements qui seraient appliqués après ce perfectionnement final, ou si un développeur tente d'ajouter un nouveau perfectionnement qui serait appliqué après ce perfectionnement final. Par exemple, la deuxième précision dans ce fichier de vue créerait une erreur LookML, car la précision précédente 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 le flag final: yes à un affinement est un bon moyen de vérifier que vos affinements sont appliqués dans l'ordre souhaité.

Les affinements 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 de perfectionnement.

Pour résumer le comportement de extends et des affinements :

  • L'extension d'un objet crée une copie de l'objet, puis la développe. 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 intégrera une copie de la vue de base. À partir de là, un développeur pourra 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 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 de l'extension, consultez la page de documentation Réutiliser du code avec extends.)
  • Affiner un objet ajoute une couche de modifications à l'objet, 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.

Voici un exemple d'utilisation standard des affinements : une exploration appelée orders et l'exploration +orders qui l'affine :

explore: orders {
  view_name: orders
  # other Explore parameters
}

explore: +orders {
  label: "Orders Information"
  # other Explore parameters to build on the original Explore
}

Vous pouvez également ajouter un affinement qui inclut un extends. En reprenant l'exemple, voici la même exploration orders. Mais en plus, il existe une exploration de base appelée users_base. Désormais, l'affinage +orders comporte un paramètre extends qui inclut 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 l'affinement +orders contient un extends. Le résultat est que la vue +orders va maintenant étendre l'explorateur users_base.

Comment Looker implémente extends dans les affinements

L'extension d'un objet dans un affinement est un concept LookML avancé. Avant d'utiliser extends dans un affinement, vous devez bien comprendre les points suivants :

  • Comment Looker implémente extends : si un élément LookML est défini à la fois dans l'objet étendu et dans l'objet étendant, la version de l'objet étendant est utilisée, sauf si le paramètre est additif. Pour en savoir plus, consultez la page de documentation Réutiliser du code avec extends.
  • 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 affinements sont appliqués dans l'ordre sur cette page.

Enfin, vous devez comprendre comment Looker combine ces principes pour implémenter extends utilisé dans les affinements. Voici l'ordre d'implémentation de Looker, chaque étape remplaçant la précédente en cas de conflit :

  1. Valeurs de extends spécifiées dans l'objet
  2. Valeurs de extends spécifiées dans les affinements de l'objet
  3. Valeurs de l'objet
  4. Valeurs issues des affinements de l'objet

Pour illustrer cela, 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 :

  1. Valeurs du extends spécifié dans l'objet. Étant donné que l'exploration orders comporte un paramètre extends, Looker commence par les éléments LookML de l'objet étendu, qui est l'exploration orders_base dans ce cas. À ce stade, la valeur label est "Base des commandes".
  2. Valeurs du extends spécifié dans les affinements de l'objet. Étant donné que orders comporte un affinement et que celui-ci comporte un paramètre extends, Looker applique ensuite les éléments LookML de l'extension de l'affinement, qui dans ce cas est l'exploration users_base. À ce stade, la valeur label est "Base d'utilisateurs".
  3. Valeurs de l'objet. Maintenant que toutes les extensions ont été traitées, Looker applique les éléments de l'objet étendu, qui dans ce cas est l'exploration orders. En cas de conflit, l'objet étendu est prioritaire. La valeur label est désormais "Orders" (Commandes).
  4. Valeurs issues des affinements de l'objet. Enfin, Looker applique les éléments de toutes les améliorations apportées à l'exploration orders. En cas de conflit, l'objet d'affinements est prioritaire. La valeur label est désormais "Commandes affinées".

Les filtres extends sont cumulatifs.

Comme décrit dans la section Les affinements remplacent les paramètres de cette page, les affinements 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 accordé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. En plus de l'users_base Explorer et de l'+orders Affiner qui étend l'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 affinements +orders ajoutent users_base à la liste extends. Le résultat est que l'exploration +orders va maintenant étendre orders_base et users_base, comme si c'était le code LookML d'origine pour l'exploration :

explore: orders {
  extends: [orders_base, users_base]
}

Ensuite, en cas de conflit, la priorité est accordé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 conflictuels de orders_base.

Le concept d'extension de plusieurs objets à la fois est abordé sur la page de documentation Réutiliser du code avec extends.

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 affinements du même objet, l'ordre des affinements est important. Comme décrit dans la section Les améliorations sont appliquées dans l'ordre de cette page, la dernière amélioration d'un fichier remplace les précédentes.

Utiliser des perfectionnements dans votre projet LookML

Voici les grandes étapes à suivre pour affiner les vues et les explorations dans votre projet :

  1. Identifiez la vue ou l'exploration que vous souhaitez affiner.
  2. Décidez où vous souhaitez héberger vos affinements. Vous pouvez ajouter des affinements dans n'importe quel fichier LookML existant ou créer des fichiers LookML distincts pour vos affinements. (Pour obtenir un exemple de création de fichiers LookML génériques, consultez la procédure de création d'un fichier de test de données sur la page de documentation Comprendre les autres fichiers de projet.)
  3. Utilisez le paramètre include pour intégrer vos améliorations à votre modèle :
    • Dans le fichier où vous écrivez vos affinements, vous devez inclure les fichiers du LookML que vous affinez. L'IDE Looker vous avertit si vous essayez d'affiner un objet qui n'est pas inclus.
    • Dans votre fichier de modèle, incluez les fichiers dans lesquels vos affinements 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 affinements pour ajouter des calques à votre modèle sur cette page.

Exemple

Le perfectionnement des objets LookML est un moyen simple d'adapter les vues et les explorations sans avoir à modifier le code LookML d'origine. C'est particulièrement utile lorsque vos vues et vos explorations sont en lecture seule dans votre projet, comme avec les fichiers importés d'autres projets. Voici un exemple de précision 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 le fichier Explorer 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 le modifier directement. Vous pouvez plutôt y ajouter un affinement. Voici un exemple de fichier distinct appelé refinements.lkml contenant 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 permet d'importer le fichier aircraft.explore.lkml d'origine à partir du projet importé (consultez la page de documentation Importer des fichiers depuis d'autres projets pour savoir comment faire référence aux fichiers de projet importés).
  • Améliorations apportées à l'onglet Explorer de aircraft :
    • Le signe + devant le nom de l'exploration indique qu'il s'agit d'un affinement d'une exploration existante.
    • Le paramètre label remplace le libellé "Explorer" par "Avion simplifié".
    • Le paramètre fields spécifie que seuls trois champs seront affichés dans l'exploration.

Le résultat final est le même que si les vues aircraft et aircraft d'origine étaient les suivantes :

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 affinements afin de personnaliser une vue unique pour plusieurs cas d'utilisation, consultez la recette du livre de cuisine Maximiser la réutilisation du code avec DRY LookML : personnaliser une vue de base unique pour plusieurs cas d'utilisation.

Autres cas d'utilisation des affinements

Comme mentionné précédemment, les affinements sont idéaux pour adapter les objets LookML en lecture seule, tels que les blocs Looker ou les fichiers importés.

Toutefois, une fois que vous aurez compris comment ajouter des affinements et les inclure dans vos modèles, vous pourrez faire des choses très intéressantes avec vos projets, comme le montrent les exemples suivants.

Utiliser des affinements pour ajouter des analyses

Vous pouvez utiliser des affinements pour ajouter des analyses à votre modèle sans modifier les 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 perfectionnements pour ajouter des analyses. Voici un exemple de table dérivée appelée distance_stats qui contient une analyse de la distance. Cet exemple montre comment affiner l'exploration flights existante à partir du fichier faa_basic.lkml qui joint la table dérivée distance_stats à l'exploration flights. De plus, en bas de l'exemple, la vue flights existante est affinée pour ajouter de nouveaux champs issus 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 affinements pour ajouter des calques à votre modèle

Un autre cas d'utilisation intéressant des affinements consiste à ajouter des calques à votre projet. Vous pouvez créer plusieurs fichiers d'affinage 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 qui contient toutes les vues et tous les Explorers générés à partir des tables de votre base de données. Ce fichier comporte une vue pour chaque table de la base de données, chacune 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 améliorations de base, comme des jointures à vos explorations ou des 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 un calque avec des analyses (consultez la sous-section Utiliser des affinements pour ajouter des analyses pour obtenir un exemple de fichier d'analyse).

Il vous suffit ensuite d'inclure tous les fichiers d'affinage dans le fichier modèle. Vous pouvez également utiliser le fichier de modèle pour ajouter des précisions afin de 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 d'affinage que vous avez créés pour définir d'autres calques que vous souhaitez inclure dans votre modèle.

Utiliser des affinements pour les PDT

Comme décrit dans la section Améliorations par rapport aux extensions de cette page, une extension crée une copie de l'objet étendu. Dans le cas des tables dérivées persistantes (PDT), vous ne devez pas utiliser d'extensions, car chaque extension d'une PDT créera une nouvelle copie de la table dans votre base de données.

Toutefois, vous pouvez ajouter des affinements à la vue du PDT, car ils ne créent pas de copie de l'objet affiné.

Utiliser les métadonnées pour afficher les affinements d'un objet

Vous pouvez cliquer sur un paramètre explore ou view dans l'IDE Looker et utiliser le panneau de métadonnées pour afficher les affinements apportés à l'objet. Pour en savoir plus, consultez la page de documentation Métadonnées pour les objets LookML.

Éléments à prendre en compte

Projets avec localisation

Lorsque vous affinez un objet, sachez que les règles de localisation s'appliquent également à vos affinements. 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 Localisation de votre modèle LookML.