Le rapport HTML Elementary condense beaucoup d’informations dans un seul fichier. Comprendre à quoi sert chaque section permet de naviguer au bon endroit selon que vous effectuez une vérification de routine, que vous investiguez un échec spécifique, ou que vous recherchez des problèmes de performance.
Data health review
La page d’accueil du rapport. Elle affiche le nombre total de tests, la répartition succès/échec/avertissement, et les échecs de tests tracés dans le temps. C’est le point de départ pour une revue quotidienne ou hebdomadaire de routine — un aperçu rapide permettant de déterminer si la situation s’améliore ou se dégrade avant de plonger dans les détails.
Le résumé de détection d’anomalies sur cette page met en évidence les valeurs statistiquement aberrantes qu’Elementary a détectées automatiquement, indépendamment des tests que vous avez définis explicitement. Le statut d’exécution des modèles offre une vue rapide de la santé d’exécution de l’ensemble de votre projet.
Une courbe de tendance stable avec un taux de réussite constant indique l’absence de nouveaux problèmes. Un pic d’échecs ou une tendance à la baisse du taux de réussite justifie d’approfondir l’analyse dans la section des résultats de tests.
Test results
Chaque test dispose de sa propre vue détaillée avec l’historique d’exécution, la description du test et sa configuration. C’est dans cette section que s’effectue le véritable débogage.
Lorsqu’un test échoue, vous obtenez trois informations importantes :
- Le SQL compilé, que vous pouvez exécuter directement contre votre entrepôt pour comprendre ce que le test vérifie et pourquoi il échoue
- Des échantillons de lignes en échec (sauf si désactivé avec
--disable-samplespour des raisons de données personnelles) - L’historique de succès/échec pour ce test spécifique
La vue temporelle dans la section des résultats de tests est particulièrement utile pour distinguer les échecs ponctuels des problèmes récurrents. Un test qui a échoué une seule fois il y a six semaines et qui réussit depuis est différent d’un test qui échoue chaque lundi. La vue temporelle rend ce schéma immédiatement visible d’une manière que les fichiers journaux ne permettent pas.
Model runtime tracking
Graphiques de durée d’exécution pour chaque modèle, montrant les tendances de performance dans le temps. Cette section détecte quelque chose que les résultats de tests ne repèrent jamais : les modèles qui deviennent progressivement plus lents.
Un modèle qui s’exécutait en 30 secondes il y a trois mois et qui en prend maintenant 4 minutes n’a fait échouer aucun test. Aucune alerte ne se déclenche. Mais c’est le signe que quelque chose s’accumule — qu’il s’agisse du volume de données, de plans de requêtes inefficaces, ou d’un changement de schéma ayant désactivé l’élagage de partitions. La section de suivi des temps d’exécution fait remonter ces tendances avant qu’elles ne deviennent des pannes.
Au-delà du temps d’exécution, vous obtenez les octets facturés et les lignes affectées pour chaque exécution. Cela rend la section des temps d’exécution des modèles utile pour les travaux d’optimisation des coûts BigQuery : vous pouvez identifier quels modèles sont les plus coûteux à exécuter et vérifier si les optimisations ont réellement réduit les coûts.
Anomaly detection
Pour les tests d’anomalies Elementary (volume_anomalies, freshness_anomalies, column_anomalies), cette section affiche des graphiques temporels des valeurs réelles des métriques tracées par rapport aux plages attendues.
La visualisation distingue deux périodes :
- La période d’entraînement, où Elementary a établi sa référence à partir des données historiques
- La période de détection, où les valeurs actuelles sont comparées à cette référence
Lorsqu’une métrique dépasse la plage attendue, cela déclenche un échec d’anomalie. Voir le graphique permet de comprendre bien plus clairement si un échec est un véritable outlier ou si la référence elle-même a besoin d’une recalibration. Un modèle avec des données fortement saisonnières peut afficher des « anomalies » qui ne sont en réalité que des schémas de trafic du week-end — le graphique le rend évident, tandis que le message d’alerte brut ne le fait pas.
Le suivi au niveau des colonnes affiche séparément chaque métrique surveillée (taux de null, moyenne, min, max, nombre de valeurs distinctes), ce qui permet de voir quelle métrique spécifique a déclenché l’échec de détection d’anomalie.
Lineage
La vue de lignage montre le flux de données de bout en bout à partir de votre manifeste dbt, avec la couverture de test superposée. Lorsqu’un test échoue, la vue de lignage répond à la question : « qu’est-ce que cela casse ? »
Pour les équipes analytiques, le lignage est le plus utile lors de la gestion d’incidents. Un échec dans un modèle de base peut se propager à travers des modèles intermédiaires jusqu’à un mart qui alimente des tableaux de bord destinés aux dirigeants. Voir l’impact complet en aval avant de commencer la remédiation permet de communiquer l’urgence avec précision — « cela casse le tableau de bord des revenus » est différent de « cela affecte une table interne rarement utilisée. »
La couverture de tests superposée sur le lignage révèle également les lacunes. Les modèles sans tests apparaissent visuellement dans la vue de lignage sans indicateurs de couverture, ce qui facilite l’identification des angles morts qui pourraient être invisibles dans une liste plate de résultats de tests.