Elementary pour dbt

Elementary est un outil d’observabilité des données natif dbt. Il étend dbt avec la détection d’anomalies, le suivi historique des tests, la surveillance de la fraîcheur et les alertes — des capacités qui comblent un écart entre les tests génériques intégrés de dbt et les plateformes d’observabilité commerciales comme Monte Carlo ou Bigeye. Tout ce qu’Elementary produit vit dans votre entrepôt sous forme de tables interrogeables, ce qui signifie que vous possédez les données et pouvez les exploiter avec n’importe quel outil BI.

Architecture : deux composants

Elementary comporte deux parties servant des objectifs distincts.

Le package dbt s’installe via packages.yml comme toute autre dépendance dbt. Il crée des tables de métadonnées dans un schéma dédié et utilise des hooks on-run-end pour capturer les artefacts après chaque dbt run ou dbt test. Les temps d’exécution des modèles, les résultats de tests, les snapshots de schéma et les métadonnées d’exécution transitent tous vers des tables que vous contrôlez.

Le CLI (edr) est un outil Python standalone qui lit depuis ces tables d’entrepôt. Il génère des rapports d’observabilité HTML, envoie des alertes vers Slack ou Teams, et exécute la logique de détection d’anomalies. Le CLI se connecte à votre entrepôt via son propre profil, séparé de votre profil dbt.

Le flux de données est linéaire :

dbt run/test --> hooks on-run-end --> INSERT dans les tables Elementary --> edr lit les tables --> rapports/alertes

Cette séparation est importante. Le package dbt n’a aucun coût d’exécution au-delà des insertions des hooks. Le CLI s’exécute indépendamment, selon le calendrier de votre choix, et peut être pointé vers n’importe quel environnement où les tables Elementary existent.

Installation

Ajoutez le package et configurez son schéma :

packages:
  - package: elementary-data/elementary
    version: 0.21.0

# dbt_project.yml
models:
  elementary:
    +schema: "elementary"

Pour dbt 1.8+, deux flags sont requis en raison des changements dans le fonctionnement des matérialisations de package :

flags:
  require_explicit_package_overrides_for_builtin_materializations: False
  source_freshness_run_project_hooks: True

Une macro d’override de matérialisation est également nécessaire. Sans elle, les tests s’exécutent mais les tables de résultats d’Elementary restent vides — l’échec silencieux le plus courant lors de l’installation :

-- macros/elementary_materialization.sql
{% materialization test, default %}
  {{ return(elementary.materialization_test_default()) }}
{% endmaterialization %}

Exécutez dbt deps, puis dbt run --select elementary pour créer les tables de métadonnées, puis dbt test pour les peupler avec les résultats initiaux.

Tests de détection d’anomalies

Là où les tests intégrés de dbt valident des règles statiques que vous définissez, les tests d’Elementary apprennent des patterns depuis les données historiques et signalent les déviations. Ils utilisent des statistiques de Z-score : une sensibilité de 3 signifie qu’une alerte est déclenchée lorsqu’une métrique se situe à plus de 3 écarts-types de sa moyenne historique.

Anomalies de volume

Détecte les comptages de lignes inhabituels. Si une table source reçoit normalement 10 000 lignes par jour et en reçoit soudainement 2 000, un test not_null passe mais volume_anomalies le détecte.

tests:
  - elementary.volume_anomalies:
      where: "event_date = current_date()"
      time_bucket:
        period: day
        count: 1

Anomalies de fraîcheur

Surveille le délai entre les mises à jour de tables. Contrairement aux vérifications de fraîcheur des sources dbt, qui utilisent un seuil fixe que vous devez définir, freshness_anomalies apprend la cadence normale de mise à jour et signale les déviations. event_freshness_anomalies suit le délai entre le moment où un événement s’est produit et celui où il a été chargé.

Anomalies de colonnes

Suit les métriques au niveau des colonnes — pourcentage de nulls, moyenne, min, max, nombre de valeurs distinctes, nombre de zéros — et alerte lorsqu’une métrique dévie de sa baseline historique. Utile pour détecter les glissements de distribution qui passent toutes les contraintes au niveau des lignes.

tests:
  - elementary.column_anomalies:
      column_name: order__amount
      column_anomalies:
        - average
        - max
      anomaly_sensitivity: 3
      training_period:
        period: day
        count: 14

Le training_period contrôle combien d’historique Elementary utilise pour établir les baselines. Quatorze jours est un défaut raisonnable ; augmentez-le si vos données ont des cycles hebdomadaires, réduisez-le si les patterns changent fréquemment.

Changements de schéma

Détecte les colonnes ajoutées ou supprimées, les changements de type et les tables supprimées. La variante schema_changes_from_baseline valide par rapport à un schéma explicitement défini, ce qui est utile pour les modèles avec des consommateurs en aval dépendant d’un contrat stable.

Alertes

La commande edr monitor envoie des notifications pour les échecs de tests. Slack est la destination la plus courante :

edr monitor --slack-token $SLACK_TOKEN --slack-channel-name data-alerts

Les alertes deviennent plus utiles avec des métadonnées dans le YAML de vos modèles :

models:
  - name: mrt__finance__revenue
    meta:
      owner: "@jessica.jones"
      channel: finance-data-alerts
      alert_suppression_interval: 24

Le champ channel route les alertes vers des canaux Slack spécifiques à l’équipe. alert_suppression_interval (en heures) empêche les alertes répétées pour le même échec persistant — essentiel pour éviter la fatigue aux alertes.

Pour le routage par chemin sur un répertoire entier de modèles :

models:
  your_project:
    marts:
      finance:
        +meta:
          channel: finance-data-alerts

Le regroupement des alertes consolide les échecs en cascade en un seul message au lieu d’inonder un canal :

edr monitor --group-by table --group-alerts-threshold 5

Rapports et tableaux de bord

edr report génère un fichier HTML autonome montrant l’historique pass/fail des tests, les tendances de temps d’exécution des modèles, les graphiques de détection d’anomalies et la lignée des données. Pour l’accès équipe, hébergez-le sur S3, GCS ou Azure Blob Storage avec edr send-report.

Puisqu’Elementary stocke tout dans les tables d’entrepôt (elementary_test_results, dbt_run_results, dbt_models), il est également possible de construire des tableaux de bord personnalisés dans votre outil BI existant. Une requête utile pour suivre la qualité des données dans le temps :

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;

Notes spécifiques à BigQuery

Le profil CLI nécessite un paramètre location explicite (US, EU ou votre région spécifique). dbt l’infère, mais pas Elementary — c’est la source d’erreurs de connexion la plus courante sur BigQuery.

elementary:
  outputs:
    default:
      type: bigquery
      method: oauth
      project: your-project-id
      dataset: your_schema_elementary
      location: US
      threads: 4

Le compte de service exécutant edr a besoin de BigQuery Data Viewer sur le dataset Elementary, Metadata Viewer et Resource Viewer sur vos datasets dbt, et Job User sur le projet. Ce sont des rôles orientés lecture ; le CLI n’écrit pas dans vos modèles de production.

La place d’Elementary dans une stratégie de tests

Elementary se comprend mieux comme un complément aux tests explicites basés sur des règles, pas comme un remplacement. La Taxonomie des tests dbt présente cinq mécanismes de test dans dbt ; Elementary occupe l’espace des « inconnus inconnus » — les anomalies qu’on ne penserait pas à tester explicitement.

Une stratification pratique :

Pour les modèles incrémentiels, les tests d’anomalies de volume et de fraîcheur d’Elementary sont particulièrement précieux. Les exécutions incrémentielles ne traitent que les nouvelles données, donc un échec silencieux en amont qui arrête l’envoi de lignes ne provoquera pas d’erreur — le modèle incrémentiel traite simplement zéro nouvelle ligne et réussit. La détection d’anomalies de volume détecte ce cas.

OSS vs. Cloud

Elementary OSS fournit la détection d’anomalies, les rapports HTML et les alertes Slack/Teams sans coût de licence. Le compromis est la maintenance : prévoyez 2 à 5 jours pour l’installation initiale, une configuration continue et un hébergement de rapports auto-géré.

Elementary Cloud ajoute des moniteurs ML automatisés (plus sophistiqués que l’approche Z-score OSS), la lignée au niveau des colonnes jusqu’aux outils BI, un catalogue de données et des intégrations de gestion des incidents avec PagerDuty, Jira et ServiceNow. Pour les équipes de moins de 4 ingénieurs, la version OSS est généralement suffisante. Au-delà, la charge opérationnelle de l’auto-hébergement commence à rivaliser avec le coût d’une solution managée.