Data Lake vs Data Mart : construisez votre plateforme de données idéale
|
6
minute de lecture
Votre équipe connaît probablement déjà ce sentiment. La finance clôture le mois et un tableau de bord indique que le chiffre d'affaires est en hausse. Les ventes extraient un rapport différent et obtiennent un chiffre différent. Le marketing a des données de campagne stockées dans un outil de BI, le produit a des journaux d'événements dans un stockage d'objets, et l'ingénierie a du JSON brut qui atterrit quelque part où personne en dehors de l'équipe de la plateforme ne veut toucher. Tout le monde s'accorde à dire que l'entreprise dispose de « beaucoup de données ». Personne ne s'accorde sur le jeu de données auquel faire confiance.
C'est généralement à ce moment-là que la question de savoir s'il faut choisir un lac de données ou un data mart cesse d'être théorique. Elle devient une décision opérationnelle. Avez-vous besoin d'une large zone de destination pour des données brutes, complexes et multi-formats, ou d'une couche analytique ciblée qui donne aux utilisateurs professionnels des réponses rapides avec moins d'ambiguïté ? C'est souvent présenté comme un choix de stockage et de modélisation. En pratique, c'est aussi une question de modes de défaillance, d'appropriation et de friction opérationnelle que votre équipe est prête à absorber.
Table des matières
Plongée architecturale approfondie : une comparaison côte à côte
Mise en œuvre de la qualité des données et de l'observability
La stratégie des données à la croisée des chemins
Une entreprise n'arrive généralement pas à cette décision par une planification d'architecture élégante. Elle y parvient parce que le travail quotidien commence à se dégrader. Les analystes passent plus de temps à rapprocher les rapports qu'à les interpréter. Les ingénieurs corrigent un pipeline pendant qu'un autre prend du retard sur le planning. Les chefs de département créent des extractions privées parce que la plateforme partagée semble trop lente ou trop opaque.
C'est la véritable croisée des chemins. Un lac de données vous offre un endroit pour ingérer presque tout sans imposer de structure immédiate. Un data mart offre à une équipe métier une surface plus étroite et plus propre, construite dans un but précis. Les deux sont utiles. Les deux peuvent échouer lamentablement lorsque le modèle opérationnel qui les entoure est faible.
Un modèle se répète sans cesse. Une entreprise souhaite des rapports en libre-service, les équipes se précipitent donc pour exposer davantage de jeux de données à davantage d'utilisateurs. Mais si ces jeux de données ne partagent pas les mêmes définitions, attentes de fraîcheur et propriété, le libre-service se transforme en libre-interprétation. Si votre organisation s'oriente dans cette direction, il est utile d'explorer le BI en libre-service sur WeekBlast parallèlement aux décisions relatives à votre plateforme, car la liberté de reporting ne fonctionne que lorsque le Data Contract sous-jacent est stable.
La question d'architecture est avant tout une question opérationnelle
Un lac privilégie la flexibilité. Il fonctionne bien lorsque la télémétrie des produits, les journaux d'applications, les documents, les fichiers d'images et les flux de partenaires doivent tous atterrir quelque part avant que quiconque ne connaisse la forme analytique finale. Un mart privilégie la cohérence. Il fonctionne bien lorsque la finance a besoin d'une couche de reporting contrôlée, ou lorsque les ventes ont besoin d'un modèle de KPI unique que personne ne peut réinterpréter à la volée.
L'erreur consiste à traiter ces éléments comme des étiquettes de stockage interchangeables. Ils créent des charges de support différentes.
Dans un lac, les équipes luttent généralement contre l'ambiguïté. Quelle table est à jour ? Quelle version de schéma est valide ? Est-ce que le système source a ajouté un champ qui a brisé la logique en aval sans avertissement ?
Dans un mart, les équipes luttent généralement contre les goulots d'étranglement. À qui appartient la définition de la métrique ? Combien de temps prend l'approbation d'un changement de modèle ? Pourquoi la solution rapide d'un département est-elle désormais un silo ?
De nombreuses équipes découvrent également que la topologie de la plateforme affecte la propriété de la qualité des données. Un contrôle centralisé peut améliorer la cohérence mais ralentir la livraison locale. Une propriété décentralisée peut accélérer le travail sur le domaine mais créer une fragmentation à moins que les normes de qualité n'accompagnent le produit de données. Cette tension est au cœur du débat entre data mesh vs plateformes de données centralisées et qualité des données.
Le mauvais choix de plateforme échoue rarement au premier jour. Il échoue six mois plus tard, lorsque davantage d'utilisateurs en dépendent et que personne ne peut expliquer pourquoi la même métrique ne cesse de changer.
Comprendre les concepts fondamentaux
La façon la plus claire de comprendre la différence entre lac de données et data mart est d'examiner l'intention, et non les outils.
Un lac de données est un référentiel centralisé et évolutif qui ingère et stocke de grands volumes de données brutes sous leur forme native, y compris les formats structurés, semi-structurés et non structurés, selon l'explication de Dataversity sur les différences entre lac de données et data mart. Cela signifie que des tables peuvent côtoyer des journaux JSON, des documents texte, des images, de l'audio ou de la vidéo. Le but n'est pas le raffinement. Le but est la conservation, l'exploration et la réutilisation ultérieure.
Un data mart est un sous-ensemble structuré et conçu sur mesure pour une unité commerciale ou un cas d'utilisation analytique spécifique. Il contient des données qui ont déjà été nettoyées, transformées et organisées pour le reporting et l'analyse commerciale, comme décrit dans l'analyse d'Atlan sur le data mart par rapport au lac de données. Le but n'est pas l'optionnalité. Le but est la facilité d'utilisation.
Pourquoi les philosophies diffèrent
Considérez le lac comme un parc de matières premières. Vous y stockez des journaux, des exportations, des événements, des fichiers multimédias et des charges utiles de partenaires parce que vous en aurez peut-être besoin plus tard, et parce que les contraindre trop tôt dans un modèle rigide élimine généralement de la valeur. Les data scientists et les ingénieurs apprécient cette configuration car elle préserve les détails et rend possible le travail exploratoire.
Considérez le mart comme un rayon de produits finis. Les données ont déjà été structurées en dimensions, faits, définitions approuvées et cycles de rafraîchissement attendus. Les analystes commerciaux, les responsables financiers et les directeurs opérationnels apprécient cette configuration car ils peuvent poser des questions connues et obtenir rapidement des réponses stables.
Un résumé utile est le suivant :
Lac : stocker d'abord, interpréter plus tard
Mart : modéliser d'abord, servir maintenant
Cette différence philosophique guide tout le reste en aval, de la conception de l'ingestion aux contrôles d'accès en passant par les alertes d'assistance.
Où les équipes se confondent
La confusion commence lorsqu'une équipe s'attend à ce qu'une architecture se comporte comme l'autre. Elle place des données d'événements brutes dans un lac, puis s'attend à ce que les tableaux de bord BI se comportent comme une couche sémantique structurée. Ou bien, elle pousse chaque besoin analytique vers un mart, puis découvre que l'apprentissage automatique, l'analyse forensic de journaux et les jointures exploratoires sont constamment bloqués par une modélisation rigide en amont.
Un modèle hybride moderne tente de combler une partie de ce fossé. Si votre équipe évalue cette voie, une étape suivante pratique consiste à comprendre ce qu'est un lakehouse et comment maintenir la qualité des données. La principale raison d'être de ce sujet ici est opérationnelle : les conceptions hybrides réduisent une partie de la duplication, mais elles n'éliminent pas le besoin de contrôles de qualité clairs.
Un lac répond à « qu'avons-nous ? » Un mart répond à « que devrait utiliser l'entreprise ? »
Plongée architecturale approfondie : une comparaison côte à côte
Les différences architecturales semblent simples sur une diapositive et complexes en production. La forme des données, le moment où le schéma est appliqué, l'identité des utilisateurs principaux et la portée de la plateforme modifient tous le comportement du système sous pression.
Aperçu du lac de données par rapport au data mart
Attribut | Lac de données | Data Mart |
|---|---|---|
Objectif principal | Stocker des données larges et brutes pour réutilisation et exploration | Servir une fonction commerciale spécifique avec des analyses préparées |
Formats de données | Données structurées, semi-structured et non structurées sous leur forme native | Données structurées, transformées et prêtes pour l'entreprise |
Modèle de schéma | Schéma à la lecture (schema-on-read) | Schéma à l'écriture (schema-on-write) |
Utilisateurs types | Ingénieurs de données, data scientists, équipes ML | Analystes commerciaux, développeurs BI, chefs de département |
Diversité des sources | Internes et externes, souvent très hétérogènes | Généralement des données commerciales sélectionnées et pertinentes pour un domaine |
Portée | Couche de destination et de réutilisation à l'échelle de l'entreprise | Couche de consommation spécifique à un département ou à un cas d'utilisation |
Timing de préparation des données | Transformation minimale lors de l'ingestion | Le nettoyage et la modélisation se font avant la livraison |
Meilleure adéquation | Exploration, expérimentation, conservation à long terme | Reporting, analyse récurrente, KPI définis |
Problème opérationnel courant | Dérive, découvrabilité, propriété incertaine | Goulots d'étranglement des métriques, duplication entre les départements |
Ce que le tableau signifie en pratique
Le modèle de schéma à la lecture dans un lac offre une liberté aux ingénieurs. Vous pouvez ingérer d'abord et décider de la structure plus tard. C'est précieux lorsque les systèmes sources évoluent rapidement ou lorsque l'entreprise n'a pas encore défini les questions en aval. C'est aussi la raison pour laquelle les lacs de données peuvent devenir difficiles à gouverner. Si trois équipes interprètent différemment le même champ brut, la plateforme n'a pas échoué techniquement. Elle a échoué opérationnellement.
Le modèle de schéma à l'écriture dans un mart fait le contraire. Il impose des décisions précoces. Les types de colonnes, les jointures, le niveau de détail, les définitions des métriques et les conventions de nommage doivent tous être résolus avant que les utilisateurs ne consomment les données. Cela ralentit la livraison initiale, mais cela réduit généralement les conflits en aval car l'entreprise dispose d'une interface plus étroite et plus délibérée.
Voici où les équipes sous-estiment souvent la différence :
L'ingestion dans un lac est plus facile au départ. Elle est plus difficile à standardiser par la suite.
La livraison dans un mart est plus lente au départ. Elle est plus facile à supporter une fois stabilisée.
Un lac invite à de nombreux cas d'utilisation. Un mart rejette par conception les cas d'utilisation vagues.
Un lac préserve les preuves brutes. Un mart emballe des réponses approuvées.
L'expérience utilisateur est façonnée par l'architecture
Un data scientist ouvrant un lac s'attend à de l'optionnalité. Il inspectera les champs bruts, testera les transformations et tolérera une certaine incohérence si la plateforme préserve la fidélité. Un analyste financier ouvrant un mart s'attend à de la confiance. Il veut un ensemble restreint de tables fiables et des requêtes rapides et reproductibles.
C'est pourquoi la décision d'opter pour un lac de données ou un data mart doit être liée aux contrats des utilisateurs, et pas seulement aux modes de stockage. Si l'audience a besoin de flexibilité, ne masquez pas les données brutes derrière des abstractions trop standardisées. Si l'audience a besoin de cohérence, ne l'exposez pas à des zones d'ingestion à moitié prêtes en lui demandant de « se débrouiller ».
Compromis entre performance, coût et governance
La plupart des débats sur l'architecture s'articulent autour de la flexibilité contre la rapidité. C'est vrai, mais c'est incomplet. La partie la plus coûteuse est souvent le travail nécessaire pour maintenir la fiabilité de la plateforme.
Les data marts sont généralement plus agréables pour la BI quotidienne car les données sont déjà formatées pour des modes d'accès connus. Selon la comparaison de performance entre data mart et lac de données par Yandex Cloud, les data marts offrent souvent une réduction de latence de 3 à 5 fois par rapport aux lacs de données en raison de leur conception structurée de schéma à l'écriture et de jeux de données optimisés pour les fonctions commerciales.
Pourquoi les marts semblent plus rapides pour l'entreprise
Un mart élimine le travail avant le moment de la requête. Il connaît déjà le niveau de détail, les dimensions, les filtres et la logique commerciale acceptée. Cela signifie que les outils BI et les analystes passent moins de temps à analyser, convertir et joindre des données sources ambiguës.
Règle opérationnelle : Si la même question de tableau de bord est posée chaque semaine, sa place est probablement dans les données préparées, et non dans les données brutes.
Cette rapidité a un coût. Quelqu'un doit concevoir et maintenir les transformations, approuver les modifications de définitions et empêcher les différents marts de dériver les uns par rapport aux autres. Si le marketing et la finance définissent le « chiffre d'affaires client » de manière légèrement différente dans des marts séparés, l'entreprise gagne en rapidité mais perd une vérité partagée.
Où apparaissent les coûts cachés
Un lac abaisse la barrière à l'ingestion et s'adapte mieux à une capture de données à grande échelle. Mais la governance dans un lac ne se fait pas automatiquement. Les équipes ont besoin de métadonnées, de propriété, de Data Contracts, de lignage (lineage), de contrôles d'accès et d'une certaine discipline de requête. Sans ces contrôles, un stockage à bas coût se transforme en une confusion coûteuse.
Deux modèles de défaillance courants apparaissent :
Le problème du marécage de données (data swamp) : les actifs de données brutes s'accumulent plus vite que les équipes ne peuvent les documenter, les classer et les valider.
La taxe de rejeu : parce que la logique en aval n'est pas structurée, les ingénieurs passent du temps à réexécuter des tâches, à re-valider des hypothèses et à expliquer des résultats incohérents.
Les marts ont leur propre version de dette opérationnelle.
Le problème des silos : chaque département souhaite une vue personnalisée, et l'optimisation locale fragmente progressivement les définitions de l'entreprise.
Le problème de la file d'attente des changements : une petite équipe de modélisation devient le goulot d'étranglement pour chaque nouvelle métrique ou ajustement de schéma.
Une plateforme bon marché qui nécessite une intervention humaine constante pour qu'on puisse lui faire confiance n'est pas réellement bon marché.
La governance se décline également différemment. Dans un mart, la governance est visible car le modèle est explicite. Dans un lac, la governance est souvent invisible jusqu'à ce qu'un problème survienne, car une ingestion permissive peut masquer des problèmes de qualité jusqu'à la consommation.
Cas d'utilisation réels pour les lacs et les marts
Les architectures prennent plus de sens lorsque vous les associez à des tâches réelles. La question n'est pas « laquelle est moderne ? », mais « laquelle réduit la friction pour cette charge de travail sans créer de nettoyage évitable par la suite ? »
Commençons par le côté lac de données. Une équipe produit collectant des journaux web, des événements de parcours de navigation (clickstream), des transcriptions de support et des téléchargements d'images a généralement besoin d'un seul endroit pour conserver ces actifs avant que quiconque n'élabore le modèle analytique final. C'est un problème de lac de données. Il en va de même pour la télémétrie de l'IoT, les pipelines d'investigation des fraudes qui nécessitent des schémas de transaction bruts, ou l'expérimentation de caractéristiques (features) de ML où la conservation de la granularité source est importante.
Quand un lac est la bonne surface de travail
Un lac fonctionne bien lorsque la valeur provient de l'exploration avant la standardisation.
L'entraînement au machine learning : les équipes ont souvent besoin d'enregistrements historiques bruts, de séquences d'événements et d'entrées non tabulaires qui ne s'intègrent pas facilement dans un modèle de reporting départemental.
Analyse d'incidents et forensic : les ingénieurs peuvent retracer les charges utiles d'origine, les journaux et les événements sources au lieu de s'appuyer sur des données synthétisées.
Analyses de nouveaux produits : lorsque l'entreprise ne sait pas encore quelles métriques comptent, imposer un mart trop tôt crée généralement des frictions et des remaniements.
Le lac est particulièrement utile lorsque plusieurs cas d'utilisation futurs peuvent émerger de la même source brute. Le produit, le risque, la science des données et la Compliance de conformité réglementaire peuvent tous dériver des résultats différents à partir d'un même jeu de données conservé.
Une courte illustration aide à comprendre. Une plateforme de vente en ligne stocke des journaux de sessions web, des messages de support, des images de produits et des exportations de transactions dans un lac. Les data scientists utilisent l'historique brut pour tester des fonctionnalités de recommandation. Les analystes des risques étudient les parcours de transaction inhabituels. Plus tard, les ingénieurs analytiques transforment un sous-ensemble en rapports de vente structurés. Le lac n'est pas le produit final. C'est la surface de travail.
La vidéo ci-dessous donne une explication visuelle simple de l'impact de ces différences en pratique.
Quand un mart est le meilleur produit
Un mart fonctionne bien lorsque l'entreprise connaît déjà les questions et a besoin de réponses fiables.
Les ventes en sont l'exemple classique. Les responsables régionaux souhaitent un suivi du pipeline, des réservations (bookings), des taux de réussite (win rates) et des rapports sur la réalisation des objectifs dans un seul endroit. Ils ne veulent pas inspecter des instantanés CRM bruts ou des charges utiles d'événements. Ils veulent un modèle fiable avec un comportement de rafraîchissement stable.
Le même principe s'applique à la finance et au marketing :
Reporting financier : les processus de clôture trimestrielle et mensuelle nécessitent des dimensions contrôlées, des faits rapprochés et des définitions claires.
Analyse de campagne : les équipes marketing ont besoin d'une surface de reporting liée à une logique d'attribution approuvée, et non d'un bac à sable de flux sources semi-structured.
Tableaux de bord opérationnels : les responsables de la chaîne d'approvisionnement ou du support ont plus besoin de répétabilité que de flexibilité.
Un mart doit être traité comme un produit destiné à une audience connue. Si tout le monde peut le redéfinir, il cesse d'être un mart et commence à devenir une autre couche de données brutes avec des noms de tables plus élégants.
Faire le bon choix : lac de données, data mart ou les deux
Les équipes demandent souvent une réponse binaire. En pratique, la bonne réponse dépend de ce que la plateforme doit faire en premier, de qui en dépend et de la maturité du modèle opérationnel.
Choisir en fonction du travail, pas de la tendance
Choisissez d'abord un lac lorsque votre besoin principal concerne l'ingestion à grande échelle, la conservation à long terme, l'analyse exploratoire ou les travaux d'IA et de ML sur des types de données mixtes. Si vos sources de données comprennent des journaux, des documents, des fichiers multimédias, des flux d'événements et des flux de partenaires, un lac gère cette variabilité bien mieux qu'une structure de reporting étroite.
Choisissez d'abord un mart lorsque l'entreprise demande des rapports plus rapides sur des KPI établis et un ensemble limité de domaines. Si les ventes, la finance ou les opérations ont besoin de chiffres cohérents au cours du prochain trimestre, un mart apporte souvent de la valeur commerciale plus rapidement en limitant le périmètre du problème.
Un filtre de décision pratique se présente comme suit :
Vos utilisateurs ont besoin d'un accès brut et d'expérimentation : privilégiez le lac.
Vos utilisateurs ont besoin de tableaux de bord gouvernés et de rapports récurrents : privilégiez le mart.
Votre équipe de plateforme est restreinte et le périmètre des métriques est connu : un mart sera plus facile à maintenir.
Vos sources de données évoluent constamment et les formats varient largement : un lac vous offre la possibilité d'absorber le changement.
Pourquoi de nombreuses équipes finissent par utiliser les deux
Un modèle opérationnel courant consiste à déposer des données brutes ou légèrement traitées dans un lac, puis à publier des résultats nettoyés et spécifiques à un domaine dans des marts ou des couches de consommation similaires à des marts. Cette configuration reflète la réalité. Différents utilisateurs ont besoin de contrats différents.
Le risque principal est la duplication sans discipline. Si le lac devient non géré et que chaque département construit de manière indépendante sa propre logique de mart, votre schéma d'architecture semblera flexible alors que votre modèle opérationnel deviendra fragile.
Un modèle plus équilibré consiste à conserver les actifs bruts et réutilisables dans une couche centrale, puis à n'exposer les modèles orientés métier que lorsqu'il y a un propriétaire clair et un besoin utilisateur stable. Les équipes qui planifient cette transition bénéficient généralement d'une réflexion pratique sur la migration, en particulier lorsque des entrepôts de données existants ou des marts alimentent déjà des rapports en production. Dans ces circonstances, les bonnes pratiques pour une transition fluide lors de la migration d'un entrepôt de données vers un lac de données sont pertinentes, car le changement ne fonctionne que si les attentes de qualité et de livraison survivent à la transition.
Un autre point important mérite d'être souligné. Si votre organisation a besoin à la fois d'une exploration flexible et d'une BI fiable, la question d'architecture peut s'orienter vers une approche de type lakehouse. Cela n'élimine pas le travail de governance. Cela réduit simplement une partie de la friction liée à l'exécution de systèmes déconnectés.
Mise en œuvre de la qualité des données et de l'observability
Le choix de l'architecture façonne la façon dont les mauvaises données cassent le système, la vitesse à laquelle les équipes s'en rendent compte et la complexité de l'analyse des causes profondes.
Un lac échoue généralement de manière silencieuse. Un système source ajoute une colonne. Un type de données change. Un champ imbriqué arrive avec une structure différente. L'ingestion se termine tout de même avec succès, mais l'analyse en aval, les jointures ou la génération de caractéristiques (features) commencent à produire des dommages subtils. Selon l'analyse de JMIR sur la dérive des schémas et les taux de défaillance des pipelines, les lacs de données peuvent connaître des taux de défaillance des pipelines de 30 % à 40 % plus élevés car ils n'imposent pas de schéma et sont davantage exposés à la dérive de schéma silencieuse et aux incohérences de types de données que la surveillance traditionnelle ne détecte pas.
Comment les défaillances diffèrent dans chaque architecture
Dans les lacs de données, les incidents de qualité commencent souvent en amont et font surface tardivement. Le pipeline s'est techniquement « exécuté », mais la structure des données a changé sous vos pieds. Une surveillance standard des tâches ne captera pas cela de manière fiable, car la bonne exécution d'une tâche ne garantit pas l'exactitude des données.
Dans les marts, les défaillances sont généralement plus visibles mais tout aussi dommageables. Une tâche de transformation s'exécute en retard. Une table de dimensions ne se met pas à jour. Une règle de gestion commerciale change et le modèle structuré continue d'appliquer la logique d'hier. Les tableaux de bord se chargent, mais ils sont obsolètes ou sémantiquement faux.
Cela signifie que l'observability doit couvrir différents types de risques.
Pour les lacs : détection des changements de schéma, surveillance de la fraîcheur aux frontières de l'ingestion, et détection d'anomalies sur les volumes, le comportement des valeurs nulles et les dérives de distribution.
Pour les marts : surveillance des délais de livraison planifiés, validation des règles métier clés, et détection d'anomalies sur les valeurs de KPI qui peuvent sembler syntaxiquement correctes mais opérationnellement fausses.
L'équipe ne perd pas confiance lorsqu'un pipeline échoue de manière flagrante. La confiance s'effrite lorsque les données sont fausses et que personne ne s'en aperçoit avant qu'une partie prenante ne le signale.
Ce que la surveillance moderne doit réellement couvrir
Les alertes d'orchestration de base ne suffisent pas. Elles vous indiquent si une tâche a été exécutée, mais pas si les données sont restées exploitables. Un système d'observability sérieux doit surveiller plusieurs niveaux à la fois :
Structure : colonnes ajoutées, colonnes supprimées, modifications des types de données et anomalies de partitionnement.
Fraîcheur : fenêtres d'arrivée attendues pour les chargements sources et les tables préparées.
Comportement du contenu : variations de volumes, pics de valeurs nulles, modifications des comptes uniques (distinct counts) et mouvements inattendus de distribution.
Validité commerciale : contrôles basés sur des règles pour les champs qui doivent respecter une logique métier.
Traçabilité : suffisamment de métadonnées de lignage (lineage) et de propriété pour assigner rapidement des résolutions.
L'implication pratique dans le débat entre lac de données et data mart est simple. Les lacs ont besoin d'une surveillance structurelle et comportementale plus forte car la flexibilité engendre de l'ambiguïté. Les marts ont besoin d'une surveillance plus étroite de la livraison et de la sémantique car les consommateurs présument que les données sont déjà fiables.
Si votre équipe utilise l'une ou l'autre de ces architectures sans observability active, vous comptez sur vos utilisateurs finaux pour qu'ils deviennent votre système de surveillance. C'est coûteux, lent et destructeur pour la confiance.
Si vous avez besoin d'un contrôle accru sur la dérive silencieuse, les retards de chargement, les transformations brisées et les anomalies difficiles à diagnostiquer à travers vos lacs, marts ou plateformes hybrides, digna offre aux équipes de données un espace unifié pour surveiller les délais, les modifications de schémas, les validations et la détection d'anomalies basée sur l'IA, tout en conservant les données dans des environnements contrôlés par le client.
