Origine et chemin des données

1) Qu'est-ce que Data Lineage

• D'où viennent les chiffres du rapport ?
• Quelles tables/champs affecteront la modification du schéma ?
• Pourquoi le KPI a-t-il changé hier à 21 heures ?
• Quelles données sont entrées dans le modèle et la version spécifiques de ML ?

Pour iGaming, c'est critique en raison de la réglementation, des rapports financiers (GGR/NET), de l'antifroda, de KYC/AML, du jeu responsable et de la vitesse élevée des changements de produits.

2) Les niveaux et la granularité de la ligne

1. Règle d'affaires - Association des métriques et des termes d'affaires (du glossaire) avec les vitrines/formules.
2. Règle technique (tabulaire) - liens entre tables/jobs/paquets de transformations.
3. Colonne (field/column-level) - quelle colonne source forme la colonne de destination, avec les règles.
4. Runtime-line (opérationnel) - essais réels : temps, volumes, versions de code/schéma, hash-artefacts.
5. End-to-end est un chemin de bout en bout du fournisseur/PSP/CRM au rapport/dashboard/modèle.
6. Cross-domain/Mesh - liens entre les produits de données de domaine contractuels.

3) Valeur clé

Confiance et vérification : explication des rapports et des modèles, enquête rapide sur les incidents.
Analyse d'impact : modifications sécurisées des schémas/logiques, prévisibilité des sorties.
Vitesse de bond : les nouveaux analystes et ingénieurs comprennent le paysage plus rapidement.
Conformité : traçabilité PII, Legal Hold, rapports aux régulateurs.
Optimisation des coûts : identification des piplines « mortes » et des vitrines dupliquées.

4) Objets et artefacts

Entités du graphique : Source (fournisseur de jeux, PSP, CRM), Topic/Stream, Raw/Staging, Bronze/Silver/Gold, DWH, ML-fiches, modèle BI, Dashbord.
Liens : transformations (SQL/ELT), jobs (Airflow/DBT/...), modèles (version), contrats (Avro/Proto/JSON Schema).
Attributs : propriétaire, domaine, classification, version du schéma, contrôle de qualité, fraîcheur, SLO/SLI.

5) Sources de vérité pour la ligne

Statique : Parsing SQL/configs (dbt, ETL) → nous construisons des dépendances.
Dynamique/Runtime : collecte des métadonnées pendant l'exécution (opérateur dans l'orchestrateur, query logs).
Evénement : lineage-ivents lors de la publication/lecture des messages dans le bus (Kafka/Pulsar), validation des contrats.
Manuel (minimum) : description d'une logique d'entreprise complexe qui n'est pas extraite automatiquement.

6) Contrats de ligne et de données

Le contrat fixe le schéma, la sémantique et la SLA.
Vérification de la compatibilité (semver) et de l'idempotence - obligatoire.
La règle stocke la référence du contrat/version et le fait de passer la vérification (CI/CD + runtime).

7) Ligne dans iGaming : exemples de domaine

Les événements de jeu → les unités RTP, la volatilité, la rétention, la vitrine "Game Performance Gold'.
Paiements/conclusions/charjbecki → rapports GGR/NET, signaux antifrod.
KYC/AML → les statuts, les contrôles, алерты → les devantures комплаенса et la comptabilité.
Responsible Gaming → les limites/autoexceptions → скоринг des risques et les bascules des interventions.
Marketing/CRM → campagnes, bonus, paris → impact sur LTV/ARPPU.

8) Visualisation graphique

• Deux modes : « carte du paysage » (macro) et « piste de passage » (micro) de champ à champ.
• Filtres : par domaine, propriétaire, classification (PII), environnement (prod/stage), heure.
• Overlay : fraîcheur, volumes, erreurs DQ, versions de circuits.
• Actions rapides : "Afficher les dépendants", "Qui consomme cette colonne ? ", "Le chemin du dashboard KPI".

9) Analyse d'impact et gestion du changement

Avant de changer de schéma/logique, exécutez what-if : quels jobs/vitrines/dashboards/modèles vont affecter.
L'auto-génération des tiquets aux propriétaires d'artefacts dépendants.
Modèle dual-write/blue-green pour les vitrines : v2 est rempli en parallèle, comparaison des métriques, commutation.
Backfill-playbooks : comment et quoi rattraper les données historiques, comment vérifier la cohérence.

10) Linéarité et qualité des données (DQ)

Associez les règles DQ aux nœuds/champs du graphe : validité, unicité, cohérence, actualité.
En cas de perturbations, affichez les « segments rouges » sur les voies et soulevez les alertes aux propriétaires.
Gardez l'historique des incidents DQ et leur impact sur les KPI.

11) Ligne pour ML/AI

Traçabilité : dataset → fonctionnalités → code de formation → modèle (version) → inference.
Enregistrez les commits, les paramètres de formation, les versions des cadres, les données de validation.
Linége aide à enquêter sur la dérive, la régression des métriques et à reproduire les résultats.

12) Linéarité et vie privée/conformité

Étiqueter les champs PII/financier, pays, loi (RGPD/local), base de traitement.
Notez les nœuds où le masquage/pseudonyme/anonymisation est appliqué.
Pour DSAR/Right to be forgotten, tracer dans quelles vitrines/backaps le sujet est présent.

13) Métriques (SLO/SLI) pour la ligne

Coverage :% des tables/champs avec une ligne de colonne.
Freshness SLI : proportion de nœuds qui sont empilés dans la mise à jour SLA.
DQ pass-rate : proportion de contrôles réussis par voie critique.
MTTD/MTTR pour les incidents de données.
Temps de changement : temps moyen de négociation et de sortie sécurisée du schéma.
Dead assets : proportion de vitrines/job non réclamées.

14) Outils (catégories)

Catalogue/Glossary/Lineage : graphique de métadonnées unique, importé à partir de SQL/orchestrateurs/bus.
Orchestration : collecte de métadonnées runtime, état des tâches, SLA.
Schema Registry/Contrats : contrôles de compatibilité, stratégies de version.
DQ/Observability : règles, anomalies, fraîcheur, volumes.
Sec/Access : étiquettes PII, RBAC/ABAC, audit.
ML Registry : version des modèles, artefacts et datacets.

15) Modèles (prêts à l'emploi)

15. 1 Passeport du nœud de ligne

• Classification : Public/Internal/Confidentiel/Restreint (PII)
• Source/Entrées : tables/tops + versions des contrats
• Transformation : SQL/job/repo + commit
• Sorties/Consommateurs : vitrines/dashboards/modèles

• Signaux d'observabilité : fraîcheur, volume, anomalies

• Historique des incidents : liens vers les tiquets/post-mortem

15. 2 Carte de communication (column-level)

Du champ : schema. table. col (type, nullable)

Dans le champ : schema. table. col (type, nullable)

Règle de transformation : Expression/fonction/dictionnaire

Contexte de qualité : contrôles, gammes, références

15. 3 Pleybuk enquête sur l'incident

1. Identifier le KPI/dashboard affecté → 2) Suivre le chemin vers le haut (Upstream) jusqu'à la source →

2. Vérifiez la fraîcheur/volumes/DQ sur chaque nœud → 4) Trouvez le dernier changement de code/schéma →

3. Comparer prod/stadge/hier → 6) Assigner une fixation et un backfill → 7) Post-mortem et règle pour l'avenir.

16) Processus et intégration

On-change : chaque merge dans un repo qui change de schéma/SQL déclenche un recalage de ligne et une analyse d'impact.
On-run : chaque job réussi/échoué écrit des métadonnées runtime dans le graphe.
Access-hooks : les demandes d'accès montrent le chemin vers PII et les propriétaires responsables.
Rituels de gouvernance : revue hebdomadaire des voies critiques, rapport mensuel sur les SLO.

17) Feuille de route pour la mise en œuvre

0-30 jours (MVP)

1. Identifiez les KPI/dashboards critiques et leur chemin de bout en bout.
2. Connectez le parsing SQL/jobs pour la ligne tabulaire.
3. Avoir un passeport de nœud/communication et des métriques minimales de fraîcheur.
4. Décrire les étiquettes PII dans les chemins clés (KYC, paiements).

60-90 jours

1. Aller à column-level pour les meilleures vitrines.
2. Intégrer les métadonnées runtime de l'orchestre (temps, volume, états).
3. Lier les règles DQ à la colonne, inclure les alertes.
4. Visualisation : filtres par domaine/propriétaires/PII, overlay de fraîcheur.

3-6 mois

1. Les contrats et le registre des circuits sur le bus d'événements (fids de jeu/paiement).
2. Piste complète de ligne ML (dannyye→fichi→model→inferens).
3. L'analyse d'impact dans CI → des tiquets automatiques aux propriétaires de dépendances.
4. Couverture column-level ≥70 % des vitrines actives ; rapports sur les OSL.

18) Patterns et anti-patterns

• Graph-first : graphique de métadonnées unique en tant que « boussole » de changement.
• Ligne contract-aware : lien avec les versions des schémas et les résultats de validation.
• Observability overlay : fraîcheur/volumes/DQ en haut du graphique.
• Product-thinking : les propriétaires de domaine publient des « produits de données » certifiés.

• « Image pour image » sans collecte et soutien automatiques.
• Main maps au lieu de parsing et runtime vérité.
• Aucun détail de colonne dans les chemins critiques de KPI.
• Linéaire sans lien avec les accès/PII et les processus DSAR/Legal Hold.

19) Chèques pratiques

Avant la publication de la modification des données

• Le contrat a été mis à jour, le contrôle de compatibilité a été passé
• Analyse d'impact des dépendances effectuée
• v2-vitrine collectée en parallèle, comparaison des métriques ok
• Plan de retour et de retour documenté

Examen hebdomadaire

• Les voies critiques sont vertes par la fraîcheur
• Pas de job/vitrine « orphelin »
• Incidents DQ fermés et documentés
• Couverture de niveau column> seuil cible

Total

La règle transforme les flux de données chaotiques en une carte gérée du terrain : vous pouvez voir d'où vient, qui répond, quels risques et comment changer en toute sécurité. Pour iGaming, c'est la base de la confiance dans les KPI, la vitesse des expériences et la conformité mature.