Le data mesh et l’avenir des architectures de données d’entreprise

Qu’est-ce que le data mesh et comment fonctionne-t-il ?

Un data mesh, également appelé maillage de données, est un modèle d’écosystème de données organisé autour de domaines d’activité. Il est régi par des fonctionnalités en libre-service qui permettent aux équipes interfonctionnelles de gérer, de servir et, en définitive, de prendre possession des données dans leurs domaines. Il peut générer des produits de données distincts qui éclairent les processus et les décisions cruciales de l’entreprise.

Les trois principaux composants d’un data mesh

1. Une propriété des données orientée domaine avec une gouvernance fédérée

Dans une architecture en data mesh, les données résident principalement au sein de l’infrastructure de différents domaines, ou sujets, qui correspondent à des préoccupations commerciales distinctes, telles que les ventes ou le support client. Chaque domaine peut avoir son propre schéma.

Les équipes interfonctionnelles, qui comprennent des chefs de produit, des développeurs, des analystes commerciaux et d’autres personnes au sein de chacun de ces domaines fonctionnant de manière autonome, travaillent avec leurs propres données et les partagent avec d’autres domaines selon les besoins. Ces équipes sont des experts de l'emplacement où leurs données sont stockées et de la manière dont elles sont chargées et de les transformées. Ils peuvent connecter plusieurs sources de données à leur section du data mesh, en utilisant parfois leur propre data lake ou un hub de données dédié.

Chaque équipe peut disposer de sa propre infrastructure physique de data mesh pour gérer les données de son domaine. Cependant, la colocalisation de plusieurs schémas peut également être efficace, en particulier pour les ensembles de données de différents domaines qui sont fréquemment joints les uns aux autres : ils fonctionnent mieux s’ils sont stockés dans la même base de données. Par conséquent, un data mesh peut prendre la forme d'une architecture de données d’entreprise physique ou logique.

Même si la propriété est divisée par domaine, la gouvernance fédérée permet d’éviter que le système ne devienne ingérable. Les normes d’interopérabilité et de qualité des données, ainsi que la culture DevOps, garantissent cette gouvernance des données.

2. La pensée produit appliquée aux des ensembles de données

Étant donné que chaque domaine d’activité constitue une unité distincte, il existe des risques associés à la fragmentation des données par domaine, au point de mettre en péril la perspective d’une collaboration efficace au sein de l’entreprise. C’est là que le concept de product thinking, ou de pensée produit, appliqué aux ensembles de données d’une entreprise fait la différence en libérant toute la valeur d’un data mesh.

Chaque équipe appartenant à un domaine donné doit considérer ses ressources en matière de données comme les composants d’un produit de données dont les utilisateurs au sein de l'entreprise, comme les développeurs ou les data scientists, qui ont besoin d’y accéder facliement et de manière sécurisée sont les « clients ». Par exemple, un ingénieur de données spécialisé en intelligence artificielle (IA) peut avoir besoin de données d'analyses issues d’un programme exécuté au sein d'un système de dossiers patients électroniques afin d'améliorer les algorithmes de ce logiciel.

Un data mesh est capable d'offrir ce niveau de commodité sur l'ensemble de l’entreprise grâce à des produits de données cohérents. Chaque produit doit être :

• Accessible : Un produit de données est inclus dans un catalogue de données qui inclut des métadonnées concernant son appartenance et son contenu. Cette configuration aide les utilisateurs à trouver ce dont ils ont besoin de manière fiable.
• Adressable : Chaque produit accessible doit également être distinguable afin qu’il puisse ensuite être adressé. Des normes cohérentes pour un accès programmatique de ce type sont essentielles dans les environnements qui comprennent une grande variété de formats de données, des CSV aux buckets de cloud public.
• Fiable : Les plateformes de data mesh sont destinées à définir des objectifs de niveau de service pour les responsables de données de domaine, en régissant la fiabilité de leurs produits de données. Ces produits ne doivent pas nécessiter le même niveau de nettoyage approfondi que les données communes contenues dans une architecture de données plus traditionnelle et strictement centralisée.
• Facilement définissable : Un produit de données doit posséder une sémantique, une syntaxe et des schémas de base de données clairs aux yeux des consommateurs de données. « Comment puis-je réellement l’exploiter ? » ne devrait que rarement, voire jamais, être une question lorsque l'utilisateur travaille au sein d'un data mesh.
• Interopérable : Les produits de données d’un data mesh doivent être corrélables entre les domaines. Les associer, par exemple, devrait être simple et ne pas être entravé par des différences entre les champs ou les formats de métadonnées.

Il est important de considérer un data mesh comme l’équivalent de la gestion des données d’entreprise d’une union douanière, à l'image de l’UE. Chaque pays est sa propre entité autonome, mais adhère simultanément à certaines normes générales pour l’échange de produits et de services avec les autres membres. De la même manière, les équipes responsables de données par domaine travaillent de manière indépendante, mais suivent également des « règles » globales pour définir les caractéristiques de leurs produits de données respectifs.

3. Le libre-service via l’infrastructure de données en tant que plateforme

Le modèle de distribution d’un data mesh semble impliquer l'existence de nombreux pipelines de données et d'infrastructures de stockage redondants, un pour chaque domaine. Cette configuration créerait des complications techniques qui empêcheraient d'obtenir des informations exploitables rapidement. Ce problème peut être contourné grâce à une plateforme d’infrastructure de données agnostique pour chaque domaine qui offre le même niveau de libre-service à chaque équipe de l’entreprise.

Une telle plateforme de données cache la complexité sous-jacente et rationalise les processus de stockage, de traitement et de service relatifs aux produits de données. Parmi les tendances actuelles du cloud et dans le monde du multi-cloud dans lesquels évoluent désormais de nombreuses entreprises, un data mesh devrait permettre :

• L'ingestion de n’importe quelle source de données distribuée, sous n’importe quel format, tout en demeurant évolutif dans toutes les dimensions - concernant le volume de données ou la complexité d’une requête, par exemple, ou encore la sophistication du schéma de données.
• Le choix du cloud, afin que les entreprises puissent avoir recours aux fournisseurs de services cloud dont les écosystèmes d’analyse répondent le mieux aux exigences actuelles en matière de performances et de tarifs.
• La prise en charge de déploiements hybrides qui incluent les ressources sur site et les services de cloud public.
• Une conception ouverte qui donnne la possibilité aux équipes d’utiliser leurs propres bibliothèques, les langages qu’elles connaissent (SQL, R, etc.) et des API bien documentées lors de la création de leurs produits de données de domaine.
• L'intégration de l’IA et du machine learning (ML) afin d'accélérer les analyses avancées à partir de données distribuées.
• La séparation de la puissance de calcul et du stockage, afin de répondre de manière dynamique aux exigences des utilisateurs sans avoir besoin de l'intervention du service informatique ou que celui-ci ne gaspille ses capacités.
• La mise en place de commandes simples pour gérer des charges de travail mixtes et respecter les accords de niveau de service sur de multiples applications.

Pourquoi choisir le data mesh ? Comment se compare-t-il à d’autres architectures de données ?

Dans l’ensemble, un data mesh offre une agilité accrue pour les équipes qui travaillent dans le cloud avec un éventail de plus en plus grande de sources de données et de projets axés sur l’innovation.

Dans un monde avec relativement peu de sources de données et un ensemble restreint de cas d’usage au sein de l’entreprisees, les architectures de données traditionnelles étaient suffisantes. Cependant, ces modèles centralisés peuvent désormais être à l'origine de goulots d’étranglement pour les équipes qui doivent passer rapidement des sources de données brutes aux informations.

Il suffit d'imaginer le cas de l'hypothétique ingénieur de données spécialisé en IA qui travaille sur des systèmes de dossiers patients et a besoin de créer un nouveau produit de données pour répondre à l'évolution rapide des exigences commerciales. Il serait probablement ralenti parce qu’il ne serait pas en mesure de changer des composants relativement petits et distincts pour ingérer et traiter les données par lui-même - il se verrait ainsi forcé d'impliquer d’autres personnes et de modifier l’ensemble du pipeline de données.

Ce scénario est la raison pour laquelle les architectures de données plus anciennes sont souvent décrites comme « monolithiques » – en modifier une partie signifie tout transformer. A contrario, les plateformes de data mesh ressemblent davantage à des architectures de microservices, avec des composants qui peuvent être mis à jour individuellement et être utilisés par plusieurs équipes.

La flexibilité et l’agilité réalisables du data mesh sont ce qui le distingue des autres architectures de données qui reposent exclusivement sur des entrepôts de données centralisés et des data lake.

Entrepôt de données, data lake, data lakehouse et data mesh

Ces quatre modèles de conception de données ne s’excluent pas mutuellement : ils peuvent coexister au sein d'une entreprise, par exemple si celle-ci est dotée d'une équipe interfonctionnelle entre plusieurs domaines qui possède son propre data lake. Cependant, il est possible de retracer l'évolution depuis l’entrepôt de données jusqu'au data mesh, en passant par le data lake, laquelle est motivée par la nécessité de surmonter certaines limitations architecturales.

Entrepôt de données

• Définition : Architecture de données orientée sujet qui intègre des données détaillées de manière cohérente tout en conservant un historique stable.
• Avantages: Génère des informations exploitables (à l'aide de tableaux de bord, par exemple) à partir de vastes quantités de données organisées, y compris la mise au point d’analyses prédictives et de tableaux de bord qui pilotent les opérations. Il agrège les données issues de toutes les sources de l’entreprise au sein d'un emplacement central à l'aide d'une gouvernance cohérente et prend en charge les sandboxes pour tester de nouvelles idées.
• Limites : Pas idéal pour les cas d’usage liés au Big Data qui nécessitent le stockage et l’extraction de valeur à partir de vastes quantités de données brutes, à l'image de celles qui sont générées par les appareils IoT et les sources web et mobiles.

Data lake

• Définition : Ensemble de conteneurs de données de long terme destiné à la gestion et à l’affinement de données brutes, grâce au stockage objet à moindre coût souvent fourni dans le cloud.
• Avantages : Capture les dark data précédemment rejetées pour stimuler l’innovation plus tard et stocke les données telles quelles sans avoir à les structurer au préalable. Le data lake permet également de capturer efficacement des informations à l'aide de services d’IA et de machine learning qui analysent les informations brutes.
• Limites : Relativement peu d’outils prêts à l’emploi sont disponibles pour les data lakes, ce qui nécessite une expérience significative des logiciels open source. Il existe également un risque élevé de création de silos en raison d’une gouvernance limitée et il peut être très difficile d’équilibrer sécurité et facilité d’accès.

Data lakehouse

• Définition : Combinaison d’un entrepôt de données et d’un data lake.
• Avantages : Permet à une entreprise d’extraire systématiquement les informations sous le mode entrepôt de données (via un moteur SQL, de machine learning ou tout autre processus) tout en tirant parti de l'échelle et des faibles coûts d’un data lake.
• Limites : Agilité limitée pour l’ajout de nouvelles fonctionnalités, car tout est centralisé et monolithique. Les ingénieurs de données finissent par passer beaucoup de temps à nettoyer les données des équipes qui n'ont pas d'intérêt à s’assurer que leurs informations sont exactes au fur et à mesure qu’elles sont intégrées.

Data mesh

• Définition : Modèle de conception de données piloté par domaine et réparti logiquement ou physiquement entre les équipes qui oeuvrent dans ces domaines.
• Avantages: Le data mesh permetla gestion active autonome des données par les équipes les plus pertinentes et permet une agilité accrue, car il ne crée pas de goulot d’étranglement central. Chaque équipe est en mesure de créer ses propres produits de données.
• Limites : Il s'agit d'une architecture relativement nouvelle que les entreprises sont encore en train de mettre en place. Les performances et la gouvernance peuvent en souffrir, car les utilisateurs doivent passer par le réseau à chaque fois qu'ils souhaitent accéder aux données. Sans gouvernance inter-domaines ni liaison sémantique des données, celles-ci peuvent devenir très cloisonnées et donner des résultats décevants.

Trois raisons pour lesquelles le data mesh est peut-être l’architecture de données de demain

Malgré ces limites, le data mesh pourrait devenir l’architecture de données de demain pour trois raisons principales :

1. Agilité accrue et évolutivité organisationnelle supérieure

Le data mesh permet aux équipes d’accéder aux données et de les exploiter sous leurs propres conditions, sans avoir à passer par le goulot d’étranglement d’un entrepôt de données ou d’un data lake unique et centralisé à l’échelle de l’entreprise. Ils peuvent utiliser leurs propres entrepôts et data lakes comme des nœuds dans le data mesh, charger et interroger leurs données de domaine et créer des produits de données plus rapidement.

Les ingénieurs de données ne portent plus le fardeau de trier toutes les informations disparates qui sont déversées dans un entrepôt de données ou un data lake central, car les données sont gérées au sein de nombreux domaines plus restreints. Ainsi, tous les membres de l’entreprise peuvent réagir plus rapidement aux changements et faire évoluer leurs charges de travail si nécessaire à l’aide d’une plateforme d’infrastructure de données en libre-service.

2. Propriété et responsabilité des données claires

Avant l’émergence du data mesh, la propriété des données d’entreprise était souvent peu définie, voire contestée. Les équipes opérationnelles dans différents domaines envoyaient leurs données sur un emplacement centralisé, où elles étaient gérées par des ingénieurs de données spécialisés et isolés du reste de l’organisation.

Ces ingénieurs ont dû faire face à la tâche difficile de travailler avec des données provenant de domaines dans lesquels ils n’étaient pas nécessairement experts. Ils ont également servi d’intermédiaires entre les équipes de différents domaines travaillant sur le même projet, pour créer des ensembles de données exploitables par chacun.

Dans un data mesh, la propriété est clairement définie, en raison de sa conception orientée domaine. Les équipes peuvent adopter une approche de service et d’extraction – plutôt que la méthode traditionnelle push and ingest décrite ci-dessus – selon laquelle différentes équipes travaillent dans les domaines qu’elles connaissent, rendent les produits de données disponibles à l'ensemble de l’entreprise et accèdent aux produits d’autres équipes selon les besoins.

3. Amélioration de la qualité des données et culture DevOps

Étant donné que la propriété des données est clairement définie dans un data mesh, les équipes sont davantage incitées à garantir la qualité de leurs produits de données avant de les rendre accessible de manière distribuée. La qualité est encore améliorée par la connexion étroite du concept de data mesh avec les principes fondamentaux de DevOps.

Les DevOps mettent l’accent sur la collaboration par le biais d’équipes interfonctionnelles, ainsi que sur le monitoring et l'amélioration continus des produits. Lorsque les principes DevOps, tels que la décomposition du travail en plus petites parties qui sont plus faciles à gérer et la création d’une vision de produit partagée, sont appliqués au sein d'un data mesh, les différents composants de l’architecture de données sont plus faciles à utiliser, à itérer et à maintenir.

Des produits de données de meilleure qualité peuvent alors être créés plus rapidement qu’auparavant. Tout comme les DevOps sont un mouvement culturel autant que technique, un data mesh nécessite la mise en place d'une culture adaptée – une culture qui met l’accent sur la responsabilité et la collaboration – pour que ses technologies profitent à l’entreprise. Les DevOps eux-mêmes contribuent à ce changement culturel.

Mise en place d’un data mesh : considérations essentielles avant de commencer

Avant de se lancer dans le data mesh, les entreprises doivent d’abord prendre en compte quelques considérations essentielles :

Taille et exigences de l’entreprise

Le data mesh est la solution idéale pour les grandes entreprises qui diposent de nombreuses sources et domaines, où il existe des frictions potentielles entre les équipes pour savoir qui possède quoi.

Si une entreprise décide d'opter pour un data mesh, la distribution des domaines doit être étroitement alignée avec les initiatives commerciales réelles, telles que la création d’une expérience client omnicanal ou l’optimisation de la chaîne d’approvisionnement. Un tel alignement s'accompagne d'objectifs plus clairs pour les équipes de données de domaine et garantit que le data mesh génère une réelle valeur commerciale, plutôt que d’être une simple expérience.

Expertise en matière de gestion et de gouvernance des données

Bien que chaque équipe de domaine soit propriétaire de ses données, cela ne signifie pas qu’il n’y a pas besoin de coordination et de gouvernance à l’échelle de l’entreprise. Les outils modernes permettent aux utilisateurs de commence plus facilement à travailler avec des charges de travail complexes, mais la sélection et la mise en œuvre de ces outils nécessitent toujours un monitoring approfondi de la part d’experts.

Les experts en gestion des données sont également utiles pour guider chaque équipe dans le développement de ses processus et produits. Résoudre ces problèmes dès le début, en bénéficiant de conseils expérimentés, permet à l’ensemble de l’entreprise d’économiser du temps et des dépenses plus tard.

Colocalisation et performances du schéma

Chaque domaine doit avoir un schéma de données distinct, afin de supprimer les goulots d’étranglement qui découlent de l’utilisation d’un schéma pour toutes les données. Dans certains scénarios, les schémas doivent être colocalisés et connectés pour des raisons de performances. Dans le même temps, il est important de se rappeler que l’intégration des données dans tous les domaines d’un data mesh est essentielle. Cela permettra à votre entreprise de générer des performances orientées vers l’entreprise grâce à des stratégies de placement de données.

Ces étapes offrent une combinaison optimale entre vitesse et coût pour les charges de travail très complexes, fréquemment jointes à d’autres ensembles de données et régulièrement réutilisées, tant qu’une structure de données à performances élevées est en place.

Perspectives d’avenir pour le data mesh

Bien que la propriété des données distribuées ne soit pas en soi un concept nouveau, l’approche spécifique qu’implique le data mesh est suffisamment nouvelle pour que les implémentations réelles de celui-ci soient encore rares.

Cependant, de nombreuses entreprises s'efforcent déjà de faire évoluer leurs modèles de conception et leurs solutions cloud pour accélérer le développement de modèles de données et mieux servir les clients d’une manière qui ressemble fortement à celle d’un data mesh. Contactez-nous pour en savoir plus sur le potentiel de ce modèle de conception de données encore émergent, mais néanmoins passionnant.

En savoir plus sur le data mesh