Évolution de Schéma : Gérer le Changement sans Casser les Pipelines
#data-engineering#schema#databases#migration#governance
Les changements de schéma sont inévitables. Les exigences métier évoluent, de nouvelles sources apparaissent, les modèles sont refactorisés. La question n'est pas si les schémas vont changer, mais si ces changements vont casser les consommateurs en aval ou traverser le système en toute sécurité.
Matrice de Compatibilité de Schéma
| Type de Compatibilité | Changement | Anciens Lecteurs → Nouvelles Données | Nouveaux Lecteurs → Anciennes Données | Opérations Sûres |
|---|---|---|---|---|
| Backward | Le nouveau schéma lit les anciennes données | Peut casser | Fonctionne | Supprimer champs, ajouter optionnels |
| Forward | L'ancien schéma lit les nouvelles données | Fonctionne | Peut casser | Ajouter champs, supprimer optionnels |
| Full | Les deux directions fonctionnent | Fonctionne | Fonctionne | Ajouter/supprimer champs optionnels uniquement |
| None | Aucune garantie | Peut casser | Peut casser | Tout changement (risqué) |
En pratique, la compatibilité backward est le mode le plus couramment appliqué. Les schema registries (Confluent, AWS Glue, Karapace) l'appliquent automatiquement.
Comparaison des Stratégies de Migration
| Stratégie | Downtime | Risque | Complexité | Rollback | Idéal Pour |
|---|---|---|---|---|---|
| Big bang | Élevé — réécriture complète | Élevé | Faible | Difficile | Petites tables, dev |
| Expand-contract | Zéro | Faible | Moyen | Facile — supprimer les nouvelles colonnes | Systèmes de production, APIs |
| Blue-green schema | Quasi-zéro | Faible | Élevé | Basculer le pointeur | Systèmes critiques |
| Shadow writes | Zéro | Très faible | Élevé | Arrêter le shadow | Changements à haut risque |
| Schémas versionnés | Zéro | Faible | Moyen | Garder l'ancienne version | Flux d'événements, APIs |
Pattern Expand-Contract
Le pattern expand-contract divise chaque changement cassant en trois phases non-cassantes.
Expand-contract sur la table users
tadataExpand-contract sur la table users
| Phase 1 : EXPAND | Phase 2 : MIGRATE | Phase 3 : CONTRACT |
|---|---|---|
| id INT · name VARCHAR (ancienne) · full_name VARCHAR (nouvelle) | id INT · name VARCHAR (dépréciée) · full_name VARCHAR (synchronisée) | id INT · full_name VARCHAR (nouvelle) |
| Double écriture dans les deux colonnes | Backfill de l'ancienne colonne vers la nouvelle | Suppression de l'ancienne colonne et de la double écriture |
| Déployer le nouveau code (écrit dans les deux) | Lancer le script de migration (backfill + vérification) | Déployer le code de nettoyage (suppression de l'ancienne colonne) |
Évaluation des Risques par Type de Changement
| Type de Changement | Niveau de Risque | Impact Compatibilité | Mitigation |
|---|---|---|---|
| Ajouter colonne optionnelle | Faible | Forward + backward OK | Valeur par défaut requise |
| Ajouter colonne obligatoire | Moyen | Casse backward | Expand-contract |
| Renommer colonne | Élevé | Casse les deux directions | Expand-contract avec alias |
| Changer type de donnée | Élevé | Casse les deux directions | Nouvelle colonne + migration |
| Supprimer colonne | Moyen | Casse forward | Déprécier d'abord, contract ensuite |
| Changer clé primaire | Très élevé | Casse jointures, CDC, lookups | Blue-green ou shadow writes |
| Fusionner/scinder tables | Très élevé | Tous les avals cassent | Abstraction par vue + expand-contract |
tadata
Extrait de la fiche « Data Contracts » · Demander la fiche complète
Essentiels du Contrat de Données
| Élément | Objectif | Exemple |
|---|---|---|
| Définition du schéma | Garantie de structure | Schéma Avro, JSON Schema, Protobuf |
| Type sémantique | Signification métier | email, devise_eur, code_pays_iso |
| SLA de fraîcheur | Délai de livraison | "Mis à jour dans les 15 min du changement source" |
| Règles de qualité | Validité des données | "taux de null < 1%", "valeurs dans [A, B, C]" |
| Propriétaire | Responsabilité | équipe-paiements@entreprise.com |
tadata
Extrait de la fiche « Data Contracts » · Demander la fiche complète