Knowledge · L'architecture, décodée · Fiche 08
Ce que fait vraiment un pipeline.
Dans cette fiche
Glossaire express
IObjectif
Savoir lire une chaîne de données sans être ingénieur.
Un pipeline n'est pas un tuyau. C'est une suite de décisions.
Le mot évoque un transport : les données partent d'un endroit et arrivent à un autre. Cette image cache l'essentiel, car chaque étape applique des règles qui changent ce que la sortie signifie.
Cette fiche donne une grille de lecture pour suivre un trajet de données et poser les quatre questions qui font apparaître les endroits où la confiance se gagne ou se perd.
IIPrincipe
La valeur ne vient pas du déplacement, mais des règles appliquées.
Entre la source et l'écran final, des choix ont été faits : ce qui est exclu, ce qui est corrigé, ce qui est agrégé, ce qui est considéré comme un doublon. Ces choix sont des décisions métier déguisées en traitements techniques.
Comprendre un pipeline consiste donc à retrouver ces décisions et à savoir qui les a prises. C'est ce qui permet de dire pourquoi deux chiffres divergent, et lequel répond réellement à la question posée.
Deux sorties différentes peuvent être exactes et ne pas répondre à la même question.
Ce qui produit la donnée, et à quel rythme.
Ce qui est récupéré, et ce qui est laissé.
Filtres, calculs, corrections, jointures.
Ce qui est conservé, et sous quelle forme.
Qui lit la sortie, et pour quelle décision.
IIIApproche
Suivre le trajet dans l'ordre, une étape à la fois.
La lecture se fait avec la personne qui exploite la chaîne. L'objectif n'est pas d'auditer le code, mais de rendre visibles les règles et leurs propriétaires.
Pars de la sortie, puis remonte.
Commencer par l'écran final oblige à formuler l'usage réel avant de discuter des traitements.
Identifie la source et sa fréquence.
Une source qui se met à jour une fois par jour interdit toute promesse de temps réel en aval.
Fais expliciter les règles de transformation.
Exclusions, déduplication, corrections manuelles. Ce sont elles qui expliquent les écarts entre deux chiffres.
Demande qui voit les erreurs.
Un traitement qui échoue en silence produit une sortie plausible et fausse, ce qui est pire qu'une absence de sortie.
Vérifie la reprise après incident.
Rejouer un traitement sans double comptage ne s'improvise pas le jour de la panne.
SOURCE : FRÉQUENCE : TRANSFORMATIONS : ERREURS VISIBLES PAR : UTILISATEUR DE LA SORTIE :
IVWatch-outs
Reconnaître une chaîne tenue d'une chaîne subie.
Ces signaux se constatent sans accès au code, en écoutant la façon dont l'équipe parle de sa chaîne.
Bon signal
- Les règles de transformation sont écrites et citées avec la sortie.
- Les échecs sont visibles par une personne nommée.
- La fraîcheur annoncée correspond à la fréquence de la source.
Alerte
- Les écarts entre chiffres s'expliquent au cas par cas, oralement.
- Les corrections manuelles ne laissent aucune trace.
- Une panne se découvre parce qu'un utilisateur trouve le chiffre étrange.
VInsight
Un pipeline ne transporte pas des données. Il applique des décisions.
C'est pourquoi la bonne question n'est pas « où est stockée la donnée ? », mais « qui a décidé de cette règle, et où est-elle écrite ? ».
VIProof of Work
Fais raconter une chaîne existante en quatre lignes.
L'exercice prend une quinzaine de minutes avec l'équipe qui exploite la chaîne, et se relit ensuite sans elle.
Si une ligne reste vide, elle indique exactement où regarder ensuite.
- Source
- Le système d'origine et sa fréquence de mise à jour.
- Transformations
- Les deux ou trois règles qui changent le sens de la donnée.
- Erreurs
- Qui les voit, par quel canal, en combien de temps.
- Usage
- La décision que la sortie doit éclairer.