Intégrité des données

1) Qu'est-ce que l'intégrité des données

L'intégrité des données est un ensemble de propriétés et de contrôles qui garantit que les données sont correctes, cohérentes et cohérentes sur tout le cycle de vie, des sources aux transformations en passant par les vitrines, les API et les exportations. L'objectif est que la même déclaration donne la même réponse à la répétition, et que toute modification soit tracable et vérifiable.

2) Types d'intégrité et où ils vivent

Entité (Entity) : clés primaires uniques, pas de doublons.
Référence (Referential) : Liens FK corrects ; l'absence de références « suspendues ».
Domaine (Domain) : plages et formats valides (type, longueur, guides).
Règles d'affaires : invariants du domaine de l'objet (solde ≥ 0, somme des câblages = 0, etc.).
Temporel : monotonie et cohérence des horodatages, zones temporelles correctes.
Politiques d'accès : RLS/CLS ne perturbe pas la cohérence logique des données visibles.

3) Contrats et schémas de données (source de vérité)

Nous définissons des contrats formels pour les jeux et les événements ; les appliquer à l'entrée et après chaque transformation.

yaml dataset: payments primary_key: txn_id foreign_keys:
- fk: user_id -> users.user_id 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: currency, type: string, in: [USD,EUR,TRY,UAH]}
- {name: event_time, type: timestamp, tz: UTC}
dq_rules:
- "duplicates(txn_id)=0"
- "ref_integrity(user_id, users.user_id)=true"
- "sum(amount) >= 0"
evolution:
semver: [MAJOR, MINOR, PATCH]
breaking_changes_require: approval:data-governance

4) Garanties transactionnelles et isolation

ACID pour OLTP : atomicité, consistance, isolation, durabilité.
Niveaux d'isolation : Read Committed/Repeatable Read/Serializable - choisissez des lectures « sales « /uniques/fantômes.
OLAP et lakehouse : commits atomiques de tables (log transaction), sink idempotent et schema-evolution avec contrôle de compatibilité.
Cohérence des formules KPI : la couche sémantique → une vérité pour les rapports et les API.

5) Systèmes distribués : ordre, répétitions, idempotence

Ordre des événements : utilisez 'event _ time' + 'ingested _ at', watermarks et la tolérance lateness ; agrégats basés sur le temps de l'événement.
Refonte (at-least-once) : global 'event _ id', tables d'idempotency keys, upsert/merge par clé durable.
Out-of-order : recalculer les fenêtres, la stratégie de retard, la rémunération.
Exactly-once au sens : le transport peut être at-least-once, le récepteur est idempotent.

6) Validation de l'intégrité (DQ) sur chaque couche

• Freshness/Completeness/Uniqueness/Valid Values/Referential Integrity.
• Anomalies : éclats de doublons, discontinuités de temps, changements brusques de distribution.
• Contrôle des formules KPI : versionalité des calculs et tests de correspondance des résultats (sets golden).
• Contrôle des exportations : interdiction de délivrer des trousses avec des irrégularités (quarantine).

yaml expect_column_values_to_be_unique: {column: txn_id}
expect_column_values_to_not_be_null: {column: user_id}
expect_column_values_to_be_in_set: {column: currency, value_set: [USD,EUR,TRY,UAH]}

7) Intégrité financière et opérationnelle

Double-entrée (double entrée) : débit/crédit au bilan ; rapprochement consolidé en cut-off.
Invariants totaux : montant des paiements = montant des prélèvements + commissions + ajustements.
Invariants opérationnels : les métriques SLA/guardrail ne brisent pas les règles commerciales (par exemple, les réparations automobiles ne créent pas de doublons).

8) Linéage, audit et reproductibilité

Lignage : de la source aux vitrines/fiches ; visibilité des transformations et des propriétaires.
Audit-trails : qui a changé quoi, quand et pourquoi ; versions des schémas/formules/jobs.
Snapshots/points de contrôle : possibilité de recalculer et de confirmer les rapports passés.
Repro : la même requête sur la même tranche → le même résultat (versions et calques).

9) Sécurité et vie privée sans perte d'intégrité

RLS/CLS : les filtres ligne/colonne ne doivent pas perturber les invariants (par exemple, la somme de l'échantillon visible doit correspondre à celle déclarée).
Masquage/Tokenization : stratégies déterministes pour que le dédoublement et l'intégrité référentielle soient préservés.
Cryptage : dans le canal et « sur disque » après compression ; gestion des clés et vérification des accès.
DSAR/Retraite : la suppression/anonymisation ne rompt pas la connectivité (politique en cascade).

10) Libre-service et réparation automatique

Quarantine : isolement des lots/trampolines suspects ; aux consommateurs - une branche « propre ».
Replay/Backfill : Republier une fenêtre à partir d'un journal raw immuable.
Reconcile : rapprochement des couches et des systèmes (raw↔curated↔marts ; istochnik↔DWH).
Dedup/Compaction/Rebuild : Procédures système de réparation d'index/agrégats.
Policy-as-code : « quelle anomalie → quelle action → seuils → escalade ».

11) Pratiques de modélisation et de stockage

Clés stables : PK substituts (UUID/ULID), clés naturelles immuables dans les manuels.
Normalizatsiya↔denormalizatsiya : Communications FK dans les sources, vitrines dénormalisées avec contrôle de la version logique.
SCD1/SCD2 : histoire guidée pour les dimensions.
Tri/clustering : améliore RLE/zone-maps et simplifie les rapprochements.
Hashs et checksum : vérification de l'intégrité des fichiers/lots.

12) Intégrité dans le temps et dans les rapports

Versions des formules : le rapport de janvier 2025 doit être reproduit par la formule de la version X.
Coupe-off et « fermeture de la période » : congélation des vitrines et des tranches d'archives.
Late arriving facts : mécanique de dosage et de recalculage avec la marque de la version du rapport.
Documentation des redéfinitions : corrections manuelles - seulement avec un audit.

13) Intégrations et API

Contrat API : schémas, types, champs obligatoires, codes d'erreur ; versioning (v1/v2).
Validation à l'entrée : reject mauvais payload's, ne pas « réparer en silence ».
Idempotent POST : clé d'idempotence, la répétition est sûre.
Exporter vers des fichiers : cohérence des lots, hachages, signatures.

14) Anti-modèles

SELECT dans les requêtes et les voyous - se brise dans l'évolution MINOR.
FK « sur les mots » : absence de vérification réelle des liens.
Corrections tacites des données sans audit ni rapport.
Mélange de TZ et de formats temporels dans un seul ensemble.
Redéfinition du KPI par des « stylos » sans versions ni journaux.
La seule clé de déduplication sans stratégies de rechange.
Suppression DSAR sans analyse en cascade des liens.

15) Feuille de route pour la mise en œuvre

1. Inventory & criticité : carte des ensembles/événements, propriétaires, risques, invariants.
2. Contrats et schémas : formaliser les types/contraintes/FK, contrôles d'interopérabilité CI.
3. DQ en pipline : Freshness/Completeness/Uniqueness/RI, quarantine, alertes.
4. Base transactionnelle : atomic-sink, upsert/merge, histoire SCD, versionalité des formules.
5. Lineedge et audit : annuaire, trace, change-logs, access-logs.
6. Politiques de réparation : replay/backfill/dedup/reconcile en tant que code ; runbook’и и SLO MTTR-data.
7. Sécurité : RLS/CLS, masquage, cryptage, processus DSAR.
8. Reporting : cut-off, freeze-tranches, gestion des versions KPI.

16) Chèque avant la sortie de l'ensemble/vitrine

• PK/FK et les restrictions de domaine sont spécifiées et testées.
• La versionation des schémas/formules est incluse ; schema-diff est vert.
• Règles DQ (fraîcheur/exhaustivité/unicité/fourchettes/IR) vertes.
• Entrées idempotentes : upsert/merge, clé d'idempotentialité (pour les événements).
• Temps : 'event _ time' et 'ingested _ at', TZ = UTC ; la politique de late data.
• Lineage et audit sont visibles ; y compris la quarantine et les alertes.
• RLS/CLS/masquage ne perturbe pas les invariants et RI.
• DSAR/Retraite testé ; cut-off/archive est prêt.

17) Mini-modèles

SQL : vérification de l'intégrité de référence

sql select count() as orphans from fact_payments f left join dim_users u on f.user_id = u.user_id where u.user_id is null;
-- ожидаем orphans = 0

Politique de quarantine/réparation (pseudo-YAML)

yaml policy: payments_integrity detect:
- rule: duplicates(txn_id) > 0
- rule: ref_integrity(user_id, users.user_id) = false auto_actions:
- quarantine_partition: {date: today}
- trigger_replay: {window: "last_2h"}
escalate_if:
- condition: violations_persist>30m page: "oncall-data"

Schéma de SCD2 pour la mesure

sql
-- dim_user_status (SCD2)
user_id, status, valid_from, valid_to, is_current

18) Résultat

L'intégrité des données n'est pas une vérification unique, mais un système de garantie de bout en bout : contrats formels et restrictions, invariants transactionnels et distribués, validation et automatisation des réparations, linéage et audit, vie privée et droits. Lorsque ces éléments travaillent ensemble, les données deviennent une base fiable pour les décisions et les incidents sont rares, courts et prévisibles.