Tableaux de bord BI personnalisés avec Elementary

Elementary stocke chaque résultat de test dans l’entrepôt sous forme de tables interrogeables — les mêmes tables que le rapport HTML lit. Tout outil BI capable de se connecter à l’entrepôt peut les interroger directement.

Raisons de construire des tableaux de bord personnalisés plutôt que d’utiliser le rapport HTML : les vues de niveau direction sont plus faciles à intégrer dans les outils BI existants aux côtés des métriques opérationnelles ; les équipes avec plusieurs projets dbt peuvent avoir besoin d’une vue unifiée ; les organisations peuvent souhaiter des seuils personnalisés ou des définitions spécifiques à leur domaine de ce qui constitue une qualité de données acceptable.

Les trois tables

Tout ce dont vous avez besoin se trouve dans trois tables :

Elementary les crée dans le schéma configuré lors de l’installation (généralement elementary ou your_project_elementary). Ce sont des modèles incrémentiels, ils grandissent dans le temps et conservent l’historique complet sauf si vous les tronquez manuellement.

Requêtes utiles

Tendance quotidienne pass/fail

La métrique de qualité des données la plus fondamentale : quel pourcentage de tests passent, suivi quotidiennement.

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;

Représentez cela sous forme de graphique en courbes dans votre outil BI. Un taux de réussite en baisse mérite une investigation même si aucun test individuel n’a déclenché une alerte critique.

Modèles les plus lents cette 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;

Cette requête est plus utile sous forme de graphique à barres trié par avg_seconds. Les modèles qui apparaissent dans le top 10 semaine après semaine sont des candidats pour des travaux d’optimisation.

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;

Si vous avez tagué vos tests avec des tags de domaine (finance, marketing, product) ou des niveaux de criticité (critical, tier-2), cette requête devient une ventilation domaine par domaine de la santé des tests. Sans tags cohérents, elle est moins utile.

Construction sur ces tables

Les tables sont plus riches que les exemples ci-dessus ne le suggèrent. elementary_test_results inclut le type de test, le nom du modèle, le nom de la colonne, la description du test et le SQL compilé pour chaque résultat. dbt_run_results inclut les octets facturés et les lignes affectées en plus du temps d’exécution. dbt_models inclut les métadonnées de nœud depuis votre manifest, ce qui signifie que les informations de propriétaire, les tags et tous les champs meta que vous avez définis se propagent vers des colonnes interrogeables.

Il est donc possible de construire des tableaux de bord filtrés par propriétaire, triés par impact sur les coûts, ou limités à un domaine spécifique — tout via des requêtes SQL standard sur des tables que vous contrôlez. Les données sont déjà là grâce au fonctionnement normal d’Elementary ; construire le tableau de bord n’est qu’une question d’écriture des requêtes.

Une note pratique : les noms de tables et de colonnes peuvent légèrement varier selon votre version d’Elementary et votre adaptateur d’entrepôt. Vérifiez le schéma réel dans votre entrepôt avant de construire des tableaux de bord, particulièrement pour les champs plus récents comme les octets facturés qui peuvent ne pas exister dans les versions plus anciennes.