La couche sémantique Lightdash vs MetricFlow

Lightdash possède sa propre couche sémantique — définie en YAML aux côtés de votre projet dbt — et ce n’est pas MetricFlow. Cette distinction importe plus qu’il n’y paraît : les deux proposent des métriques définies dans le code, vivent dans votre dépôt dbt, et génèrent du SQL contre votre entrepôt. Mais ils prennent des décisions architecturales différentes, et choisir l’un engage à un ensemble différent de compromis.

À quoi ressemble la couche Lightdash

Les métriques Lightdash référencent directement les colonnes dbt avec la syntaxe ${column_name}. Il n’y a pas de concept de “modèle sémantique” séparé. Les métriques se placent sous le bloc meta: dans les mêmes fichiers YAML où vous documentez vos modèles dbt :

models:
  - name: mrt__sales__orders
    meta:
      primary_key: order__id
      metrics:
        average_order_value:
          type: number
          sql: "${order__total_revenue} / NULLIF(${order__orders}, 0)"
          format: '[$€]#,##0.00'
    columns:
      - name: order__id
        meta:
          metrics:
            order__orders:
              type: count_distinct
      - name: order__revenue
        meta:
          dimension:
            hidden: true
          metrics:
            order__total_revenue:
              type: sum
              format: '[$€]#,##0.00'

La colonne order__revenue devient à la fois une dimension et la base d’une métrique agrégée. average_order_value divise deux autres métriques — aucun nouveau concept de langage requis. Vous travaillez en YAML familier avec quelques clés spécifiques à Lightdash.

À quoi ressemble MetricFlow

MetricFlow nécessite plus de structure. Les métriques s’appuient sur des “modèles sémantiques” qui s’appuient sur vos modèles dbt. Les concepts sont distincts : entités, mesures et dimensions sont des objets séparés avec des rôles distincts :

semantic_models:
  - name: orders
    defaults:
      agg_time_dimension: order_date
    model: ref('mrt__sales__orders')
    entities:
      - name: order_id
        type: primary
      - name: customer_id
        type: foreign
    measures:
      - name: order_total
        agg: sum
        expr: order__revenue
      - name: order_count
        agg: count_distinct
        expr: order__id
    dimensions:
      - name: order_date
        type: time
        type_params:
          time_granularity: day

metrics:
  - name: total_revenue
    type: simple
    type_params:
      measure: order_total
  - name: average_order_value
    type: derived
    type_params:
      expr: total_revenue / order_count
      metrics:
        - name: total_revenue
        - name: order_count

La séparation est délibérée. Les modèles sémantiques définissent la correspondance entre les tables de l’entrepôt et les entités métier. Les métriques se composent par-dessus les mesures. Les dimensions et les entités contrôlent le fonctionnement des jointures. Le résultat est une spécification plus expressive — mais qui nécessite d’apprendre un vocabulaire distinct et de maintenir des fichiers YAML séparés.

Les différences clés

Complexité et friction d’adoption

L’approche Lightdash est plus simple. Vous ajoutez des blocs meta: aux fichiers YAML de modèles que vous éditez déjà. Pas de nouveau type de fichier, pas de nouveaux concepts comme les entités ou les mesures. Un utilisateur dbt familier avec le YAML de schéma peut ajouter des métriques Lightdash en quelques minutes.

MetricFlow nécessite d’apprendre la hiérarchie modèle sémantique / mesure / métrique / entité, de créer de nouveaux fichiers .yml pour les modèles sémantiques, et de comprendre comment les entités guident le comportement des jointures. La courbe d’apprentissage est plus raide, et la mise en place prend plus de temps avant que quelque chose d’utile apparaisse.

Pour les équipes avec des niveaux d’expérience en analytics engineering variables, ou quand la friction d’adoption est un risque réel, la barrière plus basse de Lightdash détermine souvent si la couche de métriques est construite ou reste dans un backlog.

Couplage aux outils

Les métriques Lightdash ne fonctionnent que dans Lightdash. Si vous définissez average_order_value dans le bloc meta: de Lightdash, il est disponible dans la vue Explore de Lightdash et nulle part ailleurs. Vous ne pouvez pas l’interroger depuis un autre outil BI, depuis une API REST, depuis un bot Slack ou depuis une application personnalisée.

Les métriques MetricFlow sont agnostiques aux outils. L’API dbt Cloud Semantic Layer les expose via JDBC, GraphQL et REST — tout consommateur en aval parlant ces protocoles peut interroger des métriques gouvernées. Looker, Tableau, Sigma, les agents IA, les applications personnalisées et les intégrations Slack peuvent tous lire les mêmes définitions de métriques MetricFlow. C’est la promesse du BI headless appliquée à dbt.

La question du couplage importe surtout dans deux scénarios :

1. Plusieurs outils BI. Si vous utilisez Lightdash pour les analystes et souhaitez que les définitions de métriques soient accessibles à un dashboard orienté client construit en React, vous avez besoin soit de MetricFlow (API agnostique), soit d’une couche personnalisée par-dessus l’API Lightdash (Cloud Pro uniquement).

2. Migration d’outil BI. Si Lightdash ne répond plus à vos besoins et que vous passez à un autre outil, les définitions de métriques Lightdash ne se transfèrent pas. Les définitions MetricFlow si, pour tout outil se connectant à l’API dbt Semantic Layer.

Sémantique des jointures

Lightdash gère les jointures via une configuration meta.joins explicite sur le modèle principal. Vous définissez le SQL de jointure et déclarez la cardinalité de la relation (many-to-one, one-to-many, one-to-one). Lightdash utilise la déclaration de cardinalité pour avertir du risque de fanout sur les métriques agrégées — voir lightdash-joins-and-fanout-protection pour les détails complets.

MetricFlow utilise un système de jointures basé sur les entités. Les jointures sont déduites des références d’entités partagées entre les modèles sémantiques. Deux modèles ayant une clé étrangère customer_id et une clé primaire customer_id se joignent automatiquement sans SQL explicite — MetricFlow résout la relation depuis le graphe d’entités. C’est plus puissant pour les scénarios multi-modèles complexes mais nécessite de déclarer correctement les types d’entités dans tous les modèles sémantiques.

Intelligence temporelle

MetricFlow a un support intégré pour l’intelligence temporelle : comparaisons période sur période, métriques cumulatives et métriques de conversion (suivi des événements dans une fenêtre de temps). Ce sont des types de métriques de première classe que Lightdash n’a pas d’équivalents — les métriques post-calcul de Lightdash (percent_of_previous, running_total) sont expérimentales et plus limitées.

Si l’analyse période sur période est une exigence centrale — comparer ce mois au mois précédent, suivre les moyennes mobiles sur 7 jours — MetricFlow le gère de manière plus fiable.

Quand la couche Lightdash convient

L’approche Lightdash est pertinente quand :

• Un seul outil BI pour tout. Votre équipe interroge Lightdash et rien d’autre. Aucun consommateur externe n’a besoin de définitions de métriques via API.
• L’adoption est le risque principal. Les analytics engineers doivent définir des métriques rapidement, sans courbe d’apprentissage abrupte. Livrer 80 % de la couche de métriques que tout le monde utilise vaut mieux qu’une implémentation MetricFlow complète qui reste dans un backlog.
• dbt v1.9 ou antérieur. MetricFlow est profondément intégré avec dbt Core depuis environ v1.6, mais la spécification a évolué significativement jusqu’à v1.10 et le moteur Fusion. Les équipes sur des versions dbt plus anciennes peuvent trouver l’approche meta: de Lightdash plus stable.

Quand MetricFlow convient

MetricFlow est le meilleur choix quand :

• Plusieurs consommateurs. Les métriques doivent être disponibles aux outils BI, agents IA, analytics embarquée et applications personnalisées via une API stable.
• Exigences d’intelligence temporelle. Les métriques période sur période, cumulatives et de conversion sont au cœur de vos flux d’analyse.
• Flexibilité d’outil. Vous n’êtes pas certain que Lightdash restera votre outil BI sur le long terme et souhaitez des définitions de métriques transférables.
• Graphes de jointures complexes. Les jointures basées sur les entités entre de nombreux modèles sont plus propres à définir et maintenir que le SQL de jointure explicite dans de nombreux blocs meta:.

Ils ne sont pas mutuellement exclusifs

Lightdash peut interroger le dbt Cloud Semantic Layer comme source de données secondaire. Les équipes ayant construit des définitions MetricFlow pour leurs métriques canoniques peuvent les afficher dans Lightdash aux côtés des métriques natives Lightdash.

Ce chemin hybride est peu courant mais il existe. Le pattern pratique : définissez les métriques hautement prioritaires et critiques pour la gouvernance dans MetricFlow (disponibles via API entre les outils), et utilisez l’approche meta: native de Lightdash pour les métriques exploratoires qui n’importent que dans le contexte Lightdash.

L’important à éviter : maintenir la même définition de métrique dans les deux systèmes simultanément. Cela défait l’objectif des métriques sous contrôle de version — vous êtes de retour avec plusieurs sources de vérité et un risque de dérive entre elles. Choisissez une approche comme principale pour chaque métrique.

Pour le contexte plus large de la place de ces couches sémantiques dans le stack de données, voir semantic-layer-architecture, qui compare MetricFlow avec Snowflake Semantic Views et Databricks Metric Views.