← Retour au blog

Du glossaire au lineage exploitable

Lucian BLETAN

Avoir un glossaire de KPIs, c’est bien. Savoir exactement d’où vient chaque chiffre, comment il est calculé et quelles sources de données l’alimentent, c’est mieux. Un glossaire sans son lineage technique est un document mort. Le lineage, c’est le fil d’Ariane qui relie vos définitions métier aux tables, aux transformations et aux sources brutes. Quand un chiffre bouge, ou qu’il y a un écart, le lineage est votre meilleur allié pour comprendre pourquoi et corriger rapidement.

Est défini par

Est implémenté dans

Dépend de

Provient de

Trace les dépendances

Permet de comprendre

Glossaire KPI

Formule de Calcul

Vue SQL / Modèle DBT

Tables Sources

Systèmes Opérationnels

Lineage de Données

prérequis

  • Un glossaire de KPIs (Key Performance Indicators) avec des définitions claires et, si possible, les formules de calcul associées.
  • Accès aux métadonnées de votre entrepôt de données (schémas des tables et des vues, définitions SQL des vues).
  • Un outil ou des scripts capables d’extraire les dépendances entre les objets de votre base de données (ex: dbt, Apache Atlas, OpenLineage, ou des scripts SQL simples).

idées clefs

  • KPI et calcul: Chaque KPI dans le glossaire doit pointer vers l’objet technique (vue, modèle) qui le calcule.
  • Vues documentées: Les vues et vues matérialisées qui produisent les KPIs doivent être claires, versionnées et idéalement, décrites dans un catalogue.
  • Suivi des usages: Savoir qui utilise quoi, via les logs de requêtes ou un catalogue de données actif.
  • Alertes sur les sources: Être notifié si une table source majeure subit un changement de schéma.

tutoriel pas-à-pas

étape 1: Lier KPI et son calcul technique

La première étape est de connecter explicitement le nom métier du KPI à l’objet SQL qui le génère. C’est le pont initial entre le monde métier et le monde technique.

# Dans votre glossaire (ou catalogue de données)
---
kpi_name: "Taux de réachat à 30 jours"
description: "Pourcentage de clients ayant effectué un second achat dans les 30 jours suivant leur premier achat."
formula: "(Nombre de clients réacheteurs à J+30 / Nombre de clients premiers acheteurs) * 100"
source_view: "metrics.mv_taux_reachat_30j"
owner: "Équipe Marketing Data"
---

étape 2: Extraire le lineage technique

Utilisez les vues système de votre base de données ou un outil dédié (comme dbt-docs pour un projet dbt) pour obtenir les dépendances entre les vues et les tables. L’objectif est de savoir quelles tables alimentent quelle vue, et ainsi, quel KPI.

-- Exemple d'extraction de dépendances directes pour PostgreSQL
SELECT
    v.schemaname AS view_schema,
    v.viewname AS view_name,
    t.schemaname AS source_schema,
    t.tablename AS source_name
FROM pg_views v
JOIN pg_depend d1 ON d1.objid = v.oid AND d1.classid = 'pg_class'::regclass
JOIN pg_rewrite r ON r.oid = d1.objid
JOIN pg_depend d2 ON d2.objid = r.oid AND d2.classid = 'pg_rewrite'::regclass
JOIN pg_class t ON t.oid = d2.refobjid AND t.relkind IN ('r','v','m') -- tables, views, materialized views
WHERE v.schemaname NOT IN ('pg_catalog', 'information_schema')
  AND t.schemaname NOT IN ('pg_catalog', 'information_schema');

étape 3: Publier les métadonnées dans un catalogue

Intégrez les informations du glossaire et le lineage technique dans un catalogue de données. Cela centralise l’information et la rend accessible. Chaque fiche de données ou de KPI doit inclure : sa définition, sa formule, son code SQL source, ses dépendances amont/aval et un historique des changements.

# Fiche dans le catalogue de données
---
entity_type: "kpi"
id: "taux_de_reachat_30j"
name: "Taux de réachat à 30 jours"
description: "KPI de fidélisation client."
owner: ["data-ops"]
source_system: "warehouse"
source_code_path: "dbt/models/metrics/mv_taux_reachat_30j.sql"
upstream_dependencies:
  - id: "transactions.mv_first_purchases"
    type: "materialized_view"
  - id: "transactions.fct_orders"
    type: "table"
tags: ["marketing", "fidélisation", "kpi"]
changelog:
  - date: "2021-05-20"
    description: "Exclusion des commandes tests des calculs."
    changed_by: "dev_team_a"
---

exemples complets

cas 1: Expliquer un écart inattendu sur un KPI

Votre “taux de réachat à 30 jours” a chuté de 15% hier. Le lineage vous permet d’investiguer rapidement.

  1. Identifier les sources: Le catalogue indique que metrics.mv_taux_reachat_30j dépend de transactions.mv_first_purchases et transactions.fct_orders.
  2. Vérifier les changements récents: L’historique des modifications de mv_taux_reachat_30j ne montre rien. On regarde mv_first_purchases et fct_orders.
  3. Trouver la cause: On constate qu’un PR a été mergé la veille sur transactions.fct_orders qui a introduit un nouveau filtre excluant les commandes annulées trop tardivement. Ce filtre impacte le nombre de premiers acheteurs, ce qui explique la baisse du taux.
  4. Action corrective: Discuter de l’impact métier de ce filtre, potentiellement revenir en arrière ou ajuster la définition du KPI avec les équipes métier.
-- Comparaison des valeurs du KPI avant et après le changement suspect
WITH kpi_version_stable AS (
    SELECT date_calc, value FROM kpis_history
    WHERE kpi_name = 'taux_de_reachat_30j' AND date_calc >= '2021-05-15' AND date_calc < '2021-06-01'
),
kpi_version_actuelle AS (
    SELECT date_calc, value FROM kpis_history
    WHERE kpi_name = 'taux_de_reachat_30j' AND date_calc >= '2021-06-01' AND date_calc <= '2021-06-12'
)
SELECT
    s.date_calc,
    s.value AS stable_value,
    a.value AS current_value,
    ROUND( (a.value - s.value) / s.value * 100, 2) AS percentage_diff
FROM kpi_version_stable s
JOIN kpi_version_actuelle a ON s.date_calc = a.date_calc
ORDER BY s.date_calc;

pièges fréquents

  • Définitions isolées: Un glossaire métier sans lien direct avec le code qui l’implémente mène à des interprétations différentes.
    • Solution: Intégrer les liens vers le code SQL ou les vues dans la fiche du KPI.
  • Lineage partiel: Extraire le lineage manuellement ou avec des outils incomplets crée des angles morts.
    • Solution: Automatiser l’extraction du lineage sur toutes les couches de transformation (staging, mart, agrégats) via des outils dédiés ou des scripts robustes.
  • Changements silencieux: Une modification en amont qui n’est pas signalée entraîne des ruptures en aval.
    • Solution: Mettre en place des alertes sur les changements de schéma des tables sources critiques et maintenir un changelog détaillé pour chaque vue/modèle de données.
  • Silos d’information: Glossaire métier d’un côté, documentation technique de l’autre.
    • Solution: Centraliser l’information dans un catalogue de données unique qui agrège les vues métier et technique du même objet.

faq

  • Est-ce que ça remplace la documentation manuelle ? Non, mais ça l’enrichit considérablement. Le lineage est la documentation vivante et technique de vos flux.

  • Quel outil utiliser pour le lineage ? Pour les projets dbt, dbt-docs génère déjà un beau graphe. Pour des besoins plus avancés, des plateformes comme Amundsen, DataHub, ou des solutions commerciales sont pertinentes.

tags