Le Data Mesh, kesako ?
Il y a quelques jours, j’ai eu l’opportunité d’assister à une conférence sur le Data Mesh par Boris Dorado, conférence organisée par l’IESF (Ingénieurs et Scientifiques de France). Cela m’a donné envie de partager ce concept dans cet article, reprenant son origine, ses principes fondamentaux, ses avantages ainsi que les défis de son implémentation.
Photo de JJ Ying sur Unsplash
Répondre au besoin croissant d’accès rapide aux données
Tout d’abord, qu’est que le Data Mesh ? Ce n'est pas une technologie, mais plutôt une approche de la gestion des données. Selon cette approche organisationnelle et architecturale, la gestion et la gouvernance des données sont distribuées ET fédérées, confiant à chaque domaine d’une organisation la responsabilité de ses propres domaines de données, tandis que l'accessibilité de ces données est standardisée et facilitée par une infrastructure commune de libre-service.
Un peu d’histoire…
Le Data Mesh a été proposé en réponse aux limitations des architectures de données traditionnelles, comme les Data Warehouses puis les Data Lakes qui centralisaient les données, les traitements mais également les compétences. Cette très forte centralisation est souvent devenue source de goulots d'étranglement à mesure que les besoins en données augmentent et que les équipes en charge de leur gestion ne se trouvaient plus en capacité de répondre rapidement aux sollicitations des Métiers.
Les Premières Années (1970s - 1980s)
A l’origine…. les données opérationnelles étaient éparpillées “façon puzzle” au sein des organisations. Difficile de les récupérer, de les consolider, de les transformer en données analytiques. Dans les années 1970 et 1980, avec l'essor des bases de données relationnelles, les entreprises ont commencé à rassembler et accumuler de grandes quantités de données, mais les outils pour analyser et exploiter ces données étaient encore rudimentaires. Les premières solutions se concentraient sur la consolidation de données provenant de différentes sources pour faciliter l'analyse.
L'avènement des entrepôts de données, les Data Warehouses (1990s)
Les années 1990 ont marqué le véritable essor des entrepôts de données. Bill Inmon et Ralph Kimball sont deux figures clés qui ont popularisé ce concept. Bill Inmon est souvent appelé le "père du Data Warehousing" et a introduit l'idée de structurer les données pour faciliter les analyses historiques. Ralph Kimball a proposé une approche différente, centrée sur l'utilisateur final et les Data Marts, qui sont des segments spécialisés d'un entrepôt de données.
L'époque des grands constructeurs (2000s)
Dans les années 2000, de grandes entreprises technologiques comme IBM, Oracle, Microsoft et Teradata ont développé des solutions d'entrepôts de données robustes et intégrées. Ces solutions ont permis aux entreprises de mieux gérer et analyser leurs données, notamment grâce à des améliorations en matière de performance et de capacité de stockage.
L'ère du Big Data (2010s)
L'explosion des big data dans les années 2010 a entraîné une nouvelle évolution des entrepôts de données. Les technologies Hadoop et Spark ont permis de gérer des volumes de données encore plus importants, souvent non structurés. Les entreprises ont commencé à combiner des entrepôts de données traditionnels avec des Data Lakes pour tirer parti des avantages des deux approches.
« Si vous considérez un Data Mart comme un magasin d’eau en bouteille – nettoyée, conditionnée et structurée pour une consommation facile – le Data Lake est une grande étendue d’eau dans un état plus naturel. Le contenu du Data Lake s’écoule d’une source pour remplir le lac, et divers utilisateurs du lac peuvent venir l’examiner, y plonger ou prélever des échantillons. »
Data Warehouse (source : Zhamak Dehghani sur martinfowler.com)
Data Lake (source : Zhamak Dehghani sur martinfowler.com)
Le Data Mesh (2020s)
Dans les années 2020, les limitations des architectures centralisées ont conduit à l'émergence de nouvelles approches comme le Data Mesh. Cette approche constitue une véritable rupture dans la gestion des données, car elle ne propose pas comme précédemment de répondre à ce défi de manière technologique, mais plutôt grâce à un ensemble de propositions architecturales, méthodologiques, organisationnelles et de gouvernance. Elle a été définie en 2019 par Zhamak Dehghani dans un article intitulé “How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh“.
| Data Warehouse | Data Lake | Data Mesh | |
|---|---|---|---|
| Objectif | Centraliser et structurer les données pour des analyses rapides et précises à des fins décisionnelles | Stocker de grandes quantités de données brutes de tous types, permettant des analyses et explorations flexibles | Décentraliser la gestion des données en attribuant la responsabilité aux équipes Métiers (approche "domain-driven"), en traitant les données comme un produit (Data as a Product) |
| Type de données sources | Données structurées provenant de systèmes ERP, CRM, bases de données transactionnelles, etc. | Données structurées, semi-structurées (JSON, XML) et non structurées (images, vidéos, logs) | Toutes sortes de données (structurées, semi-structurées, non structurées), provenant de divers domaines |
| Type de données stockées | Données structurées et transformées, souvent agrégées, prêtes pour l'analyse | Données brutes, non transformées, dans leur format d'origine | Données dans des formats variés, souvent contextualisées selon le domaine métier |
| Traitement | Les données sont extraites des systèmes source, transformées selon des modèles pré-définis et chargées dans le DW (ETL - Extract, Transform, Load) | Les données sont extraites puis chargées sous leur forme d'origine, et ensuite transformées (ELT - Extract, Load, Transform) en fonction des besoins, ce qui offre une exploration et une analyse des données plus flexibles car tout ou partie des données brutes est toujours disponible pour des besoins de reporting personnalisés | Varie selon le domaine : chaque domaine peut choisir ETL, ELT ou d'autres outils adaptés à ses besoins |
| Cas d'utilisation |
|
|
|
| Avantages |
|
|
|
| Limites |
|
|
|
4 principes d’architecture pour mailler les données
Les fragilités des architectures de données classiques
Selon Zhamak Dehghani, les plateformes de données “traditionnelles” présentent trois points de fragilité en particulier.
Centralisation et monolithisme
La plateforme collecte des données très hétérogènes, issues de domaines disparates, sous des formes très variées, pour les proposer ensuite à des consommateurs aux attentes très différentes. Cette architecture peut être problématique pour les organisations couvrant des domaines très différents, avec un grand nombre de sources et une consommation de données non homogène :
à mesure que les sources de données se diversifient et prolifèrent, les solutions centralisées deviennent inefficaces pour harmoniser et gérer toutes les données en un seul endroit, nécessitant des approches décentralisées pour une exploitation optimale ;
les organisations, en raison de leur besoin d'expérimentation rapide, génèrent un nombre croissant de cas d'utilisation et de transformations de données, ce qui entraîne des frictions dues aux temps de réponse prolongés pour répondre aux besoins des consommateurs de données.
La multiplication des ETL en fonction des besoins spécifiques des Métiers est en particulier source d’une dette technique en croissance permanente.
Décomposition en pipelines couplés
Le deuxième mode de défaillance des architectures de plateformes de données traditionnelles est lié à leur décomposition architecturale autour des fonctions mécaniques telles que l'ingestion, le nettoyage, l'agrégation, etc. Cette décomposition a été proposé par les architectes afin de faire évoluer la plateforme face à de nouvelles sources et consommateurs.
Cependant, cette approche présente des limites. Bien qu'elle permette une certaine évolutivité en affectant des équipes à différentes étapes du pipeline, elle crée un couplage élevé entre les étapes, ralentissant la livraison des fonctionnalités. L’ajout d'une nouvelle fonctionnalité nécessite des changements dans tous les composants du pipeline, ce qui nécessite une synchronisation complexe et une gestion des versions.
Ainsi, bien que cette décomposition puisse sembler efficace sur le papier, en pratique, elle limite la capacité de la plateforme à répondre rapidement et à évoluer face à de nouveaux besoins.
Propriété cloisonnée et hyperspécialisée
Le troisième mode de défaillance des plateformes de données actuelles est lié à la structure des équipes qui les construisent et les exploitent. Ces équipes sont souvent hyperspécialisées et isolées des Métiers, ce qui les empêche de comprendre pleinement les domaines sources et les besoins des consommateurs. Elless doivent fournir des données pour divers besoins sans accès aux experts métiers, ce qui crée des inefficacités et de la frustration.
Une solution : le maillage de donnée
Architecture logique de l'approche de maillage de données
Afin de répondre à ces points de pression, Zhamak Dehghani propose de mettre en place un “maillage de données” (Data Mesh) : une architecture de données distribuées conçue sciemment, dans le cadre d'une gouvernance centralisée et d'une normalisation favorisant l'interopérabilité, grâce à une infrastructure de données en libre-service partagée et harmonisée.
Chaque nœud du maillage est constitué d’un produit de donnée (Data Product), plus petite unité d'architecture pouvant être déployée indépendamment avec une cohésion fonctionnelle élevée et comprenant tous les éléments structurels requis pour sa fonction.
Le Data Mesh est porté par 4 principes, collectivement nécessaires et suffisants :
Domain-oriented decentralized data ownership and architecture : pour que l’écosystème créant et consommant des données puisse évoluer à mesure que le nombre de sources de données, le nombre de cas d’utilisation et la diversité des modèles d’accès aux données augmentent, il suffit d’augmenter les nœuds autonomes sur le maillage ; la responsabilité des données est confiée aux équipes les plus proches de ces données.
Data as a product : pour que les utilisateurs de données puissent facilement découvrir, comprendre et utiliser en toute sécurité avec une expérience agréable, des données de haute qualité, réparties dans de nombreux domaines. Les données analytiques fournies par les domaines doivent être traitées comme un produit, et les consommateurs de ces données doivent être traités comme des clients.
Self-serve data infrastructure as a platform : pour que les équipes de chaque domaine puissent créer et consommer des produits de données de manière autonome en utilisant les abstractions de la plateforme, masquant la complexité de la création, de l'exécution et de la maintenance de produits de données sécurisés et interopérables.
Federated computational governance : pour que les utilisateurs de données puissent tirer parti de l'agrégation et de la corrélation de produits de données indépendants, le maillage se comporte comme un écosystème respectant des normes d'interopérabilité globales, normes qui sont intégrées de manière informatique dans la plateforme.
L’adoption de ces 4 principes doit permettre à l’organisation de gagner en évolutivité grâce au découplage des pipelines de gestion de données ; en agilité, en offrant aux Métiers des produits de données adaptés à leurs besoins, plus rapidement ; en qualité des données en particulier à travers les contrats de données ; et en collaborativité entre les équipes de domaine en attribuant à chacun des tâches concrètes pour collecter, analyser et utiliser les données, tout en nécessitant des échanges réguliers afin de s’assurer du niveau de qualité des données.
Des solutions, mais également des défis…
Bien que le Data Mesh propose des avantages significatifs, il présente toutefois également des défis non négligeables :
Mise en œuvre complexe : la transition peut être complexe et prendre du temps, car elle nécessite des changements importants dans l'infrastructure et les processus.
Résistance culturelle : les équipes habituées à des systèmes centralisés peuvent se montrer réticentes au passage à une propriété et une gouvernance décentralisées des données.
Problèmes de cohérence : il peut être difficile de garantir des normes et des pratiques cohérentes en matière de données dans plusieurs domaines.
Allocation des ressources : la gestion décentralisée des données peut nécessiter des ressources supplémentaires et du personnel qualifié pour maintenir un niveau élevé de qualité et de conformité des données.
Comprendre ces difficultés potentielles est primordial pour réussir la mise en œuvre d'un Data Mesh. Il est important de s‘interroger sur la pertinence de son intégration dans votre organisation, en se posant un certains nombres de questions comme :
La taille et la complexité (actuelles et futures) de notre entreprise justifient-elles l’implémentation d’un Data Mesh ?
Nos utilisateurs Métier se heurtent-ils à des goulots d’étranglement, un cloisonnement des données ou des problèmes de qualité ? Ces diffcultés impactent-elles nos activités ?
Nos domaines Métiers sont-ils suffisamment particulières et dissemblables pour justifier une gestion spécifique des données ?
Nos équipes Métier semblent-elles prêtent à endosser et assurer la gestion de leurs données (techniquement mais aussi culturellement) ?
Pouvez-nous mettre en place une équipe dédiée à la supervision et au soutien des équipes domaines ?
…
En conclusion…
Et les Data Warehouses et les Data Lakes dans tout ça ? Dans une architecture Data Mesh, ils deviennent des nœuds sur le maillage, plutôt que des composants centraux. Chaque domaine de données peut disposer de ses propres Data Warehouses (pour répondre à des besoins de stockage et d’historisation des données structurées), ou Data Lakes (pour des données non structurées destinées à l'apprentissage automatique ou l'analyse prédictive). Par exemple, un domaine de Ventes peut avoir un Data Warehouse pour les données historiques de vente, tandis qu'un domaine Marketing peut avoir un Data Lake pour les données de campagnes publicitaires. Mais la décision de mettre en place de telles solutions passe au second plan, après la question principale : “Sommes-nous prêts à mettre en place un écosystème de produits de données fonctionnant tous ensemble ?”.
