Vérification des contrats de données avec Soda

Soda Data Contracts fournit un moteur de contrats basé sur YAML qui s’exécute de manière programmatique après l’atterrissage des données dans l’entrepôt mais avant l’exécution de dbt, permettant une vérification des contrats avant transformation.

Pourquoi cette couche compte

La dbt-expectations sur les sources et les contrats de modèles opèrent pendant le run dbt — après l’atterrissage des données. Pour la plupart des équipes, les tests sur les sources détectent les problèmes suffisamment tôt pour que les modèles mart en aval ne se construisent pas sur des données corrompues.

La vérification pré-chargement est plus importante dans deux scénarios :

1. Les changements de schéma source se propagent dans plusieurs projets. Si trois projets dbt consomment la même table source et qu’une colonne disparaît, les trois projets doivent échouer et alerter indépendamment. La vérification post-chargement détecte le problème une fois, à la frontière, avant qu’un projet ne s’exécute.

2. Le coût d’avoir des données incorrectes dans l’entrepôt est trop élevé. Certains contextes réglementaires ou opérationnels ne peuvent pas tolérer même brièvement des données non conformes persistées. La vérification post-chargement avec une porte de pipeline empêche les processus en aval de toucher des données qui n’ont pas passé la validation.

YAML de contrat Soda

Soda v4 fournit un format de contrat dédié avec validation de schéma, vérifications de fraîcheur, détection de valeurs manquantes, règles de validité et détection de doublons :

dataset: datasource/db/schema/orders
checks:
  - schema:
  - row_count:
columns:
  - name: order_id
    data_type: VARCHAR
    checks:
      - type: duplicate_count
  - name: status
    data_type: VARCHAR
    checks:
      - type: invalid_count
        valid_values: ['pending', 'shipped', 'delivered', 'cancelled']

La vérification schema valide que les colonnes réelles de la table correspondent à ce que le contrat déclare — si une colonne est manquante ou qu’une nouvelle colonne apparaît, la vérification échoue. Les vérifications au niveau colonne valident les contraintes de contenu : duplicate_count sur order_id détecte les violations de clé primaire, et invalid_count sur status détecte les valeurs inattendues.

Ce format est délibérément plus focalisé qu’un contrat ODCS complet. Il ne couvre pas les SLA, les métadonnées de propriété ou les propriétés de gouvernance — il s’agit purement de validation à l’exécution. Si vous utilisez ODCS pour la couche organisationnelle, la vérification de contrat Soda gère l’exécution à l’exécution des règles de qualité intégrées dans ce contrat plus large.

Intégration avec l’orchestration du pipeline

La vérification Soda s’exécute de manière programmatique via Python, ce qui facilite son insertion dans l’orchestration entre EL et transformation :

from soda.contracts.contract import Contract, ContractResult

contract = Contract.from_file("contracts/orders.yml")
result: ContractResult = contract.verify()

if not result.is_ok():
    raise Exception(f"Échec de la vérification du contrat : {result.errors}")

Le pattern d’orchestration ressemble à ceci :

Outil EL termine → Vérification du contrat Soda → Build dbt

Si la vérification Soda échoue, le pipeline s’arrête. dbt ne s’exécute jamais. L’échec du contrat déclenche une alerte, et quelqu’un enquête sur le changement source avant que toute transformation ne touche les données.

Dans Airflow, Dagster ou Prefect, c’est une dépendance de tâche : la tâche de vérification Soda doit réussir avant que la tâche dbt commence. Dans les configurations plus simples (basées sur cron ou GitHub Actions), c’est une étape séquentielle avec une vérification du code de sortie.

Soda vs Elementary

Soda et Elementary servent différents points dans le pipeline, et comprendre la distinction évite à la fois le chevauchement et les lacunes :

Soda se situe en dehors de dbt. Il peut vérifier les données avant que dbt les touche. Il s’exécute comme un processus Python autonome sur des tables d’entrepôt, indépendamment de tout projet dbt. C’est le bon outil pour la frontière post-chargement, pré-transformation.

Elementary s’exécute à l’intérieur de dbt. C’est un package dbt qui s’exécute pendant dbt test ou dbt run. Il détecte les changements pendant le run de transformation — changements de schéma, anomalies de volume, anomalies de fraîcheur — mais les données ont déjà été chargées et dbt a déjà commencé à les traiter.

Les différences de couverture :

Utiliser les deux donne une couverture à deux points d’application : Soda détecte les problèmes à la frontière de l’entrepôt avant que la transformation commence, et Elementary détecte les anomalies pendant la transformation que les vérifications basées sur règles manquent. Ils sont complémentaires, pas concurrents.

Quand adopter les contrats Soda

Pour la plupart des équipes, la dbt-expectations sur les sources fournit une validation post-chargement suffisante sans ajouter un autre outil. Les tests s’exécutent pendant dbt build, détectent la dérive structurelle et de contenu, et s’intègrent à votre workflow de test dbt existant.

Les contrats Soda méritent leur place quand :

• Vous avez besoin d’une porte ferme entre le chargement et la transformation — pas « tester pendant dbt » mais « vérifier avant que dbt commence »
• Plusieurs projets dbt consomment les mêmes tables source, et vous voulez une vérification centralisée plutôt que des tests source redondants
• Vous implémentez ODCS et voulez un moteur à l’exécution qui exécute les règles de qualité de votre spécification de contrat
• Votre orchestrateur de pipeline prend en charge les dépendances de tâches et vous voulez des portes explicites de succès/échec entre les étapes du pipeline

Pour les équipes ne rencontrant pas les problèmes de fossé post-chargement décrits ci-dessus, les tests de source dbt-expectations sont suffisants. Les contrats Soda deviennent pertinents quand des portes pré-dbt, une vérification multi-projets centralisée ou une intégration ODCS sont nécessaires — la prochaine étape dans le modèle d’application en couches.

Soda Cloud vs OSS

Soda Core (la bibliothèque open-source) gère la vérification des contrats, les vérifications de schéma et les règles de qualité de base. Il s’exécute partout où Python s’exécute et ne stocke aucun état — chaque vérification est indépendante.

Soda Cloud ajoute le suivi historique (comment le taux de réussite de ce contrat a-t-il évolué dans le temps ?), les fonctionnalités de collaboration d’équipe, la gestion des incidents et les intégrations avec les catalogues de données et les systèmes d’alerte. La tarification est à l’usage.

Pour les équipes qui ont juste besoin de la porte pré-dbt, Soda Core est suffisant. La couche Cloud devient précieuse quand vous voulez une visibilité sur les tendances de conformité des contrats dans votre organisation — particulièrement utile lors de la construction du cas organisationnel pour étendre la couverture des contrats.