Filtres LookML

Il s'agit d'un sujet avancé qui suppose que le lecteur possède une connaissance approfondie de LookML.

Présentation

Les filtres LookML vous permettent d'adapter une vue ou une exploration existantes sans modifier le fichier LookML qui le contient. C'est idéal 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é ci-dessous: utilisez le paramètre view avec le même nom de vue, mais ajoutez le signe plus (+) devant le nom pour indiquer qu'il s'agit d'une suggestion 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 filtre peut être intégré dans n'importe quel fichier LookML du projet, tel qu'un fichier de modèle, un fichier de vue ou son propre fichier LookML. Pour en savoir plus, consultez la section Utiliser des filtres dans votre projet LookML.

Le raffinement combiné au LookML d'origine produit le résultat final comme s'il s'agissait du LookML d'origine pour 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, la dimension Transporteur aérien s'affiche comme si vous aviez ajouté la dimension au fichier de vue d'origine.

Pour en savoir plus, consultez l'exemple ci-dessous.

Ajustements par rapport aux extensions

Looker accepte également l'extension des objets LookML. L'extension est utile lorsque vous souhaitez créer une copie d'une vue existante ou Explorer afin d'y ajouter des objets. Par exemple, vous pouvez créer une vue de base qui définit tous vos champs, puis créer plusieurs vues supplémentaires 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 la définition ou les libellés des champs de la vue de base.

Les suggestions s'avèrent utiles lorsque vous souhaitez modifier une vue existante ou l'option "Explorer" en effectuant certains ajustements ou ajustements d'objets, mais que vous ne souhaitez pas créer de copies de la vue ou de la fonction "Explorer". Les filtres sont parfaits dans les situations où vous ne pouvez pas ou ne souhaitez pas modifier la vue de base ou l'onglet "Explorer", et dans les situations où la création d'une vue ou d'une exploration nécessite d'importantes modifications d'autres références LookML. Consultez la section Exemple de cette page pour obtenir un exemple de ce cas d'utilisation.

Dans la plupart des cas, les filtres offrent une alternative plus simple et plus claire à extends.

Les développeurs LookML avancés peuvent utiliser le paramètre extends dans un filtre LookML. Pour en savoir plus, consultez la section Les filtres peuvent contenir des extensions de cette page.

Les filtres remplacent la plupart des paramètres

Il est important de noter que, dans la plupart des cas, un affinement remplacera les paramètres d'origine d'un objet. Dans l'exemple suivant, la vue d'origine a une dimension masquée (hidden: yes):

view: faa_flights {
  dimension: carrier {
    hidden: yes
  }
}

Dans un autre fichier, vous pouvez affiner cette dimension avec hidden: no :


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

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

Le dernier filtre étant prioritaire, hidden: no est appliqué et la dimension s'affiche dans la vue finale.

Dans certains cas, les filtres sont additionnels au lieu de remplacer. Pour en savoir plus, consultez la section Certains paramètres sont additifs de cette page.

Certains paramètres sont cumulatifs

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

Cependant, les filtres peuvent être additionnels pour certains paramètres, ce qui signifie que les valeurs de l'objet de base sont utilisées avec les valeurs de l'objet affiné.

Les paramètres suivants sont additionnels :

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 ayant 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 avancée, les deux paramètres link s'ajoutent les uns aux autres. Par conséquent, la dimension name comporte les deux liens. La dimension se présente comme suit dans une exploration:

Les filtres sont appliqués dans l'ordre

Un objet peut être affiné à plusieurs reprises et à différents endroits, ce qui permet aux développeurs Looker d'utiliser les filtres de nombreuses façons créatives. Cela signifie également que les développeurs doivent faire très attention à l'ordre dans lequel les filtres sont appliqués:

  • Dans un projet, les filtres sont appliqués dans l'ordre dans lequel leurs fichiers sont inclus. Les filtres appliqués à des fichiers inclus en dernier remplaceront ceux appliqués précédemment.
  • Dans un seul fichier, les filtres sont appliqués ligne par ligne vers le bas. Les filtres ayant le numéro de ligne le plus élevé sont appliqués en dernier et remplacent tous les filtres précédents en cas de conflit.

Vous pouvez utiliser l'option final: yes pour vérifier que vos filtres sont appliqués dans l'ordre attendu. Pour en savoir plus, consultez la section Utiliser final: yes pour empêcher d'autres filtres.

Par exemple, dans le fichier de vue suivant, il existe deux filtres de la vue faa_flights. Le premier filtre permet de masquer une dimension (hidden: yes), tandis que le second permet d'afficher la dimension (hidden: no). En cas de conflit de ce type, le filtre le plus bas du 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évaudront. Par exemple, si un fichier de modèle inclut les fichiers suivants:

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

Tous les filtres du distance_analysis.lkml s'appliqueront d'abord, puis tous les filtres du fichier finishing_touches.lkml. En cas de conflit, les filtres du dernier fichier, finishing_touches.lkml, seront prioritaires.

Étant donné que les filtres exploitent l'ordre des inclusions, vous ne devez pas utiliser de caractères génériques si vous souhaitez utiliser des filtres. En règle générale, il est préférable d'éviter d'utiliser des caractères génériques dans les vues, surtout si votre projet contient un grand nombre de fichiers de vue ou s'il utilise des tables dérivées persistantes. Toutefois, avec des filtres en particulier, il n'est pas recommandé d'utiliser des caractères génériques dans vos inclusions.

Utiliser final: yes pour éviter d'autres filtres

Comme décrit précédemment, un même objet peut être affiné plusieurs fois à plusieurs endroits, et le dernier filtre remplace tous les filtres précédents.

Si vous souhaitez utiliser le filtre final de la vue ou de l'onglet "Explorer", vous pouvez ajouter l'option final: yes au filtre. L'IDE Looker renvoie une erreur LookML si des filtres existants sont appliqués après ce dernier filtre ou si un développeur tente d'ajouter un nouveau filtre qui sera appliqué après ce filtre. Par exemple, le deuxième filtre de ce fichier de vue crée une erreur LookML, car le filtre précédent comporte l'option 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'option final: yes à un filtre est un bon moyen de vérifier que vos filtres sont appliqués dans l'ordre souhaité.

Les filtres peuvent contenir des extensions

Les développeurs LookML avancés peuvent utiliser un paramètre extends dans un filtre LookML, qui ajoute l'objet étendu à l'objet en cours d'affinement.

Pour résumer le comportement de extends et les filtres:

  • L'extension d'un objet crée une 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 créer plusieurs vues supplémentaires qui étendent la vue de base. 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 afin de 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 les extensions, consultez la page Réutiliser du code avec des extensions.
  • L'amélioration d'un objet ajoute une couche de modifications, mais, contrairement à l'extension, l'affinement ne permet pas de créer plusieurs copies de l'objet. L'idée est de créer un objet de base sans modifier son LookML d'origine.

À titre d'exemple d'utilisation standard des filtres, voici 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
}

En plus de cela, vous pouvez ajouter un filtre qui inclut un extends. Pour reprendre l'exemple, voici la même exploration orders. En outre, il existe une exploration de base appelée users_base, et le filtre +orders comporte désormais un paramètre extends qui ajoute 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é de ce filtre +orders est le extends. Par conséquent, la vue +orders étend la découverte users_base.

Comment Looker implémente extends dans les filtres

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

  • Mise en œuvre de extends par Looker: si un élément LookML est défini à la fois dans l'objet étendu ed et dans l'objet extension, la version de l'objet extensible est utilisée, sauf si le paramètre est additif. Pour en savoir plus, consultez la page Réutiliser du code avec des extensions.
  • Comment Looker implémente des filtres: si un élément LookML est défini dans plusieurs filtres, le dernier filtre remplace les filtres précédents. Pour en savoir plus, consultez la section Ajustements appliqués dans l'ordre de cette page.

Enfin, vous devez comprendre comment Looker combine ces principes pour implémenter les extends utilisés dans les filtres. Voici l'ordre mis en œuvre par Looker, chaque étape remplaçant la précédente en cas de conflits:

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

Pour illustrer ceci, 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 de extends spécifiées dans l'objet. Étant donné que orders Explore contient un paramètre extends, Looker commence avec les éléments LookML de l'objet qui est étendu, ce qui correspond à la découverte orders_base. À ce stade, la valeur de label est "Orders Base".
  2. Valeurs de extends spécifiées dans les filtres de l'objet. Comme orders comporte un filtre et que ce dernier possède un paramètre extends, Looker applique ensuite les éléments LookML de l'extension du filtre, qui correspond dans ce cas à la fonction Explorer 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 extensible, qui est dans le cas présent, orders Explorer. En cas de conflit, l'objet étendu l'emporte. À présent, la valeur label est "Orders".
  4. Valeurs provenant des filtres de l'objet. Enfin, Looker applique les éléments de tous les filtres de l'exploration orders. En cas de conflit, l'objet du filtre l'emporte. Ainsi, la valeur label est"Orders affinée".

Les filtres extends s'ajoutent les uns aux autres

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 filtres précédents, le cas échéant. 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. En outre, il existe une option users_base Explorer 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 filtres +orders ajoutent users_base à la liste extends. Par conséquent, la fonction Explorer +orders étend désormais orders_base et users_base, comme s'il s'agissait du LookML d'origine pour l'exploration:

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

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 remplaceront tous les éléments en conflit dans orders_base.

La notion d'extension de plusieurs objets à la fois est abordée dans la page 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. Dans le cas de plusieurs filtres associés au même objet, l'ordre des filtres est important. Comme décrit dans la section Affinement des règles selon l'ordre de cette page, le dernier filtre d'un fichier remplace les précédents.

Utiliser des filtres 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 à affiner.
  2. Choisissez l'emplacement de vos filtres. Vous pouvez ajouter des filtres à n'importe quel fichier LookML existant ou créer des fichiers LookML distincts pour vos filtres. Pour découvrir 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 du projet.
  3. Utilisez le paramètre include pour intégrer vos filtres à votre modèle :
    • Dans le fichier où vous écrivez vos filtres, vous devez inclure les fichiers du LookML que vous ajustez. 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 filtres sont définis. Vous pouvez combiner des fichiers et utiliser des inclusions de façon très créative. Pour en savoir plus, consultez la section Utiliser des filtres pour ajouter des couches à votre modèle.

Exemple

L'amélioration des objets LookML permet d'adapter facilement des vues et des explorations sans avoir à modifier le LookML d'origine. Cette fonctionnalité est particulièrement utile lorsque vos vues et vos explorations sont en lecture seule dans votre projet, comme pour les fichiers importés à partir d'autres projets. Voici un exemple de recherche avancée.

Voici le lookML pour 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 alors le fichier Explorer aircraft. Dans le projet e_faa_refined, vous pouvez utiliser un filtre pour simplifier considérablement l'exploration aircraft.

aircraft Explorer étant un fichier importé, vous ne pouvez pas le modifier directement. Vous pouvez cependant y ajouter un filtre. Voici un exemple de fichier distinct appelé refinements.lkml qui contient 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 permettant 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 en savoir plus sur l'utilisation de fichiers de projet importés).
  • Améliorations apportées à la aircraft Explorer :
    • Le signe + devant le nom de l'exploration indique une amélioration par rapport à une exploration existante.
    • Le paramètre label change le libellé d'Explorer en "simplifié aéronautique".
    • Le paramètre fields spécifie que seuls trois champs seront affichés dans l'onglet "Explorer".

Au final, c'est comme s'il s'agissait de la vue aircraft d'origine et de la vue aircraft:

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
  }
}

Autres cas d'utilisation des filtres

Comme indiqué précédemment, les filtres sont parfaits 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 filtres et les inclure dans vos modèles, vous pouvez réaliser des tâches très intéressantes avec vos projets, comme décrit dans les exemples suivants.

Ajouter des analyses à l'aide de filtres

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 ajoutez des analyses à l'aide de filtres. Voici un exemple de nouvelle table dérivée appelée distance_stats, qui comporte une analyse de distance. Cet exemple affine les filtres de la fonction flights Explorer existante du fichier faa_basic.lkml qui joint la table dérivée de la table distance_stats à la fonction flights Explorer. 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 filtres est l'ajout de couches à votre projet. Vous pouvez créer plusieurs fichiers de filtre, puis les inclure de manière stratégique pour ajouter des calques.

Par exemple, dans le projet FAA, il y a un fichier faa_raw.lkml contenant toutes les vues et chaque exploration qui ont été générées à partir des tables de votre base de données. Ce fichier présente 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 une couche 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 contenant des analyses (consultez la section Utiliser des filtres pour ajouter des analyses pour obtenir un exemple de fichier d'analyse).

Ensuite, il vous suffit d'inclure tous les fichiers de filtre dans le fichier de modèle. Vous pouvez également utiliser le fichier de modèle pour ajouter des filtres afin de renvoyer 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 vous pouvez inclure différents fichiers de filtre que vous avez créés pour définir d'autres couches dans votre modèle.

Utiliser des filtres pour PDT

Comme décrit dans la section Affinements comparés aux extensions de cette page, une extension crée une copie de l'objet qui est étendu. Dans le cas des tables dérivées persistantes, vous ne devez pas utiliser d'extensions, car chaque extension d'un PDT crée une copie de la table dans votre base de données.

Toutefois, vous pouvez ajouter des filtres à la vue "PDT", car ils ne créent pas de copie de l'objet à affiner.

Utiliser les métadonnées pour afficher les filtres 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 afficher tous les filtres de l'objet. Pour en savoir plus, consultez la page 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 suggestions. Si vous ajustez 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 Localiser votre modèle LookML.