ARCHITECTURE

Data Mesh : l’architecture de données décentralisée

Marie de Vesvrotte
Responsable Marketing
15/7/2024
Sommaire

Qu’est-ce que l’architecture Data Mesh ? 

Le Data Mesh est une approche d’architecture décentralisée qui organise les données par domaines d’activités spécifiques. 

Cette architecture repose sur quatre principes fondamentaux : 

  • Propriété du domaine : chaque domaine de l'organisation est responsable de la gestion et de la qualité des données qu'il produit, assurant une meilleure connaissance et une plus grande responsabilisation.
  • Données en tant que produit : les données sont traitées comme des produits, avec des propriétaires clairs, une documentation complète, et des interfaces bien définies pour garantir leur accessibilité et leur qualité.
  • Infrastructure de plateforme de données en libre-service : fournir aux équipes des outils et des plateformes pour accéder, gérer et utiliser les données de manière autonome, sans dépendre des équipes centrales.
  • Gouvernance fédérée : assurer la conformité et la standardisation des données à travers des politiques et des normes partagées, tout en permettant une certaine flexibilité et autonomie aux domaines individuels.

Le principe de propriété du domaine 

Dans une architecture en Data Mesh, les données sont réparties dans différents domaines correspondant à des activités spécifiques.  Au lieu de centraliser la gestion des données au sein d'une équipe IT ou d'un département centralisé, le Data Mesh confie la responsabilité des données aux équipes qui ont une connaissance approfondie du métier auquel appartiennent les données. 

Chaque domaine dispose de son propre schéma et est géré par des équipes interfonctionnelles autonomes. Ces équipes sont responsables de leurs données, les gèrent, les transforment et les partagent avec d'autres domaines pour générer des éléments exploitables à des fins d’analyse. 

Les équipes de chaque domaine, en tant qu'experts de leurs données, savent où elles sont stockées et comment elles sont traitées. Elles peuvent intégrer plusieurs sources de données dans leur partie du Data Mesh, en utilisant parfois leur propre Data Lake. 

Les données en tant que produit ou Data Product

Ce principe signifie qu'il existe des consommateurs de données au-delà du domaine. Chaque équipe ou domaine de l'organisation est responsable de ses propres données, les traitant comme des produits qu'elles produisent et maintiennent, pour des utilisateurs finaux au sein de l’entreprise. 

C’est pourquoi les produits de données doivent être facilement accessibles et interopérables. Cela signifie qu'ils doivent être bien documentés, standardisés et disponibles via des interfaces bien définies.

Chaque produit doit être :

  • Accessible : être inclus dans un catalogue de données avec des métadonnées détaillées concernant son appartenance et son contenu, permettant aux utilisateurs de trouver et d'accéder facilement aux données nécessaires. 
  • Fiable : définir des objectifs de niveau de service pour assurer la qualité et la disponibilité des données, garantissant ainsi que les données sont prêtes à l'emploi sans nécessiter un nettoyage approfondi.
  • Interopérable : être facilement corrélable avec d'autres produits de données, en suivant des normes et des formats cohérents pour permettre une intégration fluide entre les différents domaines.
  • Sécurisé : être protégé par des mécanismes de contrôle d'accès et des politiques de confidentialité robustes, garantissant que seules les personnes autorisées peuvent accéder aux données sensibles.

La plateforme d'infrastructure de données en libre-service

En masquant la complexité architecturale sous-jacente, la plateforme d'infrastructure de données du Data Mesh vise à offrir une autonomie complète aux équipes de domaines pour créer, gérer et consommer des produits de données, sans dépendre de l'équipe centrale qui s’occupe de construire et maintenir la plateforme. 

Dans une approche traditionnelle de l’architecture de données, le système de stockage devient souvent si difficile à gérer que seules quelques personnes qui le connaissent suffisamment peuvent l’exploiter. Cela conduit certaines équipes à créer leur propre plateforme, plus simple à utiliser. 

L’approche Data Mesh offre une plateforme de données en libre-service indépendante du domaine, où l’équipe centrale fournit un ensemble d'outils standardisés pour l'ingestion, le traitement, le stockage et l'accès aux données. 

Cela permet de personnaliser et d’étendre les capacités de la plateforme en fonction des besoins spécifiques de chaque domaine, tout en empêchant le phénomène de "shadow IT". C’est la garantie que chaque équipe utilise un ensemble d’outils unique et cohérent. Par ailleurs, cela permet également de réduire les dépenses grâce à des licences groupées à prix réduit et à l’optimisation des dépenses cloud sur des ressources coûteuses telles que les entrepôts de données.

La gouvernance fédérée 

Contrairement à une gouvernance centralisée où une seule entité est responsable de toutes les décisions et politiques liées aux données, la gouvernance fédérée répartit ces responsabilités entre plusieurs équipes ou domaines.

Chaque équipe ou domaine de données doit gérer en autonomie ses propres données, y compris la définition, la gestion et l'exploitation de ses produits de données.

Toutefois, bien que chaque domaine soit autonome, des standards et politiques communes sont établis à l'échelle de l'organisation pour assurer une certaine cohérence. Ces standards peuvent inclure des formats de données, des protocoles de sécurité, des pratiques de gestion des métadonnées, et des normes de qualité des données.

Un catalogue centralisé des métadonnées peut être maintenu pour permettre à toutes les équipes de découvrir, comprendre et utiliser les données disponibles à travers l'organisation.

La gouvernance est fédérée, ce qui signifie qu'elle est partagée entre les domaines et les entités centrales, équilibrant autonomie locale et cohérence globale.

Fonctionnement de l’architecture Data Mesh 

Voici une représentation schématique de l’architecture Data Mesh : 

Architecture Data Mesh
Architecture Data Mesh

Ce schéma montre comment l'architecture Data Mesh permet à chaque domaine de produire et de consommer des produits de données de manière décentralisée et interconnectée.

Les domaines dans le Data Mesh
Les domaines de l'architecture Data Mesh

Le diagramme ci-dessus montre comment deux équipes de domaine exploitent ce modèle Data Mesh, la base du modèle étant la plateforme de données en libre-service. Voici une explication détaillée du processus de transformation des données : 

  1. Sources de données : chaque domaine collecte des données brutes de différentes sources (indiquées sur la gauche du diagramme).
  2. Données opérationnelles : ces données brutes sont transformées en données opérationnelles, prêtes à être utilisées pour des analyses ou des processus métier.
  3. Produits de données : les données opérationnelles sont ensuite organisées et transformées en produits de données spécifiques. Ces produits sont standardisés et peuvent être utilisés par d'autres domaines.
  4. Données analytiques : les produits de données sont utilisés pour générer des analyses plus ou moins avancées à travers divers outils (visualisation, analyse ad-hoc, data science…).

Mise en place d’un Data Mesh : considérations à prendre en compte

Limpida vous propose de revenir sur 4 considérations avant de mettre en place un Data Mesh :

  • Taille et exigences de l’entreprise : le Data Mesh est particulièrement adapté pour les entreprises possédant de nombreuses sources de données et domaines diversifiés, car il permet de structurer efficacement les responsabilités et de clarifier les rôles tout en optimisant la collaboration inter-domaines.  Pour les petites entreprises, qui disposent généralement de moins de sources et de domaines, l'implémentation d'un Data Mesh pourrait ne pas être aussi bénéfique et serait potentiellement complexe à gérer. 
  • Objectifs clairs et gains tangibles : pour que la mise en place d’un Data Mesh soit un succès, elle ne doit pas être perçue comme une simple expérience technologique. Il est essentiel que cette initiative génère des gains tangibles pour l’entreprise. Cela nécessite la définition d’objectifs clairs pour les équipes de données, afin de s’assurer que leurs efforts soient alignés avec les attentes de l’entreprise et qu’ils contribuent de manière significative à la performance globale.
  • Coordination et gouvernance des données : bien que le Data Mesh repose sur l’autonomie des domaines, il est important d’assurer une coordination au niveau de la gouvernance des données. Une gouvernance fédérée permet de maintenir la cohérence, la sécurité et la conformité des données à travers tous les domaines. Cette coordination garantit que, malgré l’autonomie des équipes, les données restent interopérables et que les meilleures pratiques sont respectées.
  • Schéma de données distinct pour chaque domaine : chaque domaine doit posséder un schéma de données distinct. Cela permet de définir des frontières claires entre les responsabilités des différents domaines et de faciliter la gestion et l’utilisation des données. Un schéma de données bien défini aide également à prévenir les chevauchements et les conflits, en assurant que chaque domaine comprend et respecte les limites de son propre ensemble de données.

Data Mesh vs Data Lake 

Le débat entre le Data Mesh et le Data Lake repose sur des différences méthodologiques significatives. 

Historiquement, les entreprises utilisaient un entrepôt de données centralisé pour répondre à leurs besoins en matière de données. Cette approche, bien que fonctionnelle, a généré une dette technique importante et a mis une pression excessive sur l’équipe responsable des données.

Le Data Lake a émergé comme une solution pour offrir des données en temps réel et traiter des flux de données sans augmenter la charge de travail des équipes de données. Il permet d'ingérer, enrichir, transformer et diffuser les données depuis une plateforme centralisée, avec une dette technique limitée. Cependant, avec l'augmentation du volume de données et des cas d'utilisation, même le Data Lake a montré ses limites. Les lacs de données diminuent le contrôle des équipes sur les données à mesure que leur volume augmente. 

C'est ici que le Data Mesh entre en jeu, en proposant une architecture orientée domaine qui combine les avantages des lacs de données distribués et la gestion autonome des pipelines par chaque domaine d'activité. Cette approche permet de limiter la dette technologique tout en offrant une plus grande agilité et autonomie aux équipes.

Pour la consommation des données, le Data Lake repose sur l'équipe de données pour opérationnaliser et fournir les données aux équipes fonctionnelles. Le Data Mesh, quant à lui, favorise le libre-service, permettant aux utilisateurs de se concentrer sur l'exploitation des données pour leurs besoins spécifiques sans dépendre d'une équipe centrale. Cette autonomie réduit la complexité technique pour les utilisateurs finaux et facilite l'expérimentation.

Enfin, le Data Lake est plus simple à gérer en matière de gouvernance des données puisque une seule équipe est responsable de cette dernière. Le Data Mesh demande une collaboration et un alignement sur des pratiques de qualité et des accords de niveau de service pour protéger les consommateurs de données en aval.

Pour résumer les différences entre ces deux approches, voici un récapitulatif : 

Critère Data Mesh Data Lake
Architecture Architecture distribuée avec des microservices et des API Architecture monolithique centralisée
Responsabilité Chaque domaine (équipe) est responsable de ses propres pipelines de données Équipe centralisée gère tous les pipelines de données
Propriété des données Les domaines possèdent et gèrent leurs propres ensembles de données Les données sont centralisées et gérées par une équipe unique
Gouvernance des données Gouvernance fédérée, chaque domaine suit des principes communs mais a une autonomie Gouvernance centralisée stricte
Modélisation des données Modèles de données définis par domaine, souvent avec des modèles de domaine partagés Modélisation centralisée des données, souvent un modèle global
Compétences requises Compétences en gestion de données et architecture distribuée dans chaque équipe de domaine Compétences en gestion de grands volumes de données centralisées
Stockage des données Données stockées de manière décentralisée, souvent dans des datastores spécifiques à chaque domaine Données stockées de manière centralisée dans un Data Lake
Intégration des données Intégration via des API et des contrats de données entre domaines Intégration centralisée des données brutes dans le Data Lake
Flexibilité Très flexible, chaque domaine peut adopter les technologies et les processus qui conviennent le mieux Moins flexible, une seule solution pour tous les types de données
Cas d'utilisation typiques Grandes entreprises avec des équipes de données multiples et des besoins diversifiés Entreprises cherchant à centraliser et analyser toutes leurs données brutes

Data Fabric vs Data Mesh 

Le Data Mesh considère les données comme un produit, visant à simplifier l'accès pour les équipes internes et les utilisateurs finaux. Cette approche réduit les barrières techniques et les frictions d'accès aux données, les rendant faciles à trouver et à utiliser. La Data Fabric adopte quant à elle une approche automatisée et centrée sur la technologie, ce qui la rend plus complexe à mettre en place et à comprendre pour ceux qui n'ont pas de compétences techniques en matière de données.

Le Data Mesh suit une philosophie décentralisée, créant plusieurs systèmes spécifiques à chaque domaine d'utilisation. Chaque domaine contrôle son propre jeu de données. En contraste, la Data Fabric unifie diverses sources de données en un seul système virtuel centralisé, accessible via des API. Cette différence d'architecture impacte l'accès aux données, le Data Mesh permettant un contrôle localisé par domaine, tandis que la Data Fabric centralise l'accès.

Le Data Mesh implique la contribution de chaque domaine, offrant une gouvernance plus participative où chaque service définit ses propres règles et contrôle ses flux de données. En revanche, la Data Fabric impose une gouvernance descendante, où une autorité centrale définit et applique les politiques de données.

Vous pouvez choisir l'une ou l'autre approche en fonction de vos besoins spécifiques, ou même combiner les deux pour tirer parti des avantages de chacune. L'option que vous choisissez dépendra en grande partie de votre stratégie de données et de votre facilité à démocratiser les données au sein de votre organisation. 

Cas d’utilisation d’un Data Mesh 

Le concept de Data Mesh vise à répondre aux défis de l'échelle, de la complexité et de l'accessibilité des données dans les grandes organisations. 

Voici quelques cas d'utilisation typiques du Data Mesh :

  • Une grande entreprise avec plusieurs départements et divisions ayant besoin d'accéder et d'analyser des données spécifiques à leur domaine (finance, marketing, vente…) sans dépendre d'une équipe centrale de données.
  • Une entreprise technologique cherchant à accélérer le développement de nouveaux produits et services en utilisant des données provenant de diverses sources.
  • Une organisation confrontée à des problèmes de qualité des données dus à une centralisation excessive et à des silos de données.
  • Une entreprise en croissance rapide dont les besoins en données et les volumes de données augmentent de manière exponentielle.
  • Une entreprise opérant dans un secteur fortement réglementé ayant besoin de s'assurer que les données sont conformes aux normes de sécurité et de confidentialité.
  • Une entreprise de commerce cherchant à personnaliser les expériences clients en temps réel en utilisant des données comportementales.
FAQ

Les questions fréquentes

Qu'est-ce que le Data Mesh ? +

Le Data Mesh est une architecture de données distribuée intentionnellement conçue, sous gouvernance centralisée et standardisée pour l'interopérabilité, rendue possible par une infrastructure de données en libre-service partagée. Plutôt que de centraliser toute la donnée dans une plateforme unique, chaque domaine métier devient responsable de ses propres données.

  • Architecture décentralisée orientée domaine plutôt que monolithique.
  • Chaque équipe métier traite ses données comme un produit destiné à d'autres consommateurs internes.
  • La gouvernance reste centralisée pour assurer l'interopérabilité et la conformité.
  • Une plateforme self-service permet aux équipes d'opérer leurs données sans dépendre d'une équipe centrale.
Quels sont les principes fondamentaux du Data Mesh ? +

Le Data Mesh repose sur quatre principes clés énoncés par Zhamak Dehghani chez ThoughtWorks, qui changent radicalement la donne par rapport aux architectures centralisées. Ils sont collectivement nécessaires et suffisants : retirer l'un dénature l'approche.

  • Propriété orientée domaine : chaque domaine métier (finance, marketing, vente) gère ses propres données.
  • Données comme produit : les données sont traitées avec des propriétaires clairs, une documentation et des interfaces définies.
  • Plateforme self-service : les équipes accèdent et gèrent leurs données en autonomie sans dépendre des équipes centrales.
  • Gouvernance fédérée : conformité et standardisation assurées via des politiques partagées, avec autonomie laissée aux domaines.
Qu'est-ce qu'un Data Product dans le Data Mesh ? +

Un Data Product est l'unité de base du Data Mesh : un composant autonome qui regroupe des données, leur documentation et leurs interfaces de consommation. Chaque équipe ou domaine est responsable de ses propres Data Products, qu'elle produit et maintient pour des utilisateurs finaux internes.

  • Découvrable : inclus dans un catalogue de données avec des métadonnées détaillées.
  • Accessible : disponible via des interfaces bien définies, exploitables par les consommateurs.
  • Interopérable : facilement corrélable avec d'autres produits de données via des normes communes.
  • Documenté : son contenu, ses règles de qualité et son propriétaire sont clairement identifiables.
  • Versionné : ses évolutions sont tracées et n'impactent pas les consommateurs sans préavis.
Quelle est la différence entre Data Mesh et Data Lake ? +

Data Mesh et Data Lake reposent sur des différences méthodologiques significatives. Historiquement, les entreprises utilisaient un entrepôt centralisé qui générait une dette technique importante et une pression excessive sur l'équipe centrale. Le Data Mesh propose une architecture orientée domaine.

  • Centralisation : le Data Lake centralise les données dans un seul référentiel, le Data Mesh les distribue par domaine.
  • Consommation : le Data Lake repose sur une équipe data centrale pour servir les métiers, le Data Mesh favorise le libre-service.
  • Gouvernance : centralisée et plus simple pour le Data Lake, fédérée et distribuée pour le Data Mesh.
  • Schéma par domaine : le Data Mesh impose un schéma distinct par domaine pour clarifier les responsabilités.
  • Dette technique : le Data Mesh limite la dette en évitant la concentration sur une seule équipe.
Quelle est la différence entre Data Mesh et Data Fabric ? +

Data Mesh et Data Fabric répondent à des philosophies opposées de la gouvernance des données, même si elles peuvent coexister dans certaines organisations. Le choix dépend de la stratégie data et de la facilité de l'organisation à démocratiser la donnée.

  • Architecture : décentralisée par domaine pour le Data Mesh, centralisée et virtuelle pour la Data Fabric.
  • Accès aux données : contrôle localisé par domaine pour le Data Mesh, accès unifié via API pour la Data Fabric.
  • Gouvernance : participative et fédérée pour le Data Mesh, descendante pour la Data Fabric.
  • Technologie : approche organisationnelle et orientée domaine pour le Data Mesh, approche automatisée et centrée technologie pour la Data Fabric.
  • Les deux approches peuvent être combinées pour tirer parti de leurs avantages respectifs.
Quels sont les cas d'usage typiques du Data Mesh ? +

Le concept de Data Mesh vise à répondre aux défis de l'échelle, de la complexité et de l'accessibilité des données dans les grandes organisations. Il ne s'applique pas indifféremment à toutes les structures, mais cible des contextes précis où la centralisation montre ses limites.

  • Grandes entreprises avec plusieurs départements ayant besoin de données spécifiques à leur domaine (finance, marketing, vente).
  • Organisations dont l'équipe data centrale est devenue un goulot d'étranglement.
  • Structures avec de nombreuses sources de données hétérogènes difficiles à modéliser dans un schéma unique.
  • Contextes où les besoins métiers évoluent vite et exigent autonomie et réactivité.
  • Organisations souhaitant diffuser la culture data en responsabilisant les équipes métiers.
Quand mettre en place un Data Mesh ? +

Le Data Mesh n'est pas adapté à toutes les organisations. Limpida recommande de passer en revue quatre considérations avant de se lancer pour éviter une implémentation contre-productive ou inutilement complexe.

  • Taille et exigences : le Data Mesh est particulièrement adapté aux entreprises avec de nombreuses sources et domaines diversifiés.
  • Objectifs clairs : l'initiative doit générer des gains tangibles, pas être une simple expérience technologique.
  • Maturité data : les équipes doivent être capables d'assumer la propriété de leurs données.
  • Investissement plateforme : le self-service exige une infrastructure technique solide en amont.
  • Pour les petites entreprises avec peu de sources, l'implémentation peut être complexe à gérer sans bénéfice clair.
Quels sont les pièges et défis du Data Mesh ? +

La décentralisation portée par le Data Mesh n'est pas sans risques. Les organisations qui se lancent sans cadre s'exposent à plusieurs écueils qui peuvent annuler les bénéfices attendus de l'approche.

  • Sous-estimation de l'investissement plateforme : sans self-service robuste, le modèle ne tient pas à l'échelle.
  • Gouvernance fédérée mal cadrée : risque de divergences entre domaines et perte d'interopérabilité.
  • Compétences hétérogènes : tous les domaines n'ont pas la maturité data nécessaire pour devenir Data Product Owners.
  • Confusion entre Data Mesh et simple décentralisation organisationnelle : l'approche est sociotechnique, pas juste technique.
  • Adoption précipitée dans des organisations trop petites où la centralisation reste plus efficace.