Data Mesh : qu'est-ce que c'est ?

On le présente comme l'un des sujets les plus en vogue pour l'année 2021 : le Data Mesh. Ce nouveau paradigme, bien différent des Data Lakes ou Data Warehouses, nécessite de repenser complètement la manière dont les données sont stockées, requêtées et utilisées. Le Data Mesh vient avant tout répondre à une problématique bien concrète.

Le Data Warehouse

Pour bien comprendre en quoi le Data Mesh est si avant-gardiste, prenons quelques minutes pour bien se représenter le cas du Data Warehouse.

Le schéma suivant est sûrement l'un des plus génériques (et aussi des plus efficaces) pour retranscrire les archictures Data unifiées.

Source : a16z

Nous pouvons voir qu'en termes de stockage de données, les deux pièces maîtresses sont le Data Lake et le Data Warehouse. Les technologies sont assez différentes.

• Parmi les technologies du Data Lake, on retrouve bien souvent des bases de données NoSQL (MongoDB, Cassandra, Hive) et des systèmes de stockage de fichiers plats (Amazon S3, Google Cloud Storage, HDFS). Elles sont robustes et pensées pour l'ingestion de grandes quantités de données.
• Au niveau du Data Warehouse, nous retrouvons plutôt des ensemble et/ou systèmes complets, qui vont intégrer à la fois des bases de données, des moteurs d'exécutions et divers outils de traitements analytiques. On retrouve par exemple les très populaires Snowflake, BigQuery ou encore Redshift.

Le point particulièrement intéressant ici est que, contraitement au Data Lake, le Data Warehouse s'étale aussi bien sur le stockage que sur l'historisation. Et c'est justement là un des points divergents avec le Data Lake.

Le Data Warehouse a une utilité beaucoup plus directe pour les métiers, car c'est ce système qui va permettre de faire le lien entre les données brutes, pleines d'informations mais disponibles en trop grande quantité, et les acteurs opérationnels de l'entreprise qui ont des besoins précis et spécifiques sur ces données, mais qui n'ont pas la capacité d'accéder à des outils dits « bas niveau » (plus difficiles à appréhender).

Afin d'être efficace, ce système doit être centralisé pour pouvoir interagir avec les applications, scripts et utilisateurs de l'infrastructure. Cette centralisation permet d'avoir un contrôle optimal des ressources et offre une séparation logique entre les données brutes du Data Lake et les métiers opérationnels.

À lire aussi : découvrez notre formation Data Engineer

Mais cette centralisation apporte également son lot d'inconvénients.

• Lorsque les données deviennent de plus en plus importantes, la difficulté n'est pas tant sur comment stocker techniquement (car aujourd'hui, il existe heureusement des solutions pour stocker des centaines de Go de données sur un Data Warehouse), mais plutôt sur comment compartimenter de manière pertinente les différentes « vues ». Au fur et à mesure que le Data Warehouse évolue, de nouveaux cas d'usage et besoins surviennent, ce qui rends la maintenabilité difficile.
• Toute interaction avec le Data Warehouse implique d'utiliser des standards, des règles de bonnes pratiques qui ne sont pas forcément équivalentes entre tous les services. Cela peut représenter un véritable frein pour des équipes qui souhaiteraient accéder à ces informations pas forcément cruciales dans le Data Warehouse, mais qui permettrait d'améliorer leur efficacité opérationnelle.

C'est ainsi que, depuis peu, nous assistons à l'émergence d'une nouvelle façon d'architecturer le stockage et l'historisation des données : c'est le Data Mesh.

Un paradigme axé sur la décentralisation

Le Data Mesh a beaucoup de similarités avec le Data Warehouse dans l'objectif d'offrir de l'information la plus pertinent et la plus fraîche possible. La principale différence, c'est comment cette exposition va être effectuée.

Tout comme dans une entreprise, nous avons des départements ou équipes. Chaque équipe est lié à un sujet spécifique : le marketing, l'audit, le contrôle interne, la comptabilité, etc. Toutes les équipes n'ont pas les mêmes besoins : les équipes marketing auront des besoins sur des données utilisateurs, alors que les équipes d'audit souhaiteraient avec des informations de journaux (logs, connexions, traçabilité).

L'objectif du paradigme Data Mesh est d'exposer des données directement aux services concernés, de manière compartimenté et plus centralisé en un seul point comme c'est le cas avec les Data Warehouses.

Domaines

Le Data Mesh encourage la représentation par domaines, au même titre que les unités organisationnelles dans les entreprises. Ainsi, plutôt que d'utiliser un Data Warehouse pour former un tout, chaque domaine est orienté et dispose de son propre contexte.

Prenons un cas classique avec un Data Lake et un Data Warehouse.

Le parcours de la donnée est linéaire sous cette configuration.

• Les données brutes sont récoltées et stockées au format brut, dans le sens où elles ont subi, pour l'instant, que peu de transformations.
• Afin de faire ressortir l'information pertinente, des pipelines de données (très souvent des pipelines ETL) sont interfacées entre le Data Lake, qui représente la source de ces pipelines, et le Data Warehouse, étant la cible de ces mêmes pipelines.
• Le Data Warehouse, quant à lui, va héberger des données transformées, dans le sens où elles sont agrégées et historisées.

Cette configuration présente bien sûr de nombreux avantages. En revanche, elle présente également ses limites par les arguments que nous avions évoqués plus haut.

Sous une archictecture Data Mesh, ce n'est pas cette représentation linéaire qui guide les données mais une représentation par domaine.

Dans cet exemple, nous disposons de deux domaines dans un Data Mesh.

• Tout d'abord, nous avons deux bases et données NoSQL avec MongoDB et Elastic, et deux systèmes de stockages de fichiers plats avec Amazon S3 et Google Cloud Storage. Ces quatre systèmes résident dans le Data Mesh et peuvent donc être utilisés par tous les domaines.
• Le premier domaine analytique a une visée très opérationnelle : fournir de l'information quantitative sur les utilisateurs par exemple. Une base de données SQL (PostgreSQL) permet d'héberger les données agrégées que l'on a recoltées et transformées par l'intermédiaire de pipelines, et une application de Business Intelligence (PowerBI) permet de requêter facilement dessus sans difficultés. L'intérêt de ce domaine est de pouvoir fournir des informations sans avoir besoin de mobiliser l'équipe responsable de l'architecture. Nous pourrions tout à fait imaginer une équipe marketing qui serait composé d'un Data Engineer qui pourrait mettre en place ces pipelines sans altérer les autres domaines.
• Le second domaine audit permet de journaliser les différents événements survenus dans le Data Mesh. Par exemple, cela permet aussi bien de comprendre le comportement des utilisateurs dans le cas d'une application Web ou mobile, mais également d'analyser les logs de connexions des utilisateurs authentifiés du Data Mesh (Data Scientists, Data Engineers, développeurs, administrateurs réseaux, etc).

Cette représentation par domaines permet de cloisonner les outils, processus et systèmes sans pour autant les isoler : tous les domaines ont accès aux mêmes bases de données NoSQL et systèmes de stockage de fichiers plats. Néanmoins, chaque domaine va construire une hiérarchie en fonction de ses besoins.

Si l'on compare l'approche traditionnelle avec Data Lake et Data Warehouse, il y a plusieurs points différenciants.

• Contrairement au Data Warehouse, il n'y a plus une base de données centrale qui fait office de base de connaissances, mais chaque domaine va construire ses propres bases afin qu'elles soient le plus adaptées à ses propres besoins. Cela était déjà pensé avec les Data Marts mais qui n'étaient en réalité que de sous-parties d'un Data Warehouse.
• Les pipelines de données ne sont plus l'interface entre le Data Lake et le Data Warehouse, mais sont situés directement dans les domaines. Chaque domaine intègre ses propres pipelines, toujours adapté à ses propres besoins. Cela permet d'avoir la main sur l'intégralité du processus de transformation de données, tout en garantissant une gouvernance des données efficiente.

Avec les Data Mesh, on ne décompose plus les parties par des technologies (base de données, système spécifique) mais par des domaines adaptés à chaque métier.

À lire aussi : découvrez notre formation Data Engineer

Pour approfondir ce sujet, je vous conseille cet article détaillé qui définit un très bon état de l'art sur les réflexions Data Mesh. Vous pourrez également voir l'interview de Zalando qui a construit une architecture Data Mesh pour des besoins opérationnels.

La solution à tous les maux ?

Ce qu'il faut bien retenir, c'est qu'aujourd'hui, le Data Mesh présente des alternatives à la centralisation, qui reste la référence. Pour autant, ce modèle est encore sujet à des discussions, des évolutions et des améliorations. Il ne s'agit donc pas de tout changer du jour au lendemain, mais l'objectif est surtout de bien comprendre ce qu'apporte la décentralisation et surtout pourquoi elle a un intérêt. Pourquoi pas, dans un futur pas si lointain, voir émerger des architectures hybrides, à la limite entre la centralisation et les microservices engendrés par la décentralisation ?