Créer des dashboards de qualité des données avec Elementary

Exécuter des tests dbt permet de détecter des problèmes. Mais des tests qui passent aujourd’hui ne disent rien sur l’évolution de la qualité de vos données : s’améliore-t-elle, se dégrade-t-elle, ou reste-t-elle stable dans le temps ? Sans visibilité historique, vous naviguez à l’aveugle entre les échecs.

Elementary résout ce problème en stockant chaque résultat de test dans votre warehouse. Les données brutes sont là. Nous allons voir comment les transformer en dashboards que votre équipe utilisera vraiment : des rapports HTML autonomes pour les revues rapides, des versions hébergées pour l’accès en équipe, et des dashboards BI personnalisés pour les KPIs qui comptent pour votre organisation.

Prérequis

Ce guide suppose qu’Elementary est déjà installé. Si ce n’est pas le cas, consultez d’abord le guide d’installation complet.

Vérification rapide que tout fonctionne :

# Vérifier que le package dbt est installé
dbt deps
dbt run --select elementary

# Vérifier que le CLI est disponible
edr --version

Vous devriez voir les tables Elementary dans votre warehouse (elementary_test_results, dbt_run_results et dbt_models) et la commande edr devrait renvoyer un numéro de version.

Générer votre premier rapport

La commande edr report crée un fichier HTML autonome avec tout ce qu’il faut pour évaluer la qualité de vos données en un coup d’oeil :

edr report

Par défaut, le fichier elementary_report.html est créé dans le répertoire ./edr_target. Ouvrez-le dans un navigateur : votre dashboard de qualité des données est prêt.

Les flags que vous utiliserez régulièrement :

Pour une vue ciblée de votre dernière exécution :

edr report --select last_invocation --file-path ./reports/latest.html

Pour un résumé hebdomadaire :

edr report --days-back 7 --file-path ./reports/weekly.html

Comprendre les sections du rapport

Le rapport HTML condense beaucoup d’informations dans un seul fichier. Voici ce que vous y trouverez.

Vue d’ensemble de la santé des données

La page d’accueil affiche l’état global de la santé de vos données : nombre total de tests, répartition pass/fail/warn, et l’évolution des échecs dans le temps. C’est votre point de départ pour comprendre si la situation s’améliore ou se dégrade.

Le résumé de détection d’anomalies met en évidence les valeurs aberrantes repérées automatiquement par Elementary. Le statut d’exécution des modèles offre une vue rapide de la santé d’exécution de votre projet.

Résultats des tests

Chaque test dispose de sa propre vue détaillée avec l’historique d’exécution, la description et la configuration. En cas d’échec, vous voyez :

• Le SQL compilé pour débugger directement
• Des échantillons de lignes en échec (sauf si désactivés pour les données sensibles)
• L’historique pass/fail de ce test spécifique

La vue chronologique permet de distinguer les échecs ponctuels des problèmes récurrents.

Suivi du temps d’exécution des modèles

Les graphiques de durée d’exécution révèlent les tendances de performance dans le temps. Vous repérerez les modèles qui ralentissent progressivement, identifierez les goulots d’étranglement, et verrez des métriques comme les bytes facturés et les lignes traitées. Cette section est particulièrement utile pour le travail d’optimisation des coûts.

Détection d’anomalies

Pour les tests d’anomalies Elementary, vous obtenez des graphiques chronologiques montrant les valeurs réelles par rapport aux plages attendues. La visualisation distingue la période d’entraînement (où les baselines sont établies) de la période de détection (où les anomalies sont signalées). Le suivi au niveau des colonnes affiche chaque métrique surveillée.

Lineage

La vue lineage affiche le flux de données de bout en bout depuis votre manifest, avec la couverture des tests superposée. Quand un test échoue, vous pouvez tracer l’impact en aval et comprendre ce qui est à risque.

Héberger votre dashboard

Un fichier HTML sur votre laptop n’aide pas votre équipe. Héberger le rapport le rend accessible à tous ceux qui ont besoin de visibilité sur la qualité des données.

AWS S3

edr send-report \
  --aws-access-key-id $AWS_ACCESS_KEY_ID \
  --aws-secret-access-key $AWS_SECRET_ACCESS_KEY \
  --s3-bucket-name your-reports-bucket \
  --bucket-file-path reports/elementary.html \
  --update-bucket-website true

Accessible à : http://your-reports-bucket.s3-website-us-east-1.amazonaws.com/index.html

Google Cloud Storage

edr send-report \
  --google-service-account-path /path/to/service-account.json \
  --gcs-bucket-name your-reports-bucket \
  --update-bucket-website true

Accessible à : https://storage.googleapis.com/your-reports-bucket/index.html

Azure Blob Storage

edr send-report \
  --azure-container-name your-container \
  --azure-connection-string $AZURE_CONNECTION_STRING \
  --update-bucket-website true

Accessible à : https://your-account.blob.core.windows.net/your-container/index.html

Automatiser la génération des rapports

Lancez edr send-report après chaque build dbt dans votre outil d’orchestration. Dans Airflow, ajoutez-le comme tâche en aval. Dans GitHub Actions :

- name: Generate Elementary report
  run: |
    edr send-report \
      --gcs-bucket-name ${{ secrets.REPORTS_BUCKET }} \
      --google-service-account-path ./sa.json

Le rapport se met à jour automatiquement, et votre équipe voit toujours le dernier état de la qualité des données. Pour des notifications en temps réel lors d’échecs de tests, consultez la page sur la configuration des alertes Elementary.

Construire des dashboards personnalisés dans vos outils BI

Le rapport HTML couvre la plupart des besoins, mais à un moment vous voudrez plus de contrôle. Peut-être avez-vous besoin de résumés pour la direction avec votre propre charte graphique, ou d’une vue unifiée couvrant plusieurs projets dbt. Peut-être que votre équipe a déjà des dashboards BI et que la qualité des données devrait vivre aux côtés des métriques opérationnelles plutôt que dans un outil séparé.

Comme Elementary stocke tout dans des tables interrogeables, vous pouvez connecter n’importe quel outil BI qui lit depuis votre warehouse : Looker, Tableau, Metabase, Power BI, ou tout autre outil déjà en place dans votre équipe.

Tables clés

Exemples de requêtes

Tendance quotidienne pass/fail

SELECT
  DATE(detected_at) AS date,
  COUNT(CASE WHEN status = 'pass' THEN 1 END) AS passed,
  COUNT(CASE WHEN status = 'fail' THEN 1 END) AS failed,
  ROUND(
    COUNT(CASE WHEN status = 'pass' THEN 1 END) * 100.0 / COUNT(*),
    2
  ) AS pass_rate
FROM elementary_test_results
WHERE detected_at >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY 1
ORDER BY 1;

Modèles les plus lents de la semaine

SELECT
  model_name,
  AVG(execution_time) AS avg_seconds,
  MAX(execution_time) AS max_seconds,
  COUNT(*) AS runs
FROM model_run_results
WHERE created_at >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
GROUP BY 1
ORDER BY avg_seconds DESC
LIMIT 20;

Tests par statut et tag

SELECT
  tags,
  status,
  COUNT(*) AS count
FROM elementary_test_results
WHERE detected_at >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
GROUP BY 1, 2
ORDER BY 1, 2;

Concevoir des KPIs de qualité des données efficaces

Les résultats bruts des tests ont besoin d’être interprétés. Ces KPIs traduisent les données de tests en métriques compréhensibles par les parties prenantes.

Taux de réussite des tests

La métrique la plus fondamentale : quel pourcentage de tests réussissent ?

pass_rate = passed_tests / total_tests * 100

Suivez cette métrique quotidiennement. Une tendance à la baisse signale des problèmes croissants, même si rien n’est en échec à ce moment précis. Un taux de réussite à 100 % pendant des semaines pourrait indiquer que vos tests ne sont pas assez stricts.

SLA de fraîcheur des données

Quel pourcentage de vos sources de données respecte ses exigences de fraîcheur ?

Il faut d’abord définir les SLAs. Taggez les tables avec leur fréquence de mise à jour attendue, puis mesurez :

SELECT
  COUNT(CASE WHEN status = 'pass' THEN 1 END) * 100.0 / COUNT(*) AS sla_compliance
FROM elementary_test_results
WHERE test_type = 'freshness_anomalies'
  AND detected_at >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY);

Taux de succès des modèles

Quel pourcentage des exécutions de modèles se termine avec succès ?

success_rate = successful_runs / total_runs * 100

Suivez cette métrique séparément du taux de réussite des tests. Un modèle peut s’exécuter avec succès mais échouer aux tests, ou ne pas s’exécuter du tout.

Taux de détection d’anomalies

Combien d’anomalies Elementary détecte-t-il par jour ou par semaine ? Cette métrique est plus utile en tant que tendance qu’en valeur absolue. Un pic soudain pointe souvent vers des problèmes dans les données sources plutôt que vers un problème dans vos modèles. À l’inverse, un zéro constant pendant des semaines peut signifier que la sensibilité de détection est trop basse, ou que vous ne surveillez pas les bonnes colonnes. Dans les deux cas, cela mérite investigation.

Couverture des tests

Quel pourcentage de vos modèles a au moins un test ?

SELECT
  COUNT(DISTINCT CASE WHEN has_tests THEN model_name END) * 100.0 /
  COUNT(DISTINCT model_name) AS coverage
FROM (
  SELECT
    m.name AS model_name,
    EXISTS (
      SELECT 1 FROM elementary_test_results t
      WHERE t.model_unique_id = m.unique_id
    ) AS has_tests
  FROM dbt_models m
  WHERE m.resource_type = 'model'
);

La couverture révèle vos angles morts. Un modèle sans aucun test est un modèle où les problèmes passent inaperçus.

Correspondance avec les dimensions de qualité des données

Ces KPIs correspondent aux dimensions standard de qualité des données, ce qui facilite le reporting dans des termes que les parties prenantes reconnaissent :

Bonnes pratiques

Organiser par domaine

Structurez vos dashboards autour de la façon dont votre équipe pense les données, pas selon l’organisation interne d’Elementary. Regroupez les tests par domaine (marketing, finance, produit), par criticité (tier-1 pour l’impact sur le revenu, tier-2 pour l’opérationnel, tier-3 pour l’exploratoire), ou par SLA (horaire, quotidien, hebdomadaire). Le bon regroupement dépend de qui consulte le dashboard. Les ingénieurs se soucient des niveaux de criticité. Les parties prenantes métier se soucient de leur domaine.

Taguer de manière cohérente

Les tags sont ce qui rend tout ce filtrage possible, alors il vaut la peine d’y réfléchir dès le départ. Appliquez-les dans vos définitions de tests :

tests:
  - elementary.volume_anomalies:
      tags: ['critical', 'finance', 'daily-check']
      meta:
        owner: 'analytics-team'

Puis filtrez les rapports :

edr report --select tag:critical

Ou construisez des dashboards BI filtrés par tag.

Définir la fréquence de rafraîchissement

Adaptez la cadence des rapports à la fréquence réelle de mise à jour de vos données. Les rapports de production doivent être générés après chaque exécution dbt pour que les échecs remontent immédiatement. Les dashboards pour la direction fonctionnent mieux en résumés quotidiens, car le bruit horaire distrait plus qu’il n’aide. Les rapports de développement sont à la demande : générez-les quand vous en avez besoin, ignorez-les le reste du temps.

Gérer les données historiques

Les modèles incrémentaux d’Elementary conservent l’historique indéfiniment par défaut, ce qui est souhaitable pour l’analyse de tendances à long terme. Mais les rapports qui tentent d’afficher des mois de données deviennent lents et difficiles à lire. Utilisez --days-back pour limiter la portée du rapport sans perdre l’historique sous-jacent :

# Rapport quotidien rapide (7 jours)
edr report --days-back 7 --file-path ./reports/daily.html

# Rapport de tendance mensuel (30 jours)
edr report --days-back 30 --file-path ./reports/monthly.html

L’historique complet reste dans les tables de votre warehouse, disponible pour les dashboards BI et les requêtes ad hoc quand vous en avez besoin.

L’écart entre “on exécute des tests dbt” et “on a de la visibilité sur la qualité des données” consiste surtout à rendre accessible l’information qui existe déjà. Elementary collecte déjà les données. Le rapport HTML vous fait passer de zéro à un dashboard fonctionnel en une seule commande. L’héberger donne accès à votre équipe. Construire des KPIs personnalisés dans votre outil BI relie la qualité des données aux métriques que votre organisation suit déjà.

Commencez par le rapport généré. Si c’est suffisant pour votre équipe, arrêtez-vous là. Quand vous aurez besoin de plus, les tables sous-jacentes sont dans votre warehouse, prêtes pour les dashboards personnalisés adaptés à votre situation.

Si vous êtes encore en train d’installer Elementary, le guide d’installation et de configuration couvre tout, de l’installation du package à la configuration de la détection d’anomalies.