ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Génération de rapports HTML Elementary

Comment fonctionne la commande edr report, quels flags comptent en pratique, et des patterns pour générer des rapports ciblés pour différentes audiences.

Planté
elementarydbtdata qualitytesting

La commande edr report prend tout ce qu’Elementary a collecté dans votre entrepôt et le restitue dans un fichier HTML autonome. Une commande, un fichier, tout ce qu’il faut pour évaluer la qualité des données en un coup d’œil.

Terminal window
edr report

Par défaut, cela crée elementary_report.html dans le répertoire ./edr_target. Ouvrez-le dans un navigateur et vous disposez d’un tableau de bord de qualité des données opérationnel, sans serveur, sans connexion et sans hébergement requis pour un usage personnel.

Les flags qui comptent

La plupart du temps, edr report s’utilise avec une poignée de flags :

FlagCe qu’il fait
--file-path report.htmlEmplacement de sortie personnalisé
--target-path ./reportsChanger le répertoire de sortie
--days-back 7Limiter aux 7 derniers jours de données
--select last_invocationAfficher uniquement la dernière exécution
--project-name "Analytics"Nom personnalisé dans l’en-tête du rapport
--disable-samplesMasquer les échantillons de données (utile pour les PII)

Les flags --days-back et --select sont ceux que l’on utilise le plus souvent. Les modèles incrémentiels d’Elementary accumulent l’historique indéfiniment, et un rapport tentant de restituer des mois de résultats de tests devient difficile à gérer. Aucun de ces flags ne supprime les données historiques — ils contrôlent uniquement ce que le rapport affiche. L’historique complet reste dans vos tables d’entrepôt, disponible pour les tableaux de bord BI et les requêtes ad hoc.

--disable-samples mérite une mention séparée. Par défaut, lorsqu’un test échoue, le rapport inclut des lignes d’exemple des enregistrements en échec. C’est utile pour le débogage mais inapproprié pour les colonnes contenant des PII. Désactivez-le globalement si votre entrepôt contient des données sensibles mélangées aux sorties de tests.

Deux invocations courantes

Pour un aperçu rapide de votre dernière exécution :

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

Pour un résumé hebdomadaire :

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

Le sélecteur last_invocation est particulièrement utile en CI ou lors de sessions de débogage où on veut comprendre ce qui vient de se passer sans parcourir des semaines d’historique.

Filtrage par tag

Si vous avez tagué vos tests, vous pouvez générer des rapports ciblés :

Terminal window
edr report --select tag:critical

Cela ne fonctionne que si vous avez appliqué des tags dans vos définitions de modèles et de tests. La discipline d’un tagage cohérent est récompensée ici — un rapport filtré sur tag:critical qui contient réellement vos modèles les plus importants est plus utile qu’un rapport non filtré où tests critiques et tests exploratoires se disputent l’attention. Voir Elementary dashboard organization pour réfléchir à la stratégie de tagage.

Ce que la commande lit réellement

edr report lit depuis les tables d’entrepôt d’Elementary (elementary_test_results, dbt_run_results, dbt_models), pas depuis des exécutions dbt en direct. Cela signifie que le rapport reflète les données telles qu’elles étaient lors de la dernière exécution de dbt run ou dbt test avec les hooks Elementary actifs. Exécuter edr report deux fois de suite produit le même rapport sauf si dbt a été exécuté entre-temps.

La séparation signifie également que la génération de rapports est peu coûteuse. Elle ne déclenche aucune exécution dbt, ne réexécute pas de tests et n’écrit pas dans votre entrepôt. C’est une opération en lecture seule sur des tables déjà existantes.

Fraîcheur du rapport

Comme la commande est une lecture de données historiques, il faut réfléchir au moment de générer les rapports. Générer avant un dbt run donne une image de la veille. Générer immédiatement après donne l’état actuel.

Pour les équipes utilisant des outils d’orchestration, le bon pattern est d’exécuter edr report (ou edr send-report pour les versions hébergées) comme tâche en aval après chaque dbt build. Ainsi le rapport reflète toujours la dernière exécution. Voir Elementary report hosting pour savoir comment automatiser cela dans GitHub Actions ou Airflow.