Définition et cycle de vie de l’ingénierie de la donnée
Ce chapitre présente le parcours d’une donnée, depuis sa production par une application jusqu’à son utilisation dans un tableau de bord ou un modèle. Un événement d’écoute inspiré de Spotify servira de fil conducteur.
Qu’est-ce que l’ingénierie des données ?
Définition
L’ingénierie des données est le développement, la mise en œuvre et la maintenance de systèmes et de processus qui prennent des données brutes et produisent des informations de haute qualité et cohérentes, destinées aux usages en aval tels que l’analyse et l’apprentissage automatique. Elle se situe à l’intersection de la sécurité, de la gestion des données, du DataOps, de l’architecture des données, de l’orchestration et de l’ingénierie logicielle.
Cette définition attribue trois responsabilités à l’ingénieur de données : concevoir les systèmes, les exploiter dans la durée et produire des données utilisables. Il faut donc pouvoir expliquer l’origine d’une donnée, reprendre un traitement après une panne et fournir un résultat compris par ses utilisateurs.
Le cycle de vie de l’ingénierie des données
Le cycle comprend cinq étapes : génération, stockage, ingestion, transformation et mise à disposition. Le stockage n’intervient pas à un seul moment : il sert de socle aux étapes suivantes en conservant le brut, les résultats intermédiaires et les données prêtes à servir. La sécurité, la qualité, les métadonnées et l’orchestration s’appliquent à l’ensemble du parcours (Reis et Housley, 2022, chap. 2).
Reis et Housley placent le stockage en deuxième position pour souligner ce rôle de socle. Ce chapitre suit plutôt le trajet de notre événement : génération, ingestion, stockage, transformation, puis mise à disposition.
Pour rendre ce parcours concret, nous suivrons un événement play, depuis une application inspirée de Spotify jusqu’à une table utilisée par un service de recommandation. Le scénario simplifie volontairement l’architecture réelle.
Les technologies sont données à titre d’exemple. Le point important est la succession des responsabilités. Sources d’architecture : Spotify Engineering (2019) et Spotify Engineering (2024).
1. Génération
Les données naissent dans des applications, des bases transactionnelles, des capteurs ou des API. Pour les exploiter, il faut connaître leur format, leur fréquence et leurs règles de production. Une modification non annoncée du schéma peut casser les traitements en aval.
Deux profils sont fréquents. Une base applicative impose un schéma lors de l’écriture. Une application mobile ou web peut publier des événements semi-structurés dans une file. Notre exemple relève de ce second profil.
L’application produit l’événement suivant lorsqu’un utilisateur lance un morceau. event_id l’identifie, schema_version indique la version de son contrat et event_time date l’action sur le terminal.
{
"event_id": "evt_01J4C3F9",
"schema_version": 1,
"event_type": "play",
"user_id": "u_48291",
"track_id": "t_99821",
"event_time": "2024-01-15T09:23:17Z",
"ms_played": 42180,
"device": "mobile",
"play_context": "playlist",
"country": "FR"
}ms_played: 42180 signifie que le morceau a été écouté pendant 42,18 secondes. À ce stade, track_id reste un identifiant technique. Le nom du morceau et son artiste seront ajoutés pendant la transformation.
La source et la plateforme doivent partager un contrat de données. Il précise les champs obligatoires, leurs types, le sens des dates, l’identifiant unique et les règles d’évolution du schéma. Ici, schema_version permet au pipeline de reconnaître la version reçue. La collecte doit aussi se limiter aux données nécessaires, en particulier pour les informations personnelles.
Considérations importantes
- À quel rythme et dans quel volume la source produit-elle les données ?
- Quels champs, types et identifiants son contrat garantit-il ?
- Comment une évolution du schéma est-elle annoncée et versionnée ?
- Quelles données personnelles sont réellement nécessaires ?
2. Ingestion
L’ingestion transporte les données depuis les sources vers la plateforme. Ici, l’application publie le play dans Pub/Sub. Le pipeline doit accepter les retards, les doublons et les reprises après une panne.
Deux modes répondent à des besoins différents. Le batch traite un ensemble borné, par exemple les événements d’une heure. Le streaming traite les événements au fil de leur arrivée. Une même plateforme peut utiliser les deux.
| Batch | Streaming | |
|---|---|---|
| Fraîcheur indicative | quelques minutes à un jour | quelques millisecondes à quelques secondes |
| Déclenchement | planning (Airflow, CRON) | événement (Pub/Sub, Kafka) |
| Coût | calcul périodique | service continu |
| Difficulté principale | traiter tout le lot | gérer l’ordre et l’état |
Ces délais sont des ordres de grandeur, pas des garanties. La fraîcheur réelle dépend de la fréquence des lots, des fenêtres d’agrégation, du transport et du temps de calcul. Un traitement en streaming peut donc publier ses résultats avec plusieurs minutes de retard.
Pour une base applicative, l’ingestion peut prendre trois formes :
| Stratégie | Données transférées | Cas courant |
|---|---|---|
| Chargement complet | toute la source | petite table ou initialisation |
| Chargement incrémental | nouveautés depuis le dernier passage | alimentation régulière |
| CDC | insertions, modifications et suppressions du journal | réplication avec faible latence |
Le déclenchement dépend aussi de la source. En push, la source envoie les données dès qu’elles sont produites. En pull, la plateforme vient les chercher. Le poll répète ce pull à intervalles réguliers pour détecter les nouveautés. Notre événement play est envoyé en push vers Pub/Sub.
Une reprise ne doit pas créer une seconde ligne pour le même événement. Cette propriété s’appelle l’idempotence. Dans notre exemple, event_id sert de clé pour reconnaître un événement déjà traité.
Même événement, même retry. À gauche, chaque run insère. À droite, l'upsert sur
event_id remplace.
La clé doit représenter un événement unique. Le couple (user_id, track_id) ne suffit pas, car un utilisateur peut écouter plusieurs fois le même morceau.
Trois horloges permettent de suivre son parcours :
| Horloge | Signification | Valeur pour le play |
|---|---|---|
event_time |
action enregistrée par l’application | 09:23:17 |
ingestion_time |
réception par la plateforme | 09:23:52 |
processing_time |
prise en charge par le traitement | 09:24:03 |
L’écart entre ces heures mesure le retard introduit par le transport et le traitement.
Le pipeline doit aussi pouvoir reprendre après un échec et rejouer une période passée, ce que l’on appelle un backfill. Son suivi porte au minimum sur le débit reçu, le retard, les erreurs et les doublons. Les messages invalides sont isolés afin de ne pas bloquer le reste du flux.
Considérations importantes
- Quelle fraîcheur l’usage exige-t-il : batch, streaming ou mode hybride ?
- Le transfert doit-il être complet, incrémental ou fondé sur le CDC ?
- Comment reprendre et rejouer sans perdre ni dupliquer les données ?
- Quels indicateurs suivent le débit, le retard et les erreurs ?
3. Stockage
Une file de messages transporte les événements, mais ne remplace pas leur conservation durable. Après sa réception dans Pub/Sub, le play est écrit tel quel dans une zone brute sur Cloud Storage :
gs://spotify-events-raw/year=2024/month=01/day=15/hour=09/events_20240115T09.jsonl
Cette copie permet de rejouer les traitements sans demander à l’application de renvoyer les événements. Le stockage accueille aussi les données nettoyées et les tables finales. Il faut choisir leur format, leur partitionnement, leur durée de conservation et leurs droits d’accès.
Deux familles de stockage se complètent souvent :
| Data lake | Data warehouse | |
|---|---|---|
| Données | fichiers bruts ou préparés, formats variés | tables nettoyées et structurées |
| Schéma | appliqué à la lecture, schema-on-read | défini avant ou pendant l’écriture, schema-on-write |
| Usage courant | conservation, exploration, ML | SQL analytique, indicateurs, BI |
| Exemple GCP | Cloud Storage | BigQuery |
| Décision | Effet concret |
|---|---|
| Format | JSONL conserve facilement le brut ; Parquet réduit les lectures analytiques |
| Partitionnement | regroupe les données par date ou par source pour limiter les fichiers parcourus |
| Rétention | fixe la durée pendant laquelle un replay ou un audit reste possible |
| Localisation | répond aux contraintes de latence, de résidence et de souveraineté |
| Accès | limite la lecture et la modification aux identités autorisées |
Ces choix se font pour chaque niveau de données. Le brut peut être conservé longtemps sur stockage objet, alors qu’une table destinée au reporting privilégie des lectures rapides et un schéma stable.
Les architectures de type data lake, data warehouse et lakehouse sont détaillées dans ETL/ELT et architectures de stockage.
Considérations importantes
- Quelles données faut-il conserver et pendant combien de temps ?
- Quels formats et partitionnements facilitent les traitements prévus ?
- Quelle fréquence d’accès et quel coût faut-il anticiper ?
- Dans quelle région stocker les données et qui peut y accéder ?
4. Transformation
La transformation corrige, valide, enrichit et agrège les données. Dans notre exemple, elle supprime les doublons, associe track_id au catalogue musical et calcule des indicateurs par utilisateur, artiste et semaine.
L’architecture medallion organise ce travail en trois niveaux : Bronze pour le brut, Silver pour les données nettoyées et enrichies, Gold pour les données préparées pour un usage. Ces niveaux décrivent la préparation des données, pas des produits GCP particuliers.
Le format évolue avec l’usage : le Bronze conserve le message JSON, le Silver le transforme en ligne détaillée et le Gold agrège plusieurs lignes dans une table métier.
Bronze : conserver le message reçu
Le Bronze garde les champs de la source afin de permettre un replay ou un audit.
{
"event_id": "evt_01J4C3F9",
"schema_version": 1,
"event_type": "play",
"user_id": "u_48291",
"track_id": "t_99821",
"event_time": "2024-01-15T09:23:17Z",
"ms_played": 42180,
"device": "mobile",
"play_context": "playlist",
"country": "FR"
}Silver : nettoyer et enrichir
Le Silver conserve une ligne par événement, supprime les doublons et ajoute les informations du catalogue. La durée est convertie dans une unité plus simple à lire.
Table Silver : plays_enriched
event_id |
user_id |
event_time |
track_id |
track_name |
artist_name |
played_sec |
country |
|---|---|---|---|---|---|---|---|
evt_01J4C3F9 |
u_48291 |
2024-01-15 09:23:17 |
t_99821 |
Planet Caravan | Black Sabbath | 42,18 | FR |
Gold : agréger pour un usage
Le Gold change de grain. Plusieurs événements deviennent une ligne par utilisateur, artiste et semaine. event_id disparaît donc de cette table.
Table Gold : user_artist_weekly
user_id |
artist_name |
week |
stream_count |
|---|---|---|---|
u_48291 |
Black Sabbath | 2024-W03 |
14 |
La transformation applique des règles vérifiables :
| Contrôle | Erreur évitée |
|---|---|
event_id renseigné et unique |
écoute manquante ou comptée deux fois |
track_id présent dans le catalogue |
morceau impossible à enrichir |
ms_played compris entre 0 et la durée du morceau |
durée d’écoute incohérente |
| données publiées dans le délai attendu | indicateur périmé |
Une table Gold n’est fiable que si ces contrôles sont exécutés et suivis. Comme event_id n’y figure plus, le lignage doit permettre de retrouver les données et les transformations qui ont produit cette ligne.
Le choix du grain et du modèle de table est approfondi dans Modélisation de données.
Considérations importantes
- Quel usage métier et quel grain la table doivent-ils servir ?
- Quelles règles valident, corrigent ou enrichissent les données ?
- Les transformations sont-elles versionnées, testées et rejouables ?
- Le lignage permet-il de retrouver les sources et les calculs appliqués ?
5. Mise à disposition
Mettre à disposition consiste à publier une donnée que ses utilisateurs peuvent trouver, comprendre et utiliser. Une table techniquement correcte devient un produit de données lorsqu’elle possède un usage défini, un propriétaire et des engagements mesurables. Elle peut alimenter un tableau de bord, un modèle de machine learning ou une application métier.
| Propriété | Valeur |
|---|---|
| Produit | user_artist_weekly |
| Finalité | Alimenter les recommandations |
| Granularité | Une ligne par utilisateur, artiste et semaine |
| Propriétaire | Équipe du produit de recommandation |
| Fraîcheur | Chaque jour, avant 6 h UTC, au moins 99 % des événements datés de la veille (UTC) sont intégrés aux agrégats publiés |
| Qualité | Moins de 0,1 % d’artistes inconnus |
| Classification | Donnée pseudonyme, usage interne |
| Compatibilité | Préavis de 30 jours avant une rupture du schéma |
Pour mesurer cet engagement, on rapporte le nombre d’événements distincts de la veille intégrés aux agrégats au nombre attendu selon le comptage source, sur la même période définie par event_time. La table est actualisée chaque jour : les écoutes alimentent la semaine à laquelle elles appartiennent, et les arrivées tardives entraînent une mise à jour des agrégats concernés.
Ce contrat indique à quoi sert la table, qui en répond et à quel moment elle peut être utilisée. Le catalogue la rend trouvable, la documentation explique ses colonnes et les droits d’accès limitent ses consommateurs.
Considérations importantes
- Les utilisateurs peuvent-ils trouver et comprendre la donnée sans aide ?
- Un propriétaire répond-il de sa finalité et de sa qualité ?
- Les engagements de fraîcheur et de disponibilité sont-ils mesurables ?
- Les droits d’accès et les changements de schéma sont-ils maîtrisés ?
- Génération = production de la donnée par une application, une base, un capteur ou une API.
- Ingestion = transport de la donnée depuis sa source vers la plateforme, en batch ou en streaming.
- Stockage = conservation du brut, des résultats intermédiaires et des tables finales.
- Transformation = nettoyage, validation, enrichissement et agrégation des données.
- Mise à disposition = publication d’une donnée documentée, accessible et adaptée à un usage.
- Tout au long du cycle : sécurité, qualité, métadonnées, supervision et reprise après incident.