Img_couverture_blog_Ysance

    Comment passer d'un DataLake monolithique à un Data Mesh distribué

    [fa icon="calendar"] 03/03/21 08:10 / par Laurent Letourmy

    De nombreuses entreprises investissent dans leur lac de données de nouvelle génération, dans l'espoir de démocratiser les données à grande échelle pour fournir des informations commerciales et, en fin de compte, prendre des décisions intelligentes automatisées. Les plateformes de données basées sur l'architecture du lac de données ont des modes de défaillance communs qui conduisent à des promesses non tenues à grande échelle. Pour faire face à ces modes de défaillance, nous devons passer du paradigme centralisé d'un lac ou de son entrepôt de données prédécesseur. Nous devons passer à un paradigme qui s'inspire de l'architecture distribuée moderne: considérer les domaines comme la préoccupation de premier ordre, appliquer la pensée de plate-forme pour créer une infrastructure de données en libre-service et traiter les données comme un produit.

     

    Le commentaire d’Ysance: Nous souhaitons tout d’abord remercier Zhamak Dehghani pour nous avoir autorisé à traduire et publier cet article sur notre blog. Nous invitons tous les data-addicts à lire consciencieusement cet article, tant il éclaire un nouveau paradigme d’organisation des données que nous sentons tous devoir implémenter un jour, tant la gestion d’un immense volume de données centralisé est complexe, et la demande en entreprise est forte. Prenons le pari ce jour que nous n‘avons pas fini d’entendre parler de Data-Mesh.

     

    Publication originale: Le 20 mai 2019

    Lien original : https://martinfowler.com/articles/data-monolith-to-mesh.html

    Par : Zhamak Dehghani

     

    Zhamak est consultante principale en technologies chez ThoughtWorks et se concentre sur l'architecture de systèmes distribués et la stratégie de plate-forme numérique en enterprise. Elle est membre du conseil consultatif de ThoughtWorks Technology et contribue à la création du ThoughtWorks Technology Radar.

    Introduction

    Devenir une organisation axée sur les données reste l'un des principaux objectifs stratégiques de nombreuses entreprises avec lesquelles je travaille. Mes clients sont bien conscients des avantages de devenir intelligemment responsabilisés : offrir la meilleure expérience client basée sur les données et l'hyper-personnalisation; réduire les coûts opérationnels et le temps grâce à des optimisations basées sur les données; et donner aux employés de super pouvoirs grâce à l'analyse des tendances et à la veille économique. Ils ont investi massivement dans la création de catalyseurs tels que les plateformes de données et de business intelligence. Malgré des efforts et des investissements croissants dans la création de telles plateformes, les organisations trouvent les résultats peu convaincants.

    Je conviens que les organisations sont confrontées à une complexité à plusieurs facettes pour se transformer et devenir data-driven; migration de décennies de systèmes hérités, résistance de la culture héritée à s'appuyer sur les données et priorités commerciales. Cependant, ce que je voudrais partager avec vous, c'est une perspective architecturale qui sous-tend l'échec de nombreuses initiatives de plateformes de données. Je montre comment nous pouvons adapter et appliquer les apprentissages de la dernière décennie dans la construction d'architectures distribuées à grande échelle, au domaine des données; et je présenterai une nouvelle architecture de données d'entreprise que j'appelle le Data-Mesh .

    Ma demande avant de poursuivre la lecture est de suspendre momentanément les hypothèses et les préjugés profonds que le paradigme actuel de l'architecture de plate-forme de données traditionnelle a établi; Être ouvert à la possibilité de passer des lacs de données monolithiques et centralisés à une architecture de Data-Mesh intentionnellement distribuée; Embrassez la réalité toujours présente, omniprésente et distribuée la nature des données.

    L'architecture actuelle de la plateforme de données d'entreprise

    Elle est centralisée , monolithique et agnostique du domaine aka lac de données .

    Presque tous les clients avec lesquels je travaille planifient ou construisent leur plate-forme de données et d'intelligence de 3e génération, tout en admettant les échecs des générations précédentes:

    • La première génération : entrepôt de données d'entreprise et plateformes de veille stratégique propriétaires ; des solutions avec des prix élevés qui ont laissé les entreprises avec des dettes techniques tout aussi importantes; Dette technique en milliers d'emplois, de tableaux et de rapports ETL non réalisables que seul un petit groupe de personnes spécialisées comprend, ce qui entraîne un impact positif sous-réalisé sur l'entreprise.
    • La deuxième génération : un écosystème de big data avec un data lake comme solution miracle ; un écosystème big data complexe et des travaux par lots de longue durée gérés par une équipe centrale d'ingénieurs de données hyper-spécialisés ont créé des monstres de lac de données qui, au mieux, ont permis des poches d'analyse R&D; plus promis et sous-réalisé.

    Les plateformes de données de troisième et actuelle génération sont plus ou moins similaires à la génération précédente, avec une touche moderne vers (a) le streaming pour la disponibilité des données en temps réel avec des architectures telles que Kappa , (b) unification du traitement par lots et par flux pour la transformation des données avec des frameworks tels qu'Apache Beam , ainsi que (c) intégrant pleinement les services gérés basés sur le cloud pour le stockage, les moteurs d'exécution de pipeline de données et les plateformes d'apprentissage automatique. Il est évident que la plate-forme de données de troisième génération comble certaines des lacunes des générations précédentes telles que l'analyse de données en temps réel , ainsi que réduire le coût de gestion de l'infrastructure Big Data . Cependant, il souffre de plusieurs caractéristiques sous-jacentes qui ont conduit aux échecs des générations précédentes.

    Modes de défaillance architecturale

    Pour décortiquer les limitations sous-jacentes de toutes les générations de plateformes de données, examinons leur architecture et leurs caractéristiques. Dans cet article, j'utilise le domaine des activités de streaming multimédia sur Internet telles que Spotify, SoundCloud, Apple iTunes, etc. comme exemple pour clarifier certains des concepts.

    Centralisé et monolithique

    À 30 000 pieds, l'architecture de la plate-forme de données ressemble à la figure 1 ci-dessous; une architecture centralisée dont le but est de:

    • Ingérer des données de tous les recoins de l'entreprise, allant des systèmes et domaines opérationnels et transactionnels qui gèrent l'entreprise, ou des fournisseurs de données externes qui augmentent les connaissances de l'entreprise. Par exemple, dans une entreprise de streaming multimédia, la plate-forme de données est responsable de l'ingestion d'une grande variété de données: les ‘performances des lecteurs multimédias’ la manière dont leurs ‘utilisateurs interagissent avec les lecteurs’, les ‘chansons qu'ils jouent’, les ‘artistes qu'ils suivent’, ainsi que en tant que «labels et artistes» que l'entreprise a intégrés, les «transactions financières» avec les artistes et les données d'études de marché externes telles que les informations «démographiques des clients».
    • Nettoyez, enrichissez et transformez les données sources en données fiables qui peuvent répondre aux besoins d'un ensemble diversifié de consommateurs. Dans notre exemple, l'une des transformations transforme les flux de clics de l'interaction de l'utilisateur en sessions significatives enrichies de détails sur l'utilisateur. Cela tente de reconstruire le parcours et le comportement de l'utilisateur en vues agrégées.
    • Servez les ensembles de données à une variété de consommateurs avec un ensemble diversifié de besoins. Cela va de la consommation analytique à l'exploration des données à la recherche d'informations, de la prise de décision basée sur l'apprentissage automatique, aux rapports de BI qui résument les performances de l'entreprise. Dans notre exemple de diffusion multimédia en continu, la plate-forme peut fournir des informations d'erreur et de qualité en temps quasi réel sur les lecteurs multimédias du monde entier via des interfaces de journal distribuées telles que Kafka ou servir les vues agrégées statiques des enregistrements d'un artiste particulier en cours de lecture pour piloter le calcul des paiements financiers. aux artistes et labels.

    Figure 1: La vue de 30000 pieds de la plate-forme de données monolithique

    C'est une convention acceptée selon laquelle la plate-forme de données monolithique héberge et possède les données qui appartiennent logiquement à différents domaines, par exemple «lire les événements», «les KPI de vente», «artistes», «albums», «étiquettes», «audio», «podcasts. »,« événements musicaux », etc .; données provenant d'un grand nombre de domaines disparates.

    Alors qu'au cours de la dernière décennie, nous avons appliqué avec succès la conception axée sur le domaine et le contexte à nos systèmes opérationnels, nous avons largement ignoré les concepts de domaine dans une plate-forme de données. Nous sommes passés de la propriété de données orientée domaine à une propriété de données centralisée indépendante du domaine . Nous sommes fiers de créer le plus grand monolithe de tous, la plate-forme Big Data.

    Figure 2: Plateforme de données centralisée sans limites de domaine de données claires et propriété des données orientées domaine

    Bien que ce modèle centralisé puisse fonctionner pour les organisations qui ont un domaine plus simple avec un plus petit nombre de cas de consommation divers, il échoue pour les entreprises avec des domaines riches, un grand nombre de sources et un ensemble diversifié de consommateurs.

    Il existe deux points de pression sur l'architecture et la structure organisationnelle d'une plateforme de données centralisée qui conduisent souvent à son échec:

    • Données omniprésentes et prolifération des sources: Au fur et à mesure que de plus en plus de données deviennent disponibles partout, la capacité de tout consommer et de l'harmoniser en un seul endroit sous le contrôle d'une plate-forme diminue. Imaginez juste dans le domaine de «l'information client», il existe un nombre croissant de sources à l'intérieur et à l'extérieur des frontières de l'organisation qui fournissent des informations sur les clients existants et potentiels. L'hypothèse selon laquelle nous devons ingérer et stocker les données en un seul endroit pour obtenir de la valeur à partir d'un ensemble diversifié de sources va limiter notre capacité à répondre à la prolifération des sources de données. Je reconnais la nécessité pour les utilisateurs de données tels que les data scientists et les analystes de traiter un ensemble diversifié d'ensembles de données avec une faible surcharge, ainsi que la nécessité de séparer l'utilisation des données des systèmes opérationnels des données consommées à des fins analytiques. Mais je propose que la solution centralisée existante n'est pas la réponse optimale pour les grandes entreprises avec des domaines riches et de nouvelles sources continuellement ajoutées.
    • Programme d'innovation des organisations et prolifération des consommateurs : le besoin d'expérimentation rapide des organisations introduit un plus grand nombre de cas d'utilisation pour la consommation des données de la plate-forme. Cela implique un nombre toujours croissant de transformations sur les données - agrégats, projections et tranches qui peuvent satisfaire le cycle de test et d'apprentissage de l'innovation . Le long temps de réponse pour satisfaire les besoins des consommateurs de données a toujours été un point de friction organisationnelle et le reste dans l'architecture de plate-forme de données moderne.

    Bien que je ne veuille pas donner ma solution pour l'instant, je dois préciser que je ne préconise pas des données fragmentées et cloisonnées orientées domaine souvent cachées dans les entrailles des systèmes opérationnels; données de domaine cloisonnées difficiles à découvrir, à comprendre et à consommer. Je ne préconise pas de multiples entrepôts de données fragmentés qui sont le résultat d'années de dettes technologiques accumulées. C'est une préoccupation que les dirigeants de l'industrie ont exprimée . Mais je soutiens que la réponse à ces silos accidentels de données inaccessibles ne consiste pas à créer une plate-forme de données centralisée, avec une équipe centralisée qui possède et gère les données de tous les domaines. Il n'est pas à l'échelle de l'organisation comme nous l'avons appris et démontré ci-dessus.

    Décomposition de pipeline couplé

    Le deuxième mode de défaillance d'une architecture de plate-forme de données traditionnelle est lié à la façon dont nous décomposons l'architecture. À 10 000 pieds en zoomant sur la plate-forme de données centralisée, nous trouvons une décomposition architecturale autour des fonctions mécaniques d' ingestion , de nettoyage , d'agrégation , de service , etc. Les architectes et les responsables techniques des organisations décomposent une architecture en réponse à la croissance de la plate-forme. Comme décrit dans la section précédente, la nécessité d'intégrer de nouvelles sources ou de répondre aux nouveaux consommateurs nécessite que la plate-forme se développe. Les architectes doivent trouver un moyen de faire évoluer le système en le décomposant en quanta architecturaux . Un quantum architectural, tel que décrit dans Building Evolutionary Architectures, est un composant déployable indépendamment avec une haute cohésion fonctionnelle, qui comprend tous les éléments structurels nécessaires au bon fonctionnement du système. La motivation derrière la décomposition d'un système en son quantum architectural est de créer des équipes indépendantes qui peuvent chacune construire et exploiter un quantum architectural. Parallélisez le travail entre ces équipes pour atteindre une évolutivité et une vitesse opérationnelles plus élevées.

    Compte tenu de l'influence des générations précédentes d'architecture des plateformes de données, les architectes décomposent la plate-forme de données en un pipeline d'étapes de traitement de données . Un pipeline qui à un très haut niveau met en œuvre une cohésion fonctionnelle autour de la mise en œuvre technique des traitements de données; c'est-à-dire des capacités d' ingestion , de préparation , d' agrégation , de service , etc.

    Figure 3: Décomposition architecturale de la plateforme de données

    Bien que ce modèle offre un certain niveau d'échelle, en affectant des équipes à différentes étapes du pipeline, il présente une limitation inhérente qui ralentit la livraison des fonctionnalités. Il a un couplage élevé entre les étapes du pipeline pour fournir une fonction ou une valeur indépendante. Il est décomposé orthogonalement à l'axe du changement .

    Regardons notre exemple de streaming multimédia. Les plateformes de diffusion multimédia en continu sur Internet ont une solide structure de domaine autour du type de média qu'elles offrent. Ils démarrent souvent leurs services avec des «chansons» et des «albums», puis s'étendent aux «événements musicaux», aux «podcasts», aux «émissions de radio», aux «films», etc. Activation d'une seule nouvelle fonctionnalité, telle que la visibilité sur le « podcasts play rate », nécessite un changement dans tous les composants du pipeline. Les équipes doivent introduire de nouveaux services d'ingestion, un nouveau nettoyage et une nouvelle préparation ainsi que des agrégats pour afficher les taux de lecture des podcasts. Cela nécessite une synchronisation entre la mise en œuvre des différents composants et la gestion des versions entre les équipes. De nombreuses plateformes de données fournissent des services d'ingestion génériques et basés sur la configuration qui peuvent faire face à des extensions telles que l'ajout de nouvelles sources facilement ou la modification des sources existantes pour minimiser la surcharge liée à l'introduction de nouvelles sources. Cependant, cela ne supprime pas la gestion des dépendances de bout en bout de l'introduction de nouveaux ensembles de données du point de vue du consommateur. Bien que sur le papier, l'architecture du pipeline puisse sembler avoir atteint un quantum architectural d'une étape de pipeline, en pratique, l'ensemble du pipeline, c'est-à-dire la plate-forme monolithique, est la plus petite unité qui doit changer pour répondre à une nouvelle fonctionnalité: déverrouiller un nouvel ensemble de données et le rendre disponible pour une consommation nouvelle ou existante.

    Figure 4: La décomposition de l'architecture est orthogonale à l'axe de changement lors de l'introduction ou de l'amélioration des caractéristiques, conduisant à un couplage et à une livraison plus lente

    Propriété cloisonnée et hyper-spécialisée

    Le troisième mode de défaillance des plateformes de données actuelles est lié à la façon dont nous structurons les équipes qui construisent et possèdent la plate-forme. Lorsque nous zoomons suffisamment près pour observer la vie des personnes qui construisent et exploitent une plate-forme de données, nous trouvons un groupe d'ingénieurs de données hyper-spécialisés isolés des unités opérationnelles de l'organisation; d'où proviennent les données ou où elles sont utilisées et mises en action et prise de décision. Les ingénieurs de la plate-forme de données sont non seulement cloisonnés sur le plan organisationnel, mais également séparés et regroupés en une équipe en fonction de leur expertise technique des outils Big Data, souvent absents des connaissances métier et du domaine.

    Figure 5: Équipe de plateforme de données hyper-spécialisée cloisonnée

    Personnellement, je n'envie pas la vie d'un ingénieur de plateforme de données. Ils doivent consommer des données d'équipes qui ne sont pas incitées à fournir des données significatives, véridiques et correctes. Ils ont très peu de connaissances sur les domaines sources qui génèrent les données et n'ont pas l'expertise du domaine dans leurs équipes. Ils doivent fournir des données pour un ensemble diversifié de besoins, opérationnels ou analytiques, sans une compréhension claire de l'application des données et un accès aux experts du domaine de consommation.

    Dans le domaine du streaming multimédia, par exemple, du côté source, nous avons des équipes de ‘lecteurs multimédias’ interfonctionnelles qui fournissent des signaux sur la manière dont les utilisateurs interagissent avec une fonctionnalité particulière qu'ils fournissent, par exemple ‘lire des événements de chanson’, ‘acheter des événements’, “qualité audio”, etc .; et à l'autre extrémité se trouvent les équipes interfonctionnelles de consommateurs telles que l'équipe de «recommandation de chanson», «l'équipe de vente» rapportant les indicateurs de performance clés de vente, «l'équipe de paiement des artistes» qui calcule et paie les artistes en fonction des événements de jeu, etc. Malheureusement, au milieu se trouve l'équipe de la plate-forme de données qui, grâce à de simples efforts, fournit des données appropriées pour toutes les sources et consommations.

    En réalité, ce que nous trouvons, ce sont des équipes sources déconnectées, des consommateurs frustrés qui se battent pour une place au-dessus du backlog de l'équipe de la plate-forme de données et une équipe de plate-forme de données surchargée.

    Nous avons créé une architecture et une structure organisationnelle qui ne s'adaptent pas et ne fournissent pas la valeur promise de créer une organisation basée sur les données.

    La prochaine architecture de plateforme de données d'entreprise

    Il embrasse les données omniprésentes avec un Data-Mesh distribué .

    Alors, quelle est la réponse aux modes de défaillance et aux caractéristiques dont nous avons discuté ci-dessus? À mon avis, un changement de paradigme est nécessaire. Un changement de paradigme à l'intersection de techniques qui ont contribué à la construction d'une architecture distribuée moderne à grande échelle; Des techniques que l'industrie de la technologie dans son ensemble a adoptées à un rythme accéléré et qui ont donné des résultats positifs.

    Je suggère que la prochaine architecture de plate-forme de données d'entreprise se situe dans la convergence de l'architecture pilotée par domaine distribué, de la conception de plate-forme libre-service et de la réflexion produit avec les données.

    Figure 6: Convergence: le changement de paradigme pour construire les prochaines plateformes de données

    Bien que cela puisse sembler beaucoup de mots à la mode dans une phrase, chacune de ces techniques a eu un impact spécifique et incroyablement positif dans la modernisation des fondements techniques des systèmes opérationnels. Explorons en profondeur comment nous pouvons appliquer chacune de ces disciplines au monde des données pour échapper au paradigme actuel, hérité d'années d'architecture d'entreposage de données héritée.

    Convergence de l'architecture pilotée par les données et le domaine distribué

    Décomposition et propriété des données orientées domaine

    Le livre d'Eric Evans Domain-Driven Design a profondément influencé la pensée architecturale moderne et, par conséquent, la modélisation organisationnelle. Il a influencé l'architecture des microservices en décomposant les systèmes en services distribués construits autour des capacités du domaine métier. Cela a fondamentalement changé la façon dont les équipes se forment, de sorte qu'une équipe puisse posséder de manière indépendante et autonome une capacité de domaine.

    Bien que nous ayons adopté la décomposition et la propriété orientées domaine lors de la mise en œuvre des capacités opérationnelles, nous avons curieusement ignoré la notion de domaine métier lorsqu'il s'agit de données. L'application la plus proche de DDD dans l'architecture de plate-forme de données est pour les systèmes opérationnels source d'émettre leurs événements de domaine métier et pour la plate-forme de données monolithique pour les ingérer. Cependant, au-delà du point d'ingestion, le concept de domaines et la propriété des données de domaine par différentes équipes sont perdus.

    Domain Bounded Context est un outil merveilleusement puissant pour concevoir la propriété des ensembles de données. L'article de Ben Stopford sur la dichotomie des données décompose le concept de partage d'ensembles de données de domaine via des flux.

    Afin de décentraliser la plate-forme de données monolithique, nous devons inverser notre façon de penser les données, leur localité et leur propriété. Au lieu de transférer les données des domaines vers un lac de données ou une plate-forme centralisée, les domaines doivent héberger et servir leurs ensembles de données de domaine d'une manière facilement consommable.

    Dans notre exemple, au lieu d'imaginer des données provenant de lecteurs multimédias dans une sorte d'endroit centralisé pour qu'une équipe centralisée les reçoive, pourquoi ne pas imaginer un domaine de joueur possédant et servant leurs ensembles de données pour l'accès par n'importe quelle équipe à n'importe quelle fin en aval. L'emplacement physique où résident réellement les ensembles de données et leur flux est une implémentation technique du «domaine du joueur». Le stockage physique pourrait certainement être une infrastructure centralisée telle que les compartiments Amazon S3, mais le contenu et la propriété des ensembles de données des joueurs restent avec le domaine qui les génère. De même dans notre exemple, le domaine «recommandations» crée des ensembles de données dans un format adapté à son application, comme une base de données de graphes, tout en consommant les ensembles de données du joueur.

    Cela implique que nous pouvons dupliquer des données dans différents domaines lorsque nous les transformons en une forme qui convient à ce domaine particulier, par exemple un événement de lecture de séries chronologiques sur un graphique d'artistes apparentés.

    Cela nécessite de déplacer notre réflexion d'un modèle push and ingest, traditionnellement via les ETL et plus récemment via des flux d'événements, vers un modèle de service et d'attraction dans tous les domaines.

    Le quantum architectural dans une plate-forme de données orientée domaine, est un domaine et non l'étape du pipeline.

    Figure 7: Décomposition de l'architecture et des équipes possédant les données en fonction des domaines - domaines partagés source, consommateur et nouvellement créés

    Données de domaine orientées “source”

    Certains domaines s'alignent naturellement sur la source, d'où proviennent les données. Les ensembles de données du domaine source représentent les faits et la réalité de l'entreprise. Les jeux de données du domaine source capturent les données qui sont mappées très étroitement à ce que les systèmes opérationnels de leur origine, les systèmes de réalité, produisent. Dans notre exemple, des faits de l'entreprise tels que ‘comment les utilisateurs interagissent avec les services’ ou ‘le processus d'intégration des étiquettes’ conduisent à la création d'ensembles de données de domaine tels que ‘flux de clics utilisateur”, ‘flux de qualité de lecture audio’ et ‘étiquettes intégrées’. Ces faits sont mieux connus et générés par les systèmes opérationnels qui se trouvent au point d'origine. Par exemple, le système de lecteur multimédia connaît mieux les «flux de clics des utilisateurs».

    Dans une situation mature et idéale, un système opérationnel et son équipe ou unité organisationnelle sont non seulement responsables de fournir des capacités commerciales, mais également de fournir les vérités de leur domaine d'activité sous forme d'ensembles de données de domaine source. À l'échelle de l'entreprise, il n'y a jamais de mappage un à un entre un concept de domaine et un système source. Il existe souvent de nombreux systèmes qui peuvent servir des parties des données appartenant à un domaine, certaines héritées et d'autres faciles à modifier. Par conséquent, il pourrait y avoir de nombreux ensembles de données alignés source aka ensembles de données de réalité qui doivent finalement être agrégées à un ensemble de données de domaine cohérent et aligné.

    Les faits commerciaux sont mieux présentés sous forme d'événements de domaine d’entreprise, peuvent être stockés et servis sous forme de journaux distribués d'événements horodatés auxquels tout consommateur autorisé peut accéder.

    Outre les événements horodatés, les domaines de données sources doivent également fournir des instantanés historiques facilement consommables des ensembles de données du domaine source, agrégés sur un intervalle de temps reflétant étroitement l'intervalle de changement pour leur domaine. Par exemple, dans un domaine source ‘étiquettes intégrées’, qui montre les étiquettes des artistes qui fournissent de la musique à l'entreprise de streaming, l'agrégation des étiquettes intégrées sur une base mensuelle est une vue raisonnable à fournir en plus des événements générés par le processus de étiquettes d'intégration.

    Notez que les ensembles de données du domaine aligné sur la source doivent être séparés des ensembles de données des systèmes source internes. La nature des jeux de données du domaine est très différente des données internes que les systèmes opérationnels utilisent pour faire leur travail. Ils ont un volume beaucoup plus important, représentent des faits chronométrés immuables et changent moins fréquemment que leurs systèmes. Pour cette raison, le stockage sous-jacent réel doit être adapté au Big Data et séparé des bases de données opérationnelles existantes. La section Convergence de la conception des données et des plateformes libre-service décrit comment créer une infrastructure de stockage et de service de Big Data.

    Les ensembles de données du domaine source sont les ensembles de données les plus fondamentaux et changent moins souvent, car les faits commerciaux ne changent pas si souvent. On s'attend à ce que ces ensembles de données de domaine soient capturés et rendus disponibles en permanence, de sorte que, au fur et à mesure que l'organisation fait évoluer ses services de données et de business intelligence, ils puissent toujours revenir aux faits commerciaux et créer de nouvelles agrégations ou projections.

    Notez que les ensembles de données du domaine source représentent étroitement les données brutes au point de création et ne sont ni ajustés ni modélisés pour un consommateur particulier.

    Données de domaine partagées et orientées consommateur

    Certains domaines correspondent étroitement à la consommation. Les ensembles de données du domaine consommateur et les équipes qui les possèdent visent à satisfaire un groupe de cas d'utilisation étroitement liés. Par exemple, le «domaine de recommandation sociale» qui se concentre sur la fourniture de recommandations basées sur les connexions sociales des utilisateurs entre eux, créez des ensembles de données de domaine qui répondent à ce besoin spécifique; peut-être par une «représentation graphique du réseau social des utilisateurs». Bien que cet ensemble de données graphiques soit utile pour un cas d'utilisation de recommandation, il peut également être utile pour un domaine ‘notifications d'écouteurs’, qui fournit des données concernant différents types de notifications envoyées à l'auditeur, y compris ce que les personnes de leur réseau social écoutent. Il est donc possible que le «réseau social des utilisateurs» devienne un ensemble de données de domaine partagé et nouvellement réifié que plusieurs consommateurs peuvent utiliser. L'équipe du domaine «réseau social utilisateur» se concentre sur la fourniture d'une vue toujours organisée et actualisée du «réseau social utilisateur».

    Les ensembles de données de domaine alignés sur le consommateur ont une nature différente de celle des ensembles de données de domaines source. Ils subissent structurellement plus de changements et transforment les événements du domaine source pour agréger des vues et des structures adaptées à un modèle d'accès particulier, comme l'exemple de graphique que nous avons vu ci-dessus. Une plate-forme de données orientée domaine devrait être en mesure de régénérer facilement ces ensembles de données consommateurs à partir de la source.

    Pipelines distribués comme implémentation interne du domaine

    Alors que la propriété des ensembles de données est déléguée de la plate-forme centrale aux domaines, le besoin de nettoyage, de préparation, d'agrégation et de diffusion des données demeure, tout comme l'utilisation du pipeline de données. Dans cette architecture, un pipeline de données est simplement une complexité interne et une implémentation du domaine de données et est géré en interne au sein du domaine. En conséquence, nous assisterons à une répartition des étapes des pipelines de données dans chaque domaine.

    Par exemple, les domaines sources doivent inclure le nettoyage, la déduplication et l'enrichissement de leurs événements de domaine afin qu'ils puissent être consommés par d'autres domaines, sans réplication du nettoyage. Chaque jeu de données de domaine doit établir des objectifs de niveau de service pour la qualité des données qu'il fournit: actualité, taux d'erreur, etc. Par exemple, notre domaine de lecteur multimédia fournissant un ‘flux de clics de lecture’ audio peut inclure le nettoyage et la normalisation du pipeline de données dans leur domaine qui fournit un flux de "lecture d'événements de clic audio" dédupliqué en temps quasi réel qui sont conformes aux normes d'encodage d'événements de l'organisation.

    De même, nous verrons que les étapes d'agrégation d'un pipeline centralisé se déplacent vers les détails de mise en œuvre des domaines consommateurs.

    Figure 8: Distribuez les pipelines dans les domaines en tant que préoccupation de deuxième classe et le détail d'implémentation interne du domaine

    On pourrait soutenir que ce modèle pourrait conduire à des efforts dupliqués dans chaque domaine pour créer leur propre mise en œuvre de pipeline de traitement de données, leur pile technologique et leurs outils. J'aborderai cette préoccupation sous peu lorsque nous parlerons de la convergence des données et de la réflexion sur les plateformes avec une infrastructure de données partagée en libre-service en tant que plate-forme.

    Convergence de la réflexion sur les données et les produits

    La répartition de la propriété des données et de la mise en œuvre du pipeline de données entre les mains des domaines d'activité soulève une préoccupation importante concernant l'accessibilité, la convivialité et l'harmonisation des ensembles de données distribués. C'est là que l'apprentissage de l'application de la réflexion sur les produits et de la propriété des actifs de données est utile.

    Domaine de données “as a product”

    Au cours de la dernière décennie, les domaines opérationnels ont intégré la réflexion sur les produits aux capacités qu'ils offrent au reste de l'organisation. Les équipes de domaine fournissent ces fonctionnalités en tant qu'API au reste des développeurs de l'organisation, en tant que blocs de construction pour créer une valeur et des fonctionnalités d'ordre supérieur. Les équipes s'efforcent de créer la meilleure expérience développeur pour leurs API de domaine; y compris une documentation d'API découvrable et compréhensible, des sandbox de test d'API et des KPI de qualité et d'adoption étroitement suivis.

    Pour qu'une plateforme de données distribuée réussisse, les équipes de données de domaine doivent appliquer la réflexion sur les produits avec une rigueur similaire aux ensembles de données qu'elles fournissent; considérant leurs actifs de données comme leurs produits et le reste des scientifiques des données, du ML et des ingénieurs des données de l'organisation comme leurs clients.

    Figure 9: Caractéristiques des jeux de domaine de données en tant que produit

    Prenons notre exemple, l'entreprise de streaming multimédia sur Internet. L'un des domaines critiques est les «événements de lecture», quelles chansons ont été jouées par qui, quand et où. Ce domaine clé possède différents consommateurs dans l'organisation; par exemple les consommateurs en temps quasi réel qui s'intéressent à l'expérience de l'utilisateur et éventuellement aux erreurs afin qu'en cas d'expérience client dégradée ou d'un appel d'assistance client entrant, puissent répondre rapidement pour récupérer l'erreur. Quelques consommateurs préféreraient également les instantanés historiques des agrégats quotidiens ou mensuels d'événements de lecture de chansons.

    Dans ce cas, notre domaine «chansons jouées» fournit deux ensembles de données différents en tant que produits au reste de l'organisation; des événements de lecture en temps réel exposés sur des flux d'événements et des événements de lecture agrégés exposés sous forme de fichiers sérialisés sur un magasin d'objets.

    Une qualité importante de tout produit technique, dans ce cas les produits de domaine de données, est de satisfaire leurs consommateurs; dans ce cas, des ingénieurs de données, des ingénieurs en Machine Learning ou Data Scientists. Pour offrir la meilleure expérience utilisateur aux consommateurs, les produits de domaine de données doivent présenter les qualités de base suivantes:

    Découvrable

    Un Data Product doit être facilement détectable. Une implémentation courante consiste à disposer d'un registre, d'un catalogue de données, de tous les Data Products disponibles avec leurs méta-informations telles que leurs propriétaires, leur source d'origine, leur lignage, des exemples d'ensembles de données, etc. Ce service de découvrabilité centralisé permet aux consommateurs de données, aux ingénieurs et aux scientifiques de une organisation, pour trouver facilement un ensemble de données qui les intéresse. Chaque produit de domaine de données doit s'enregistrer auprès de ce catalogue de données centralisé pour une découverte facile.

    Notez que le changement de perspective ici est d'une plate-forme unique extrayant et détenant les données pour son utilisation, à chaque domaine fournissant ses données en tant que produit d'une manière découvrable .

    Adressable

    Un Data Product, une fois découvert, doit avoir une adresse unique suivant une convention globale qui aide ses utilisateurs à y accéder par programme. Les organisations peuvent adopter différentes conventions de dénomination pour leurs données, en fonction du stockage sous-jacent et du format des données. Considérant la facilité d'utilisation comme un objectif, dans une architecture décentralisée, il est nécessaire de développer des conventions communes. Différents domaines peuvent stocker et servir leurs ensembles de données dans différents formats, les événements peuvent être stockés et accessibles via des flux tels que des rubriques Kafka, des ensembles de données en colonnes peuvent utiliser des fichiers CSV ou des compartiments AWS S3 de fichier sérialisé en Parque. Une norme d'adressabilité des ensembles de données dans un environnement polyglotte supprime les frictions lors de la recherche et de l'accès aux informations.

    Digne de confiance et véridique

    Personne n'utilisera un produit auquel il ne peut pas faire confiance. Dans les plateformes de données traditionnelles, il est acceptable d'extraire et d'intégrer des données contenant des erreurs, ne reflétant pas la vérité de l'entreprise et ne pouvant tout simplement pas faire confiance. C'est là que se concentrent la majorité des efforts des pipelines de données centralisés, nettoyant les données après l'ingestion.

    Un changement fondamental exige que les propriétaires des Data Products fournissent un objectif de niveau de service acceptable en ce qui concerne la véracité des données et dans quelle mesure il reflète la réalité des événements qui se sont produits ou la forte probabilité de la véracité des informations qui ont été générées. L'application du nettoyage des données et des tests automatisés d'intégrité des données au moment de la création du Data Product font partie des techniques à utiliser pour fournir un niveau de qualité acceptable. Fournir la provenance des données et le lignage des données car les métadonnées associées à chaque Data Product aident les consommateurs à gagner en confiance dans le Data Product et à sa pertinence pour leurs besoins particuliers.

    La valeur ou la plage cible d'un indicateur d'intégrité (qualité) des données varie selon les Data Products de domaine. Par exemple, le domaine «play event» peut fournir deux Data Products différents, un en temps quasi réel avec un niveau de précision inférieur, y compris des événements manquants ou en double, et un avec un délai plus long et un niveau de précision des événements plus élevé. Chaque Data Product définit et garantit le niveau cible de son intégrité et de sa véracité en tant qu'ensemble de SLO.

    Sémantique et syntaxe auto-descriptives

    Les produits de qualité ne nécessitent aucune prise en main par le consommateur: ils peuvent être découverts, compris et consommés de manière indépendante. Construire des ensembles de données en tant que produits avec un minimum de friction pour que les ingénieurs de données et les scientifiques des données les utilisent nécessite une sémantique et une syntaxe bien décrites des données, idéalement accompagnées d'exemples de jeux de données comme exemples. Les schémas de données sont un point de départ pour fournir des actifs de données en libre-service.

    Interopérable et régi par des normes globales

    L'une des principales préoccupations d'une architecture de données de domaine distribué est la capacité à corréler les données entre les domaines et à les assembler de manière merveilleuse et perspicace; rejoindre, filtrer, agréger, etc. La clé pour une corrélation efficace des données entre les domaines est de suivre certaines normes et règles d'harmonisation. Ces normalisations devraient appartenir à une gouvernance mondiale, pour permettre l'interopérabilité entre les ensembles de données du domaine polyglotte. Les préoccupations communes de ces efforts de normalisation sont le formatage du type de champ, l'identification des polysèmes dans différents domaines, les conventions d'adresse des ensembles de données, les champs de métadonnées communs, les formats d'événements tels que CloudEvents , etc.

    Par exemple, dans le secteur de la diffusion multimédia en continu, un «artiste» peut apparaître dans différents domaines et avoir des attributs et des identifiants différents dans chaque domaine. Le domaine «play eventstream» peut reconnaître l'artiste différemment du domaine «paiement des artistes» qui prend en charge les factures et les paiements. Cependant, pour être en mesure de corréler les données sur un artiste à travers différents Data Products de domaine, nous devons nous entendre sur la façon dont nous identifions un artiste en tant que polysème. Une approche consiste à considérer «l'artiste» avec une entité fédérée et un identifiant d'entité fédérée global unique pour «l'artiste», de la même manière que les identités fédérées sont gérées.

    L'interopérabilité et la normalisation des communications, régies à l'échelle mondiale, sont l'un des piliers fondamentaux de la construction de systèmes distribués.

    Sécurisé et régi par un contrôle d'accès global

    L'accès sécurisé aux ensembles de données produits est indispensable, que l'architecture soit centralisée ou non. Dans le monde des Data Products décentralisés orientés domaine, le contrôle d'accès est appliqué avec une granularité plus fine, pour chaque Data Product de domaine. À l'instar des domaines opérationnels, les politiques de contrôle d'accès peuvent être définies de manière centralisée mais appliquées au moment de l'accès à chaque produit de jeu de données individuel. L'utilisation du système de gestion d'identité d'entreprise (SSO) et de la définition de stratégie de contrôle d'accès basé sur les rôles est un moyen pratique de mettre en œuvre le contrôle d'accès aux ensembles de données de produit.

    La section Convergence de la conception des plateformes de données et de libre-service décrit l'infrastructure partagée qui permet les capacités ci-dessus pour chaque Data Product facilement et automatiquement.

    Équipes interfonctionnelles de données de domaine

    Les domaines qui fournissent des données en tant que produits doivent être complétés par de nouveaux ensembles de compétences: (a) le Data Product Owner et (b) les Data Engineers .

    Un Data Product Owner prend des décisions autour de la vision et de la feuille de route pour les Data Products, se préoccupe de la satisfaction de ses consommateurs et mesure et améliore en permanence la qualité et la richesse des données que son domaine possède et produit. Elle est responsable du cycle de vie des ensembles de données du domaine, du moment où changer, réviser et retirer les données et les schémas. Elle trouve un équilibre entre les besoins concurrents des consommateurs de données de domaine.

    Les Data Product Owners doivent définir des critères de réussite et des indicateurs clés de performance (KPI) axés sur l'activité pour leurs Data Products. Par exemple, le délai nécessaire aux consommateurs d'un Data Product pour découvrir et utiliser le Data Product avec succès est un critère de succès mesurable.

    Afin de créer et d'exploiter les pipelines de données internes des domaines, les équipes doivent inclure des Data Engineers. Un effet secondaire merveilleux d'une telle équipe interfonctionnelle est la pollinisation croisée de différentes compétences. Mon observation actuelle de l'industrie est que certains Data Engineers, bien que compétents dans l'utilisation des outils de leur métier, manquent de pratiques standard en matière d'ingénierie logicielle, telles que la livraison continue et les tests automatisés, lorsqu'il s'agit de créer des actifs de données. De même, les ingénieurs en logiciel qui construisent des systèmes opérationnels n'ont souvent aucune expérience de l'utilisation d'ensembles d'outils d'ingénierie de données. La suppression des silos de compétences conduira à la création d'un pool de compétences de plus en plus large en ingénierie des données à la disposition de l'organisation. SRE .

    Les données doivent être traitées comme un élément fondamental de tout écosystème logiciel.Par conséquent, les ingénieurs en logiciel et les généralistes en logiciel doivent ajouter l'expérience et les connaissances du développement de Data Products à leur ceinture d'outils. De même, les ingénieurs d'infrastructure doivent ajouter des connaissances et une expérience de la gestion d'une infrastructure de données. Les organisations doivent proposer des parcours de développement de carrière allant d'un généraliste à un Data Engineer. Le manque de compétences en ingénierie de données a conduit à l'optimisation locale de la formation d'équipes d'ingénierie de données centralisées comme décrit dans la section Propriété cloisonnée et hyper-spécialisée .

    Figure 10: Équipes de données inter-domaines fonctionnelles avec propriété explicite du Data Product

    Convergence de la conception des plateformes de données et de libre-service

    L'une des principales préoccupations liées à la répartition de la propriété des données entre les domaines est la duplication des efforts et des compétences nécessaires pour exploiter la pile technologique et l'infrastructure des pipelines de données dans chaque domaine. Heureusement, la construction d'une infrastructure commune en tant que plate-forme est un problème bien compris et résolu; bien qu'il soit vrai que les outils et les techniques ne sont pas aussi matures dans l'écosystème de données.

    La collecte et l'extraction de capacités d'infrastructure indépendantes du domaine dans une plate-forme d'infrastructure de données résout le besoin de dupliquer l'effort de configuration des moteurs de pipeline de données, du stockage et de l'infrastructure de streaming. Une équipe d'infrastructure de données peut posséder et fournir la technologie nécessaire dont les domaines ont besoin pour capturer, traiter, stocker et servir leurs Data Products.

    Figure 11: Extraction et récolte de l'infrastructure de pipeline de données indépendante du domaine et de l'outillage dans une infrastructure de données distincte en tant que plate-forme

    La clé pour construire l' infrastructure de données en tant que plate - forme est (a) de ne pas inclure de concepts ou de logique métier spécifiques à un domaine, en la gardant indépendante du domaine, et (b) de s'assurer que la plate-forme cache toute la complexité sous-jacente et fournit les composants d'infrastructure de données dans une manière en libre-service. Il existe une longue liste de fonctionnalités qu'une infrastructure de données libre-service en tant que plate-forme fournit à ses utilisateurs, les ingénieurs de données d'un domaine. En voici quelques-uns:

    • Stockage de Big Data polyglotte évolutif
    • Chiffrement des données au repos et en mouvement
    • Gestion des versions des Data Products
    • Schéma du Data Product
    • Désidentification des Data Products
    • Contrôle d'accès et journalisation unifiés aux données
    • Implémentation et orchestration du pipeline de données
    • Découverte de Data Products, enregistrement et publication de catalogues
    • Gouvernance et normalisation des données
    • Lignée de Data Products
    • Surveillance / alerte / journal des Data Products
    • Mesures de qualité des Data Products (collecte et partage)
    • En mémoire cache des données
    • Gestion des identités fédérées
    • Calcul et localité des données

    L'un des critères de réussite de l'infrastructure de données en libre-service est de réduire le «délai de création d'un nouveau Data Product» sur l'infrastructure. Cela conduit à l'automatisation, nécessaire pour mettre en œuvre les capacités d'un «Data Product», comme décrit dans la section Domaine de données en tant que produit. Par exemple, automatisation de l'ingestion de données via des configurations et des scripts, des scripts de création de Data Products pour mettre en place des échafaudages, enregistrement automatique d'un Data Product avec le catalogue, etc.

    L'utilisation de l'infrastructure cloud comme substrat réduit les coûts opérationnels et les efforts requis pour fournir un accès à la demande à l'infrastructure de données, mais cela ne supprime pas complètement les abstractions supérieures qui doivent être mises en place dans le contexte de l'entreprise. Quel que soit le fournisseur de cloud, il existe un ensemble riche et toujours croissant de services d'infrastructure de données disponibles pour l'équipe infra de données.

    Le changement de paradigme vers un Data-Mesh

    Cela a été une longue lecture. Rassemblons tout cela.

    Nous avons examiné certaines des caractéristiques sous-jacentes des plateformes de données actuelles: centralisées, monolithiques, avec une architecture de pipeline hautement couplée, exploitées par des silos de data engineers hyper-spécialisés . Nous avons introduit les éléments constitutifs d'un Data-Mesh omniprésent en tant que plate-forme; Data Products distribués orientés autour de domaines et détenus par des équipes interfonctionnelles indépendantes qui ont des ingénieurs de données et des propriétaires de Data Products intégrés, utilisant une infrastructure de données commune comme plateforme pour héberger, préparer et servir leurs actifs de données.

    La plateforme de Data-Mesh est une architecture de données distribuée conçue intentionnellement, sous une gouvernance centralisée et une normalisation pour l'interopérabilité, rendue possible par une infrastructure de données libre-service partagée et harmonisée. J'espère qu'il est clair que c'est loin d'être un paysage de silos fragmentés de données inaccessibles.

    Figure 12: Architecture de Data-Mesh depuis une vue de 30 000 pieds



    Thèmes : Data, Data Lake, Machine Learning, Data Architecture, Data Scientist, Data Engineer, temps réel, Data Mesh

    Laurent Letourmy

    Par Laurent Letourmy

    Ingénieur Epita, il a débuté sa carrière dans le groupe Cross Systems dont il a co-fondé la filiale parisienne en 1996. La société connaît une forte croissance et le groupe s'introduit sur le Nouveau Marché en 1999 et atteindra une capitalisation de 800M€. Spécialiste reconnu des architectures transactionnelles, il y exerce diverses responsabilités techniques, managériales et commerciales et travaille avec des clients tels que le Club Med, Voyages-Sncf.com, Orange. Entrepreneur passionné de technologies innovantes, vainqueur de deux hackathons dans la Silicon Valley, investisseur actif au sein de nombreux projets pionniers B2B et B2C. En 2005, il co-fonde et dirige Ysance qui connaît un fort développement depuis ses débuts.

    S'abonner au blog