Lac de données vs Data Mart : lequel vous convient le mieux ?
|
8
minute de lecture
De nombreuses équipes se heurtent au même mur à peu près au même stade de croissance. Les événements produit affluent. Les données CRM ne cessent de se multiplier. La finance souhaite une vue mensuelle claire. Le marketing veut une attribution à laquelle il peut faire confiance. La data science veut des journaux bruts (raw logs), pas la table de synthèse d'un autre. Tout le monde dit avoir besoin de « la bonne architecture », mais la décision réelle se résume généralement à un débat simpliste : data lake vs data mart.
Ce cadrage pose problème. En pratique, la plupart des équipes modernes ne choisissent pas l'un pour toujours en ignorant l'autre. Elles construisent les deux, ou elles en construisent un et finissent par dépendre de l'autre. La question centrale est de savoir comment chacun s'intègre dans le pipeline, quelles sont leurs forces respectives et où apparaissent les risques lorsque la qualité des données brutes commence à se dégrader. Si vous évaluez également un modèle de lakehouse, ce guide expliquant ce qu'est un lakehouse et comment maintenir la qualité des données est un compagnon utile car les mêmes problèmes opérationnels s'y appliquent.
Table des matières
Plongée d'architecture approfondie : comparaison côte à côte
Analyse des coûts de performance et des compromis de gouvernance
Faire le bon choix pour votre cas d'utilisation
Choisissez un data lake lorsque les questions futures importent plus que la commodité actuelle
Choisissez un data mart lorsque l'entreprise a besoin de réponses stables selon un planning défini
Ne traitez pas un data mart comme la couche principale pour le machine learning
En pratique, les équipes matures utilisent les deux et gèrent la dépendance avec soin
Le risque invisible : la qualité des données dans votre pipeline de données
Mise en œuvre de l'Observability pour les lacs et les data marts
La croisée des chemins de l'architecture de données moderne
Le déclencheur habituel n'est pas technique. Il est organisationnel.
Une entreprise commence avec quelques tableaux de bord et une base de données de rapports. Ensuite, de nouveaux produits sont lancés, les équipes ajoutent des outils SaaS, les interactions avec les clients se répartissent sur le Web, l'application, le support et les plateformes tierces, et quelqu'un demande du machine learning en plus de tout cela. Soudain, l'ancienne stack ne peut plus absorber les entrées brutes assez rapidement, et l'entreprise s'attend toujours à des chiffres soignés pour le lundi matin.
À ce stade, les dirigeants entendent souvent deux réponses concurrentes. Un camp plaide pour un data lake car l'entreprise a besoin de flexibilité, d'historique brut et de support pour la data science. L'autre pousse pour un data mart parce que les équipes métier ont besoin de réponses gouvernées, fiables et rapides pour une fonction spécifique. Les deux ont raison, mais uniquement dans les limites des problèmes qu'ils résolvent.
Ce que les équipes se trompent généralement
L'erreur consiste à traiter la décision comme s'il s'agissait d'un duel de produits. Ce n'est pas le cas.
Un data lake est une base d'ingestion et d'exploration. Un data mart est une couche de consommation pour un public métier ciblé. Ils résolvent des problèmes différents, servent des utilisateurs différents et échouent de manières différentes. Lorsque les équipes les confondent en un seul choix, elles surdimensionnent généralement un côté et sous-investissent dans les contrôles qui les relient.
Les équipes regrettent rarement de stocker des données brutes dont elles pourraient avoir besoin plus tard. Elles regrettent souvent d'exposer les utilisateurs métier à des données qui n'ont pas été préparées pour des décisions opérationnelles.
La conséquence pratique
Si vous choisissez uniquement en fonction des rapports immédiats, vous risquez de limiter vos options futures d'analyse et de ML. Si vous choisissez uniquement pour la flexibilité, vous risquez de créer une plateforme qui stocke tout mais ne répond clairement à pas grand-chose.
C'est pourquoi la question n'est pas « Qui l'emporte ? » mais plutôt « Où doivent résider les données brutes, où doivent résider les données prêtes pour le business, et comment empêcher que les problèmes de qualité en amont n'empoisonnent subtilement les décisions en aval ? »
Définition des concepts clés
Ces définitions sont importantes car les équipes utilisent souvent ces termes de manière vague, pour ensuite construire la mauvaise couche pour le travail à effectuer.
Qu'est-ce qu'un data lake
Un data lake est un entrepôt centralisé pour les données brutes dans leur format natif. Il peut contenir des tables structurées, des enregistrements semi-structurés tels que du JSON, et du contenu non structuré tel que des images, de l'audio, des journaux et des flux d'événements. La définition du data lake par IBM correspond à la manière dont les praticiens utilisent le terme dans les plateformes modernes. Le lac est l'endroit où atterrissent les données avant que chaque règle métier, jointure et norme de nommage n'ait été finalisée.
Cette flexibilité est utile, mais elle déplace le travail en aval.
En pratique, un lac prend en charge d'abord l'ingestion, puis l'interprétation. Les ingénieurs peuvent conserver les données sources en toute fidélité, préserver les détails historiques et prendre en charge des cas d'utilisation qui évoluent encore. Les Data Scientists et les équipes d'analyse avancée bénéficient de cette liberté car les attributs bruts, les champs clairsemés et les particularités des sources comptent souvent lors du développement de fonctionnalités et de l'analyse des causes profondes.
Le compromis est opérationnel, pas théorique. Un lac sans normes claires de partitionnement, de métadonnées, de propriété et de contrôles de qualité devient rapidement une couche de stockage peu fiable. Lorsque des enregistrements erronés, des mises à jour tardives ou des schémas brisés pénètrent dans le lac sans être détectés, le problème y reste rarement. Ces défauts s'écoulent souvent vers les data marts en aval et apparaissent plus tard sous forme de KPI incorrects qui semblent légitimes.
Qu'est-ce qu'un data mart
Un data mart est un entrepôt de données structuré et organisé, conçu pour un domaine d'activité défini tel que les ventes, la finance, le support ou les opérations. Il contient des données transformées et façonnées pour des analyses répétées, généralement avec des définitions convenues, des dimensions contrôlées et des métriques stables.
Un data mart fonctionne comme un produit standardisé pour un public cible connu. L'objectif est la rapidité, la cohérence et la clarté, et non la flexibilité brute.
Selon la comparaison des data marts et des data lakes par Dataversity, les data marts s'alimentent généralement à partir de systèmes transactionnels internes, tandis que les data lakes peuvent combiner des sources de données internes et externes. Cette même analyse de Dataversity note également que les data lakes sont couramment utilisés par les Data Scientists travaillant avec des données brutes, tandis que les data marts sont plus souvent utilisés par les parties prenantes métier pour suivre des KPI prédéfinis.
Cette distinction a des conséquences pratiques. Un data mart réduit l'ambiguïté pour les personnes qui prennent des décisions récurrentes. Il donne à la finance une définition unique du chiffre d'affaires, aux ventes une vue acceptée du pipeline et aux opérations une version unique des performances des niveaux de service. Mais chaque simplification dans le data mart est également une décision de filtrage. Si la transformation en amont est incorrecte, incomplète ou basée sur des données de lac altérées, le data mart peut fournir des réponses soignées mais systématiquement fausses.
La façon la plus simple de les séparer
Un test rapide permet généralement de clarifier le rôle de chaque couche :
Si la question change encore ou si les données nécessitent plusieurs interprétations futures, commencez par un data lake.
Si la question métier est stable et posée de manière répétée par une équipe définie, construisez ou alimentez un data mart.
Si la plateforme doit prendre en charge à la fois l'exploration et les rapports standardisés, utilisez les deux, et traitez le pipeline qui les relie comme un système de production contrôlé.
Aspect | Data Lake | Data Mart |
|---|---|---|
Objectif principal | Stocker les données sources pour analyse et réutilisation futures | Fournir des données organisées pour une fonction métier spécifique |
Forme des données | Brutes ou légèrement traitées, formats mixtes | Structurées, nettoyées, prêtes pour le business |
Utilisateurs typiques | Ingénieurs de données, data scientists, équipes de plateforme | Analystes, managers, utilisateurs métier |
Couverture des sources | Données internes et externes | Généralement des données métier sélectionnées et préparées pour un domaine |
Meilleur cas d'usage | Exploration, machine learning, conservation historique | Rapports, tableaux de bord, suivi des KPI |
Plongée d'architecture approfondie : comparaison côte à côte
La différence d'architecture entre un lac et un data mart n'est pas cosmétique. Elle affecte la conception de l'ingestion, la stratégie de transformation, l'accès des utilisateurs, les modes de défaillance et les coûts d'exploitation.
Schéma et modélisation des données
La distinction la plus importante est d'ordre structurel.
Data lake : schéma à la lecture (schema-on-read)
Data mart : schéma à l'écriture (schema-on-write)
Dans un lac, l'équipe stocke d'abord les données et applique une structure lors de l'accès. Dans un data mart, l'équipe définit la structure avant ou pendant le chargement afin que le résultat stocké corresponde déjà au modèle analytique prévu.
Cette différence importe plus que ce que la plupart des diagrammes d'architecture veulent bien admettre. Le schéma à la lecture vous offre de la flexibilité. Vous pouvez ingérer de nouvelles variantes d'événements, des champs supplémentaires ou des formats mixtes sans avoir à reconcevoir la cible à chaque fois. Mais cette même flexibilité repousse la discipline en aval. Quelqu'un doit tout de même définir la signification, les types, les jointures et la logique métier plus tard.
Un data mart fait l'inverse. Il impose l'ordre dès le départ. Cela facilite les rapports en aval car les utilisateurs interrogent des tables stables, souvent dans des modèles dimensionnels conçus pour un domaine précis.
Style de traitement et timing de transformation
Les lacs prennent généralement en charge un modèle de chargement préalable. Les données brutes atterrissent rapidement, puis les ingénieurs les transforment plus tard pour des parcours analytiques spécifiques. Les data marts dépendent d'une préparation préalable. Les données sont nettoyées, typées, alignées sur les définitions métier et stockées sous une forme prête pour les questions que l'entreprise sait déjà qu'elle va poser.
Les équipes confondent souvent « plus rapide à ingérer » avec « plus rapide à utiliser ». Un lac est plus rapide à recevoir des données diverses. Un data mart est plus rapide pour répondre à des questions métier récurrentes.
Portée et échelle
Un lac est vaste par conception. Il peut contenir au même endroit des enregistrements bruts provenant d'ERP, de CRM, de journaux d'applications, de parcours de navigation (clickstream), de flux tiers et de données générées par des machines. Il est conçu pour s'adapter à de nombreux formats et à des volumes croissants.
Un data mart est volontairement restreint. Il est censé être plus petit, ciblé et aligné sur un seul domaine. Les bons data marts savent dire « non » aux détails inutiles.
Expérience utilisateur
C'est l'une des lignes de démarcation les plus nettes :
Les utilisateurs du lac ont tendance à être des ingénieurs, des équipes de plateforme et des Data Scientists.
Les utilisateurs du data mart ont tendance à être des analystes, des responsables financiers, des gestionnaires opérationnels et des consommateurs de tableaux de bord.
L'interface peut être SQL dans les deux cas, mais les hypothèses diffèrent. Dans un lac, les utilisateurs tolèrent souvent l'exploration, la reconstruction et l'ambiguïté. Dans un data mart, ils s'attendent à une sémantique stable et à des résultats cohérents.
Performance en pratique
Selon la comparaison des data marts et des data lakes par Yandex Cloud, les data lakes utilisent le schéma à la lecture tandis que les data marts imposent le schéma à l'écriture avec des modèles dimensionnels. La même source indique que les data marts peuvent offrir des performances de lecture 2 à 5 fois plus rapides pour l'informatique décisionnelle (BI) car ils limitent la portée et s'optimisent pour des ensembles de données pré-nettoyés et prédéfinis.
Cela correspond au comportement réel des plateformes. Un data mart l'emporte lorsque de nombreux utilisateurs posent des questions familières. Un lac l'emporte lorsque les équipes ont besoin d'un large accès aux détails bruts pour divers flux de travail d'analyse et de machine learning.
Règle pratique : Optimisez le lac pour la conservation et la flexibilité. Optimisez le data mart pour la confiance et la rapidité.
Analyse des coûts de performance et des compromis de gouvernance
La plupart des débats d'architecture se transforment en débats budgétaires plus tôt qu'on ne le pense. Le stockage semble bon marché jusqu'à ce que les pipelines de transformation, l'optimisation des performances de BI, les contrôles d'accès aux données et les frais de support commencent à apparaître dans les backlogs des différentes équipes.
Le coût n'est pas un simple poste budgétaire
Un lac est généralement logique d'un point de vue financier lorsque vous devez conserver de grandes quantités de données brutes et que vous ne souhaitez pas modéliser chaque source avant l'ingestion. Vous évitez d'imposer une structure coûteuse à des données qui n'ont peut-être pas encore de cas d'utilisation défini.
Un data mart déplace les coûts vers la conception et la maintenance. Vous payez pour des modèles organisés, des schémas d'accès contrôlés et des performances de requête sur lesquelles les utilisateurs métier peuvent compter. C'est généralement le bon choix lorsque les équipes financières, commerciales ou opérationnelles ont besoin de réponses claires sans avoir à reconstruire la logique dans chaque tableau de bord.
L'erreur est de comparer uniquement le stockage. Le panorama complet des coûts comprend :
L'effort d'ingénierie : Qui maintient l'ingestion, les transformations et les définitions des métriques ?
Le comportement des requêtes : Payez-vous pour de l'exploration ou pour des accès métier répétés ?
Le travail de refonte : À quelle fréquence les équipes reconstruisent-elles la logique parce que le modèle d'origine était trop rigide ou trop lâche ?
La performance dépend de la charge de travail
Si la charge de travail concerne l'ingénierie de fonctionnalités à grande échelle, la reconstruction d'événements historiques ou l'analyse multi-format, le lac est le choix naturel. Si la charge de travail concerne de la BI récurrente, un data mart offre généralement une meilleure expérience utilisateur car moins de jointures, une portée plus étroite et un grain affiné facilitent l'optimisation des requêtes.
C'est aussi la raison pour laquelle de nombreuses initiatives de BI en libre-service s'essoufflent. Les utilisateurs professionnels ne veulent pas d'une flexibilité brute. Ils veulent des données gouvernées qu'ils peuvent utiliser en toute sécurité. Si votre équipe s'efforce de résoudre efficacement les goulets d'étranglement des équipes de données, la leçon fondamentale reste la même : le libre-service fonctionne lorsque la couche sémantique et les ensembles de données organisés sont solides, pas lorsque tout le monde est parachuté dans des tables brutes.
La gouvernance change de forme avec l'architecture
La governance dans un lac est plus difficile car les données sont plus vastes, plus désordonnées et souvent moins normalisées. Les équipes de sécurité doivent réfléchir à l'exposition des données brutes, aux champs sensibles, à l'absence de propriété claire et à la qualité des métadonnées. Vous avez besoin d'une discipline de catalogage, de traçabilité (lineage) et d'accès forte, sinon le lac devient rapidement un dépotoir.
Un data mart présente un fardeau de gouvernance différent. Il expose des chiffres prêts pour l'entreprise, de sorte que les différends deviennent sémantiques plutôt que structurels. Les équipes débattent des définitions, du moment de la mise à jour et de l'attribution de la logique du KPI.
Une bonne governance dans un lac prévient le chaos. Une bonne governance dans un data mart évite les querelles politiques sur l'exactitude des chiffres de chacun.
Faire le bon choix pour votre cas d'utilisation
Une équipe prend généralement cette décision sous pression. Le produit veut un historique au niveau des événements directs pour de futurs travaux de ML. La finance souhaite des chiffres mensuels fixes qui ne bougeront plus après la clôture. Un mauvais choix ne se contente pas de ralentir un projet. Il engendre des correctifs coûteux dans la conception du stockage, la modélisation, le contrôle d'accès et l'exploitation des pipelines.
La réponse pratique commence par une question : optimisez-vous pour l'évolutivité future ou pour la reproductibilité ?
Choisissez un data lake lorsque les questions futures importent plus que la commodité actuelle
Un lac est un meilleur point de départ si l'entreprise cherche encore à comprendre ce dont elle a besoin en matière de données. Cela signifie généralement de multiples types de sources, des schémas changeants, des exigences de conservation à long terme ou des travaux analytiques dépendant d'un historique très détaillé.
Utilisez un lac lorsque :
Vous devez conserver les détails au niveau de la source provenant de systèmes, de flux d'événements, d'API, de journaux, de documents ou de sorties machine.
Votre modèle d'ingestion change souvent et figer chaque schéma à l'avance créerait des retards et des pipelines fragiles.
Vous soutenez la science des données ou le ML et avez besoin de l'historique brut, pas seulement d'agrégations préparées.
Vous prévoyez des cas d'utilisation secondaires plus tard, tels que la reconstruction d'audits, l'analyse d'anomalies ou le rétro-remplissage (backfilling) de nouveaux modèles d'après d'anciens événements.
Ce choix comporte un coût opérationnel. Les lacs préservent la flexibilité en acceptant plus d'ambiguïté au départ. Si la discipline concernant les métadonnées est faible, les équipes le paient plus tard lors du débogage, du travail de traçabilité et de la confiance dans les données. C'est pourquoi les équipes qui adoptent des lacs ont également besoin de normes claires concernant la propriété, les contrats de données et les dimensions de qualité des données et comment les mesurer à l'échelle.
Choisissez un data mart lorsque l'entreprise a besoin de réponses stables selon un planning défini
Un data mart est adapté lorsque les utilisateurs ne se posent pas de questions analytiques ouvertes. Ils ont besoin d'une vue validée de l'activité avec des définitions acceptées, des mises à jour prévisibles et des performances de requête qui tiennent la route lors des périodes de forte production de rapports.
Utilisez un data mart lorsque :
Une fonction a besoin de métriques gouvernées pour des rapports récurrents, de la planification ou des revues opérationnelles.
Les utilisateurs ont besoin d'accès simples au lieu de devoir recréer des jointures et des logiques métiers par eux-mêmes.
La cohérence sémantique compte plus que l'exhaustivité brute car les décisions dépendent d'une version acceptée d'un KPI.
Le public comprend des utilisateurs non techniques qui ont davantage besoin de confiance dans les résultats que de flexibilité de modélisation.
C'est pourquoi les équipes financières, commerciales et opérationnelles demandent souvent des data marts en priorité. Elles achètent de la clarté et de la stabilité, pas du stockage.
Do not treat a mart as the primary layer for machine learning
Je vois souvent cette erreur. Une équipe dispose déjà d'un data mart propre, elle commence donc par là pour le ML car les tables semblent plus faciles à utiliser. Cette commodité peut subtilement éliminer les signaux bruts qui font l'utilité des modèles.
65 % des entreprises tentent d'utiliser des data marts pour le ML, 20 à 25 % de la diversité des fonctionnalités est perdue lorsque les data marts pré-filtrent les données non structurées, et 40 % des modèles d'IA échouent en raison d'un manque de fonctionnalités lorsqu'ils sont entraînés uniquement sur des données de data mart, selon l'analyse d'Atlan sur le choix entre data mart et data lake pour les charges de travail de ML.
Les data marts ont tout de même un rôle à jouer dans le ML. Ils constituent souvent une bonne couche de service pour restituer les prédictions, distribuer les scores ou exposer des fonctionnalités stables qui ont déjà été validées. Ils remplacent avantageusement le support d'entraînement brut lorsque le modèle dépend de détails comportementaux, de signaux tardifs ou de la découverte de nouvelles fonctionnalités.
En pratique, les équipes matures utilisent les deux et gèrent la dépendance avec soin
La structure la plus solide consiste généralement à placer un lac en amont et des data marts en aval. Le lac conserve l'intégralité des enregistrements. Le data mart publie un modèle plus restreint, prêt pour les besoins métier et destiné à un usage répété.
Cette relation est utile, mais elle est aussi fragile. Un data mart peut sembler soigné tout en héritant de défauts subtils provenant des données brutes stockées en dessous. Si le lac accepte un changement de type, un champ manquant ou un flux retardé sans que cela ne soit détecté, le data mart peut tout de même se mettre à jour avec succès et publier des informations erronées. Choisir les deux est souvent la bonne approche. Les exploiter correctement toutes les deux est la partie la plus difficile.
Le risque invisible : la qualité des données dans votre pipeline de données
La plupart des articles comparant les « data lakes et data marts » commettent une erreur majeure. Ils décrivent les deux comme s'il s'agissait de systèmes isolés.
Ce n'est pas le cas. Dans les déploiements réels, le data mart dépend souvent du lac. Cela signifie que la qualité du lac n'est pas uniquement un problème technique en amont. C'est un enjeu de fiabilité pour l'entreprise.
Où commence l'écart de qualité silencieux
La flexibilité du schéma à la lecture d'un lac est puissante, mais elle crée aussi un point de faiblesse. Un système source ajoute une colonne. Un type passe d'entier à chaîne. Un horodatage commence à arriver dans un autre format. Un flux partenaire commence à accuser du retard. Le pipeline peut continuer à fonctionner et le data mart à se mettre à jour, mais la sémantique des données qui en résultent a changé.
C'est le scénario dangereux. Pas d'échec de tâche visible. Pas de tableau de bord planté. Juste des chiffres faux ou incomplets qui descendent le pipeline avec un indicateur vert.
Un pipeline brisé attire l'attention. Un pipeline réussi contenant des données altérées sémantiquement est pire, car les utilisateurs s'y fient.
Ce n'est pas un cas limite théorique
Les observations issues des pipelines de réutilisation des données de santé rendent le problème difficile à ignorer. Selon les recherches de JMIR Medical Informatics sur les défaillances en aval causées par des modifications de lacs bruts, les changements non surveillés dans les données brutes des lacs, tels que l'ajout de colonnes ou les modifications de types, provoquent 30 à 40 % des défaillances des data marts en aval dans ces environnements.
Ce point est crucial bien au-delà de la santé car le mécanisme est universel. L'ingestion brute change. La logique de transformation repose sur des hypothèses. Les data marts en aval héritent de l'anomalie, parfois de façon bruyante, parfois de façon invisible.
Ce que les équipes doivent surveiller
Les schémas de défaillance apparaissent généralement dans quelques domaines clés :
L'évolution du schéma : Des champs ajoutés, supprimés ou re-typés cassent les transformations ou altèrent les jointures.
La dérive de fraîcheur : Des arrivées tardives en amont produisent des data marts obsolètes qui semblent pourtant valides.
Les décalages de distribution des valeurs : Les taux de valeurs nulles, l'équilibre des catégories ou la répartition des valeurs aberrantes changent suffisamment pour fausser les métriques métier.
Les hypothèses de traçabilité rompues : Une table en amont supposée stable ne correspond plus à ce que la logique en aval attend.
Si votre équipe met en place des contrôles renforcés autour de ces problèmes, une référence pratique sur les dimensions de la qualité des données et la façon de les mesurer à l'échelle aide à structurer ce qui doit être surveillé systématiquement plutôt que vérifié ponctuellement.
Mise en œuvre de l'Observability pour les lacs et les data marts
Une équipe charge de nouvelles données sources dans le lac le lundi, les tâches de nuit restent au vert, et le jeudi, le data mart financier signale une chute de marge qui n'a jamais eu lieu. C'est le problème opérationnel que l'observabilité doit résoudre. Dans une architecture combinant lac et data mart, le statut des tâches ne suffit pas. Les équipes ont besoin de visibilité sur la propagation des changements bruts, sur les points de rupture de la confiance et sur la conformité de la couche ordonnée par rapport à l'activité réelle de l'entreprise.
Ce que l'observabilité doit couvrir dans un lac
La surveillance d'un lac doit composer avec des entrées désordonnées, des métadonnées incomplètes et des données qui arrivent avant que quiconque ne soit d'accord sur leur signification métier finale. Cela transforme le modèle de contrôle. Les vérifications statiques suffisent rarement car le mode de défaillance est souvent un changement de comportement sémantique, et non une erreur bloquante du pipeline.
En pratique, la couche du lac doit surveiller :
Les anomalies d'ingestion de sorte que les chutes, pics ou variations de latence inattendus soient détectés tôt.
La dérive de schéma (schema drift) afin que les ajouts de champs, renommages de colonnes ou modifications de types ne surprennent pas les transformations en aval.
Les problèmes de fraîcheur (timeliness) pour éviter que les retards à l'arrivée ne vieillissent progressivement les data marts qui en dépendent.
Les changements de distribution de sorte que les schémas de valeurs nulles, la répartition des catégories et les comportements aberrants soient analysés avant de déformer les résultats en aval.
L'un des enseignements pratiques tirés de l'exploitation de lacs à grande échelle est que les alertes ont besoin de contexte. L'ajout d'une colonne à une table d'événements bruts peut s'avérer inoffensif. Un changement de type sur une clé de jointure ne l'est généralement pas. Une bonne observabilité sépare le bruit des pannes en reliant les changements bruts à la dépendance et à l'utilisation en aval.
Ce que l'observabilité doit couvrir dans un data mart
Le suivi du data mart commence plus loin dans le pipeline mais comporte des exigences différentes. Les utilisateurs font confiance aux data marts car les données y apparaissent nettoyées, labellisées et prêtes pour la prise de décision. Cela rend les erreurs silencieuses beaucoup plus dangereuses ici que dans la couche brute.
Une bonne surveillance de data mart comprend généralement :
La validation par rapport aux règles métier pour les logiques de champs, les plages de valeurs autorisées et les contraintes obligatoires
Les contrôles des métriques afin que les variations de KPI soient étudiées avant d'arriver dans les réunions de planification ou les rapports de direction
Le suivi de la fraîcheur pour confirmer que chaque data mart respecte sa plage horaire de livraison promise
Les alertes basées sur la traçabilité pour qu'un chiffre erroné puisse être associé à la table en amont, à la transformation ou à l'hypothèse qui l'a causé
De nombreuses implémentations s'avèrent insuffisantes. Elles vérifient que le data mart s'est rafraîchi, mais ne vérifient pas s'il est resté sémantiquement correct après une modification en amont.
Le modèle opérationnel qui fonctionne réellement
L'approche qui résiste en production est l'observabilité multiniveau. Surveillez l'ingestion dans le lac. Surveillez les transformations entre les zones du lac et les modèles de restitution. Surveillez les data marts utilisés par les décideurs. Chaque couche intercepte une catégorie d'anomalie distincte, et les espaces entre les couches sont souvent les endroits où se glissent les mauvaises données.
Exécutez ces vérifications là où résident déjà les données, en particulier dans les environnements réglementés ou sensibles. Copier des données brutes vers une infrastructure de surveillance distincte génère une exposition inutile, des coûts additionnels et un système de plus à maintenir. Les équipes comparant ces démarches doivent comprendre la différence entre les pratiques d'observabilité des données et de qualité des données, car l'une mesure la santé du pipeline tandis que l'autre définit ce que des données "correctes" signifient en contexte réel.
Conseil opérationnel : Si le lac alimente le data mart, vos alertes doivent suivre le même parcours. Vérifiez les transitions, les points de dépendance et les hypothèses sémantiques, et pas seulement les points terminaux.
Si votre équipe a besoin d'un moyen concret pour détecter les anomalies, valider les enregistrements, suivre la fraîcheur et identifier les changements de schémas à la fois dans les lacs et dans les data marts, digna est conçu pour cela. Cet outil exécute ses analyses au sein de votre propre infrastructure, prend en charge les déploiements sur cloud privé comme sur site, et offre aux ingénieurs et aux parties prenantes un tableau de bord unique pour inspecter la santé de la chaîne de traitement avant que des données erronées n'atteignent les rapports, tableaux de bord ou modèles de ML.
