Origine des données

Origine des données (Lineage)

1) Qu'est-ce que lineage et pourquoi il est nécessaire

Data Lineage est un enregistrement formel « d'où viennent les données, comment elles se sont transformées, où et par qui elles ont été utilisées ». Le résultat est un graphique de dépendance orienté avec des attributs (temps, versions, propriétaires, transformations, politiques d'accès, qualité) qui rend le système de données compréhensible et auditable.

• Transparence des métriques (finance, produit, risque) : "pourquoi le nombre X = 1 234 ? ».
• Analyse rapide des changements d'impact (schéma/job) : « ce qui va casser si »....
• Conformité et audit (GDPR/ISO/SOC) : chemin de champ prouvé.
• Accélérez l'onbording et réduisez le toil (savoir-faire libre-service).
• Amélioration de la qualité : contrôles ciblés lorsque le risque est plus élevé.

2) Zones de couverture et niveaux de détail

Niveau streaming (pipeline/job) : quels jobs/orchestrateurs ont donné naissance aux datacets.
Niveau datacet (table/view/topic/file) : entrées → sorties, versions/snapshots.
Niveau de colonne (column/feature-level) : comment chaque champ est calculé, à partir de quelles sources.
Couche consommation : rapports BI, API, modèles ML, dashboards et alertes.

Pour les entités critiques (argent, réglementation) - column-level est obligatoire.

3) Modèle de données lineage : entités clés

Dataset: `{urn, type, schema, owners, pii_class, retention, tags}`

Job/Task: `{urn, code_ref, version, runtime, schedule, owners}`

Run/Execution: `{run_id, job_urn, start/end, status, inputs[], outputs[], code_sha, infra}`

Field : '{dataset _ urn, name, type, derivation}' (dérivation - expression/AST/opérateur).

Policy: `{dataset_urn/field, access_rules, masking, consent_scope}`

Quality Check: `{check_id, scope, rule, severity, result}`

4) Sources de lignage : vs actif assemblage passif

Actif (event-based) : Nous instrumentons des orchestrateurs/moteurs (Spark/DBT/SQL engines/Kafka) pour l'émission d'événements « job started/finished, inputs/outputs, column-mapping ».

Avantages : précision, pertinence, minimisation du post-parsing.
Passive (inference) : parsim DAG 'et, SQL/DDL/logs-requêtes, logs d'annuaire/stockages ; nous construisons les dépendances rétroactivement.

Avantages : couverture rapide du patrimoine ; inconvénients : moins de précision sur le niveau column.

L'hybride est généralement utilisé : les événements actifs sont là où vous pouvez et l'analyse passive est une « grille d'assurance ».

5) Architecture de solution (référence)

Producteurs (orchestrateurs/moteurs) → Bus d'événements lineage → Normalisateur → Référentiel graphique → Index/recherche → UI/API/alerties → Exportation/catalogue.

Événements : unifiés (job/run/dataset/column-lineage), avec des identifiants URN et des versions sémantiques.
Stockage de graphe : graphe column-level (par exemple, basé sur une OBD graphique ou un indice relationnel + inverted).
UI : visualisation interactive des chemins les plus courts, impact/racine-cause, « signaux de qualité » sur les côtes et les nœuds.
Intégrations : catalogue de données, système de qualité (DQ), contrôle d'accès (ABAC), audit (journaux append-only).

6) Identifiants et versioning

URN/Global ID pour chaque datacet/jobs/champs : stable, humain, incluant la plate-forme/neimspace/nom/version.
Versions de schémas (SchemaVersion) et versions de code (code SHA, image digest).
Time-travel lineage : reproductibilité des enquêtes.

7) Lien Column-level : comment obtenir fiable

Parsing SQL avec construction AST et normalisation alias/STE/wuh.
Annotations dans le code de transformation (tests DBT, comètes primitives, UDF-metadata).
Événements des moteurs : spécification des expressions "target. col = f(src. a, src. b)».
Règles sémantiques : Les UDF/ops d'agrégation sont marqués « lossy » (avec perte de granularité) ou « sensible-preserving » (transfère des étiquettes PII).

8) Lien avec la vie privée et la sécurité

Privacy by Design : étiquettes de champs 'pii _ class', 'consent _ scope', 'retentation'. Lors de la promotion des colonnes, les étiquettes sont transmises selon les règles (par exemple, 'email → hash_email' reste PII-derived).
Tokenization PII : lineage stocke le fait de tokenization/désintoxication et les noeuds du service token ; toute désintoxication est un événement avec un audit.
Cryptage : pour les champs de ligne AEAD/FPE, il enregistre un « état crypto » et une zone clé (tenant/scope) - sans révéler les clés.
Audit et WORM : les événements lineage et les modifications de règles sont stockés dans un journal inchangé (append-only avec des chaînes de hachage).

9) Qualité des données et SLO basé sur lineage

Chèques sur les côtes : fraîcheur (freshness), plénitude (completeness), unicité/clés, dérive des distributions.
SLO/SLI : « 95 % des jobs alimentant les métriques de finotchet sont terminés ≤ 06:00 UTC ».
Root-cause : Graphique + temps d'exécution donnent une définition rapide du « premier nœud cassé ».

10) Analyse d'impact et gestion du changement

Lors d'un changement planifié de schéma/logique : par colonne en aval (downstream) - liste des rapports/modèles/clients API concernés.
Politique « breaking changes » : notification obligatoire aux propriétaires d'artefacts downstream, période grace, versions parallèles ('v1 '/' v2') et drapeau « sunset-date ».
RP/tickets automatiques avec liste des consommateurs et chèque de migration.

11) Intégration avec orchestrateurs et moteurs

Orchestrateurs : avant/après job, les événements 'RunStarted/RunCompleted' avec inputs/outputs sont émis.
SQL/ELT : connecteurs vers les moteurs (warehouse, lakehouse) pour obtenir le plan d'exécution réel et mapper les colonnes.
Stream-processing : lineage des messages (topic→topic, key/headers), schémas Avro/Protobuf, évolution des schémas via registry.
ML : lignage fiches/datacets, versions du modèle, artefacts d'entraînement, sources de signes.

12) Modélisation des règles de promotion des étiquettes (contrats de données)

Contrat d'ensemble de données : schéma + sémantique des champs (clés, PII, agrégabilité, licences/bases légales, rétention).

• 'SELECT a, b FROM T '→ déplacer les étiquettes' a, b '.
• 'Hash (email) '→ l'étiquette' PII-derived (pseudonomized) 'avec interdiction de désintoxication.
• 'SUM (amount) '→ perte d'individualité ; join's sont interdits sur le champ de résultat.
• Les contrats sont validés dans le CI (blocker en cas de non-conformité) et les irrégularités dans les événements de l'audit.

13) Performance et échelle

Injection incrémentale d'événements de lignage ; déduplication par '(run_id, job_urn)'.
Stockage du graphique : séparation de l'index chaud (les 30 à 90 derniers jours) et de l'archive ; snapshots.
Mise en cache des chemins pour les requêtes fréquentes (chemins courts vers les métriques « or »).
Sharding par neumspace/locataires ; protection contre les « nœuds monstres » (limitation du fan-out).

14) Visualisation et UX

• Chemin vers metric : « à partir duquel la métrique est collectée ».
• Impact de la source : « qui sera affecté par le changement ».
• Ligne de champ : « comment le champ est calculé ».
• Overley : statuts de job, qualité, étiquettes PII, retences, propriétaires.
• Actions : Ouvrir un contrat, créer un ticket de migration, souscrire à des modifications alertes.

15) Sécurité de l'accès au graphique

ABAC : la visibilité des nœuds/côtes est limitée aux locataires/rôles.
Redaction : masque les noms des champs sensibles (ou leur pseudonyme) dans l'interface utilisateur pour les rôles non préparés.
mTLS/OIDC pour l'API ; les événements de lineage sont signés par des identités de service.
WORM et contrôle de lecture : la lecture des segments critiques du graphe est également journalisée.

16) Exploitation : SLO, surveillance, alertes

SLO du graphe : retarder l'apparition de l'événement <5 min ; l'exhaustivité de la couverture> 98 % des piplines critiques ; 100 % des « métriques d'or » ont column-level lineage.
Alerties : rupture de la chaîne, exécution sans événements d'achèvement, incohérence des schémas, datacets « orphelins », croissance fan-out/cycles.
Rapports : hebdomadaire « state of lineage coverage », top 10 des noeuds à risque.

17) Intimité et conformité (ligaments)

GDPR/PbD : Stocker les bases de traitement et de retence comme étiquettes ; lineage permet une recherche DSAR rapide des chemins et un « droit de suppression » via la suppression crypto-crypto-cascade des segments correspondants.
Gestion des secrets : les sources d'accès aux matières premières ne tombent jamais dans la lignée comme des crédits ouverts ; seule la référence de rôle/politique est stockée.
Audit/journaux immuables : tous les événements lineage sont signés et fixés dans le magasin append-only (voir l'article correspondant).

18) Chèques-feuilles

• Des accords URN ont été définis pour les datasets/jobs/fields.
• L'émission des événements lineage des orchestres et des moteurs est incluse.
• Le parser SQL/DDL et le normalisateur de schémas fonctionnent.
• Les contrats de données et les règles de promotion des IPI/rétentions ont été approuvés.
• Le journal d'événements WORM et les sauvegardes du graphe sont configurés.
• BI/ML sont connectés en tant que consommateurs lineage (rapports, modèles, fiches).

• Couverture lineage pour les domaines critiques ≥ 98 %, column-level pour « argent » = 100 %.
• Alerties sur les discontinuités, datacets « orphelins », dérive des schémas inclus.
• Audit trimestriel des étiquettes PII et des contrats.
• Trafic de documents de changement (breaking) et envoi aux consommateurs.

19) Mini recettes

json
{
"event": "RunCompleted",
"run": {
"id": "run_2025-10-31T14:20:00Z_42",
"job": "urn:job:etl:finance:close_books_v3",
"status": "SUCCESS",
"code_sha": "b3f9…",
"started_at": "2025-10-31T14:05:00Z",
"ended_at": "2025-10-31T14:19:52Z"
},
"inputs": [
"urn:dataset:lake:bank_txn_v2",
"urn:dataset:warehouse:fx_rates_d+1"
],
"outputs": [
"urn:dataset:warehouse:pnl_daily_v3"
],
"column_lineage": [
{
"output": "pnl_daily_v3. pnl_usd",
"expr": "SUM(txn. amount_local fx. rate)",
"inputs": ["bank_txn_v2. amount_local", "fx_rates_d+1. rate"],
"lossy": true
}
]
}

if input. field. pii in {email, phone, id} and transform in {hash, tokenize}:
output. field. pii = "pseudonymized"
elif transform in {aggregate, anonymize_k}:
output. field. pii = "anonymous"
else:
output. field. pii = input. field. pii

affected = downstream(urn:"urn:dataset:warehouse:users_v4", depth=4)
filter affected where kind in {"dashboard","model","api"} and owner not in {"team-exp"}

20) Erreurs fréquentes et comment les éviter

Lineage « par image » sans modèle formel. Vous avez besoin d'événements/schémas/URN, sinon le graphique n'est pas mis à l'échelle.
Il n'y a pas de column-level où est l'argent. Sans niveau de colonne, vous ne pouvez pas expliquer les calculs.
Événements incomplets (pas de schémas code_sha/versii). Impossible de se reproduire.
Ignorer la vie privée. Les étiquettes PII doivent vivre et être transportées avec les champs.
Une grande OBD graphique sans sharding. Divisez par niemspace, gardez les snapshots.
Une foi aveugle pour les parses. Dans les cas controversés - les événements actifs des moteurs.

21) Runbook’и

Incident : la métrique « a sauté ».

1. Ouvrir « Path to metric » → vérifier les derniers 'Run'nœuds en cours de route.
2. Vérifier les versions de code/schémas, l'état DQ des chèques sur les côtes.
3. Si vous trouvez un maillon cassé, créez un tiquet pour le propriétaire, activez la publication temporaire "hold'de la métrique.
4. Après la fixation, marquer RCA et lier aux nœuds du graphe.

Modifie le schéma source.

1. Demander un impact downstream.
2. Envoyer des notifications aux propriétaires, créer des RP de migration.
3. Soulevez le « v _ next » parallèle, gardez les deux versions jusqu'à la date sunset.
4. Fermer 'v _ prev', mettre à jour les contrats et lineage-graphe.

• «Privacy by Design (GDPR)»
• « Tokénisation des données PII »
• « Gestion des secrets »
• Audit et journaux invariables
• Cryptage At Rest/In Transit
• Gestion des clés et rotation