"Le Data Mesh et les outils associés."

Bonjour à tous je suis Emmanuel Malherbe, j’ai le plaisir d’animer ces data coffees de la plateforme média The Bridge, et nous parlons aujourd’hui des Data mesh avec Jean-Baptiste, bonjour Jean-Baptiste. Qui es-tu pour commencer? 

Alors je suis lead Software Engineer chez Artefact, concrètement ça revient à mettre en production des cas d’usage data chez nos clients. 

Et le Data Mesh, de ton point de vue qu’est-ce que c’est?

Alors, le data mesh, faut se dire qu’on va avoir différents mesh, chacun de ces mesh représente un domaine. Un domaine c’est par exemple la vision client, ou la vision des ventes; et l’idée de chacun de ces mesh, c’est qu’il est autoporteur, donc ça veut dire qu’on va avoir une équipe qui va être spécialisée dans la compréhension des données, la structuration de ces données, et on va aussi avoir des personnes techniques qui vont permettre de récupérer la donnée, de la transformer, et de l’exposer. Donc c’est à dire qu’on a des petites équipes avec une grande diversité de profils, focalisées sur un domaine de données.

En terme d’exposition des données, qu’implique le Data Mesh par rapport aux standards de production ?

Un mesh, et un domaine dans sa constitution, c’est un aspect de la connaissance de la donnée donc ça veut dire quelles sont les données qui composent ce mesh, sa documentation, pour avoir une bonne vision complète de l’ensemble des facettes de ce domaine de données, et on va aussi avoir un aspect technique, c’est à dire qu’on va ingérer la donnée, on va la transformer, on va l’exposer. Donc c’est déjà l’ensemble des

 fonctionnalités que l’équipe technique doit satisfaire; mais on a aussi des problématiques de qualité de données. On doit s’assurer que la donnée qui est exposée est de bonne qualité. Et un dernier objectif qui est la disponibilité et la fraîcheur de la donnée, parce que typiquement la donnée, je vais l’utiliser, et j’ai besoin de m’assurer qu’elle est de bonne qualité. Je vais par exemple avoir un dashboard sur les ventes, j’ai besoin d’avoir quelque chose qui est exact, tout le temps, parce que les équipes en ont besoin tout le temps. Cela implique d’avoir une solution qui est aussi disponible avec des données toujours aussi fraîches; et c’est une contrainte supplémentaire, que l’ensemble des domaines qui ont et qui gèrent ce domaine, c’est à dire avec l’injection et l’exposition, doivent voir dans leur périmètre de compétences.

Comment simplifier la mise en place d’un Data Mesh?

Déjà, le data mesh, c’est très intéressant dans la mesure où chaque domaine va avoir une vision complète de A à Z c’est à dire que la donnée, je la connais et après jusqu’à l’exposition. Après, je vais avoir certaines contraintes dans la mesure où ça peut s’avérer coûteux. Et je vais aussi avoir des personnes qui sont très rares sur le marché, que je vais devoir dupliquer, donc ça c’est problématique. Donc l’objectif c’est de se dire je vais commencer à standardiser et rationaliser pour simplifier et permettre une meilleure mise à l’échelle de cette approche. Donc, comment on peut faire déjà avoir une équipe de Data gouvernance centrale. Une équipe de Data gouvernance centrale va permettre de partager les bonnes pratiques à l’ensemble des domaines donc ça permet d’avoir une uniformisation, que ça soit par rapport à la structuration de la donnée, à la composition et à la documentation des domaines. Un deuxième axe d’un point de vue technique, serait de se dire, je vais mettre en place tous les assets c’est à dire de collecte, de transformation, de déploiement automatisé, standard, sur les différents domaines, parce qu’au final on se rend compte que ce sont différentes actions qui se répètent d’un domaine à un autre. Donc, plutôt que le faire à chaque fois, autant standardiser et le rationaliser; donc ça c’est déjà une première approche pour y arriver.

Par la suite, on peut se baser sur les technologies; le fait d’avoir des technologies de data warehousing, tel que Big Query, Synapse, Snowflake, qui permettent de désiloter la donnée, c’est vraiment quelque chose de positif, et ça c’est une vraiment grande avancée par rapport à ce qu’on pouvait avoir au préalable. Et on a d’autres technologies telles que DBT, Airbyte, qui vont nous permettre de nous baser sur des technologies du marché utilisables de tous, ce qui va faire que moi en tant que software engineer, je vais avoir moins de choses à développer, parce que je vais pouvoir me baser sur les technologies du marché.

Donc c’est vraiment un écosystème très riche en terme de technologie, en termes d’organisation; est-ce que tu as des exemples que tu peux nous partager de cas clients justement de déploiement du Data Mesh? 

Oui bien sûr, souvent chez nos clients, il y a déjà eu des choses; donc on a déjà ingéré de la donnée, on a déjà un environnement, et donc l’objectif c’est de pas repartir de zéro, mais de capitaliser sur ce qui est fait côté client, et souvent on se retrouve avec un client qui a fait du lift and shift. Qu’est-ce que c’est du lift and shift, c’est je pense que j’ai dans mon environnement Legacy ou environnement on premise, et je le copie avec une même organisation dans l’environnement cloud. Donc ça veut dire que la structure silotée de la donnée persiste; l’idée avec le Data mesh, c’est de retirer cette structure silotée de la donnée, donc là on va avoir un problème. L’idée, côté client c’est aussi d’avoir moins d’équipes techniques qui vont être en responsabilité d’ingérer et de gérer la donnée. Donc cette vision silotée, ça répond à ce besoin. Le point c’est de trouver un bon compromis; soit on veut avoir une approche théorique du Data mesh, et donc là l’idée ça va être se dire: ok j’ai toute la donnée, je vais commencer par un domaine, je vais définir quelles sont les tables qui constituent ce domaine, et donc quelles sont les tables sous-jacentes sur lesquelles je dois me baser, pour au final décommissionner la plateforme existante, et créer des domaines; ça c’est une première approche, et ça peut s’avérer un peu coûteux côté client parce qu’on va avoir une multiplication des profils.
Il y a une autre approche on va dire avec un Data mesh un peu plus light, où au final l’équipe qui va être en charge du mesh, ne va pas avoir à gérer toute la partie ingestion; il va se mettre au dessus, donc il va capitaliser sur toute la donnée qui est mise à sa disposition, et va construire ses domaines de données; donc le désavantage de ça c’est que j’ai une connaissance qui est moins bonne de bout en bout parce que je gère pas la donnée de son ingestion à son exposition. L’avantage, c’est que je vais avoir un système qui va être plus flexible, donc on va pas rentrer dans une approche data mesh théorique, mais au moins on pourra construire des domaines de données, avec des personnes qui seront owner de ce périmètre là. Ca permet aussi de définir à quoi pourrait ressembler une vision mesh, pour se dire, j’ai mon domaine, je sais quelles sont les tables qui la composent. Maintenant, si j’ai besoin de déstructurer ma plateforme, et savoir au final comment composer mes domaines c’est possible. Pourquoi? Parce qu’en fait j’ai un linéage de ma donnée, qui me permet de savoir d’où vient chaque domaine.

Donc toutes ces nouvelles technologies et ce nouveau concept de Data mesh doit avoir des impacts en termes de profil, lesquels sont-ils?

Oui. L’approche standardisée dont je t’ai parlé, au final ça permet de construire un asset qui sera réutilisable; donc le fait de construire cette asset va nécessiter moins de profils qui sont assez techniques de type data engineer; et ça permettra ensuite de se dire que cet outil je vais pouvoir le partager à tous les domaines. Et donc, c’est plus des profils de type Analytics engineer, qui vont rentrer en scène. Ces profils sont polyvalents, donc ils seront en capacité d’utiliser ces outils technologiques, de déployer la plateforme, de faire des transformations sur la donnée, tout en ayant une facette plus business, pour mieux comprendre les thématiques qui vont être rapportées par le Data product owner. Ce profil va permettre de faire le pont entre des profils extrêmement experts pour mettre à disposition un outil et un produit stable et facilement configurable, et l’application de notion business qui seront rapportées par data product owner.

Merci beaucoup Jean-Baptiste donc c’était très clair avec différents niveaux de Data Mesh, plus théorique, ou plus pragmatique, c’est vraiment très puissant comme organisation. J’espère que vous avez aussi beaucoup appris avec cette discussion avec Jean-Baptiste et je vous donne rendez-vous la semaine prochaine pour un nouvel épisode de Data coffee sur la plateforme médias The Bridge.