Test technique Looker avancé : LookML, explores, PDTs, déploiement

Looker est l outil BI le plus technique du marché. Sa valeur vient du LookML, le langage de modélisation sémantique. En entretien, on évalue la capacité à architecturer un modèle LookML maintenable.

Data Builder·Juin 2025·7 min de lecture·Analytics Engineer

Sommaire

Modèle sémantique LookML
Explores et joins
Persistent Derived Tables
Dimensions et mesures avancées
Git et déploiement
Performance et optimisation
Grille

1Qu est-ce que le modèle sémantique LookML

Question discriminante

Pourquoi le modèle sémantique LookML est-il la principale valeur de Looker ?

# view : définit les champs disponibles
view: orders {
  sql_table_name: analytics.fct_orders ;;

  dimension: order_id {
    type: string
    primary_key: yes
    sql: ${TABLE}.order_id ;;
  }

  dimension_group: order_date {
    type: time
    timeframes: [date, week, month, quarter, year]
    sql: ${TABLE}.order_date ;;
  }

  measure: total_revenue {
    type: sum
    sql: ${TABLE}.amount ;;
    value_format_name: eur
    description: 'Revenu total HT'
  }

  measure: avg_basket {
    type: average
    sql: ${TABLE}.amount ;;
  }
}

Source de vérité unique — la définition de 'chiffre d affaires' est dans le LookML, pas dans chaque dashboard
Self-service — les métiers explorent les données en combinant des dimensions et mesures définies par l équipe data
Séparation — l équipe data maintient le modèle, les métiers créent leurs propres explorations

2Explores et gestion des jointures

Question discriminante

Comment organisez-vous vos explores pour qu ils restent performants ?

# model : assemble les explores
explore: orders {
  label: 'Commandes et revenus'
  description: 'Analyse des commandes, clients et produits'

  join: customers {
    type: left_outer
    sql_on: ${orders.customer_id} = ${customers.customer_id} ;;
    relationship: many_to_one
  }

  join: products {
    type: left_outer
    sql_on: ${orders.product_id} = ${products.product_id} ;;
    relationship: many_to_one
  }

  # Restriction d accès selon le rôle
  access_filter: {
    field: customers.region
    user_attribute: user_region
  }
}

Fanout problem — joindre deux tables de faits dans un explore peut créer des doublons. Toujours joindre via la dimension
relationship — toujours définir la cardinalité (many_to_one, one_to_many). Looker optimise la requête SQL en fonction

3Persistent Derived Tables : optimiser les calculs lourds

Question discriminante

Qu est-ce qu une PDT ? Dans quel cas l utilisez-vous ?

# PDT : table précalculée stockée dans le warehouse
view: revenue_by_cohort {
  derived_table: {
    sql:
      SELECT
        DATE_TRUNC('month', first_order_date) AS cohort_month,
        DATE_TRUNC('month', order_date) AS activity_month,
        COUNT(DISTINCT user_id) AS active_users
      FROM ${orders.SQL_TABLE_NAME}
      GROUP BY 1, 2 ;;

    # Rebuild chaque nuit à 3h
    persist_for: '24 hours'
    # Ou via datagroup (déclenché par Airflow)
    # datagroup_trigger: nightly_refresh
  }
}

PDT — requête SQL complexe dont le résultat est stocké physiquement dans le warehouse. Évite de recalculer à chaque requête
Quand utiliser — calculs d agrégation lourds, cohortes, métriques complexes consultées fréquemment
Incremental PDT — ne rebuilde que les nouvelles lignes. Économise du compute sur les grosses tables

4Dimensions et mesures avancées

Question discriminante

Comment implémentez-vous une métrique de rétention à 30 jours dans LookML ?

view: orders {
  # Dimension de période relative
  dimension: days_since_last_order {
    type: number
    sql: DATE_DIFF(CURRENT_DATE, ${last_order_date}, DAY) ;;
  }

  # Mesure conditionnelle : clients actifs dans les 30 derniers jours
  measure: active_customers_30d {
    type: count_distinct
    sql: CASE WHEN ${days_since_last_order} <= 30
              THEN ${customer_id} END ;;
    drill_fields: [customer_id, last_order_date]
  }

  # Mesure de ratio
  measure: retention_rate_30d {
    type: number
    sql: ${active_customers_30d} * 1.0 / NULLIF(${total_customers}, 0) ;;
    value_format_name: percent_2
  }
}

5Git et déploiement : workflow LookML

Question discriminante

Comment gérez-vous le cycle de vie d un projet LookML en équipe ?

Git intégré — Looker est nativement connecté à Git (GitHub/GitLab). Chaque modification est un commit
Branches de développement — chaque développeur travaille sur sa branche. L UI Looker permet de switcher de branche
PR et review — revue de code sur les changements LookML avant merge sur main
lookml-validator — outil CLI pour valider le LookML en CI/CD sans l UI Looker
Environnements — pointer vers différents schémas (dev/prod) selon la branche

6Performance et optimisation Looker

Question discriminante

Comment optimisez-vous les performances d un explore Looker lent ?

Aggregate Awareness — définir des rollup tables que Looker utilise automatiquement quand la requête le permet
Caching — configurer des datagroups pour invalider le cache intelligemment
PDT pour les calculs lourds — sortir les calculs complexes du runtime
Limiter les explores — un explore trop large avec 20 vues jointes sera lent. Créer des explores spécialisés par cas d usage

7Grille par niveau

Niveau	Maitrise	Signal GO	NO-GO
Confirmé	LookML basics, views/explores/models, dimensions/mesures	A créé un explore avec jointures, sait la différence dimension/mesure	N a fait que cliquer dans l UI Looker sans toucher au LookML
Senior	PDTs, aggregate awareness, Git workflow, access filters	A créé des PDTs, gère le cache avec datagroups, travaille en branches Git	Ne sait pas ce qu est une PDT, n a jamais utilisé Git dans Looker

Vous recrutez un Analytics Engineer Looker ?

Premier entretien gratuit. Rapport GO/NO-GO sous 48h.

Tester gratuitement Reserver un appel