Entrepôt, Data Mart, Data Lake
Ce que ce chapitre apporte
- Opposer une charge transactionnelle et une charge analytique, et dire pourquoi elles ne cohabitent pas.
- Distinguer un fait d'une dimension, et construire un schéma en étoile.
- Choisir une granularité, et énoncer ce qu'elle interdit définitivement.
- Traiter le changement d'une dimension au cours du temps.
- Distinguer entrepôt, Data Mart et Data Lake, et organiser ce dernier en zones.
Une base transactionnelle est optimisée pour écrire beaucoup de petites choses très vite et sans jamais se tromper. Une analyse veut l'inverse : lire énormément, en une fois, sans rien écrire. Les deux charges s'excluent sur une même base, et la faire tenir les deux rôles à la fois est la cause la plus commune des lenteurs inexpliquées d'un système d'information.
Le modèle normalisé du parcours sur les bases de données a une qualité et un défaut, tous deux issus de la même propriété. Il élimine les redondances, donc chaque fait n'est écrit qu'une fois, donc une modification ne touche qu'un endroit : c'est exactement ce qu'il faut pour écrire. Mais alors chaque question un peu large exige de recoller une dizaine de tables, sur des millions de lignes, ce qui est exactement ce qu'il ne faut pas pour lire.
Ce chapitre construit le modèle inverse, celui des questions, et situe les deux organisations de stockage qui l'entourent.
Deux charges qui s'excluent
Une charge transactionnelle, dite OLTP, est faite de très nombreuses opérations courtes touchant peu de lignes chacune, en lecture comme en écriture, avec des exigences fortes de cohérence immédiate.
Une charge analytique, dite OLAP, est faite d'un petit nombre de requêtes qui balaient des millions de lignes, en lecture seule, et tolèrent des données vieilles de quelques heures.
| Transactionnel | Analytique | |
|---|---|---|
| Requêtes | des milliers par seconde | quelques dizaines par heure |
| Lignes touchées | une poignée | des millions |
| Colonnes lues | toutes celles de la ligne | trois ou quatre sur cinquante |
| Écritures | permanentes | par lots, ou aucune |
| Fraîcheur exigée | immédiate | la journée, souvent |
| Modèle adapté | normalisé | dimensionnel |
| Stockage adapté | par lignes | par colonnes |
Une requête analytique balaie des millions de lignes, occupe la mémoire cache du moteur, sature les disques et pose des verrous de lecture. Pendant ce temps, les opérations transactionnelles attendent.
Le symptôme est toujours le même : l'application ralentit à heures fixes, celles où quelqu'un actualise un tableau de bord. Le remède n'est pas d'optimiser la requête, mais de la déplacer sur une copie prévue pour cela.
C'est la première raison d'être d'un entrepôt : séparer physiquement les deux charges, avant même toute considération de modélisation.
Faits et dimensions
Un fait est un événement mesurable et daté : une vente, un passage, une mesure de capteur, une consultation. La table de faits est longue et étroite, et ne fait que grandir.
Une mesure est une valeur numérique portée par le fait, et qu'il a un sens d'additionner : un montant, une quantité, une durée.
Une dimension est un axe selon lequel on veut regarder les faits : le temps, le produit, le client, le lieu. La table de dimension est courte et large, et change peu.
« Le chiffre d'affaires par mois par magasin par famille de produits » nomme la mesure puis trois dimensions. La phrase du métier donne le modèle presque littéralement, et c'est ce qui rend la modélisation dimensionnelle accessible sans formalisme.
L'exercice utile consiste à écrire les dix questions que le métier posera, à souligner les mesures et à entourer les mots qui suivent « par ». Les tables se déduisent ensuite.
Le schéma en étoile
Un schéma en étoile place la table de faits au centre, entourée des tables de dimensions, chacune reliée par une clé étrangère unique. Aucune dimension n'en référence une autre.
clé primaire clé étrangère, avec la table visée
Trois traits distinguent ce schéma d'un modèle normalisé, et chacun est délibéré.
Les dimensions sont dénormalisées. famille et rayon restent dans Dim_Produit au lieu de vivre dans des tables séparées. La redondance est assumée : une dimension compte quelques milliers de lignes, la place ne coûte rien, et chaque table évitée est une jointure évitée.
La profondeur est de un. Toute question se répond avec la table de faits et les dimensions dont elle a besoin, jamais davantage. Le moteur n'a pas de choix difficile à faire, et les temps de réponse deviennent prévisibles.
Le temps est une table. Cela surprend, puisque toute base sait manipuler une date. Mais trimestre, jour férié, semaine ISO ou période de soldes ne se calculent pas, ou mal, et sont exactement ce sur quoi le métier veut regrouper.
Un schéma en flocon normalise les dimensions : Dim_Produit référence une table Famille, qui référence une table Rayon.
Le gain en place est négligeable, puisque les dimensions sont petites. Le coût est réel : une jointure de plus par niveau, et des requêtes que le métier ne sait plus écrire.
Le flocon se justifie dans deux cas seulement. Quand une hiérarchie est réellement partagée entre plusieurs dimensions, et quand un niveau porte beaucoup d'attributs propres qui n'ont rien à faire dans la dimension principale. Partout ailleurs, l'étoile gagne.
La granularité, décision irréversible
La granularité d'une table de faits est ce que représente exactement une de ses lignes : un article vendu, un ticket de caisse, un total quotidien par magasin.
Elle se déclare en une phrase, avant toute autre décision : « une ligne de cette table est... ». Si cette phrase ne se formule pas simplement, le modèle est faux.
Descendre d'un grain fin vers un grain grossier se fait par une somme. Remonter est impossible : rien dans un total quotidien ne permet de reconstituer les tickets.
Or les questions les plus intéressantes arrivent après, et personne ne les avait prévues. « Quels produits s'achètent ensemble » exige le grain de l'article ; conservé au grain du magasin, l'entrepôt ne répondra jamais, et il faudra attendre un an de nouvelles données pour commencer à répondre.
La règle est donc constante : conserver le grain le plus fin que le volume autorise, et construire les agrégats à côté, jamais à la place. Les agrégats se recalculent, le détail perdu ne revient pas.
Quand une dimension change
Un client déménage, un produit change de famille, un magasin change de région. Que devient le passé ?
Écraser. La dimension est mise à jour, l'ancienne valeur disparaît. Tout l'historique est alors relu avec la valeur actuelle : les ventes d'il y a trois ans apparaissent dans la nouvelle région du magasin. C'est ce qu'on veut pour corriger une faute de frappe, et jamais pour un vrai changement.
Historiser. Une nouvelle ligne de dimension est créée, avec une période de validité, et les faits antérieurs continuent de pointer vers l'ancienne. L'historique reste conforme à ce qui s'est réellement passé. C'est le traitement par défaut de toute dimension dont le passé compte.
La question à poser au métier est simple, et elle n'est pas technique : « quand ce client déménage, ses achats de l'an dernier appartiennent-ils à l'ancienne ville ou à la nouvelle ? » Les deux réponses sont défendables selon l'usage, et il faut choisir sciemment plutôt que de laisser l'outil décider.
clé primaire clé étrangère, avec la table visée
La clé primaire idClient est une clé de substitution, propre à l'entrepôt, distincte du codeClient du système source. C'est elle qui permet à deux versions d'un même client de coexister, chacune avec sa période de validité, et aux faits de désigner la bonne.
Data Mart et entrepôt
Un Data Mart est un entrepôt restreint à un domaine métier : les ventes, la logistique, la qualité. Il contient les faits et les dimensions de ce domaine, et rien d'autre.
Deux façons de les articuler existent, et opposent deux écoles.
Construire d'abord l'entrepôt d'entreprise, normalisé et exhaustif, puis en dériver des Data Marts par domaine. La cohérence est garantie par construction ; la première livraison est lointaine.
Construire d'abord les Data Marts, domaine par domaine, en imposant des dimensions conformes, c'est-à-dire partagées et identiques d'un mart à l'autre. La valeur arrive vite ; la cohérence repose sur une discipline.
Deux Data Marts construits séparément définissent chacun leur dimension « client », leur dimension « produit », et souvent leur notion de « mois ».
Les totaux ne se recoupent alors plus, personne ne sait lequel est juste, et la confiance dans l'entrepôt s'effondre. Une réunion entière peut se passer à comparer deux chiffres qui répondent en réalité à deux questions différentes.
Une dimension conforme, partagée par tous les marts, est ce qui rend les chiffres comparables. C'est une décision d'organisation autant que de technique, et c'est la partie difficile.
Le Data Lake
Un Data Lake conserve les données brutes, dans leur format d'origine, structurées ou non, sans schéma imposé à l'écriture. Le sens est donné à la lecture, par celui qui exploite.
L'entrepôt et le lac répondent à deux questions différentes. L'entrepôt répond vite et bien à des questions connues. Le lac garde de quoi répondre à des questions qui n'existent pas encore, y compris sur des données dont personne ne sait aujourd'hui quoi faire.
Déposer sans schéma ne veut pas dire déposer sans règle. Un lac où l'on écrit sans convention devient en deux ans un ensemble de fichiers dont personne ne sait ce qu'ils contiennent, d'où ils viennent, ni s'ils sont encore alimentés.
Trois disciplines l'évitent, et aucune n'est facultative.
Des zones. Une zone brute où rien n'est modifié, une zone raffinée où les données sont nettoyées et typées, une zone exploitable où elles sont modélisées pour l'usage. On ne saute pas de zone, et on ne remonte jamais.
Un catalogue. Chaque jeu déposé porte sa source, son propriétaire, sa fréquence de rafraîchissement, son schéma et son niveau de confidentialité. Sans catalogue, le lac n'est pas interrogeable, seulement stockable.
Un partitionnement lisible. Les fichiers rangés par date et par source, dans une arborescence stable, permettent de ne lire que ce qui est utile. C'est le sujet du chapitre sur l'optimisation.
Les deux organisations tendent aujourd'hui à se rejoindre : des formats de tables posés sur du stockage objet apportent au lac les transactions, l'évolution de schéma et l'historique qui manquaient, ce qu'on désigne parfois sous le nom de lakehouse. Le vocabulaire changera ; la distinction entre schéma à l'écriture et schéma à la lecture, elle, restera.
Exercices type
Exercice 1 : un service veut analyser « le taux de retour par fournisseur et par mois ». Quels faits, quelles dimensions, quelle mesure ?
Afficher la solution
Le mot qui suit « par » donne les dimensions : fournisseur et temps.
La mesure est plus subtile. Un taux n'est pas additif : la moyenne de deux taux n'est pas le taux global, exactement comme au chapitre sur le découpage. Il ne faut donc pas stocker le taux, mais ses deux composantes, le nombre de retours et le nombre d'articles livrés, et calculer le rapport à la lecture.
Le fait est la livraison d'un article, avec un indicateur de retour, ou plus simplement deux tables de faits, livraisons et retours, partageant les mêmes dimensions conformes.
C'est la règle générale : stocker ce qui s'additionne, calculer le reste à la lecture.
Exercice 2 : une table de faits est au grain du total quotidien par magasin. Le métier demande le panier moyen. Que répondre ?
Afficher la solution
Que c'est impossible avec ce qui est stocké, et que cela le restera.
Le panier moyen est le chiffre d'affaires divisé par le nombre de tickets. Le nombre de tickets n'est pas dans la table, et rien ne permet de le reconstituer à partir d'un total.
Deux issues. Ajouter dès maintenant une mesure « nombre de tickets » à la table existante, ce qui répondra à partir d'aujourd'hui mais pas pour le passé. Ou reprendre l'alimentation à un grain plus fin, si les données sources sont encore disponibles, ce qui n'est pas garanti.
C'est l'illustration exacte du caractère irréversible de l'agrégation.
Exercice 3 : un magasin passe de la région Est à la région Nord en mars. Le chiffre d'affaires de janvier doit-il apparaître dans l'Est ou dans le Nord ?
Afficher la solution
Les deux réponses sont défendables, et la question est métier.
Pour un suivi de performance des équipes régionales, janvier appartient à l'Est : c'est cette équipe qui a réalisé la vente. Cela impose d'historiser la dimension, avec deux lignes de magasin et des périodes de validité.
Pour un pilotage de l'organisation actuelle, janvier doit apparaître dans le Nord, afin que les totaux correspondent au découpage d'aujourd'hui. Cela impose d'écraser.
L'erreur n'est pas de choisir l'un ou l'autre, mais de ne pas choisir et de découvrir le comportement obtenu en constatant un écart inexpliqué dans un tableau de bord.
Exercice 4 : une équipe propose de remplacer l'entrepôt par un Data Lake, « puisque tout y est ». Que manque-t-il ?
Afficher la solution
Trois choses, dont deux ne s'obtiennent pas par la technique.
Le modèle. Le lac contient les données brutes, pas les faits et dimensions. Chaque analyste devra reconstruire les jointures et les règles de gestion, différemment, et les chiffres ne se recouperont pas.
Les définitions partagées. « Client actif », « chiffre d'affaires net », « mois » sont des conventions qui doivent exister à un seul endroit. L'entrepôt est cet endroit.
Le temps de réponse. Un balayage de fichiers bruts ne répond pas en deux secondes à un tableau de bord interrogé par cent personnes.
Le lac et l'entrepôt ne s'opposent pas : le lac alimente l'entrepôt, et garde ce dont l'entrepôt n'a pas encore l'usage.
1.Pourquoi ne pas lancer les analyses sur la base de production ?
2.Comment reconnaître une dimension dans une demande métier ?
3.Pourquoi dénormalise-t-on les dimensions dans un schéma en étoile ?
4.Une table de faits est au grain du total quotidien. Peut-on en tirer le panier moyen ?
5.Un client déménage. Qu'implique le choix d'historiser sa dimension ?
6.Qu'est-ce qui empêche un Data Lake de devenir un marécage ?
La méthode
- Séparer physiquement la charge analytique de la charge transactionnelle, avant toute modélisation.
- Écrire les dix questions du métier, souligner les mesures, entourer ce qui suit « par ».
- Déclarer la granularité en une phrase avant de dessiner quoi que ce soit.
- Conserver le grain le plus fin que le volume autorise, et construire les agrégats à côté.
- Stocker ce qui s'additionne, et calculer les taux et les moyennes à la lecture.
- Préférer l'étoile au flocon, sauf hiérarchie réellement partagée.
- Faire une table du temps, avec les découpages dont le métier a besoin.
- Demander au métier ce que devient le passé quand une dimension change, et décider sciemment.
- Imposer des dimensions conformes entre les Data Marts, faute de quoi les chiffres ne se recoupent pas.
- Organiser le lac en zones, avec un catalogue, dès le premier dépôt.
Synthèse
- Une charge transactionnelle et une charge analytique s'excluent sur une même base.
- La première raison d'être d'un entrepôt est la séparation physique des deux charges.
- Un fait est un événement daté et mesurable ; une dimension est un axe d'observation.
- Les dimensions sont les mots qui suivent « par » dans la question du métier.
- Le schéma en étoile dénormalise les dimensions et garde une profondeur de jointure de un.
- Le temps est une table, parce que trimestre, jour férié et semaine ne se calculent pas.
- Le flocon ne se justifie que pour une hiérarchie réellement partagée.
- La granularité se déclare en une phrase, et se choisit la plus fine que le volume autorise.
- Agréger est irréversible : les agrégats se recalculent, le détail perdu ne revient pas.
- Un taux ne se stocke pas : on stocke ses composantes et on divise à la lecture.
- Une dimension qui change s'écrase ou s'historise, et la question est métier.
- Une clé de substitution permet à deux versions d'une même entité de coexister.
- Sans dimensions conformes, deux Data Marts produisent des chiffres qui ne se recoupent pas.
- Un Data Lake garde de quoi répondre aux questions qui n'existent pas encore.
- Un lac sans zones ni catalogue devient un marécage en deux ans.