Le Data Mesh, nouveau paradigme, nous propose aujourd’hui d’exploiter ce qui a été fait précédemment en proposant un shift technologique et organisationnel.
Alors est-ce un effet de mode ou une réelle innovation?
Nous parlerons principalement dans ce billet de blog des concepts qui définissent le Data Mesh, les technologies pour mettre en place cette architecture ne seront pas abordées. En effet, il est aujourd’hui trop tôt pour en parler car nous sommes aux prémices de cette nouvelle méthode.
Le Data Mesh: Pourquoi ?
Nous rencontrons actuellement des difficultés à exploiter les données d’une entreprise de manière simple et sans investissement colossal dans des équipes et infrastructures massives.
Les plateformes data construites aujourd’hui autour d’une équipe dédiée n’arrivent pas vraiment à passer à l’échelle par rapport aux nouvelles demandes d’intégration et d’exploitation des données. Cette équipe data devient un goulot d’étranglement composée de personnes très spécialisées dans les technologies dédiées à la data mais pour qui le sens fonctionnel de ce qu’ils manipulent est secondaire.
Cette façon de faire implique deux problèmes :
- Une pénurie des profils data du fait qu’ils doivent être très spécialisés dans leur domaine de compétence pour pouvoir mener à bien leurs missions ;
- Des data pipelines difficiles à maintenir car elles n’ont pas été construites sur des données métier. Les évolutions demandées sont de plus en plus complexes à implémenter.
Pour contourner ces problématiques, la façon dont on produit, manipule et exploite la data doit être repensée pour faciliter l’accès à la donnée son exploitation et ainsi la valeur qu’elle contient.
Le Data Mesh: Comment ?
Ces problématiques de gestion d’un monolithe souvent ingérable et que l’on n’arrive pas à passer à l’échelle par rapport à l’évolution de l’entreprise sont des questionnements auxquels le monde de l’informatique a déjà répondu notamment grâce au Domain-Driven Design. Le Data Mesh est l’application du DDD au monde de la data.
Succinctement, le DDD est une méthodologie de développement logiciel qui vise à structurer les développements par domaine métier.
Néanmoins, les besoins data ont des particularités, notamment le fait que l’on doive croiser et transformer ses données pour en créer une valeur business, l’ensemble des data doit donc être accessible pour en tirer des bénéfices, le Data Mesh propose donc de fournir la data en mode self-service.
De plus, si on doit appliquer le DDD à la data, toute la donnée générée par un domaine devient sa responsabilité. L’approche Data Mesh considère donc la donnée comme étant un produit.
Pour mettre en place cette approche, nous devons repenser la manière d’utiliser mais aussi de servir (i.e. mettre à disposition) la donnée. Les data engineer qui sont responsables de la production et de la qualité de la donnée sont dispersés dans l’entreprise, et la donnée est générée au niveau de chaque domaine. Le cluster Hadoop n’est donc plus forcément le centre de vérité de la donnée
En résumé, le concept de Data Mesh est la convergence des trois principes suivants: Data Ownership By Domain, Data As a Product et Data As a Self-Service. Détaillons ces principes un à un.
Data Ownership By Domain
Avec le Data Mesh, plutôt que d’avoir de la donnée qui se déverse dans une plateforme data unifiée à partir de chaque domaine de l’entreprise et qu’une unique équipe data en soit responsable pour l’exploiter, la donnée doit être gérée et servie par le domaine métier qui la génère. Un domaine pourra donc produire un ensemble de datasets dont il maîtrise l’aspect fonctionnel et est tenu de le gérer pour en faciliter le plus possible sa mise à jour ainsi que l’accès à cette donnée aux différents consommateurs de l’entreprise.
Les datasets dont on parle à ce niveau diffèrent des données opérationnelles du système interne du domaine en question, il s’agit là des différents ensemble de données que peut exposer un domaine dans le but d‘être exploité par d’autres équipes. Ces datasets auront un volume plus conséquent du fait que l’historique est gardé et leurs schémas évoluent moins dans le temps par rapport aux données du système source.
Imaginons par exemple une équipe web qui peut génèrer les données des clickstreams ainsi que les données utilisateurs, elle créera deux datasets. Le premier à travers un event stream puisque que les données sont en en temps réel et **le second sous forme de fichiers déposés dans un object storage.
Un dataset source issue d’un domaine ne doit en aucun cas être modelé pour correspondre aux particularités d’un de ses consommateurs. Un dataset source doit représenter fidèlement la donnée du domaine tout en étant qualitatif en vue de son exploitation. Il doit donc respecter des SLO définis au préalable. C’est dans ce cadre que vont être utilisés les différents pipelines de données pour nettoyer, construire et garantir la qualité et l’exploitation des datasets générés et servis au reste de l’entreprise.
Data As a Product
Du fait qu’un domaine construit, nettoie et expose des données qui ont été créées par son activité, il doit incorporer un service ou un produit data. La data est donc considérée comme un produit à part entière d’un domaine de l’entreprise et est exploitée par le reste de l’organisation. De plus, du fait que les datasets générés sont distribués, des problématiques d’accessibilité et d’harmonisation émergent.
Pour y palier, l’architecture Data Mesh propose de considérer la data comme un produit et d’y appliquer les règles du Product Thinking le plus rigoureusement possible pour que les consommateurs aient une entière satisfaction des datasets produits.
Un produit data doit être :
- Découvrable : C’est à dire que les datasets générés s’inscrivent dans un Data Catalog centralisé qui peut être vu par le reste de l’organisation.
- Facile d’accès : Un produit data doit être facilement accessible aux consommateurs. Il doit respecter les conditions de nommage et doit avoir une adresse unique pour en faciliter son exploitation de manière programmatique.
- Fiable : Un produit data doit être fiable, chaque dataset exposé doit atteindre un niveau de SLO respectable. Il doit être nettoyé et peut par exemple contenir dans ses métadonnées l’intégralité des transformations qui lui ont été appliqués.
- Non ambigüe : ****Comme la donnée peut être utilisée par une multitude d’équipes du moment qu’elle est disponible à toute l’entreprise, elle doit générer le moins de frustration possible pour sa compréhension, le schéma de la donnée doit être fournit avec une explication de chaque champ et idéalement un dataset d’exemple pour illustrer.
- Gouverné par les standards de l’entreprise et sécurisé : Pour être exposée, la donnée doit respecter les standards de nommage de l’entreprise et notamment de la sécurité. L’accès à la donnée doit être géré par des policy très fines pour pouvoir donner l’accès à la donnée que l’on veut à qui on veut. La donnée sensible doit être anonymisée notamment dans ce contexte.
Data As a Self Service
Le fait que l’on construise un produit data par domaine métier implique une complexité à rajouter lors de la construction d’une architecture Data Mesh. En effet, construire des data pipelines qui sont souvent redondantes entre domaine n’a pas l’air d’être une bonne idée.
L’architecture Data Mesh propose donc de construire une infrastructure data utilisée en tant que plateforme (Data Infra as a Platform).
Cette plateforme doit être agnostique aux domaines métiers et ne doit incorporer aucune logique business. Elle aura pour responsabilité de fournir des services et ressources aux différents produits data à construire.
Elle doit fournir à minima les services suivants:
- Stocker la donnée de manière scalable ;
- Un catalogue de données unifié pour visualiser mais aussi modifier le schéma des données ;
- Mesurer la qualité des données ;
- Une couche applicative pour standardiser les données ;
- Pouvoir gérer qui a accès à quelle donnée ;
- Proposer des services pour monitorer et alerter si besoin les produits data.
Une data infra as a platform réussie est une plateforme qui aide les équipes à créer des produits de manière simple et automatisée.
Ce type d’infrastructure peut être mis en place avec des services managés des différents fournisseurs de Cloud, mais il faudrait y apporter une surcouche d’automatisation et de simplification en terme d’accès à ces services.
Pour mener à bien ce type d’architecture distribuée, il faudra changer l’organisation de l’entreprise concernant la data.
Data Mesh: d’un point de vue organisationnel
Comme on l’a vu, pour éviter d’avoir une équipe data qui gère à elle seule toutes les données de l’entreprise, les données générées doivent être rattachées à leurs domaines respectif. Chaque domaine aura une responsabilité en plus pour garantir l’accès et la qualité à son produit data. Un domaine qui produit des données doit intégrer dans son équipe des profils de Data Engineers et un Product Owner acculturé aux produits data.
Le PO data prendra des décisions concernant la vision qu’il a sur le dataset de données qu’il doit produire et cela en fonction de la richesse et de la qualité de celles-ci. Il doit se baser sur des KPIs mesurables pour s’assurer que le dataset exposé assure le niveau de qualité requis. Un des KPIs qui peut être intéressant est le temps requis par un consommateur de la donnée pour découvrir et utiliser le dataset exposé. Il doit en continu récupérer du feedback des consommateurs pour améliorer son produit.
Le Data Engineer s’occupera quant à lui de la construction et de l’exposition (ou serving) de ce dataset. Il n’est plus isolé dans une équipe data où la compréhension métier des données qu’il manipule est secondaire. Il est placé au cœur technique d’une organisation Data Mesh. Il lui faut cette connaissance métier pour pouvoir délivrer un dataset utile et de qualité.
L’ogranisation en Data Mesh contribuera à favoriser les échanges et mutualiser les bonnes pratiques et les connaissances etre les Data Engineers et Software Engineers. En effet, l’écart est mince et le but est de créer des synérgies pour que la production de ces datasets soit faite avec les outils data tout en respectant les normes de développement du software engineering (CI/CD, tests automatisés …).
Des formations doivent être proposées pour préparer les Software Engineers mais aussi les Ops à travailler avec des outils data.
Pour construire et gérer la data infrastructure as a platform, il faut aussi des Data Infra Engineers qui s’occuperont de la mise en place de cette plateforme de ressources et de service. Ils auront un rôle tout aussi primordial pour fluidifier la création des dataset. On retrouve ce rôle chez les SRE (Site Reliability Engineers) ayant de l’éxpériences sur des architectures data traditionelles.
Conclusion
Pour conclure, le but d’une architecture Data Mesh et de permettre aux entreprises de passer à l’échelle l’exploitation de leurs données de manière synchrone avec la mise en place de nouveaux domaines fonctionnels. Elle vise à distribuer la responsabilité de la création et du maintient de la qualité de la donnée à chaque domaine qui la produit.
Basé sur une approche DDD appliquée à la data, il est utile d’avoir déjà mis en place une organisation de ce type au sein de votre entreprise avant de se jeter à l’eau pour la partie data. Un effort doit aussi être fournit dans la formation des différents collaborateurs notamment les Software Engineers qui doivent avoir des compétences data pour construire ces datasets métier ou encore à former des POs pour qu’ils puissent être à l’aise dans la vision qu’ils doivent avoir pour concevoir des datasets qui ont du sens et de qualité.
Technologiquement parlant, les outils sont déjà disponibles sur le marché pour construire une telle architecture. C’est maintenant aux ingénieurs de mettre en place des services pour pouvoir créer et exploiter les données de manière fluide et ainsi avoir une plateforme data décentralisée au sein de l’entreprise, où les données ont été créées de manière collaborative et harmonisée quel que soit le service qui en est responsable.
