Alimenter : ETL, qualité, RGPD
Ce que ce chapitre apporte
- Distinguer les trois étapes d'une alimentation et justifier leur ordre.
- Opposer ETL et ELT, et dire ce qui a fait basculer l'usage.
- Extraire sans relire toute la source, et charger de façon rejouable.
- Alimenter un modèle dimensionnel dans le bon ordre, avec des clés de substitution.
- Qualifier un jeu de données selon des critères mesurables.
- Distinguer pseudonymisation et anonymisation, et mesurer un risque de réidentification.
Entre les sources et l'entrepôt se trouve la partie du travail que personne ne montre et qui occupe l'essentiel du temps. Elle consiste à extraire sans perturber, à transformer sans perdre, et à charger de façon qu'un rejeu ne casse rien. Elle consiste aussi à savoir ce que valent les données obtenues, et à traiter des informations personnelles sans se contenter de retirer les noms, ce qui ne suffit presque jamais.
Le chapitre précédent a construit un modèle cible. Il reste à le remplir, à partir de systèmes qui n'ont pas été conçus pour être lus par d'autres, qui changent sans prévenir, et dont les données contiennent des erreurs que personne n'a jamais eu besoin de corriger jusqu'ici.
Extraire, transformer, charger
Extraire : récupérer les données des systèmes sources, sans les perturber et sans en oublier.
Transformer : nettoyer, typer, normaliser les libellés, croiser les sources, appliquer les règles de gestion, calculer les clés.
Charger : écrire le résultat dans la cible, entrepôt, Data Mart ou base NoSQL.
À l'extraction, ne rien transformer. La tentation est forte de filtrer ou de convertir au passage, puisque c'est gratuit. C'est une erreur : une transformation faite ici n'est pas rejouable sans redemander la source, et l'erreur qu'elle introduit devient invisible et irrattrapable.
À la transformation, tout rendre explicite. Chaque règle de gestion appliquée doit être une opération nommée, testable et documentée. Une règle enfouie dans une requête de chargement finit par n'être connue de personne.
Au chargement, ne rien décider. Le chargement écrit ce qu'on lui donne. Toute logique métier qui s'y trouve est invisible depuis l'entrepôt et depuis les sources à la fois.
L'ELT charge les données brutes dans la cible, puis les transforme sur place, avec la puissance de la cible.
Le basculement d'usage a une cause précise : le stockage est devenu bon marché et les moteurs analytiques sont devenus capables de transformer des volumes considérables plus vite qu'un serveur d'intégration dédié. Garder le brut ne coûte donc presque rien, et transformer sur place coûte moins.
L'avantage décisif n'est pas la performance mais la rejouabilité. Une règle de gestion erronée découverte six mois plus tard se corrige en relançant la transformation sur le brut conservé. En ETL classique, le brut n'existe plus, et il faut redemander aux sources ce qu'elles ne savent souvent plus fournir.
Extraire sans tout relire
Relire intégralement une source à chaque alimentation devient impossible dès que le volume grandit, et pèse sur un système de production qui a autre chose à faire.
Extraction complète. Tout est relu à chaque fois. Simple, fiable, et acceptable jusqu'à quelques millions de lignes.
Extraction incrémentale. Seules les lignes dont la date de modification dépasse la dernière extraction sont relues. Efficace, et fragile : elle rate toute ligne supprimée, et toute ligne modifiée sans que la date le soit.
Capture des changements. Le journal des transactions de la source est lu, ce qui donne chaque insertion, modification et suppression dans l'ordre, sans requête sur les tables. C'est la seule stratégie qui voie les suppressions, et la seule qui ne pèse pas sur la source.
Une ligne supprimée dans la source n'a plus de date de modification à comparer : elle n'existe plus. Elle reste donc indéfiniment dans l'entrepôt, et les totaux dérivent lentement, sans que rien ne le signale.
Le symptôme apparaît des mois plus tard, sous la forme d'un écart de quelques pour cent entre le chiffre de l'entrepôt et celui du système source, que personne n'arrive à expliquer.
Trois parades : lire le journal des transactions plutôt que les tables, obtenir de la source qu'elle marque les lignes supprimées au lieu de les effacer, ou faire une extraction complète périodique pour recaler.
Charger de façon rejouable
Une alimentation échoue. Le réseau coupe, la source répond mal, une machine redémarre. La question n'est pas d'éviter ces incidents mais de pouvoir relancer sans rien casser.
Un traitement est idempotent si l'exécuter deux fois donne le même résultat que l'exécuter une fois.
Un chargement qui ajoute des lignes ne l'est pas : deux exécutions doublent les données. Un chargement qui remplace une partition entière l'est : la seconde exécution écrase le résultat de la première.
Une alimentation interrompue au milieu laisse la cible dans un état inconnu : une partie des lignes est chargée, l'autre non, et personne ne sait laquelle.
Relancer un chargement par ajout double alors ce qui avait déjà été écrit. Ne pas relancer laisse un trou. Les deux issues sont mauvaises, et le choix se fait dans l'urgence, sur des données de production.
La règle qui évite tout cela : charger par remplacement d'une unité entière, en général une journée ou une partition, plutôt que par ajout de lignes. Relancer devient alors sans risque, et l'incident redevient un simple contretemps.
Alimenter un modèle dimensionnel
L'ordre n'est pas indifférent, et il découle des clés étrangères.
Charger ou mettre à jour les dimensions. Chaque ligne source est rapprochée de la dimension par sa clé naturelle. Si elle est nouvelle, une ligne est créée avec une clé de substitution. Si elle a changé, on écrase ou on historise selon la décision prise au chapitre précédent.
Charger les faits. Chaque fait remplace ses clés naturelles par les clés de substitution des dimensions, obtenues par une recherche. Ce remplacement s'appelle la résolution des clés, et c'est l'opération la plus coûteuse de l'alimentation.
Charger les faits avant les dimensions produit des faits qui pointent vers des lignes inexistantes.
Un fait arrive avec un code produit qui n'existe dans aucune dimension. Le rejeter perd le chiffre d'affaires ; le charger avec une clé vide casse la jointure et le fait disparaît des totaux.
La pratique établie consiste à créer dans chaque dimension une ligne « inconnu », portant une clé de substitution réservée, vers laquelle pointent tous les faits orphelins.
Le total reste juste, l'anomalie devient visible et chiffrable au lieu d'être silencieuse, et l'on peut suivre son évolution : une dimension « inconnu » qui grossit signale une source qui dérive.
Qualifier un jeu de données
Avant d'exploiter des données, il faut savoir ce qu'elles valent. Cela se mesure, et un petit nombre de critères suffit.
Complétude. Quelle part des valeurs attendues est présente ? Se mesure par colonne, en pourcentage de valeurs renseignées.
Unicité. Combien de doublons sur la clé métier ? Se mesure en comparant le nombre de lignes au nombre de clés distinctes.
Validité. Quelle part des valeurs respecte le format, le domaine, l'intervalle attendus ? Une date de naissance en 1899 ou un code postal à quatre chiffres sont invalides.
Cohérence. Les données se contredisent-elles entre elles ou entre sources ? Une date de fin antérieure à une date de début, un total qui ne vaut pas la somme de ses lignes.
Fraîcheur. Quel âge a la donnée la plus récente ? Un entrepôt dont l'alimentation a échoué depuis trois jours répond toujours, et répond faux.
Exactitude. La valeur correspond-elle à la réalité ? C'est le seul critère qui ne se mesure pas depuis les données elles-mêmes, et il exige un référentiel externe ou un sondage.
Mesurer la complétude d'une colonne et l'afficher sur un tableau de bord ne change rien tant que personne n'agit.
Une mesure de qualité doit porter un seuil et une conséquence : en dessous de tel taux, l'alimentation s'arrête et alerte, plutôt que de charger des données dont on sait qu'elles sont fausses.
Charger malgré tout, en espérant que quelqu'un remarquera, revient à propager l'erreur dans tous les tableaux de bord qui en dérivent, où elle sera bien plus difficile à retrouver.
Les données personnelles
Une donnée à caractère personnel est toute information se rapportant à une personne physique identifiée ou identifiable, directement ou indirectement.
Le mot décisif est identifiable. Un jeu sans nom ni identifiant reste composé de données personnelles si le recoupement de ses colonnes permet de retrouver quelqu'un.
Cinq principes commandent le traitement, et deux d'entre eux ont des conséquences techniques immédiates.
Finalité. Les données sont collectées pour un objectif déterminé et explicite, et ne peuvent pas être réutilisées pour un autre sans examen.
Minimisation. Seules les données nécessaires à cette finalité sont collectées. Cela contredit frontalement le réflexe du domaine, qui est de tout garder au cas où.
Exactitude. Les données inexactes doivent être rectifiées ou effacées.
Limitation de conservation. Une durée de conservation est fixée par finalité, et l'effacement à l'échéance doit être effectif, y compris dans les sauvegardes et les copies dérivées.
Intégrité et confidentialité. Chiffrement, contrôle d'accès, traçabilité des consultations.
Un jeu dont on a supprimé les noms et remplacé les identifiants par des codes est pseudonymisé, et reste soumis à la réglementation dans son intégralité.
Il devient anonyme seulement si plus personne ne peut y être réidentifié, par aucun moyen raisonnable, y compris par recoupement avec d'autres jeux. Cette condition est bien plus difficile à atteindre qu'il n'y paraît, et le bloc suivant montre pourquoi.
La distinction n'est pas rhétorique : un jeu anonyme sort du champ de la réglementation, un jeu pseudonymisé n'en sort pas.
Mesurer le risque de réidentification
Un quasi-identifiant est un attribut qui n'identifie personne à lui seul, mais qui, croisé avec d'autres, réduit la population à une seule personne.
Le code postal, la date de naissance et le sexe en sont l'exemple classique : chacun désigne des milliers de gens, leur combinaison en désigne souvent un seul.
Le bloc montre l'effet de chaque élargissement : remplacer le mois par rien, le code postal par le département, l'année par une tranche. À chaque étape, le nombre de personnes seules de leur combinaison s'effondre.
C'est la mécanique du k-anonymat : exiger que chaque combinaison de quasi-identifiants soit partagée par au moins k personnes. Un jeu où k vaut 1 n'est pas anonyme, quel qu'ait été le soin apporté à retirer les noms.
Et c'est aussi la limite de l'exercice. Chaque généralisation supprime de l'information réelle : une analyse par tranche de dix ans ne répond plus aux questions qui portaient sur l'année. L'anonymisation n'est pas gratuite, elle s'achète en précision.
Supposons dix personnes partageant la même combinaison de quasi-identifiants, donc k valant 10. Si toutes les dix portent le même diagnostic, connaître la combinaison de quelqu'un suffit à connaître son diagnostic, sans jamais l'avoir identifié individuellement.
Des critères complémentaires existent pour cela, exigeant une diversité minimale des valeurs sensibles à l'intérieur de chaque groupe.
La leçon générale, elle, est indépendante des critères : l'anonymat se mesure, il ne se décrète pas, et la mesure doit être refaite chaque fois qu'une colonne est ajoutée au jeu.
Exercices type
Exercice 1 : une alimentation quotidienne charge les ventes par ajout de lignes. Elle échoue à mi-parcours un mardi. Que se passe-t-il, et comment éviter la situation ?
Afficher la solution
La cible contient une partie des ventes du mardi, sans que rien n'indique laquelle. Relancer double ce qui est déjà chargé ; ne pas relancer laisse un trou. Les deux options faussent les totaux, et le choix se fait dans l'urgence.
La correction est structurelle : charger par remplacement de la partition du jour plutôt que par ajout. Le traitement devient idempotent, une relance écrase le partiel, et l'incident redevient un contretemps.
C'est l'une des rares décisions de conception qui ne coûte rien à la mise en place et évite une classe entière d'incidents.
Exercice 2 : l'entrepôt affiche 3 % de chiffre d'affaires de plus que le système source, et l'écart grandit chaque mois. Quelle cause chercher en premier ?
Afficher la solution
Les suppressions non répercutées, presque certainement.
Une extraction incrémentale fondée sur une date de modification ne voit pas les lignes supprimées, puisqu'elles n'existent plus pour être comparées. Les commandes annulées restent donc dans l'entrepôt indéfiniment, et l'écart s'accumule.
Le profil de l'écart le confirme : un écart constant viendrait d'une règle de gestion différente, un écart qui grandit vient d'un flux qui ajoute sans jamais retirer.
Les remèdes sont ceux du chapitre : lire le journal des transactions, obtenir un marquage logique des suppressions, ou recaler par une extraction complète périodique.
Exercice 3 : un jeu de consultations médicales est publié sans nom, avec le code postal, la date de naissance et le sexe. Peut-on le considérer comme anonyme ?
Afficher la solution
Non. Ces trois attributs forment le quasi-identifiant classique, et leur combinaison désigne fréquemment une seule personne dans une commune.
Le jeu est pseudonymisé, pas anonyme : il reste intégralement soumis à la réglementation, et sa publication constitue une divulgation de données de santé.
Pour l'anonymiser, il faut généraliser jusqu'à ce que chaque combinaison soit partagée par un nombre suffisant de personnes : le département plutôt que la commune, l'année ou une tranche plutôt que la date exacte. Puis vérifier la diversité des diagnostics à l'intérieur de chaque groupe, sans quoi l'appartenance au groupe suffit à révéler l'information sensible.
Et refaire cette mesure à chaque colonne ajoutée.
Exercice 4 : un flux charge chaque nuit des faits dont 2 % portent un code produit absent de la dimension. Que faire ?
Afficher la solution
Ni les rejeter, ni les charger avec une clé vide.
Les rejeter perd 2 % du chiffre d'affaires, silencieusement, et les totaux de l'entrepôt cessent de correspondre à la réalité.
Les charger sans clé casse la jointure vers la dimension, et ils disparaissent de toute analyse qui passe par le produit, donc de presque toutes.
La pratique consiste à les rattacher à un membre « inconnu » de la dimension : le total reste juste, l'anomalie devient chiffrable, et son évolution se surveille. Deux pour cent stables signalent un référentiel incomplet ; deux pour cent qui grimpent signalent une source qui a changé sans prévenir.
Il faut ensuite traiter la cause, qui est presque toujours un référentiel produit alimenté moins souvent que les ventes.
1.Pourquoi ne rien transformer à l'étape d'extraction ?
2.Quel est l'avantage décisif de l'ELT sur l'ETL ?
3.Que ne voit jamais une extraction incrémentale par date de modification ?
4.Qu'est-ce qu'un chargement idempotent ?
5.Un jeu dont les noms ont été retirés et les identifiants remplacés par des codes est…
6.Dix personnes partagent la même combinaison de quasi-identifiants, et toutes portent le même diagnostic. Le jeu est-il protégé ?
La méthode
- Ne rien transformer à l'extraction, et conserver le brut.
- Choisir la stratégie d'extraction en se demandant d'abord comment les suppressions seront vues.
- Rendre chaque chargement idempotent, par remplacement d'unité plutôt que par ajout.
- Charger les dimensions avant les faits, et résoudre les clés naturelles en clés de substitution.
- Prévoir un membre « inconnu » dans chaque dimension, et surveiller sa croissance.
- Mesurer les six critères de qualité, et attacher à chacun un seuil et une conséquence.
- Arrêter l'alimentation sous le seuil, plutôt que de propager une erreur dans tous les tableaux de bord.
- Lister les quasi-identifiants d'un jeu avant de le diffuser, et mesurer combien de personnes y sont seules.
- Généraliser jusqu'à un k suffisant, en acceptant la perte de précision, et vérifier la diversité des valeurs sensibles.
- Refaire la mesure à chaque colonne ajoutée.
Synthèse
- Extraire sans transformer, transformer en rendant tout explicite, charger sans rien décider.
- L'ELT l'emporte pour sa rejouabilité, non pour sa vitesse : le brut conservé permet de corriger après coup.
- Une extraction incrémentale ne voit jamais une suppression, et l'écart grandit sans rien signaler.
- Un chargement idempotent transforme un incident en contretemps ; un chargement par ajout le transforme en corruption.
- Les dimensions se chargent avant les faits, à cause des clés étrangères.
- Un membre inconnu garde les totaux justes et rend l'anomalie chiffrable.
- Six critères mesurables : complétude, unicité, validité, cohérence, fraîcheur, exactitude.
- Un indicateur de qualité sans seuil ni conséquence ne sert à rien.
- Une donnée est personnelle dès que la personne est identifiable, même indirectement.
- Minimisation et limitation de conservation contredisent le réflexe de tout garder au cas où.
- Retirer les noms pseudonymise, cela n'anonymise pas.
- Trois quasi-identifiants anodins suffisent souvent à désigner une seule personne.
- La généralisation restaure l'anonymat et détruit de l'information : elle s'achète en précision.
- Le k-anonymat ne suffit pas si un groupe est homogène sur la valeur sensible.