Les forces et les limites du Data Mesh
Les forces et les limites
des architectures
Data Mesh.
est ?
Le Data Mesh, qu’est-ce que c’est ?
Traiter les données comme un produit
Le Data Mesh fait référence à un système de traitement de données massive avec une architecture décentralisée. Cette architecture a le vent en poupe, en particulier dans les entreprises importantes opérant dans des domaines fortement concurrentiels.
L’architecture est subdivisée en « domaines » gérés par une équipe en responsabilité jouissant d’une véritable indépendance. Ces domaines de donnée sont rendus interopérables avec des APIs. L’idée est d’avoir des données segmentée, prêtes à emploi ! C’est un peu une actualisation des "datamarts", mais en self-service, et dont la gestion est distribuée.
La propriété des données est ainsi fédérée pour générer de la valeur afin de permettre des cycles de création de valeur et d'apprentissage plus rapides. La « fédération » de la propriété est souvent logique car la valeur métier peut être mieux définie, hiérarchisée et itérée par la Business Unit (=le domaine) avec l'exigence requise.
Quelle est la nuance entre une Data Lake vs un Data Warehouse vs le Data Mesh ?
- Le Data Lake : il renvoie comme son nom l’indique à la mise à disposition d’un volume de données aussi récentes et pertinentes que possible. Les données sont en lecture seule, sont chargées de façon brute, et interprétées uniquement quand elles sont lues.
- le Data warehouse : il s’agit d’un stockage selon des schémas préétablis en fonction des usages que l’on fera de la donnée. Le modèle s’opère dès le chargement.
- Le Data Mesh : c’est des passerelles virtuelles entre des bases de données, qui sont spécialisées par domaines. Les équipes data vont requêter, transformer, créer des ponts entre les domaines pour obtenir le résultat le plus pertinent possible.
Le Data Mesh viendra compléter judicieusement le Data Lake et le Data Warehouse. Et c’est aujourd’hui une lame de fond, portée par les ressources infinies du Cloud.
Quels sont les avantages des architectures Data Mesh ?
Une décentralisation de la préparation des données.
Le Data Mesh va consommer des données brutes en entrées pour les restituer nettoyées, avec un surcroît de structuration. Ces « produits » pourront être consommés par d’autres entités que le data owner, et les croisements sont infinis.
Une propriété des données décentralisée.
Chaque domaine (BU) de l’entreprise est titulaire de ses données, car c’est lui qui les connaît le mieux et qui en a le plus d’usage. Il doit donc se charger de la collecte, du nettoyage, des transformations… et il a tout intérêt à bien le faire. Le Data Mesh est (en théorie) un gage de qualité.
Un véritable libre-service.
Les données sont rendues accessible à tous ceux qui ont besoin d’y accéder, il n’y a plus de cloisonnement, de silo étanche. Cela s’opère par la mise à disposition d’une infrastructure en libre-service avec des APIs, qui est le seul point centralisé dans le Data Mesh.
Une gouvernance décentralisée et donc (théoriquement) efficace.
Chaque domaine (ou BU) va opérer sa propre data governance : qualité, sourcing, conformité, etc. Et le niveau « inter domaine » va d’avantage régir l’harmonisation des formats, la sécurité des systèmes, les cycles de vie de la donnée.
Quels sont les limites des architectures Data Mesh ?
Les risques de complexification du SI.
L’évolution vers un modèle intégralement décentralisé peut aboutir à la création des silos de données infinis, une duplication inutile des efforts.
Pour créer de nouvelles réponses, de nouveaux business insights, un nouveau « Mesh » est créé en croisant différents domaines. Ce « Mesh » peut être croisé à son tour avec un autre domaine, et ainsi de suite. Au fur et à mesure que l’on empile les réponses, la complexité s’accroît. On est dans la mécanique bien connue de l’entropie, mais à vitesse accélérée.
Le Data Mesh est un modèle opérationnel qui évolue continuellement dans le temps.
Il n'y a pas d'implémentation de référence de Data Mesh. Par conséquent, chaque entreprise qui adopte le Data Mesh doit planifier l'évolution de sa plate-forme de données et de son modèle d'exploitation au fil du temps. Le risque est d’être continuellement débordé par les data owners qui bien souvent ne sont pas rattachés à l’IT.
Les rôles et les responsabilités ne sont pas clairement établis.
Ces rôles et responsabilités des uns et des autres doivent être normalisés afin garantir que le déploiement d’un Data Mesh s’opère harmonieusement. Sans cette organisation préétablie avec des rôles dédiés, les data engineers peuvent passer à côté des exigences nécessaire à la construction de données de qualité.
Le risque fort en matière de gouvernance des données.
Une gouvernance informatique fédérée doit être un principe fondamental du Data Mesh, et doit mettre l'accent sur l'automatisation et la normalisation afin de permettre une surveillance, une détection et une correction plus complètes, et en temps réel, des problèmes qui surgissent ici et là.
L’intrication des flux d’information peut devenir tel qu’il devient impossible de faire de l’analyse d’impact d’un côté à l’autre du système. Le recours à un outil de data lineage qui va analyser en temps continu l’ensemble des flux, les raccorder les uns aux autres, sera une aide précieuse pour permettre de déployer un Data Mesh. Cet outil devra être complètement automatisé, et devra aussi englober la couche de dataviz dans laquelle sont positionnées de plus en plus massivement les règles de gestion.
Conclusion
L’objectif du Data Mesh est donc bien de favoriser la flexibilité maximale, pour créer de nouveaux "business insights", avec des données prêtes à emploi, validées par leurs propriétaires fonctionnels. Et ça fonctionne ! Certaines entreprises se rêvent data driven, et le Data Mesh est un catalyseur de cette stratégie.
Cependant les impératifs de maîtrise du processing de la donnée dans des chaines d’alimentation de fait hyper intriquées, peut vite devenir un « pain point » et décrédibiliser la stratégie. Il conviendra d’y remédier par des mécanismes automatisés d’analyse d’impact (data lineage) dans le système complet pour avoir une compréhension du déploiement exhaustif de chaque donnée.
Par ailleurs, les coûts associés à cette inflation de l’information peuvent être exponentiels. Les infras Cloud se prêtent très bien à cette scalabilité, mais les modèles de revenu des Clouds Provider reposent largement sur les I/O de données. Les considérations de coût peuvent vite peser dans la balance et freiner les ambitions.
#datalineage #bdaip2022 #datamesh
Commentaires
Enregistrer un commentaire