Conception de contrats de données

Que fait Conception de contrats de données ?

Quand l'utiliser

• Un flux amont (service, événement, API, fichier) alimente des pipelines en aval et un changement pourrait les casser silencieusement.
• Définir l'interface entre une équipe/système producteur et l'entrepôt.
• Ajouter une validation du schéma/qualité à la frontière d'ingestion.
• À NE PAS utiliser pour des changements internes modèle-à-modèle au sein d'un projet dbt (utiliser des tests + handling-schema-evolution).

Ce que spécifie un contrat

• Schéma : champs, types, nullabilité et valeurs autorisées.
• Sémantique : ce que signifie chaque champ et son unité/granularité.
• Garanties : fraîcheur/SLA, attentes de volume, unicité des clés.
• Responsabilité : qui le produit et qui contacter.
• Versionnement + politique de changement : comment les changements cassants sont communiqués.

Flux de travail

- [ ] Rédiger le contrat comme un schéma versionné et versionné (pas de connaissance tribale)
- [ ] L'appliquer à la frontière d'ingestion (valider à l'arrivée)
- [ ] Classifier les changements : additifs (sûrs) vs cassants (nécessitent une nouvelle version)
- [ ] En cas de violation, rejeter/mettre en quarantaine et alerter le producteur
- [ ] Versionner et communiquer les changements cassants à l'avance

1. Rendez-le explicite et versionné. Stockez le contrat comme code (JSON Schema, schéma Avro/Protobuf, ou une spécification YAML) à côté du pipeline, examiné comme toute API.
2. Appliquez à la frontière. Validez les données entrantes par rapport au contrat à l'arrivée ; rejetez ou mettez en quarantaine les violations au lieu de les charger.
3. Classifiez les changements. Les champs additifs/optionnels = rétrocompatibles. Supprimer des champs, renommer, resserrer les types/nullabilité = cassant → nouvelle version.
4. Échouez bruyamment vers le producteur, pas silencieusement en aval.

Modèles

Contrat en JSON Schema (appliqué à l'ingestion) :

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["order_id", "amount", "ordered_at"],
  "properties": {
    "order_id": { "type": "string" },
    "amount": { "type": "number", "minimum": 0 },
    "ordered_at": { "type": "string", "format": "date-time" },
    "coupon": { "type": ["string", "null"] }
  },
  "additionalProperties": false
}

Point d'application — validez chaque enregistrement à l'ingestion ; acheminez les échecs vers un emplacement quarantine avec la raison, et alertez l'équipe productrice. Cela transforme une panne silencieuse en aval en un signal immédiat et attribué à la source.

Registre de schémas (Kafka/Avro) — appliquez la compatibilité (BACKWARD) au moment de la publication afin que les producteurs ne puissent pas publier un schéma incompatible.

Pièges courants

• Contrat comme documentation uniquement — s'il n'est pas appliqué dans le code, il dérive et casse silencieusement.
• Application en profondeur dans l'entrepôt — capturez les violations à la frontière, avant que les mauvaises données ne se propagent.
• Absence de versionnement — chaque changement devient une urgence ; versionnez et dépréciez gracieusement.
• additionalProperties sans restriction quand vous avez besoin de rigueur — des champs inattendus passent ; mettez-le à false là où c'est approprié.
• Absence de propriétaire — un lot rejeté sans personne à contacter bloque le pipeline.
• Changements cassants sans délai de prévenance — coordonnez producteur/consommateur via des schémas versionnés et une fenêtre de dépréciation.