Data Mesh Architecture

Le Data Mesh d’un Point de Vue Ingénierie

Pourquoi Vous Pourriez Avoir Besoin d’un Data Mesh
De nombreuses organisations ont investi dans un lac de données central et une équipe dédiée aux données, espérant piloter leur activité grâce aux données. Cependant, après quelques premiers succès rapides, elles constatent souvent que l’équipe centrale devient un goulot d’étranglement. Cette équipe n’est pas en mesure de répondre assez rapidement à toutes les questions analytiques des responsables et des propriétaires de produits. Cela représente un problème majeur, car prendre des décisions basées sur les données en temps opportun est crucial pour rester compétitif. Par exemple : est-il judicieux d’offrir la livraison gratuite pendant la Black Week ? Les clients acceptent-ils des délais de livraison plus longs mais plus fiables ? Comment une modification de la page produit influence-t-elle les taux de conversion et de retour ?

L’équipe de données souhaite répondre rapidement à toutes ces questions. En pratique, cependant, elle est confrontée à des difficultés, car elle consacre trop de temps à corriger des pipelines de données défaillants après des changements dans les bases de données opérationnelles. Avec le peu de temps restant, l’équipe doit découvrir et comprendre les données spécifiques aux différents domaines. Pour chaque question, elle doit acquérir des connaissances approfondies sur le domaine pour fournir des informations significatives. Acquérir cette expertise de domaine est une tâche ardue.

D’un autre côté, les organisations ont également investi dans la conception orientée domaine, les équipes de domaine autonomes (aussi appelées équipes alignées sur les flux ou équipes produit) et une architecture décentralisée de microservices. Ces équipes de domaine possèdent et maîtrisent leur domaine, y compris les besoins en information de l’entreprise. Elles conçoivent, développent et gèrent elles-mêmes leurs applications web et leurs API. Malgré leur connaissance du domaine et des besoins en information, elles doivent solliciter l’équipe centrale de données surchargée pour obtenir des analyses basées sur les données nécessaires.

Avec la croissance progressive de l’organisation, la situation des équipes de domaine et de l’équipe centrale de données se dégrade encore davantage. Une solution consiste à transférer la responsabilité des données de l’équipe centrale vers les équipes de domaine. C’est l’idée principale derrière le concept de data mesh : une décentralisation orientée domaine pour les données analytiques. Une architecture de data mesh permet aux équipes de domaine de réaliser elles-mêmes des analyses de données inter-domaines et d’interconnecter les données, de manière similaire à l’utilisation des API dans une architecture de microservices.

Comment Concevoir un Data Mesh ?
Une architecture de data mesh est une approche décentralisée qui permet aux équipes de domaine de réaliser elles-mêmes des analyses de données inter-domaines. Au cœur de cette architecture se trouve le domaine avec son équipe responsable ainsi que ses données opérationnelles et analytiques.

L’équipe de domaine ingère des données opérationnelles et construit des modèles de données analytiques sous forme de produits de données afin de réaliser ses propres analyses. Elle peut également choisir de publier ces produits de données avec des contrats de données pour répondre aux besoins en données d’autres domaines.

Qu’est-ce que le Data Mesh ?
Le concept de Data Mesh repose sur quatre principes fondamentaux : Propriété par Domaine, Données comme Produit, Plateforme de Données en Libre-Service et Gouvernance Fédérée. Ce terme a été introduit par Zhamak Dehghani en 2019 et s’appuie sur des concepts bien établis.

1. Propriété par Domaine (Domain Ownership)

Ce principe exige que les équipes de domaine assument la responsabilité de leurs données. Selon cette approche, les données analytiques doivent être organisées autour des domaines, tout comme les équipes s’alignent sur les contextes délimités d’un système. En suivant une architecture distribuée axée sur les domaines, la propriété des données analytiques et opérationnelles passe des équipes centrales de données aux équipes de domaine.

2. Données comme Produit (Data as a Product)

Ce principe applique une philosophie centrée sur le produit aux données analytiques. Cela signifie que les données d’un domaine ont des consommateurs au-delà de ce domaine. Les équipes de domaine ont donc la responsabilité de répondre aux besoins des autres domaines en fournissant des données de haute qualité. Essentiellement, les données d’un domaine doivent être traitées comme n’importe quelle autre API publique.

3. Plateforme de Données en Libre-Service (Self-serve Data Platform)

L’idée ici est d’adopter une logique de plateforme pour l’infrastructure de données. Une équipe dédiée à la plateforme de données fournit des outils, des systèmes et des fonctionnalités agnostiques aux domaines pour concevoir, exécuter et maintenir des produits de données interopérables pour tous les domaines. Grâce à cette plateforme, les équipes de domaine peuvent consommer et créer des produits de données de manière fluide et autonome.

4. Gouvernance Fédérée (Federated Governance)

Ce principe vise à garantir l’interopérabilité de tous les produits de données grâce à une standardisation promue par un groupe de gouvernance. L’objectif principal de la gouvernance fédérée est de créer un écosystème de données respectant les règles organisationnelles et les réglementations industrielles.

En résumé, le Data Mesh offre une approche décentralisée et collaborative pour la gestion des données analytiques, mettant l’accent sur la qualité, l’autonomie et la conformité.

L’équipe de domaine s’accorde avec les autres sur des politiques globales, telles que l’interopérabilité, la sécurité et les standards de documentation, au sein d’un groupe de gouvernance fédérée. Cela permet aux équipes de domaine de savoir comment découvrir, comprendre et utiliser les produits de données disponibles dans le data mesh.

La plateforme de données en libre-service, agnostique aux domaines et fournie par l’équipe de la plateforme de données, permet aux équipes de domaine de créer facilement leurs propres produits de données et de réaliser efficacement leurs analyses.

Une équipe facilitatrice guide les équipes de domaine sur la manière de modéliser les données analytiques, d’utiliser la plateforme de données, et de construire et maintenir des produits de données interopérables.

Approfondissons les composants clés d’une architecture de data mesh et leurs relations:

Produit de Données
Un produit de données est une unité logique qui contient tous les composants nécessaires pour traiter et stocker les données d’un domaine dans le cadre de cas d’usage analytiques ou nécessitant une grande intensité de données. Il rend ces données disponibles pour d’autres équipes via des ports de sortie. Vous pouvez le comparer à un module ou un microservice, mais dédié aux données analytiques.

Fonctionnement des Produits de Données

Les produits de données se connectent à des sources, comme des systèmes opérationnels ou d’autres produits de données, et effectuent des transformations de données. Ils fournissent des ensembles de données via un ou plusieurs ports de sortie. Ces ports de sortie sont généralement des ensembles de données structurées, définis par un contrat de données.

Exemples de ports de sortie :

Un ensemble de données BigQuery contenant plusieurs tables liées.
Des fichiers Parquet dans un bucket AWS S3.
Des fichiers Delta dans Azure Data Lake Storage Gen2.
Des messages dans un topic Kafka.

Responsabilité des Produits de Données

Un produit de données est sous la responsabilité d’une équipe de domaine. Cette équipe est chargée des opérations liées au produit de données pendant tout son cycle de vie. Elle doit :

Surveiller en continu la qualité des données.
Garantir leur disponibilité.
Contrôler les coûts associés.

Outils et Méthodes Recommandés

Conception des produits de données : Nous recommandons d’utiliser le Data Product Canvas pour concevoir les produits de données.
Gestion des produits de données : Pour gérer les produits de données, suivre les coûts et assurer la conformité, envisagez d’utiliser Data Mesh Manager.

Contrat de Données
Un contrat de données est un document qui définit la structure, le format, les sémantiques, la qualité et les conditions d’utilisation pour l’échange de données entre un fournisseur de données et ses consommateurs.

Contenu d’un Contrat de Données

Il inclut :

Fournisseur du produit de données : Informations sur le propriétaire et le port de sortie pour accéder aux données.
Conditions d’utilisation : Termes et conditions pour l’usage des données.
Schéma et sémantiques : Attributs de données fournis et leur signification.
Attributs de qualité : Par exemple, la fraîcheur des données et le nombre de lignes disponibles.
Objectifs de niveau de service (SLO) : Tels que la disponibilité et les délais de support.
Détails de facturation : Coûts associés à l’utilisation des données.

Rôle des Contrats de Données

Bien que le contrat de données représente une spécification d’interface, l’implémentation réelle qui fournit les données est le port de sortie d’un produit de données.

Les contrats de données sont particulièrement utiles lorsque des données sont échangées entre différentes équipes ou unités organisationnelles. Ils sont avant tout un outil de communication, permettant d’exprimer une compréhension commune sur la manière dont les données doivent être structurées et interprétées. Ils rendent explicites les attentes en matière de sémantique et de qualité.

Utilisation des Contrats de Données

Au développement et en production : Les contrats servent de base pour :
- La génération de code.
- Les tests.
- Les validations de schéma.
- Les contrôles de qualité.
- La surveillance.
- Le contrôle d’accès.
- Les politiques de gouvernance computationnelle.
Tests contractuels orientés consommateur : Ils peuvent être utilisés pour les ports d’entrée afin de vérifier que les données fournies respectent les spécifications définies.

Spécification des Contrats de Données

La Data Contract Specification définit un format YAML permettant de décrire les conditions d’utilisation et les attributs des ensembles de données fournis.

Gouvernance Fédérée
Le groupe de gouvernance fédérée est généralement organisé sous forme de guilde, composée de représentants de toutes les équipes participant au data mesh. Ces équipes s’accordent sur des politiques globales, qui définissent les règles du jeu dans le data mesh. Ces règles spécifient la manière dont les équipes de domaine doivent concevoir leurs produits de données.

Politiques de Gouvernance

Les politiques d’interopérabilité sont le point de départ. Elles permettent aux autres équipes de domaine d’utiliser les produits de données de manière cohérente. Par exemple, une politique globale pourrait définir que la manière standard de fournir des données est sous forme de fichier CSV sur AWS S3, dans un bucket appartenant à l’équipe de domaine correspondante.

Ensuite, il doit y avoir une forme de documentation permettant de découvrir et de comprendre les produits de données disponibles. Une politique simple pourrait être une page wiki avec un ensemble prédéfini de métadonnées, telles que le propriétaire du produit de données, l’URL de localisation et les descriptions des champs du fichier CSV.

Une méthode uniforme pour accéder aux produits de données de manière sécurisée pourrait être l’utilisation de l’accès basé sur les rôles dans AWS IAM, géré par l’équipe de domaine.

Politiques Globales de Gouvernance

Les politiques globales telles que la confidentialité et la conformité sont également courantes. Cela concerne, par exemple, la protection des informations personnelles identifiables (PII) ou les exigences légales spécifiques à un secteur.

Exemples de Politiques

De nombreuses politiques exemples sont disponibles sur notre autre site, datamesh-governance.com, que vous pouvez facilement utiliser dans Data Mesh Manager, notre outil de gouvernance pour data mesh.

Transformations
En examinant l’organisation des données au sein d’un produit de données, on peut observer les différents types de données qui circulent à travers les différentes étapes. Les données opérationnelles sont souvent ingérées sous forme de données brutes et non structurées.

Lors d’une étape de prétraitement, les données brutes sont nettoyées et structurées en événements et entités. Les événements sont de petites unités, immuables et fortement orientées domaine, comme OrderPurchased (commande achetée) ou ShipmentDelivered (expédition livrée). Les entités représentent des objets métiers, tels que les expéditions ou les articles, dont l’état change au fil du temps. C’est pourquoi les entités sont souvent représentées sous forme de liste de snapshots (instantanés), l’historique, avec le dernier snapshot étant l’état actuel.

En pratique, on rencontre souvent des données saisies manuellement ou importées. Par exemple, des données prévisionnelles envoyées par e-mail sous forme de fichiers CSV ou des descriptions textuelles pour des codes métier.

Les données provenant d’autres équipes sont intégrées en tant que données externes. Lors de l’utilisation de produits de données provenant d’autres équipes bien gouvernées, cette intégration peut être mise en œuvre de manière très légère. En cas d’importation de données provenant de systèmes hérités, la zone externe agit comme une couche anti-corruption.

Les agrégations combinent les données pour répondre à des questions analytiques. Les données de domaine peuvent être publiées vers d’autres équipes en définissant un contrat de données. Le contrat de données est généralement mis en œuvre par une vue, qui reste stable même lorsque les modèles de données sous-jacents changent.

Ingestion
Comment les équipes de domaine peuvent-elles ingérer leurs données opérationnelles dans la plateforme de données ? Un système logiciel conçu selon les principes de la conception pilotée par le domaine contient des données sous forme d’entités/agrégats mutables et d’événements de domaine immuables.

Les événements de domaine sont particulièrement adaptés pour être ingérés dans la plateforme de données, car ils représentent des faits métier pertinents. Si un système de messagerie est en place, les événements de domaine peuvent être envoyés à la plateforme de données en ajoutant un consommateur de messages supplémentaire. Les données peuvent ainsi être collectées, traitées et envoyées à la plateforme en temps réel. Avec cette ingestion en streaming, les données sont envoyées en petits lots dès leur arrivée, elles sont donc immédiatement disponibles pour l’analyse. Comme les événements de domaine sont déjà bien définis, il y a peu à faire en termes de nettoyage et de prétraitement, à l’exception de la déduplication et de l’anonymisation des données personnelles identifiables (PII). Parfois, il est aussi conseillé de définir et d’ingérer des événements analytiques internes contenant des informations uniquement pertinentes pour des cas d’usage analytiques, afin que les événements de domaine n’aient pas besoin d’être modifiés.
Exemples d’ingestion en streaming : Kafka Connect, Kafka Streams, AWS Lambda.

De nombreux objets métier sont persistés en tant qu’entités et agrégats dans des bases de données SQL ou NoSQL. Leur état change au fil du temps, et seul l’état actuel est persister dans la base de données. Les bons candidats pour des entités avec état sont les articles, les prix, les données clients ou le statut des expéditions. Pour des cas d’usage analytiques, il est souvent nécessaire d’avoir à la fois l’état actuel et l’historique des états au fil du temps. Il existe plusieurs approches pour ingérer les entités. Une manière est de générer et de publier un événement onCreate/onUpdate/onDelete avec l’état actuel chaque fois qu’une entité est modifiée, par exemple, en ajoutant un aspect ou des EntityListeners. Ensuite, l’ingestion en streaming peut être utilisée pour ingérer les données comme décrit ci-dessus. Lorsque la modification du logiciel opérationnel n’est pas faisable, le capture de données modifiées (CDC) peut être utilisé pour écouter directement les changements dans les bases de données et les diffuser dans la plateforme de données.
Exemples de streaming CDC : Debezium.

Enfin, des tâches ELT ou ETL programmées traditionnelles qui exportent des données dans un fichier et les chargent dans la plateforme peuvent être mises en place, avec l’inconvénient de ne pas disposer de données en temps réel, de ne pas avoir tous les changements d’état entre les exportations et de devoir consolider les données exportées à nouveau. Cependant, elles restent une option viable pour les systèmes hérités, tels que les mainframes.

				
					-- Step 1: Deduplicate
WITH inventory_deduplicated AS (
    SELECT *
    EXCEPT (row_number)
    FROM (
       SELECT *,
              ROW_NUMBER() OVER (PARTITION BY id ORDER BY time DESC) row_number
       FROM `datameshexample-fulfillment.raw.inventory`)
    WHERE row_number = 1
),
-- Step 2: Parse JSON to columns
inventory_parsed AS (
    SELECT
        json_value(data, "$.sku")                           AS sku,
        json_value(data, "$.location")                      AS location,
        CAST(json_value(data, "$.available") AS int64)      AS available,
        CAST(json_value(data, "$.updated_at") AS timestamp) AS updated_at,
    FROM inventory_deduplicated
)
-- Step 3: Actual Query
SELECT sku, location, available, updated_at
FROM inventory_parsed
ORDER BY sku, location, updated_at

Analytique
Pour obtenir des insights, les équipes de domaine interrogent, traitent et agrègent leurs données analytiques avec les produits de données pertinents provenant d’autres domaines.

Requêtes et Traitement des Données

Le SQL est la base de la plupart des requêtes analytiques. Il offre des fonctions puissantes pour connecter et examiner les données. La plateforme de données doit être capable d’exécuter efficacement des opérations de jointure, même pour de grands ensembles de données. Les agrégations permettent de regrouper les données, tandis que les fonctions de fenêtre facilitent les calculs sur plusieurs lignes. Les notebooks aident à construire et documenter les découvertes exploratoires.
Exemples : Jupyter Notebooks, Presto.

Visualisation des Données

Les humains comprennent beaucoup mieux les données, tendances et anomalies lorsqu’ils les perçoivent visuellement. Il existe plusieurs excellents outils de visualisation de données qui permettent de créer des graphiques attrayants, des tableaux de bord d’indicateurs clés de performance (KPI), des rapports et des tableaux de bord interactifs. Ils offrent une interface utilisateur facile à utiliser pour approfondir, filtrer et agréger les données.
Exemples : Looker, Tableau, Metabase, Redash.

Analyses Avancées

Pour des insights plus avancés, des méthodes de science des données et d’apprentissage automatique peuvent être appliquées. Ces techniques permettent des analyses de corrélation, des modèles de prédiction et d’autres cas d’usage avancés. Cela nécessite des compétences spécifiques en méthodologie, en statistiques et en technologies.
Exemples : scikit-learn, PyTorch, TensorFlow.

Plateforme de Données

La plateforme de données en libre-service peut varier selon les organisations. Le data mesh étant un domaine émergent, les fournisseurs commencent à intégrer des capacités liées au data mesh dans leurs offres existantes.

Capacités Analytique et de Produit de Données

Capacités analytiques : Permettent aux équipes de domaine de construire un modèle de données analytique et de réaliser des analyses pour des décisions basées sur les données. La plateforme doit offrir des fonctions pour l’ingestion, le stockage, l’interrogation et la visualisation des données en libre-service. Des solutions typiques comme les entrepôts de données et les lacs de données (on-premise ou cloud) existent déjà, avec pour différence majeure que chaque équipe de domaine dispose de sa propre zone isolée.
Capacités de produit de données : Une plateforme avancée inclut des fonctionnalités pour créer, surveiller, découvrir et accéder aux produits de données, sans distinction de domaine. Elle doit permettre aux équipes de domaine de publier rapidement des produits de données et d’assurer leur exécution en production dans leur espace isolé. La découverte des produits nécessite un point d’entrée central (par exemple, un catalogue de données centralisé tel qu’un wiki, un dépôt Git, ou des solutions comme Select Star, Google Data Catalog, ou AWS Glue Data Catalog).

Automatisation des Politiques

Une plateforme plus avancée automatise les politiques globales pour éviter que les équipes de domaine ne doivent les appliquer manuellement. Exemple : garantir que tous les produits de données respectent la même structure de métadonnées ou supprimer automatiquement les données PII lors de l’ingestion.

Moteur de Requête

Un moteur de requête performant influence l’architecture de la plateforme. Par exemple :

Une plateforme partagée, avec un langage de requête unique et un support pour des zones séparées (comme Google BigQuery).
Un moteur de requêtes distribué, tel que Presto, pour des jointures inter-domaines sans importation, bien qu’ayant certaines limitations.

Équipe Facilitatrice

L’équipe facilitatrice promeut l’idée du data mesh dans l’organisation. Elle agit comme un groupe d’experts et d’ambassadeurs du data mesh en aidant les équipes de domaine à devenir autonomes.

Rôles et Responsabilités

Les membres travaillent temporairement avec les équipes de domaine (par exemple, un mois) en tant que consultants internes pour :
- Comprendre les besoins.
- Établir un environnement d’apprentissage.
- Former les membres aux analyses de données.
- Guider sur l’utilisation de la plateforme de données en libre-service.
En dehors des engagements, ils partagent des ressources comme des exemples, des bonnes pratiques, et des tutoriels.

Mesh (Réseau)

Le réseau émerge lorsque des équipes utilisent les produits de données d’autres domaines.

Les données des domaines amont simplifient les références et les recherches (par exemple, obtenir le prix d’un article).
Les données des domaines aval permettent d’analyser les effets, comme pour des tests A/B (par exemple, variations dans les taux de conversion).
Les données de multiples domaines peuvent être agrégées pour créer des rapports complets ou de nouveaux produits de données.

Exemple Simplifié : E-Commerce

Imaginez un cas où une équipe combine des données de prix (amont), de commandes et de retours pour analyser l’impact d’une réduction sur les marges et les taux de retour. Le produit de données agrégé devient une ressource précieuse pour d’autres analyses ou décisions.

Classification des Domaines dans un Data Mesh

La classification proposée par Zhamak Dehghani fournit un cadre pour organiser les domaines en fonction des caractéristiques des données et de l’utilisation des produits de données. Les trois principales catégories sont les domaines alignés sur la source, agrégés, et orientés consommateur.

Domaines Alignés sur la Source

Ces domaines publient des produits de données étroitement liés à leurs données opérationnelles, comme les événements de domaine et les entités.

Exemple : Dans une boutique en ligne, les domaines peuvent être divisés selon le parcours client : recherche de produit, passage en caisse, paiement.
Caractéristiques :
- Publient des produits de données qui reflètent directement les événements ou entités des systèmes opérationnels.
- Les ingénieurs analysent leurs propres données pour améliorer les systèmes opérationnels et valider les nouvelles fonctionnalités.
- Utilisent les données des domaines voisins pour simplifier les requêtes et comprendre les effets en aval.
Cas d’utilisation : Améliorer les systèmes opérationnels et valider les fonctionnalités en analysant les données locales et voisines.

Domaines Agrégés

Les équipes de ces domaines se concentrent sur la création de produits de données complets à partir de plusieurs domaines sources.

Exemples :
- Vue 360° du Client : Combine les données de compte, commandes, expéditions, factures, retours, soldes et évaluations internes de plusieurs domaines.
- Modèles d’Apprentissage Automatique Sophistiqués : Créés à partir de données agrégées, comme un système de recommandations utilisant les données des commandes et des clients.
Caractéristiques :
- Difficile à construire en raison des différents contextes délimités, mais très utile.
- Nécessite souvent des équipes spécialisées avec des compétences avancées, comme des data scientists.
Cas d’utilisation : Fournir des insights complets ou des fonctionnalités spécialisées, comme la segmentation des clients ou des recommandations personnalisées.

Domaines Orientés Consommateur

Ces domaines répondent aux besoins des départements métier nécessitant des données provenant de toute la chaîne de valeur, en se concentrant souvent sur des utilisateurs non techniques.

Exemples :
- Gestion et Contrôle : Rapports détaillés et indicateurs clés de performance (KPI) couvrant tous les domaines pour une prise de décision stratégique.
- Marketing : Analyse de funnels et du web à l’aide d’outils comme Google Analytics ou Adobe Analytics.
Caractéristiques :
- Optimisés pour répondre aux besoins spécifiques d’un département, plutôt que pour une utilisation générale.
- Conçus pour des experts métier, pas pour des ingénieurs ou des utilisateurs très techniques.
- Peuvent ne pas publier de produits de données pour d’autres domaines, mais se concentrent sur les analyses et rapports internes.
Cas d’utilisation : Permettre aux équipes métier d’obtenir des insights pour la prise de décision et d’optimiser les processus sans expertise technique approfondie.

Le voyage de l’équipe de domaine

Tout comme l’équipe des données a un voyage à entreprendre, chaque équipe de domaine doit également suivre un parcours pour devenir une partie contributive de votre maillage de données. Chaque équipe peut commencer son voyage dès qu’elle est prête et à son propre rythme. Les bénéfices apparaissent déjà au fur et à mesure du voyage. Les équipes tireront rapidement parti des premières décisions basées sur les données, amorçant ainsi une avalanche d’utilisation de données plus nombreuses et de meilleure qualité pour des analyses encore plus approfondies. Le maillage de données évolue avec chaque équipe qui partage ses données sous forme de produits, permettant ainsi l’innovation guidée par les données.

Pour que ce voyage soit réussi, l’équipe a besoin de trois choses : une vision claire du maillage de données de la part de la direction pour que tout le monde avance dans la même direction, un environnement favorable comprenant une plateforme de données en libre-service facile à utiliser pour amener l’équipe d’ingénierie sur la voie de l’analyse des données, et un environnement de haute confiance pour que chaque équipe puisse suivre son propre chemin et rythme.

Alors, commençons votre voyage !

Niveau 0 : Pas d’analyse de données
Votre équipe est responsable d’un domaine et construit et gère des systèmes autonomes, y compris l’infrastructure nécessaire. Cela a demandé un effort considérable pour construire ces systèmes, et vous vous êtes concentré sur l’excellence de la livraison. Ces systèmes opérationnels génèrent désormais des données de domaine.

L’analyse des données n’était tout simplement pas pertinente.

Niveau 1 : Requêtes de base de données opérationnelles
Étant en production, vous devez probablement enquêter sur un incident et analyser combien de clients sont affectés. De plus, certains acteurs peuvent avoir des questions concernant vos données, telles que « Quels articles en stock n’ont pas été vendus au cours des six derniers mois ? » ou « Quels ont été les délais de livraison pendant la dernière Black Week ? » Pour répondre à toutes ces questions, vous envoyez des requêtes analytiques à votre base de données opérationnelle. Au fil du temps, vous réalisez également quelques premières analyses exploratoires pour mieux comprendre le comportement de votre système.

Cela augmente la charge sur votre base de données de production, et vous pourriez être tenté de modifier la base de données de production pour mieux supporter vos requêtes analytiques, comme la création d’index supplémentaires. Vous pourriez décharger la charge supplémentaire sur des réplicas de lecture. Mais les requêtes analytiques restent lentes et difficiles à écrire.

Niveau 2 : Analyser ses propres données
Avec les difficultés des requêtes analytiques lentes et difficiles à écrire en tête, vous testez la plateforme de données en libre-service promue par l’équipe de la plateforme de données. Par exemple, vous avez maintenant accès à Google BigQuery. Sur cette plateforme, votre équipe commence à construire un modèle de données analytique en ingérant des messages de Kafka. C’est votre premier produit de données. La plateforme de données vous permet d’analyser les données concernant vos propres systèmes avec des requêtes rapides et maintenables, tout en préservant les schémas de vos bases de données opérationnelles. Vous apprenez à structurer, prétraiter, nettoyer, analyser et visualiser des données analytiques — il y a beaucoup à apprendre, même si la plupart est en SQL, que vous maîtrisez déjà.

Comme les questions concernant vos propres données peuvent désormais être répondues rapidement, vous et votre responsable produit entrez dans le cycle des décisions basées sur les données : définir des hypothèses et les vérifier avec les données.

Niveau 3 : Analyser des données inter-domaines
Analyser les données de votre propre domaine est un excellent début, mais les combiner avec des données provenant d’autres domaines, c’est là que la magie opère. Cela permet d’obtenir une vue d’ensemble malgré la décentralisation des données. Parmi les exemples, on trouve des tests A/B pour mesurer l’effet d’un changement d’interface utilisateur sur le taux de conversion, ou la construction de modèles d’apprentissage automatique pour la détection de fraude incluant l’historique des achats précédents et le comportement actuel de navigation. Cela nécessite que d’autres équipes partagent leurs produits de données de manière à ce que votre équipe puisse les découvrir, y accéder et les utiliser. C’est à ce moment-là que le maillage commence à se former.

Lorsqu’une équipe devient un membre consommateur du maillage de données, elle commence à s’intéresser à l’interopérabilité et à la gouvernance du maillage de données. Idéalement, l’équipe enverra un représentant au groupe de gouvernance du maillage de données.

Si vous êtes la première équipe, vous devrez peut-être passer cette étape pour l’instant et passer au niveau 4 pour être la première à fournir des données pour les autres.

Niveau 4 : Publier des contrats de données
En fonction des besoins des autres équipes, vous partagez vos données avec elles en publiant des contrats de données. Par exemple, vous fournissez les commandes confirmées, rejetées et annulées afin que d’autres puissent corréler leurs événements au taux de conversion. Au lieu de simplement consommer des produits de données, vous devenez un éditeur de produits de données. Vous générez de la valeur pour les autres équipes. Mais en même temps, cela augmente vos responsabilités et vos devoirs opérationnels à long terme.

Les produits de données publiés doivent respecter les politiques globales définies par le groupe de gouvernance fédéré. Vous devez connaître et comprendre les politiques globales en vigueur. À ce stade, il est indispensable que vous participiez et contribuez au groupe de gouvernance fédéré.

Le voyage de l’équipe de données

Le maillage de données est avant tout un concept organisationnel et s’intègre parfaitement dans les principes des team topologies. Il transfère les responsabilités des données vers les équipes de domaine, soutenues par une équipe de plateforme de données et une équipe de facilitation des données. Les représentants de toutes les équipes se réunissent dans un groupe de gouvernance fédéré pour définir les standards communs.

Aujourd’hui, dans de nombreuses organisations, une équipe centrale de données est responsable d’une large gamme de tâches analytiques, allant de l’ingénierie des données et de la gestion de l’infrastructure des données à la création de rapports pour la direction. Une telle équipe centrale souffre de surcharge cognitive, englobant les connaissances sur le domaine, la technique et les méthodes. Le maillage de données permet de remédier à cela.

Le maillage de données offre de nouvelles perspectives pour les membres de l’équipe centrale de données, car leurs compétences en analyse et en ingénierie des données restent essentielles. Par exemple, ils sont parfaitement placés pour établir la plateforme de données pour ceux qui préfèrent travailler sur l’infrastructure. Certains d’entre eux peuvent former une équipe de facilitation des données pour agir en tant que consultants internes, aidant les équipes de domaine dans leur parcours. Quelle que soit leur nouvelle fonction, beaucoup d’entre eux se retrouveront dans le groupe de gouvernance fédéré du maillage de données pour façonner l’avenir du maillage de données.

Le véritable changement de mentalité se produit cependant lorsqu’on crée de nouveaux domaines axés sur les données, comme montré dans la figure ci-dessus. Regardons les rapports de gestion typiques que les grandes équipes centrales de données produisent habituellement à partir de data warehouses ou de data lakes monolithiques. Avec le maillage de données, les ingénieurs de données qui créaient ces rapports de gestion forment une nouvelle équipe de domaine avec un responsable produit dédié. En tant qu’ingénieurs de la nouvelle équipe de domaine, ils peuvent désormais se concentrer sur leur nouveau domaine et leurs consommateurs. Cela leur permet d’acquérir une connaissance approfondie du domaine au fil du temps, ce qui se traduit par de meilleurs rapports et des optimisations continues. De plus, ils passent de l’utilisation du data warehouse monolithique à l’utilisation de produits de données provenant d’autres domaines. Ce changement est un processus progressif, alimenté par la demande de produits de données, accélérant ainsi la formation d’un maillage de données. Le responsable produit négocie avec les autres équipes de domaine les produits de données nécessaires et s’assure que les rapports et autres produits que la nouvelle équipe de domaine construira à l’avenir répondront aux besoins de l’entreprise.

À mesure que les équipes de domaine existantes, dans leur parcours, réalisent de plus en plus d’analyses de données, une autre perspective pour les membres de l’équipe centrale de données est de rejoindre l’une de ces équipes. Grâce à leur savoir-faire existant, ils peuvent accélérer le parcours des équipes de domaine vers un maillage de données en diffusant et en enseignant leurs connaissances et compétences aux autres membres de l’équipe. Il est important qu’ils deviennent des membres à part entière de l’équipe et ne fondent pas une sous-équipe de données au sein de l’équipe de domaine. En plus de leurs connaissances et compétences, les ingénieurs de données peuvent également apporter des responsabilités et des artefacts de l’équipe centrale de données à leurs équipes de domaine. Par exemple, la segmentation des clients, qui était auparavant réalisée par l’équipe centrale de données, passera sous la responsabilité de l’équipe de domaine des recommandations.

Les data scientists, quant à eux, sont généralement organisés de manière centralisée. C’est pourquoi leur avenir, d’un point de vue organisationnel, ressemble beaucoup à celui de l’équipe centrale de données. Les produits de données dans le maillage de données sur lesquels ils se concentrent sont des caractéristiques et des modèles d’apprentissage automatique. Lorsqu’ils rejoignent une équipe de domaine existante, un tel modèle d’apprentissage automatique pourrait être totalement intégré dans un microservice. Ainsi, le maillage de données permet de créer des services basés sur l’apprentissage automatique, car les capacités MLOps nécessaires peuvent être facilement construites au-dessus du maillage de données.

Questions Fréquemment Posées (FAQ)

Alors, qu'est-ce qui se cache vraiment derrière tout ce battage ?

Le data mesh est avant tout un changement organisationnel. Les responsabilités liées aux données sont rapprochées du flux de valeur de l’entreprise. Cela permet de prendre des décisions plus rapides basées sur les données et réduit les obstacles à l’innovation centrée sur les données.

Qui a réellement mis en place un data mesh ?

Il existe une collection complète d’histoires de parcours utilisateurs provenant de la communauté Data Mesh Learning, qui couvre des exemples de data mesh provenant de nombreuses industries différentes.

Le Data Mesh est-il adapté à mon entreprise ?

Cela dépend, bien sûr. Il y a quelques prérequis qui devraient être en place : Vous devez avoir modélisé votre système logiciel en suivant les principes du design basé sur les domaines ou quelque chose de similaire. Vous devez avoir un bon nombre (5+) d’équipes de domaine indépendantes qui ont déjà leurs systèmes en production. Enfin, vous devez avoir confiance en vos équipes pour prendre des décisions basées sur les données de manière autonome.

Comment commencer ?

Commencez petit et définissez la vision globale. Trouvez deux équipes de domaine (au niveau 2) qui ont un cas d’utilisation à forte valeur ajoutée, où une équipe a besoin de données provenant de l’autre équipe. Laissez une équipe construire un produit de données (niveau 4) et l’autre équipe utiliser ce produit de données (niveau 3). Vous n’avez pas encore besoin d’une plateforme de données sophistiquée. Vous pouvez commencer par partager les fichiers via AWS S3, un dépôt Git, ou utiliser une base de données en cloud, comme Google BigQuery.

Quand devrais-je éviter un Data Mesh ?

Il existe certains indicateurs qui montrent qu’une approche Data Mesh pourrait ne pas être adaptée à votre entreprise, notamment :

Vous êtes trop petit et n’avez pas plusieurs équipes d’ingénierie indépendantes.
Vous avez des exigences de données à faible latence. Le Data Mesh est un réseau de données. Si vous devez optimiser pour la faible latence, investissez dans une plateforme de données plus intégrée.
Vous êtes satisfait de votre système monolithique hautement intégré (comme SAP). Il pourrait être plus efficace d’utiliser leur plateforme analytique.

Qu'est-ce que le Data Mesh n'est pas ?

Le Data Mesh n’est pas :

Une solution miracle.
Une religion.
Une approche plug-and-play.
Un produit que l’on peut simplement acheter.
Une plateforme uniquement dédiée aux données.
Quelque chose que l’équipe de données peut mettre en œuvre seule.
Un concept destiné aux données opérationnelles.
De la virtualisation des données.
Le successeur du Data Warehouse ou du Data Lake.
Une solution que l’on peut implémenter rapidement en mode « Big Bang ».
Un service mesh pour les données.
Et le Data Mesh n’a absolument rien à voir avec la blockchain.

Le Data Mesh est-il une solution générique pour une architecture de données distribuée ?

Non, le Data Mesh n’est pas une solution générique pour une architecture de données distribuée. Il s’agit d’une approche spécifique visant à organiser la gestion des données de manière décentralisée, en attribuant des responsabilités aux équipes de domaine. Cette approche repose sur des principes de conception basés sur les domaines et nécessite une transformation organisationnelle pour que les équipes puissent gérer leurs propres produits de données de manière autonome. Il ne s’agit pas simplement d’un modèle d’architecture technique, mais d’un changement dans la manière dont les données sont gérées à travers l’organisation.

Produit de données : Quelles données inclure dans un produit de données ? Un produit de données doit-il inclure les données d'autres domaines ?

Les données créées et détenues par un domaine sont des candidates idéales, et l’équipe du domaine devrait être encouragée à les publier sous une forme appropriée, nettoyée et gérée.

Pour les domaines alignés sur la source, on recommande généralement d’inclure des identifiants de référence. Il est possible d’inclure les données d’autres domaines, si elles ont été transformées, servent de base aux décisions commerciales ou si l’état exact des données au moment du traitement est pertinent. En fait, ce sont des cas où le domaine de traitement prend la responsabilité de ces données en fonction des besoins commerciaux.

Les domaines agrégés et les domaines alignés avec les consommateurs peuvent inclure toutes les données externes qui sont pertinentes pour les cas d’utilisation de leurs consommateurs.

Quelle est la différence entre Data Mesh et Data Fabric ?

Au début, le Data Fabric semble similaire au Data Mesh car il offre une plateforme de données en libre-service similaire. En y regardant de plus près, on constate que le Data Fabric est une approche centralisée et agnostique des domaines, ce qui contraste fortement avec l’approche décentralisée et centrée sur les domaines du Data Mesh.

Quel pourrait être le parcours pour les équipes qui exploitent des systèmes commerciaux prêts à l'emploi (COTS) ?

De nombreux systèmes commerciaux prêts à l’emploi (COTS) tels que Salesforce, SAP, Shopify, Odoo offrent des capacités analytiques optimisées pour les domaines. Ainsi, le parcours des équipes de domaine commence directement au niveau 2.

Le défi consiste à intégrer les produits de données d’autres domaines (niveau 3, qui peut être omis si ce n’est pas nécessaire) et à publier des produits de données pour d’autres domaines (niveau 4). Les données du système doivent être exportées vers la plateforme de données et gérées en tant que produits de données, conformément aux politiques globales. À mesure que les modèles de données évoluent avec les mises à jour des systèmes, une couche anti-corruption est essentielle, par exemple, comme étape de nettoyage.

Comment les ensembles de données acquis externes peuvent-ils faire partie d'un Data Mesh ?

Les ensembles de données acquis de manière externe, comme des bases de données de prix ou des études médicales, doivent être gérés par une équipe qui en prend la responsabilité et les intègre dans le Data Mesh. Si cette équipe n’est pas très technique, la plateforme de données devrait offrir un service facile à utiliser pour télécharger les fichiers et fournir des métadonnées. Une API Excel ou Google Sheets pourrait également être une option dans ce cas.

Comment avez-vous créé les diagrammes ?

Cette question nous a été posée fréquemment, donc nous sommes heureux de partager notre outil :
Nous utilisons diagrams.net avec le style « Sketch » et les Streamline Icons. Nous automatisons la conversion en PNG, SVG et WebP à l’aide d’un petit script.

Quelles sont vos questions ?

Si vous avez d’autres questions, n’hésitez pas à en discuter avec nous sur GitHub ou à nous contacter directement. Mais attention : votre question pourrait finir dans la FAQ. 🙂

Ils nous font confiance

Next Data est un cabinet de recrutement et de conseil IT. Nous sommes des vecteurs de performance, plaçant l’humain au cœur de notre réussite. L’important n’est pas tant ce que nous faisons que la manière dont nous le faisons. En plus de nos activités principales, nous proposons également des formations pour accompagner nos partenaires et collaborateurs dans leur montée en compétences.

Liens utiles

Présentation Nextdata

Notre liste d'emploi

Nos services

S'abonner dés maintenant et recevez notre Newsletter

NextData votre cabinet de formation , sourcing & intégration

appelez-nous : +212608068989