Données auto-réparatrices

1) Définition et objectifs

Les données auto-réparatrices sont une approche de l'ingénierie des données dans laquelle les défauts sont détectés automatiquement et les actions correctives (réparation, refonte, retour, reconsilation, réindexation) sont effectuées sans intervention humaine ou avec un minimum d'intervention (humain-in-the-loop pour les cas sensibles).
Objectifs : réduction des données MTTR, confiance accrue, résistance à la dérive et aux pannes, coût de possession prévisible.

2) Défaillances types pour lesquelles il faut être traité

Schémas et contrats : modifications incompatibles, colonnes manquantes, conflits types.
Qualité/intégrité : doublons, omissions, violations de l'intégrité unique/référentielle.
Temps et fraîcheur : retards d'injection, « trous » par les fenêtres, dissynchronisation TZ/local.
Identifiants et clés : changement de générateur d'ID, collisions, clés naturelles flottantes.
Ordre des événements : événements tardifs, réorganisation, refonte (at-least-once).
Stockages : dégradation des lots, fichiers/blocs battus, distorsion du sharding.
Droits/sécurité : masques/cryptage incorrects, fuites PII dans les décharges.

3) Les piliers de l'auto-guérison

1. Contrats de données (schemas + règles) avec tests automatiques.
2. Piplines idempotentes (redémarrage sans double effet).
3. Journalisation et reproductibilité (raw/bronze immuable, lineage).
4. Mécanismes de réparation (replay, backfill, compaction, merge-repair, rebuild).
5. Observabilité et SLO (fraîcheur, exhaustivité, unicité, latence).
6. Les politiques décisionnelles (quand l'auto-fixe, quand l'escalade).

4) Contrats et tests de qualité

Le contrat décrit : schéma, gammes admissibles, unicités, RLS/masquage, SLA de fraîcheur.

yaml dataset: payments schema:
- name: txn_id; type: string; unique: true
- name: user_id; type: string; not_null: true
- name: amount; type: decimal(18,2); min: 0
- name: created_at; type: timestamp; tz: UTC freshness_sla: 15m constraints:
- "count(distinct txn_id) = count()"
- "pct_null(user_id) < 0. 1%"
privacy:
- mask: card_pan -> BIN6LAST4 actions_on_violation:
- auto_quarantine_partition
- backfill_missing_window
- notify_owner_and_open_ticket

Les tests sont exécutés à chaque étape : injection → staging → vitrine. La violation des règles active la réparation automatique (voir ci-dessous) et/ou la quarantaine.

5) Idempotence et déterminisme

Upsert/Merge par clés stables (SCD2 pour l'historique, SCD1 pour les tranches).
Transformations déterministes : une entrée → une sortie avec les mêmes paramètres.
Contrôle de version : enregistrez la version code/schémas/couches et l'étiquette de données (watermark).
Idempotent sink : enregistrement via staging + atomic swap/rename.
Exactly-once au sens : le transport « at-least-once » + récepteur idempotent est acceptable.

6) Mécanismes de réparation automatique (réparation toolkit)

Replay/Backfill : refoulement par la fenêtre 't ∈ [T0, T1]' à partir d'un journal invariable (raw).
Reconciliation (rapprochement) : comparaison des agrégats/clés entre les couches (raw ↔ curated ↔ marts) et entre les systèmes (source ↔ DWH).
Deduplication : window-dedup par clé (txn_id, event_id) + heuristique des distances (fuzzy pour les clés « sales »).
Compaction : transfert de petits fichiers en gros lots (Parquet/ORC), réindexation.
Merge-repair : en cas de conflit d'enregistrements, prédicats de priorité (par source/heure/version).
Rebuild indices/matérialisations : recalculer les agrégats/cube/roll-up.
Quarantine/Shadow : les lots suspects sont isolés ; les consommateurs lisent la branche « propre ».
Schema mediation : sélecteur automatique de projections (remplissage des défauts, colonnes déduites) en cas de changements mineurs.

7) Protection du stockage et intégrité

Chèques-montants et validation des blocs (CRC, parité).
Stockage de quorum (systèmes compatibles RAFT/Paxos, quorum reads/writes).
Codage d'effacement (erasure coding) pour une redondance économique.
Versioning des objets (object store versioning, undelete).
Atomic commit в Lakehouse (transaction log, ACID-таблицы: Delta/Iceberg/Hudi).

8) Ordre des événements et « sale réalité »

Événements tardifs : gardez la fenêtre lateness, utilisez watermark 'et ; recalculer les fenêtres.
Refonte : dedup par global 'event _ id', tables idempotency-keys.
Temps décalé : normalisation TZ, stockage 'ingested _ at' et 'event _ time'.
Out-of-order : agrégats basés sur le event_time avec ajustement par watermark.

9) Logique décisionnelle (moteur politique)

Règle : « quelle anomalie → quelle action → quels seuils → qui est le propriétaire ».

yaml policy: payments_freshness detect: freshness_delay > 15m auto_actions:
- trigger: backfill(last_60m)
- if: gap_persisted > 30m then: quarantine_partition(date=today, hour=current_hour)
escalate:
- if: gap_persisted > 60m -> page_oncall:data guardrails:
- do_not_expose_unverified_to_marts

10) Observabilité et SLO pour les données

• La fraîcheur (Freshness) des vitrines ≤ 15 min.
• Exhaustivité> 99. 5 % sur les champs clés.
• Unicité des clés (Uniqueness) : duplicata <0. 01%.
• Latence de calcul : p95 <5 min.
• Stabilité des réparations : MTTR-data <30 min.

Métriques et alertes : exposez dans Prometheus/Grafana ; Construire une bande d'incidents de données prioritaire.

11) Reconsilation et rapprochement (pratiques)

Rapprochement des agrégats : 'count/somme/min/max' entre les calques/systèmes de la fenêtre glissante.
Rapprochement des clés : différence symétrique des ensembles 'Δ = (A\B) ∪ (B\A).
« Audit job » périodique : comparaison avec la source, vérification sélective sur la primaire.
Paiements/finances : double entrée (double entrée), rapprochements coupés par jour, journal des ajustements.

12) Gestion des schémas et évolution

BouVer pour les schémas : MAJOR (casser )/MINEUR (ajouter )/PATCH (corriger).
Contrats en CI/CD : schema-diff, interopérabilité, automatisation des migrations.
Backfill-hook : avec MINOR, ajoutez les champs par défaut/déduits, recalculez les vitrines.
Projections flexibles : les lecteurs lisent des sous-ensembles de colonnes ; on interdit « SELECT ».

13) Sécurité, vie privée, conformité

RLS/CLS : filtres ligne/colonne, en particulier dans les branches de réparation et les exportations.
Masque PII : déterministe (tokenization) pour la déduplication durable.
Audit accès/exportation : qui a vu ce qu'il a exporté, où il a envoyé.
DSAR/Retraite : auto-suppression/anonymisation dans les processus de réparation ; les remboursements tiennent compte des exigences légales.

14) Coût et performance

Cost-aware backfill : limiter la largeur des fenêtres (par exemple, glisser 3-7 jours).
Matérialisations et caches : recalculer uniquement les lots changés (incrémental).
Hiérarchisation : d'abord vitrines critiques (finances, risques), puis analytiques.
Réparations off-peak : fenêtres de nuit/priorité faible dans le planificateur.

15) Tests et simulations d'incidents

Chaos-data-testing : brisez délibérément les lots/schémas sur le steadge.
Faux retards : simulez les sauts de trampoline, out-of-order, doublons.
Datasets Golden : références pour le rapprochement après réparation.
GameDays : entraînement régulier de l'équipe sur runbook 'am.

16) Anti-modèles

Corrections « invisibles » : modifications silencieuses sans audit ni rapport.
Backfill's non collés : aucune source de vérité/version de formule.
Lourdes demandes en direct à OLTP lors de la réparation : vous obtenez la prod.
SELECT chez les consommateurs : cassé en cas de changement MINEUR.
La seule clé de déduplication est l'absence de clés/signatures de hachage.

17) Feuille de route pour la mise en œuvre

1. Discovery : kits/métriques critiques, risques, propriétaires ; carte des dépendances.
2. Contrats et tests : formaliser les schémas/règles dans l'IC ; glossaire publié.
3. Idempotence : réécrire les piplines clés en upsert/merge, sink atomique.

4. Journal raw et lineage : couche immuable, métadonnées complètes, watermark 'et

5. Réparations mécaniques : backfill/replay, dedup, compaction, quarantine ; policy engine.
6. Observabilité et SLO : dashboards de qualité, alertes, ruban prioritaire.
7. Chaos-data et entraînement : exercice régulier + runbook '.
8. Optimisation des coûts : recalculations incrémentielles, hiérarchisation des fenêtres.

18) Chèque-liste avant la sortie

• Les contrats de données et les tests de qualité couvrent les ensembles critiques.
• Les piplines sont idempotentes ; il y a le commit atomique et les rebonds.
• Configurés backfill/replay et quarantine, les politiques d'escalade sont définies.
• Métriques Freshness/Completeness/Uniqueness/Latency et alertes en vente.
• Vérification des modifications/réparations incluses ; les versions des formules et des vitrines sont conservées.
• DSAR/Retraite sont respectées lors des réparations et des restaurations.
• Il y a un runbook 'et, des exercices ont été effectués, MTTR cible est enregistré.
• Le coût des backfill's est limité par le budget des gardes.

19) Exemples d'autopsies (modèles)

« Échec de la fraîcheur de la vitrine X » → backfill (last_2h) → sinon en 30 min → quarantine + page on-call.
L'augmentation des doublons txn_id → inclure un dedup + rapprochement strict avec la source → un rapport de cause à effet.
« MINOR Scheme Change » → générer un champ de défaut déduit → rebuild des agrégats.
La « perte de lots » → être restaurée à partir de l'objet versionné → la vérification du chèque-somme.

Résultat : les données auto-réparatrices ne sont pas un seul « script de réparation », mais une architecture système : contrats formels, piplines idempotentes, journal fiable, mécanique automatisée de réparation et observation transparente avec des SLO stricts. Un tel système non seulement se répare, mais transforme les incidents en événements gérables avec un coût et un temps de récupération compréhensibles.