Data observability surveiller de bout en bout

Le monitoring traditionnel nous dit si un pipeline a fonctionné : le job est vert, le CPU est stable. Mais il ne nous dit rien sur la donnée elle-même. Un job peut très bien tourner et produire des données inutilisables ou fausses. L’observabilité des données va plus loin : elle surveille la santé de la donnée en continu. Elle ne se contente pas de dire “quelque chose a cassé”, elle aide à comprendre “pourquoi” en analysant les signaux émis par les données elles-mêmes.

prérequis

Un catalogue des jeux de données critiques et de leurs propriétaires.
Un système pour stocker l’historique des métriques de données (une simple table dans votre warehouse suffit pour commencer).
Un canal d’alerte configuré (Slack, email, PagerDuty) pour notifier les bonnes équipes.

les 5 piliers de l’observabilité des données

L’observabilité des données repose sur cinq piliers d’analyse. Plutôt qu’une simple liste, voici une carte mentale qui les résume.

pas à pas

étape 1: collecter des métriques simples

Inutile d’acheter un outil complexe pour démarrer. Vous pouvez commencer à collecter des métriques de base avec de simples requêtes SQL, exécutées à la fin de chaque pipeline.

-- Requête simple pour collecter des métriques de base sur une table
-- Le résultat peut être stocké dans une table 'data_observability_metrics'.
SELECT
    'ventes.orders_v' AS dataset_id,
    NOW() AS metric_timestamp,
    COUNT(*) AS row_count,
    COUNT(DISTINCT order_id) AS distinct_order_ids,
    MAX(order_date) AS max_order_date -- Pour la fraîcheur
FROM
    ventes.orders_v;

étape 2: définir des seuils et des alertes intelligentes

Une fois que vous avez un historique de métriques, vous pouvez définir des seuils. L’objectif n’est pas d’alerter sur tout, mais sur les déviations anormales.

# Exemple de règle d'alerte dans un fichier de configuration
alerts:
  - dataset: ventes.orders_v
    metrics:
      # Alerte si la fraîcheur dépasse 3 heures
      - name: freshness
        type: max_hours_since_last_record
        threshold: 3

      # Alerte si le volume chute de plus de 20% par rapport à la veille
      - name: volume
        type: daily_row_count_change_pct
        threshold: -20

étape 3: utiliser le lineage pour accélérer la résolution

Quand une alerte se déclenche, la première question est : “Qu’est-ce que ça impacte en aval ?” et “D’où vient le problème en amont ?”. Le lineage (la cartographie des dépendances) est la clé pour répondre à ces questions.

-- Requête pour trouver les dépendances amont d'une vue
SELECT
    source_schema,
    source_table
FROM
    lineage.table_dependencies
WHERE
    view_name = 'orders_v'
    AND view_schema = 'ventes';

exemples

cas: une alerte utile et actionnable

Voici à quoi ressemble une bonne alerte, envoyée sur un canal Slack. Elle ne se contente pas de dire qu’il y a un problème, elle donne le contexte nécessaire pour agir.

pièges fréquents

Symptôme: L’équipe d’astreinte ignore les alertes car elles se déclenchent toutes les nuits.
- Cause: “Alert fatigue” due à des seuils trop stricts ou statiques qui ne tiennent pas compte de la saisonnalité.
- Correctif: Utiliser des seuils dynamiques (ex: écart-type par rapport à la moyenne des 7 derniers jours) plutôt que des valeurs fixes.
Symptôme: Une alerte est déclenchée, mais personne ne sait qui doit la prendre en charge.
- Cause: Pas d’owner clairement défini pour le jeu de données.
- Correctif: Rendre le champ owner obligatoire dans votre catalogue de données. L’alerte doit automatiquement taguer l’équipe propriétaire.
Symptôme: Un dashboard d’observabilité est en place, mais personne ne comprend les métriques affichées.
- Cause: Métriques avec des noms obscurs (ex: metric_xyz_t2) et sans documentation.
- Correctif: Utiliser des noms clairs et explicites pour les métriques (ex: freshness_in_hours). Chaque métrique doit avoir une description simple dans le catalogue.

faq

Quelle est la différence entre monitoring et observabilité ? Le monitoring vous dit si votre système fonctionne (le pipeline est vert ou rouge). L’observabilité vous aide à comprendre pourquoi il ne fonctionne pas comme prévu en analysant ses sorties (la donnée). Le monitoring est une question binaire (ça marche / ça marche pas), l’observabilité est une investigation.
Faut-il acheter un outil pour faire de l’observabilité de données ? Non, pas pour commencer. Vous pouvez construire une base solide avec des outils que vous avez déjà : des requêtes SQL, un orchestrateur (comme Airflow) pour les exécuter, et un outil de BI pour visualiser les métriques. Les outils spécialisés deviennent utiles pour passer à l’échelle et automatiser la détection d’anomalies.

Menu