Une stratégie de gestion des données décentralisée, en libre-service et axée sur le domaine. Définition, avantages et inconvénients du Data Mesh. Faisons le tour de la question.
[Un article rédigé par Alexis Mckenzie qui nous a très aimablement autorisé à le traduire]
Cet article a été originellement publié ici
Comment les Data Warehouses devraient-ils évoluer dans un monde de big data en évolution rapide ? Image de John Do
Le Data Mesh est un nouveau paradigme qui permet des stratégies de données inspirées des meilleures pratiques d’ingénierie logicielle telles que l’architecture de microservices. Mais cette approche est-elle adaptée pour les données ?
Le concept originel a été proposé par Zhamak Dehghani, qui a affirmé qu’une approche des données en libre-service axée sur le domaine était la voie à suivre – traduction : une approche produit des données, collectées et constamment évaluées pour s’assurer qu’elles soient pertinentes, valorisables et effectivement utilisées.
Ce paradigme se juxtapose à un système legacy monolithique contenant toutes les données de l’entreprise. Le Data Mesh de son côté, offre une approche décentralisée de la gestion des données en les mettant à disposition des personnes qui en ont l’usage.
Dans cet article, nous discuterons des avantages et des inconvénients du Data Mesh ainsi que des mesures que les organisations peuvent prendre pour améliorer leurs stratégies. Mon avis est que cette approche aurait déjà dû se démocratiser depuis longtemps, mais il est nécessaire de procéder avec prudence et d’apporter quelques adaptations au concept original.
Aller trop vite vers cette nouvelle méthodologie sans ancrage dans les organisations serait passer à côté du point. À mesure que les données accélèrent, il faut les manager de la manière la plus modulaire et agile possible. C’est un défi, car les données sont intrinsèquement moins agiles que les logiciels pour deux raisons :
1 – toute modification mineure apportée à un modèle de données a un impact en cascade ;
2 – la plupart des entreprises ont créé des entrepôts de données immenses et complexes. Il faut du temps et de la collaboration pour créer des modèles de données bien pensés qui restituent correctement les informations brutes et leur granularité à travers l’organisation.
Qu’est-ce qu’un Data Mesh ?
Un Data Mesh c’est de la conception pilotée par le domaine (ou DDD, de l’anglais domain-driven design) pour les données ! Avec cette approche DDD, la structure des datas est déterminée par les domaines d’une organisation, de sorte que chaque domaine en façonne l’organisation et la logique.
Étant donné que les datas sont considérées en tant qu’entités et attributs, tous deux naturellement axés sur le domaine, DDD a au moins autant de sens ici que pour l’ingénierie logicielle. Le Data Mesh de Zhamak applique l’approche Produit aux données, dont les produits sont des API. La data se doit d’être clairement définie et documentée, c’est-à-dire « découvrable ».
Le Data Mesh a beaucoup en commun avec les Data Marts (magasins de données ou comptoirs de données) traditionnels qui s’appuient sur des Data Warehouses souvent pilotés par domaine et managés par une petite équipe de manière agile. Ils permettent de répondre à des questions stratégiques spécifiques et de générer des insights.
Comment les principes FAIR peuvent-ils aider ?
Les principes FAIR (voir l’illustration ci-dessous) sont conformes aux objectifs du Data Mesh et fournissent des composants clairs à valider lors de sa construction.
Image de John Do
Ces principes garantissent que les modèles de données et les dictionnaires pour une source particulière peuvent être trouvés dans un emplacement central (Findable), et que les modalités d’accès et les prérequis soient clairement documentés avec des explications sur la façon de demander l’accès à une source de données (Accessible). L’accès doit être réservé à des personnes formées à HIPAA ou PII (Personally identifiable information) ou être limité à certains employés ou fonctions particulières. L’essentiel ici est simplement que les modalités et les restrictions d’accès ne soient pas un mystère pour les employés ou les utilisateurs.
Le composant « Interoperable » exige que la mécanique de traduction entre les différentes sources de données soit claire. Par exemple, s’il existe un domaine pour les clients, un domaine pour les commandes et un domaine pour les fournisseurs, la documentation du domaine commandes doit clairement indiquer comment se connecter aux domaines clients et fournisseurs. En bref, l’interopérabilité garantit que les utilisateurs puissent se connecter à des domaines depuis d’autres domaines.
Enfin, le composant « Reusable » rassemble tous les composants. L’intérêt d’en créer un est de pouvoir réutiliser les composants dans des applications, des outils et des rapports.
Avantages des Data Warehouses
Les Data Warehouses offrent une vue complète des données de l’entreprise. Deux principales écoles de pensée existent dans ce domaine : l’approche Inmon Enterprise Data Warehouse (EDW) et l’approche de modélisation dimensionnelle Kimball.
Les EDW permettent des écritures rapides et les modèles traditionnels Extract, Load et Transform (ELT). La modélisation dimensionnelle a apporté des lectures plus rapides et une approche moins normalisée. Les nouveaux Data Warehouses cloud comme Redshift ou Azure Synapse facilitent le suivi d’une approche ELT quand le Data Warehouse lui-même est utilisé pour effectuer des transformations. Ce qui permet de maintenir un certain niveau de flexibilité des Data Warehouses, en particulier les plus récents sur le marché.
Inconvénients des Data Warehouses
Si vous avez déjà travaillé sur un grand Data Warehouse monolithique, vous savez combien il est difficile de changer une logique métier, d’incorporer de nouvelles données ou de compenser des failles dans ces dernières. C’est lent, c’est lourd, et il faut un certain temps pour que l’entreprise en perçoive les résultats. Souvent, il faut s’appuyer sur le sénior expérimenté de l’équipe qui a travaillé sur la conception initiale pour comprendre la complexité des données. Si celui-ci gagnait à la loterie, prenait sa retraite ou quittait l’organisation, une grande partie de cette connaissance serait perdue. Au cours de ma carrière, j’ai vu de nombreux Data Warehouses avec un faible facteur d’autobus (de l’anglais bus factor, aussi appelé truck factor ou lottery number) peut-être parce qu’il y a tellement de choses à savoir…
Les EDW ont été conçus pour héberger des données disparates de manière normalisée pour pallier un stockage coûteux et bénéficier de capacités de calcul moins chères (en comparaison). La normalisation garantit l’absence de redondance et des écritures rapides, mais elle a un revers : des jointures et des lectures coûteuses. Les approches modernes du stockage de données tendent à s’éloigner de la normalisation complète. Cela signifie qu’il suffit généralement de passer à la première ou à la deuxième forme normale et qu’il n’est pas nécessaire de forcer vos données à se conformer à la 6NF ou DKNF (sixième forme normale ou forme normale de clé de domaine).
Outre l’approche EDW de la modélisation des données, la modélisation dimensionnelle est aussi une technique utilisée dans l’entreposage de données.
Les points de vigilance à avoir en tête avec le Data Mesh
Le manque de propriété claire sur les données peut être un énorme problème. Avoir quelques datas répliquées n’est pas nécessairement un problème, mais sans une propriété clairement attribuée à une équipe, le niveau de réplication peut augmenter. Sans propriété claire, vous obtenez potentiellement des réponses différentes aux mêmes questions en examinant vos différents Data Products.
Si vous posez la même question aux personnes de votre organisation et obtenez des réponses différentes, cela indique que votre stratégie de données a un problème. Ces échecs de stratégie résultent généralement d’une mauvaise gestion, et non d’erreurs d’ingénierie.
J’ai vu des équipes concurrentes calculer et faire les mêmes prédictions à partir de systèmes de bases de données construits par ces mêmes équipes. Une bonne option pourrait être la création d’une solution commune où les équipes d’ingénierie travaillent avec le métier pour établir des définitions communes et chercher à résoudre les conflits entre les systèmes sources concurrents. Mais la création d’une solution commune et d’une source vérifiée et sûre nécessite qu’elle soit prise en charge par une équipe clairement identifiée.
Les bénéfices potentiels d’une approche Data Mesh ?
Lorsqu’il est implémenté correctement, le Data Mesh définit clairement qui possède les données et donc qui peut contribuer à ajouter des fonctionnalités supplémentaires, fournir plus d’informations sur les écarts et les irrégularités, et travailler avec les équipes commerciales et logicielles pour combler les écarts.
Les données sont réparties en domaines qui n’ont pas besoin d’être, et dans la plupart des cas ne doivent pas être complètement normalisés. Des données 100% normalisées ne sont plus nécessaires aujourd’hui, car non seulement le stockage est bon marché, mais la normalisation complexifie la jointure pour les usages en Business Intelligence (BI) et en analyse avancée. Au lieu de cela, dans la plupart des équipes avec lesquelles j’ai travaillé, nous avons opté pour un schéma plus « starflake »: une combinaison de “flocons de neige” et “d’étoiles”. Cela nous a permis de répondre aux besoins d’autres équipes de développement, de réaliser des analyses avancées et de remonter des cas d’usage.
Dans un second article sur le Data Mesh à paraître mercredi prochain sur notre blog, nous aborderons comment cette approche se traduit d’un point de vue opérationnel, et comment migrer ?
{{cta(’75c19cbf-9575-4604-8ca3-ebb91649dbff’)}}
