De l'Ingestion à la Valorisation : Découvrez la puissance de l'Architecture en Médaillon !
Montez vos Data sur le podium avec l'Architecture en Médaillon
Popularisée par Databricks, on retrouve désormais cette organisation sur de nombreux Lakehouse ! Dans cet article, je vous propose mon interprétation et une proposition d'organisation et de principes qui vont encore plus loin.
Qu’est-ce que l’architecture en médaillon ?
Quand on parle d'architecture en médaillon dans le monde de la data, on parle d'une organisation particulière de nos données. Cette architecture représente une série de couches indiquant la qualité des données stockées selon le métal associé.
Il y a donc 3 couches, comme les médailles olympiques :
Bronze = données brut
Argent (silver) = données validées
Or (gold) = données valorisées
Comme la qualité des métaux, plus on monte dans les couches plus la donnée est qualitative. La donnée a également été plus travaillée, donc plus transformée par rapport à la source brute.
Présentation des 3 couches (layers)
Dans cette section, je vais rentrer plus dans le détail de chaque couche de données en indiquant notamment son périmètre d'action, ses caractéristiques principales ainsi que ses limites.
Bronze = données brutes
Périmètre
L'ingestion de toutes les données brutes sources dans un format de stockage optimisé (exemple: Parquet, Delta, etc).
Caractéristiques principales
Sans perte de données (lignes, colonnes).
Sans altération de données (valeur).
Ajout de métadonnées indispensables :
Date et heure de réception des données,
Nom de la source (nom du fichier, arborescence, topic, endpoint, ...).
Ajout de métadonnées optionnelles :
Numéro de la ligne d'un fichier (parfois utile),
Flag de rejet de la ligne,
Ligne de données brutes (en cas de rejet).
Pas de modélisation spécifique : on garde la structure de la source.
Les données sont empilées (historique complet).
Avantages
Conservation historique complet dans un format de stockage efficace.
Possibilité de retraiter la donnée brute sans solliciter de nouveau la source.
Aucune règle de gestion métier dans cette couche.
Gestion archivage et rétention de la donnée brute (chaud, tiède, froid, suppression définitive).
Limites
L'émetteur de la donnée ne doit pas porter de règles fonctionnelles (pour garantir un périmètre complet dans le Bronze).
Nécessite de monitorer et optimiser la durée de vie de l'historique complet car le volume de stockage peut vite devenir conséquent (FinOps)
Pour le streaming, il faudra une alimentation en Y pour stocker durablement les données brutes sur un S3, et pour alimenter le Silver en temps-réel (idéalement dans un système de messages pour ensuite continuer en streaming vers le Gold)
Usages principaux
- Data Engineer pour le rattrapage des données
- Data Scientist pour des modèles temps-réels basés sur les données brutes
Silver = données validées
Périmètre
Garantir que seules les données valides (exploitables opérationnellement) soient misent à disposition de la couche Gold. Toutes les données validées sont typées, harmonisées, normées et certifiées comme qualitative.
Le traitement Bronze vers Silver c'est un peu le douanier qui contrôle les marchandises et autorise le changement de pays.
Caractéristiques principales
Typage des champs.
Définition des clés primaires, et gestion des doublons.
Harmonisation du nommage des champs (cohérence des noms sur le Datalake) :
Langue utilisée dans le nommage (généralement l'anglais),
Mode d'écriture (camelCase, snake_case, etc),
Termes cohérents avec l'entreprise (lexique interne).
Standardisation des données (format des dates, timezone, unités de mesure, transcodage, enrichissements légers par des référentiels).
Nettoyage des données au minimum (supprimer les données vraiment inutiles)
Avantages
Optimisation du stockage
Les données publiées en Silver ont forcément une qualité minimum.
Détection simplifiée des anomalies de changement de type ou de format de date.
Centralisation des règles de qualité de données et des rejets associés.
Possibilité de gérer une vision courante uniquement, une vision historisée ou les deux.
Possibilité de recalculer facilement les données depuis le Bronze.
Limites
Enrichissement/transformations limités des données
Modélisation similaire à la source ou en 3ième forme normale
Stockage de la donnée validée (assez proche de la donnée brute). Il est important de bien gérer le cycle de vie de la donnée selon les besoins (FinOps).
Usages principaux
Data Analyst pour comprendre les données de détails et pour préparer de nouvelles modélisations pour le *Gold*.
Data Scientist pour mettre en place des modèles de *Machine Learning* (ML).
Gold = données valorisées
Périmètre
Données valorisées donc fortement transformées (souvent agrégées) pour répondre à des cas d'usages. Elles sont donc prêtes à être consommées.
Caractéristiques principales
Modélisation en étoile (star) ou dans une seule table (One Big Table)
OBT répond souvent à des besoins OLAP à très faible temps de réponse,
La modélisation en étoile est la plus répandue de nos jours.
Des données Gold peuvent servir de base aux calculs d'autres données Gold pour avoir un raffinage des données en plusieurs temps.
Avantages
Organisation logique par typologie d'usage métier ou par projets.
Haute performance d'accès aux données
Les données en amont sont déjà propre et normées ce qui simplifie les jointures et les règles de gestion.
Limites
On s'autorise de la redondance de données (donc plus de stockage) pour prioriser les performances.
Usages principaux
Business Intelligence (BI) pour des reportings ou dashboards métier.
Digital pour des portails Web, des applications opérationnelles ou des API.
Organisation des couches
Dans cette section, je vous propose un exemple d'organisation de vos données au sein de chacun des couches de données.
Le schéma ci-dessous permet d'avoir une vision synthétique de l'organisation et de ses flux de données, et ensuite je vais détailler chaque espace de données.
Bronze
Fonctionnement nominal
Zone d'atterrissage (landing) pour les données brutes arrivant sur la plateforme (sans aucune optimisation du stockage)
À noter que généralement, il faut prévoir un espace de landing dédié, accessible depuis l'extérieur, avec ensuite un transfert de la donnée brute vers le landing de l'espace Bronze.
Zone d'archivage (archive) facultative des fichiers brutes déjà traités et qui ne sont plus censés servir (puisque le Bronze optimize doit déjà être sans perte et optimisé).
Dans l'idéal, une fois le fichier brut chargé dans optimize, il doit être supprimé.
Par sécurité, il est possible de le déplacer dans la zone archive pendant quelques jours. Il faut prévoir un traitement régulier qui supprime les anciens fichiers archivés pour libérer le stockage.
Zone optimize qui stocke les données brutes dans un format optimisé et avec ajout de métadonnées.
Stockage des colonnes en string pour s'assurer qu'il n'y a pas d'altération
On peut déjà typer les colonnes, mais dans ce cas, il faut systématiquement rejeter les lignes avec au moins une colonne en rejet sur une erreur de typage.
Or, certaines colonnes peuvent être facultative, et c'est à mon avis au Silver de le gérer (sinon la couche Bronze contient trop d'intelligence).
Cette gestion simple, en String, du Bronze (sans intelligence) permet de créer des traitements génériques facilement pour cette étape.
En plus de chaque colonne en String, on peut prévoir une colonne contenant tout le contenu du message (ou de la ligne) en String. C'est très utile s'il y a un écart sur le nombre de colonnes attendues (pour un CSV, mais valable pour du JSON ou XML également).
Particularité du Streaming
Pour du temps réel, avec un topic Kafka par exemple, c'est le topic alimenté par la source qui correspond à la zone Bronze landing.
De plus, pour des raisons de latence, on va généralement réaliser l'action de la couche Bronze et Silver dans le même traitement, et mettre à disposition les données Silver dans un autre topic Kafka qui sera ensuite utilisé en streaming pour alimenter une ou plusieurs tables Gold.
Il reste nécessaire de prévoir des traitements annexes qui stockeront le contenu de ces différentes couches sur un système de stockage long terme (type S3) de manière optimisé.
Silver
Espace de validation des données avec respect du typage, mais également des contrôles de cohérence et de qualité des données.
Zone validate pour les données validées comme ayant un niveau de qualité suffisant.
Zone reject pour les données non validées et nécessitant un retraitement manuel ou une exclusion définitive.
On garde les métadonnées de l'étape Bronze pour faciliter le suivi, a minima la date de réception et la source de la donnée.
Ajout d'un moins une métadonnée indiquant la ou les raisons du rejet.
Ajout facultatif d'une seconde métadonnée pour indiquer si un retraitement manuel est nécessaire, ou si c'est un rejet définitif. Cette métadonnée permet de plus facilement monitorer les rejets. La raison du rejet n'est pas forcément suffisante. On peut estimer qu'un rejet répété d'une même donnée (même identifiant par exemple) entraîne un rejet définitif, alors que la même raison sur une autre ligne engendrera un retraitement manuel.
Gold
Une zone par cas d'usage et/ou domaine métier ou encore en vision produit (Data Mesh) selon les besoins.
Zone partagée (shared) pour accueillir des dimensions communes entre plusieurs cas d'usage (Exemple: calendrier)
Synthèse
Pour terminer cet article, je vous propose un petit tableau comparatif entre les couches, et ma conclusion.
Tableau comparatif des couches
Conclusion
J'espère que cet article vous a éclairé sur l'architecture en médaillon, et vous donnera des pistes pour l'implémenter dans votre SI.
Je l'ai déjà mis en place sur plusieurs projets et je constate que ça permet de donner une vraie organisation, sans pour autant être bloquant. C’est un cadre de travail.
Certains rajoutent des couches supplémentaires, mais attention de ne pas augmenter trop la complexité et donc la maintenance ensuite.
Parfois, une couche après le Gold est ajoutée pour distinguer les données valorisées (peu agrégées) de celle très agrégées (pour un usage BI). C'est possible, mais comme la couche Gold est déjà organisée par cas d'usage, c'est suffisant dans la majorité des cas.
Et vous, comment avez-vous implémenté votre architecture en médaillon ?