Intelligence des données

Le voyage vers le Data Mesh - Partie 3 - Créer vos premiers Data Products

Actian Corporation

22 avril 2024

vers le data mesh

Bien que la littérature sur le data mesh soit abondante, elle décrit souvent un état final, mais rarement la manière d'y parvenir dans la pratique. La question se pose alors :

Quelle approche adopter pour transformer la gestion des données et mettre en place un data mesh?

Dans cette série d'articles, vous trouverez un extrait de notre Guide pratique du Data Mesh, dans lequel nous proposons une approche pour lancer un parcours de data mesh data mesh dans votre organisation, structurée autour des quatre principes du data mesh (propriété et architecture de données décentralisées orientées vers le domaine, données en tant que produit, infrastructure de données en libre-service en tant que plateforme, et gouvernance informatique fédérée) et tirant parti des ressources humaines et technologiques existantes.

Tout au long de cette série d'articles, et afin d'illustrer cette approche pour construire les bases d'un data mesh réussi, nous nous appuierons sur un exemple : celui de l'entreprise fictive Premium Offices - une société d'immobilier d'entreprise dont l'activité consiste à acquérir des biens immobiliers pour les louer à des entreprises.

Dans les premiers articles de la série, nous avons identifié les domaines, défini un premier cas d'usage et constitué l'équipe chargée de son développement. Il est maintenant temps de passer au deuxième principe du data mesh , "les données en tant que produit", en développant les premiers data products.

L'approche de la réflexion sur les produits de la maille

Au cours de la dernière décennie, les domaines ont souvent développé une culture du produit autour de leurs Fonctionnalités opérationnelles. Ils offrent leurs produits au reste de l'organisation sous la forme d'API qui peuvent être consommées et composées pour développer de nouveaux services et applications. Dans certaines organisations, les équipes s'efforcent d'offrir la meilleure expérience possible aux développeurs qui utilisent les API de leur domaine : recherche dans un catalogue global, documentation complète, exemples de code, environnements "bac à sable", niveaux de service garantis et contrôlés, etc.

Ces API sont ensuite gérées comme des produits qui naissent, évoluent dans le temps (sans rupture de compatibilité), s'enrichissent et finissent par être obsolètes, généralement remplacées par une version plus récente, plus moderne et plus performante.

Le data mesh propose d'appliquer cette même approche de réflexion sur les produits aux données partagées par les domaines.

Caractéristiques des Data Products

Dans certaines organisations, cette culture axée sur le produit est déjà bien établie. Dans d'autres, elle devra être développée ou introduite. Mais ne nous y trompons pas :

Un produit de données n'est pas un nouvel artefact numérique nécessitant de nouvelles Fonctionnalités techniques (comme un produit API). C'est simplement le résultat d'une approche particulière de gestion des données exposée par un domaine au reste de l'organisation.

La gestion des API en tant que produit n'a pas nécessité de percée technologique : les intergiciels existants ont très bien fait le travail. De même, les data products peuvent être déployés sur des infrastructures de données existantes, quelles qu'elles soient. Techniquement, un produit de données peut être un simple fichier dans un lac de données avec une interface SQL ; un petit schéma en étoile, complété par quelques vues facilitant l'interrogation, instancié dans une base de données relationnelle ; ou encore une API, un flux Kafka, un fichier Excel, etc.

Un produit de données n'est pas défini par la manière dont il est matérialisé, mais par la manière dont il est conçu, géré et gouverné, ainsi que par un ensemble de caractéristiques permettant son exploitation à grande échelle au sein de l'organisation.

Ces caractéristiques sont souvent résumées dans l'acronyme DATSIS (Discoverable, Addressable, Trustworthy, Self-describing, Interoperable, Secure).

En outre, l'obtention d'un produit de données DATSIS ne nécessite pas d'investissements importants. Il s'agit de définir un ensemble de conventions globales que les domaines doivent respecter (nommage, protocoles pris en charge, gestion des accès et des permissions, contrôles de qualité, métadonnées, etc.) La mise en œuvre opérationnelle de ces conventions ne nécessite généralement pas de nouvelles Fonctionnalités technologiques - les solutions existantes sont généralement suffisantes pour démarrer.

Le catalogue constitue toutefois une exception. Il joue un rôle central dans le déploiement du data mesh en permettant aux domaines de publier des informations sur leurs data products et aux consommateurs d'explorer, de rechercher, de comprendre et d'exploiter ces data products.

Bonnes pratiques pour la conception de produits de données

La conception d'un produit de données n'est certainement pas une science exacte - il pourrait n'y avoir qu'un seul produit, ou trois ou quatre. Pour guider ce choix, il est une fois de plus utile de s'inspirer des meilleures pratiques des architectures distribuées - un produit de données doit.. :

  • Avoir une responsabilité unique et bien définie.
  • Avoir des interfaces stables et assurer la compatibilité ascendante.
  • être utilisables dans plusieurs contextes différents et donc support polyglotisme.

Expérience de développeur de Data Products

L'expérience du développeur est également un aspect fondamental du data mesh, avec l'ambition de faire converger le développement de data products et le développement de services ou de composants logiciels. Il ne s'agit pas seulement d'être convivial pour les ingénieurs, mais aussi de répondre à une certaine rationalité économique :

La décentralisation de la gestion des données implique que les domaines disposent de leurs propres ressources pour développer des data products. Dans de nombreuses organisations, l'équipe centralisée chargée des données n'est pas assez importante pour support équipes distribuées. Pour assurer le succès du data mesh, il est essentiel de pouvoir puiser dans le vivier des ingénieurs logiciels, qui est souvent plus important.

L'état de l'art en matière de développement logiciel repose sur un niveau élevé d'automatisation : allocation déclarative des ressources d'infrastructure, tests unitaires et d'intégration automatisés, construction et déploiement orchestrés via des outils CI/CD, flux de travail Git pour la gestion des sources et des versions, publication automatique de la documentation, etc.

Le développement des data products doit converger vers cet état de l'art - et selon la maturité de l'organisation, ses équipes et sa pile technologique, cette convergence prendra plus ou moins de temps. La bonne approche consiste à automatiser le plus possible en utilisant les outils existants et maîtrisés, puis à identifier les opérations qui ne sont pas automatisées pour intégrer progressivement des outils supplémentaires.

En pratique, voici ce qui constitue un produit de données :

  1. Le code d'abord - Pour les pipelines qui alimentent le produit de données avec des données provenant de différentes sources ou d'autres data products; pour toute API de consommation du produit de données ; pour tester les pipelines et contrôler la qualité des données ; etc.
  2. Les données, bien sûr - Mais le plus souvent, les données existent dans des systèmes et sont simplement extraites et transformées par des pipelines. Elles ne sont donc pas présentes dans le code source (sauf exceptions).
  3. métadonnées - Certaines documentent le produit des données : schéma, sémantique, syntaxe, qualité, lignage, etc. D'autres visent à assurer la gouvernance produit à l'échelle de la maille : contrats, responsabilités, politiques d'accès, restrictions d'utilisation, etc.
  4. L'infrastructure - Ou plus précisément, la déclaration des ressources physiques nécessaires à l'instanciation du produit de données : déploiement et exécution du code, déploiement des métadonnées, allocation des ressources pour le stockage, etc.

Du côté de l'infrastructure, le data mesh ne nécessite pas de nouvelles Fonctionnalités - la grande majorité des organisations disposent déjà d'une plate-forme de données. La mise en œuvre du data mesh ne nécessite pas non plus de plateforme centralisée. Certaines entreprises ont déjà investi dans une plateforme commune, et il semble logique de tirer parti des Fonctionnalités cette plateforme pour développer le maillage. Mais d'autres ont plusieurs plateformes, certaines entités, ou certains domaines disposant de leur infrastructure. Il est tout à fait possible de déployer le data mesh sur ces infrastructures hybrides : tant que les data products respectent des normes communes d'adressabilité, d'interopérabilité et de contrôle d'accès, les modalités techniques de leur exécution importent peu.

Exemple de bureaux de primes :

Afin d'établir un cadre initial pour la gouvernance son data mesh, Premium Offices a fixé les règles suivantes :

  • Un produit de données se matérialise par un projet dédié dans BigQuery - ce qui permet de définir des règles d'accès au niveau du projet, ou plus finement si nécessaire. Ces projets seront placés dans un répertoire "data products" et un sous-répertoire portant le nom du domaine auquel ils appartiennent (dans notre exemple, "Brokerage").
  • Les Data products doivent offrir des vues pour accéder aux données - ces vues fournissent une interface de consommation stable et permettent potentiellement de faire évoluer le modèle interne du produit sans avoir d'impact sur ses consommateurs.
  • Tous les data products doivent identifier les données en utilisant des références communes pour les données communes (clients, produits, fournisseurs, employés, etc.) - cela simplifie le recoupement des données provenant de différents data products (LEI, code produit, UPC, EAN, adresse électronique, etc.)
  • L'accès aux data products nécessite une authentification forte basée sur les Fonctionnalités IAM de GCP - l'utilisation d'un compte de service est possible, mais chaque utilisateur d'un produit de données doit alors avoir un compte de service dédié. Lorsque les politiques d'accès dépendent des utilisateurs, l'identité de l'utilisateurfinal doit être utilisée via l'authentification OAuth2.
  • La norme est de n'accorder l'accès qu'aux vues - et non au modèle interne.
  • Les demandes d'accès sont traitées par le product owner données au moyen de flux de travail établis dans ServiceNow.
  • DBT est l'ETL préféré pour la mise en œuvre de pipelines - chaque produit de données a un dépôt dédié pour son pipeline.
  • Un produit de données peut être consommé soit via le protocole JDBC, soit via les API BigQuery (lecture seule).
  • Un produit de données doit définir son contrat - fréquence de mise à jour des données, niveaux de qualité, classification des informations, politiques d'accès et restrictions d'utilisation.
  • Le produit de données doit publier ses métadonnées et sa documentation sur une marketplace - en l'absence de système existant, Premium Offices décide de documenter ses premiers data products dans un espace dédié sur le wiki de son entreprise.

Ce premier ensemble de règles est bien sûr appelé à évoluer, mais il fixe un cadre pragmatique pour garantir les caractéristiques DATSIS des data products en s'appuyant exclusivement sur les technologies et les compétences existantes. Pour son pilote, Premium Offices a choisi de décomposer l'architecture en deux data products:

  • Analyse des contrats de location - Ce premier produit de données offre des Fonctionnalités analytiques sur les contrats de location - entité, société mère, emplacement de la propriété, date de début du bail, date de fin du bail, type de bail, montant du loyer, etc. Il est modélisé sous la forme d'un petit schéma en étoile permettant une analyse selon 2 dimensions : le temps et le locataire - ce sont les dimensions d'analyse nécessaires pour construire la première version du tableau de bord. Il comprend également une ou deux vues qui exploitent le schéma en étoile pour fournir des données pré-agrégées - ces vues constituent l'interface publique du produit de données. Enfin, il comprend une vue permettant d'obtenir la liste la plus récente des locataires.
  • Notations des entités - Ce deuxième produit de données fournit des notations historiques d'entités sous la forme d'un simple jeu de données et d'une vue miroir servant d'interface, conformément à des règles communes. La notation est obtenue auprès d'un fournisseur spécialisé, qui la distribue sous forme d'API. Pour invoquer cette API, il faut fournir une liste d'entités, obtenue en consommant l'interface appropriée du produit Tenancy analytics.

En conclusion, l'adoption d'un état d'esprit consistant à traiter les données comme un produit est essentielle pour les organisations qui procèdent à la décentralisation de la gestion des données . Cette approche favorise une culture de la responsabilité, de la normalisation et de l'efficacité dans le traitement des données dans différents domaines. En considérant les données comme un actif précieux et en mettant en œuvre des frameworks gestion structurés, les organisations peuvent assurer la cohérence, la fiabilité et l'intégration transparente des données dans l'ensemble de leurs activités.

Dans notre dernier article, nous aborderons le quatrième et dernier principe du data mesh: la gouvernance informatique fédérée.

Le guide pratique du Data Mesh: Mise en place et supervision d'un Data Mesh à l'échelle de l'entreprise

Rédigé par Guillaume Bodet, notre guide a été conçu pour vous fournir des stratégies pratiques pour mettre en œuvre le data mesh dans votre organisation, en vous aidant :

  • Commencez votre parcours de data mesh par un projet pilote ciblé.
  • Découvrez des méthodes efficaces pour augmenter la taille de votre data mesh.
  • Reconnaître le rôle essentiel que joue une marketplace interne pour faciliter la consommation effective des data products.
  • Découvrez comment la plateforme Actian Data Intelligence se présente comme un système de supervision robuste, orchestrant un data mesh à l'échelle de l'entreprise.

Obtenez le livre électronique.

logo avatar actian

À propos d'Actian Corporation

Actian permet aux entreprises de gérer et de gouverner en toute confiance les données à l'échelle, en rationalisant les environnements de données complexes et en accélérant la fourniture de données prêtes pour l'IA. L'approche d'Actian en matière d'intelligence des données combine la découverte de données, la gestion des métadonnées et la gouvernance fédérée pour permettre une utilisation plus intelligente des données et améliorer la conformité. Grâce à desFonctionnalités intuitives libre-service , les utilisateurs professionnels et techniques peuvent trouver, comprendre et faire confiance aux actifs de données dans les environnements cloud, hybrides et sur site . Actian fournit des solutions de gestion des données flexibles à 42 millions d'utilisateurs au sein de sociétés Fortune 100 et d'autres entreprises dans le monde entier, tout en maintenant un taux de satisfaction de la clientèle de 95 %.