Schema Evolution: Managing Change Without Breaking Pipelines

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.

Phase 1: EXPAND                    Phase 2: MIGRATE                  Phase 3: CONTRACT
┌──────────────────┐              ┌──────────────────┐              ┌──────────────────┐
│  Table: users    │              │  Table: users    │              │  Table: users    │
│  id         INT  │              │  id         INT  │              │  id         INT  │
│  name       VARCHAR ◄── ancien │  name       (déprécié)          │  full_name  VARCHAR ◄── nouveau
│  full_name  VARCHAR ◄── nouveau│  full_name  VARCHAR ◄── synchro│                  │
│  Double-écriture  │              │  Backfill ancien →│              │  Supprimer ancien│
│                  │              │  nouvelle 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

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

Ressources

:::