Les rapports et tableaux de bord Elementary sont les plus utiles lorsqu’ils sont organisés par audience plutôt que par exhaustivité. Un rapport unique non filtré sur tous les domaines tend à être trop large pour être actionnable.
Organisez selon la façon de penser de votre équipe, pas selon la structure d’Elementary
L’organisation par défaut d’Elementary est par modèle — chaque résultat de test est associé au modèle sur lequel il a été exécuté. C’est la bonne structure pour les données sous-jacentes. Ce n’est pas nécessairement la bonne structure pour le tableau de bord.
Regroupez par domaine si vous avez des équipes distinctes qui possèdent des zones de données distinctes. Les analystes marketing n’ont pas besoin de visibilité sur les échecs des modèles finance ; l’équipe finance n’a pas besoin de voir les résultats de tests sur l’attribution marketing. Un tableau de bord spécifique finance — soit un rapport Elementary filtré, soit un tableau de bord BI interrogeant elementary_test_results avec un filtre de domaine — sert chaque équipe mieux qu’une vue unifiée où elles doivent filtrer mentalement le bruit.
Regroupez par criticité si vous avez un modèle de niveaux. Les modèles de niveau 1 ont un impact sur les revenus ; les niveaux 2 sont opérationnels ; les niveaux 3 sont exploratoires ou en développement. Un tableau de bord montrant uniquement les échecs de niveau 1 est celui qu’un ingénieur d’astreinte consulte en premier lorsque quelque chose se casse. Un tableau de bord montrant les échecs de niveau 3 est celui qu’un développeur examine lors de la construction de nouveaux modèles.
Le bon regroupement dépend du public. Les ingénieurs s’intéressent à la criticité. Les parties prenantes métier s’intéressent à leur domaine. Concevez le tableau de bord pour son audience plutôt que pour l’exhaustivité.
Les tags permettent le filtrage
Les tags dans vos définitions de tests sont ce qui permet tout ce filtrage. Appliquez-les délibérément :
tests: - elementary.volume_anomalies: tags: ['critical', 'finance', 'daily-check'] meta: owner: 'analytics-team'Puis filtrez les rapports par tag :
edr report --select tag:criticalOu construisez des tableaux de bord BI filtrant elementary_test_results par la colonne tags.
Les tags ne fonctionnent que s’ils sont cohérents. Un tag finance appliqué à 60 % des modèles finance et absent des 40 % restants produit un tableau de bord filtré avec des lacunes inexpliquées. Établissez un vocabulaire de tags avant de commencer à les appliquer, faites-le respecter en revue de code, et vérifiez les lacunes lors des revues trimestrielles. La note dbt Test Alert Routing and Ownership couvre un pattern connexe pour le routage des alertes basé sur les mêmes métadonnées.
La fréquence de rafraîchissement doit correspondre à la cadence de mise à jour des données
Il n’y a aucune valeur à rafraîchir un rapport plus souvent que vos données ne changent réellement.
Les rapports de production devraient être générés après chaque exécution dbt, de sorte que les échecs remontent dès qu’ils se produisent. Si dbt s’exécute toutes les heures, générez le rapport Elementary toutes les heures. S’il s’exécute une fois par jour, quotidien suffit.
Les tableaux de bord de direction fonctionnent mieux comme synthèses quotidiennes. Un cadre consultant un tableau de bord de qualité des données à 9h n’a pas besoin de mises à jour à la seconde — il a besoin d’une image claire de la santé sur les dernières 24 heures. Un bruit horaire dans un tableau de bord de synthèse distrait plus qu’il n’informe.
Les rapports de développement et ad hoc sont à la demande. Générez-les lorsque vous avez besoin d’examiner un modèle spécifique ou d’investiguer un échec spécifique, sautez-les sinon. Automatiser les rapports de développement en CI crée souvent du bruit sans valeur — un échec de test dans une branche de fonctionnalité est attendu et n’a pas besoin d’apparaître dans un rapport partagé.
Le flag --days-back pour gérer la portée des rapports
Les modèles incrémentiels d’Elementary conservent l’historique indéfiniment par défaut, ce qui est souhaitable pour l’analyse de tendances long terme. Mais les rapports tentant de restituer des mois de données deviennent lents et difficiles à lire.
Utilisez --days-back pour limiter ce que chaque rapport affiche sans perdre l’historique sous-jacent :
# Rapport quotidien rapide (7 jours)edr report --days-back 7 --file-path ./reports/daily.html
# Rapport de tendance mensuelle (30 jours)edr report --days-back 30 --file-path ./reports/monthly.htmlL’historique complet reste dans vos tables d’entrepôt et demeure disponible pour les tableaux de bord BI et les requêtes ad hoc quand vous en avez besoin. Le flag contrôle uniquement ce que le rapport HTML affiche, pas ce qui est stocké.
Pour l’analyse de tendances long terme — répondre à la question « notre qualité des données est-elle meilleure qu’il y a six mois ? » — interrogez directement elementary_test_results plutôt que de vous appuyer sur le rapport HTML. L’approche tableau de bord BI vous donne un contrôle complet sur la fenêtre temporelle et la méthode d’agrégation.