Validation des données
1) Pourquoi est-ce nécessaire iGaming-plate-forme
Confiance dans les rapports et les KPI : GGR/NET, conversions, rétention, signaux RG.
Fiabilité ML/scoring : fiches correctes pour antifrode/recommandations/RG.
Opérations en temps réel : alertes à la dérive/perte d'événements avant que les paiements/UX ne soient affectés.
Conformité : absence de PII/secrets là où il ne devrait pas y en avoir ; traçabilité prouvable.
2) Où valider : niveaux de contrôle
1. Ingest (batch/stream) : schéma, types, champs obligatoires, idempotency/dedup.
2. Stream-processing : fenêtres/filigranes, ordre, omissions/retards, exactly-once.
3. ETL/ELT et transformations : références/joyaux, agrégats, bilans d'entreprise.
4. DWH/vitrines (Gold) : consistance entre les tables, fraîcheur, unicité des clés.
5. Feature Store/online : gammes de fiches, cohérence des offlayn↔onlayn.
6. BI/API : comptages et filtres, SLAs sur latency/freshness, k-anonymat.
3) Types de contrôles (catalogue)
Schémas : type/nullable/enum/regex/JSON-shape ; modifications incompatibles → stop.
Domaines : montants de ≥0, devise ∈ {EUR, USD, TRY, BRL}, taux ≤ limite, strana∈litsenzii.
Identité/clés : la clé primaire est unique, la clé étrangère n'est pas « suspendue ».
Qualité des champs : remplissage, longueurs, format (IBAN, BIN, jeton électronique).
Statistiques/lignes de base : fréquences, distributions, corridors quantiles.
Anomalies : surtensions de volume/lobes, zéros/doublons, schema drift.
Fraîcheur : max (ts) pas plus grand que X ; lag ingest→gold ≤ T.
Consistance : somme par détail = sommaire ; multi-table reconciliation.
Confidentialité/sécurité : Zero-PII en dehors des zones autorisées ; Tokenization/masques.
Réglementation : Les champs RG/AML sont présents et plausibles (dates, signes).
4) Contrats de données (contrats de données)
Le contrat fixe le schéma + règles de qualité + SLO entre la source et les consommateurs.
Contrat minimum (fragment) :yaml dataset: payments_ingest_v2 owner: team-payments schema:
id: {type: string, pattern: "^[a-f0-9]{32}$", unique: true}
ts: {type: timestamp, timezone: "UTC", nullable: false}
amount: {type: decimal(18,2), min: 0. 00}
currency: {type: string, enum: ["EUR","USD","TRY","BRL"]}
psp: {type: string, required: true}
quality:
freshness_max: "PT5M"
completeness_min: 0. 995 duplicate_rate_max: 0. 001 pii_allowed: false slo:
p95_ingest_latency_ms: 30000 success_rate: 0. 995
Modifications de contrat - via semver et migration : 'MAJOR' casse, 'MINOR' ajoute un champ, 'PATCH' corrige la description.
5) « Attentes » et politiques
Les attentes sont des vérifications déclaratives exécutables en piplines (batch/stream).
Exemples d'attentes (YAML) :yaml expectations:
- name: unique_primary_key check: "unique(id)"
severity: "error"
- name: amount_non_negative check: "amount >= 0"
severity: "error"
- name: currency_enum check: "currency in ['EUR','USD','TRY','BRL']"
severity: "error"
- name: ts_fresh_enough check: "now() - max(ts) <= interval '5 minutes'"
severity: "warn"
- name: pii_absent check: "no_plain_pii(columns: ['email','card','iban'])"
severity: "error"
Politique d'intervention :
- 'Error '→ quarantaine lot/batch, alerte + ticket ; bloc downstream.
- 'Warn '→ passe, mais crée une tâche d'analyse ; marque de qualité.
- 'Info '→ seulement la surveillance.
6) Streaming : spécificité des contrôles
Watermarks/late data : nous admettons le retard « ≤ 120s », sinon la quarantaine ; nous compensons par les fenêtres finales.
Idempotency : clé d'événement + hash payload → dedup sur le courtier/dans le flux.
Exactly-once : Sing transactionnel (+ inks idempotent) pour les flux critiques (paiements/rounds).
Compteurs de volume : « attendu » vs « reçu » par fenêtre ; divergence → alert.
scala val deduped = stream
.keyBy(_.id)
.process(new DeduplicateWithin(Time. minutes(10)))
val validated = deduped
.filter(_.amount >= 0)
.filter(_.currency in Set("EUR","USD","TRY","BRL"))
emitToQuarantineIfLate(validated, allowedLateness = 120. seconds)
7) DWH/SQL : invariants et rapprochements
Vérifications SQL (exemple) :sql
-- uniqueness
SELECT id, COUNT() c FROM gold. payments GROUP BY 1 HAVING c>1;
-- freshness
SELECT NOW() - MAX(ts) AS lag FROM gold. payments;
-- reconciliation of totals
SELECT
SUM(amount) AS by_rows,
(SELECT total_amount FROM gold. payments_summary WHERE date=CURRENT_DATE) AS by_summary
FROM gold. payments
WHERE date = CURRENT_DATE;
Matching with vitrines : rapprochements quotidiens 'detail → summary', rapports de divergence, ticket automatique.
8) Vie privée et sécurité
Édition PII par défaut : masques/tokens à l'entrée ; on interdit les e-mails/cartes/téléphones « crus » dans les logs.
Politique d'autorisation : tables avec PII - couche séparée/annuaire, accès par rôle (RBAC/ABAC).
K-anonymat des rapports : minimum N lignes dans la tranche.
Détecteurs leak : contrôles réguliers des modèles PII, « secrets » (clés/tokens).
Juridictions : géo/tenant-isolation (pays/marque/licence), clés séparées.
9) Métriques de qualité et SLO
Mesures de qualité (D) :- Freshness est un retard max (ts).
- Completeness est la proportion d'enregistrements non vides/attendus.
- Uniqueness - clés en double.
- Consistency - invariants et bilans (intertabulaires).
- Accuracy : Vérifie avec une source/des règles de domaine externes.
- Validation - conformité avec les types/enum/regex.
- `Freshness payments_gold ≤ 5 мин` (p95).
- `Completeness game_rounds ≥ 99. 7 %/день `.
- `Duplicate_rate ≤ 0. 1‰`.
- `PII_leak = 0`.
10) Alertes, tiquets et runbook
Itinérance : Slack/PagerDuty → propriétaire du domaine ; nous appliquons automatiquement les samples et le diff.
Regroupement : un incident par ensemble « labels : dataset = payments, brand = TR ».
1. Vérifiez l'ingest et la file d'attente du courtier.
2. Comparer « attendu vs reçu » par PSP.
3. Activer les retraits/commuter l'itinéraire PSP.
4. Annoter la cause ; la restauration des bacs ; faire un post-mortem.
11) Versioning, tests et processus waiver
Semver des règles de qualité : 'quality @ MAJOR. MINOR. PATCH`.
Tests unitaires de transformation (SQL/DBT/python) et tests contractuels pour les sources.
Les réseaux GOLDEN : les cas connus de divergence/fuite sont obligatoires dans la régression.
Waiver (exception) : autorisation à court terme d'enfreindre la règle (description, propriétaire, durée, mesures compensatoires).
12) Catalogues/artefacts (modèles finis)
12. 1 Passeport datacet
yaml dataset: gold. game_rounds owner: team-games steward: data-governance contracts: ["games_rounds_v3"]
quality_slo:
freshness_p95: "PT10M"
completeness_min: 0. 997 uniqueness_max_dup: 0. 0005 alerts:
channels: ["#dq-incidents","#games-ops"]
severity_map: {error: "P1", warn: "P2"}
12. 2 Stratégie de quarantaine
yaml quarantine:
storage: "s3://quarantine/payments/"
retention: "P30D"
access: ["team-payments","data-governance"]
auto_reprocess:
cron: "/15 "
max_attempts: 3
12. 3 Expectation для Feature Store
yaml featureset: fs_payments_online_v1 checks:
- name: feature_freshness check: "now() - max(feature_ts) <= interval '60 seconds'"
severity: "error"
- name: range_amount_avg check: "amount_avg in [0, 2000]"
severity: "warn"
- name: enum_device check: "device in ['ios','android','web']"
severity: "error"
13) Spécificité iGaming : cas prêts
Paiements/RFP : rapprochement du montant des dépôts/retraits avec les rapports du RFP ; les statuts manquants → la quarantaine batch ; alert sur la croissance de 'decline _ rate'.
Fournisseurs de jeux : la chute de 'rounds _ per _ min' vs baseline + schema drift du fournisseur → l'unité de transformation du fournisseur A, la bannière de statut.
RG/AML : champs obligatoires (limites, auto-exclusion, statuts KYC) ; les KYC périmés → un drapeau par bloc de paiement, un ticket de conformité.
Marketing/CRM : validation des paramètres de campagne, UTM, déduplication des événements ; k-anonymat dans les vitrines.
14) Feuille de route pour la mise en œuvre
0-30 jours (MVP)
1. Inclure les contrats pour les jeux clés : payments, game_rounds, utilisateurs, fonctionnalités.
2. Catalogue des attentes (10-15 basiques) + quarantaine + alertes.
3. Dashboard Freshness/Completeness/Uniqueness ; le rapport des incidents.
4. Runbook’и для `Freshness`, `Duplicates`, `Schema drift`.
30-90 jours
1. Rapprochement et équilibres intertabulaires ; waiver processus et semver règles.
2. Stream-validation (late data, dedup, watermarks) ; Détecteurs PII.
3. Intégration avec CI/CD : test contractuel des sources et transformations.
4. SLO de qualité dans OKR commandes de domaine.
3-6 mois
1. Indices de seuil AIOps ; auto-localisation des causes.
2. Cross-brand/geo politique de qualité et rapports de conformité.
3. L'après-mortem P1 des incidents → la reconstitution des réseaux d'or et des règles.
4. Lien avec l'alerte de flux et l'analyse des anomalies (boucle unique).
15) RACI
Gouvernance des données (A/R) : normes, contrats, audit des règles.
Domain Owners (R) : attentes de domaine et invariants.
Data Platform (R) : cadre d'attente, quarantaine, alertes, surveillance.
Sécurité/DPO (A/R) : vie privée/PII/k-anonymat, géo/tenant-isolement.
SRE/Observability (C) : routage des incidents, SLO/SLI.
Produits/Finances (C) : bilans d'affaires, priorités des incidents.
16) Anti-modèles
La validation « seulement en DWH » est tardive, coûteuse, douloureuse.
Pas de quarantaine - la « boue » va à Gold/ML et brise la confiance.
Seuils rigides sans saisonnalité/heures/marchés → tempête d'alerts.
L'absence de propriétaire et de règles semver → le chaos des exceptions.
Logs avec PII et « captures d'écran dans le canal partagé ».
Des « jours sanitaires » ponctuels au lieu d'un circuit permanent.
17) Sections connexes
Pratiques DataOps, Audit des données et versionalité, Origine et chemin des données, Alertes des flux de données, Analyse des anomalies et corrélations, Contrôle d'accès, Sécurité des données et cryptage, Politiques de stockage, MLOps : exploitation des modèles.
Résultat
La validation n'est pas un filtre à la fin, mais un contrat de qualité de bout en bout : de l'injection et du strim aux vitrines et aux fiches en ligne. Les attentes claires, la quarantaine, les alertes et les SLO transforment les données en un atout fiable : les rapports sont corrects, les modèles sont durables, les paiements sont sûrs, la conformité est calme.