Technology

Data mesh vs. data fabric : éliminez les humains ou utilisez-les plus intelligemment

La découverte, l’accès et l’intégration de nouveaux ensembles de données à utiliser dans l’analyse de données, la science des données et d’autres tâches de pipeline de données est généralement un processus lent dans les grandes organisations complexes. Ces organisations disposent généralement de centaines de milliers d’ensembles de données qui sont activement gérés à travers une variété de magasins de données en interne et ont accès à des ordres de grandeur d’ensembles de données externes supplémentaires. Le simple fait de trouver des données pertinentes pour un processus particulier est une tâche presque écrasante.

Même une fois que les données pertinentes ont été identifiées, passer par les processus d’approbation, de gouvernance et de mise en scène nécessaires à l’utilisation réelle de ces données peut prendre plusieurs mois en pratique. C’est souvent un obstacle majeur à l’agilité organisationnelle. Les scientifiques et les analystes de données sont poussés à utiliser des données pré-approuvées et pré-organisées trouvées dans des référentiels centralisés, tels que des entrepôts de données, au lieu d’être encouragés à utiliser un éventail plus large d’ensembles de données dans leur analyse.

De plus, même une fois que les données de nouveaux ensembles de données deviennent disponibles pour être utilisées dans des tâches analytiques, le fait qu’elles proviennent de différentes sources de données implique généralement qu’elles ont une sémantique de données différente, ce qui rend difficile l’unification et l’intégration de ces ensembles de données. Par exemple, ils peuvent faire référence aux mêmes entités du monde réel en utilisant des identifiants différents en tant qu’ensembles de données existants ou peuvent associer différents attributs (et types de ces attributs) aux entités du monde réel modélisées dans des ensembles de données existants. De plus, les données sur ces entités sont susceptibles d’être échantillonnées en utilisant un contexte différent par rapport aux ensembles de données existants. Les différences sémantiques entre les ensembles de données rendent difficile leur intégration dans la même tâche analytique, réduisant ainsi la possibilité d’obtenir une vue holistique des données.

Relever les défis de l’intégration des données

Néanmoins, malgré tous ces défis, il est essentiel que ces tâches de découverte, d’intégration et de mise en scène des données soient effectuées pour que les analystes de données et les scientifiques d’une organisation réussissent. Cela se fait généralement aujourd’hui grâce à un effort humain important, certains au nom de la personne effectuant l’analyse, mais la plupart sont effectués par des équipes centralisées, en particulier en ce qui concerne l’intégration, le nettoyage et la mise en scène des données. Le problème, bien sûr, est que les équipes centralisées deviennent des goulots d’étranglement organisationnels, ce qui entrave davantage l’agilité. Le statu quo actuel n’est acceptable pour personne et plusieurs propositions ont émergé pour résoudre ce problème.

Deux des propositions les plus connues sont le « data fabric » et le « data mesh ». Plutôt que de se concentrer sur un aperçu de ces idées, cet article se concentre plutôt sur l’application de la structure de données et du maillage de données spécifiquement au problème de l’intégration des données, et sur la façon dont ils abordent le défi d’éliminer la dépendance à une équipe centralisée à l’échelle de l’entreprise pour effectuer cette intégration.

Prenons l’exemple d’un constructeur automobile américain qui rachète un autre constructeur automobile en Europe. Le constructeur automobile américain gère une base de données de pièces, détaillant les informations sur toutes les différentes pièces nécessaires à la fabrication d’une voiture – fournisseur, prix, garantie, inventaire, etc. Ces données sont stockées dans une base de données relationnelle – par exemple, PostgreSQL. Le constructeur automobile européen gère également une base de données de pièces, stockée en JSON dans une base de données MongoDB. Évidemment, l’intégration de ces deux ensembles de données serait très utile, car il est beaucoup plus facile de traiter une seule base de données de pièces que deux distinctes, mais les défis sont nombreux. Ils sont stockés dans différents formats (relationnels ou imbriqués), par différents systèmes, utilisent différents termes et identifiants, et même différentes unités pour divers attributs de données (par exemple, pieds ou mètres, dollars ou euros). L’exécution de cette intégration représente beaucoup de travail, et si elle est effectuée par une équipe centrale à l’échelle de l’entreprise, cela pourrait prendre des années.

Automatisation avec l’approche Data Fabric

L’approche Data Fabric tente d’automatiser autant que possible le processus d’intégration avec peu ou pas d’effort humain. Par exemple, il utilise des techniques d’apprentissage automatique (ML) pour découvrir le chevauchement des attributs (par exemple, ils contiennent tous deux des informations sur le fournisseur et la garantie) et les valeurs des ensembles de données (par exemple, de nombreux fournisseurs d’un ensemble de données apparaissent dans l’autre ensemble de données). ainsi ) pour signaler ces deux ensembles de données comme candidats à l’intégration en premier lieu.

ML peut également être utilisé pour convertir l’ensemble de données JSON en un modèle relationnel : les dépendances fonctionnelles logicielles qui existent dans l’ensemble de données JSON sont découvertes (par exemple, chaque fois que nous voyons une valeur pour supplier_name de X, nous voyons supplier_address de Y) et utilisées pour identifier des groupes d’attributs susceptibles de correspondre à une entité sémantique indépendante (par exemple, une entité fournisseur), et créer des tables pour ces entités et les clés étrangères associées dans des tables parentes. Les entités dont les domaines se chevauchent peuvent être fusionnées, le résultat final étant un schéma relationnel complet. (Une grande partie de cela peut en fait être fait sans ML, comme avec l’algorithme décrit dans ce SIGMOD 2016 document de recherche.)

Ce schéma relationnel produit à partir du jeu de données européen peut ensuite être intégré au schéma relationnel existant du jeu de données américain. ML peut également être utilisé dans ce processus. Par exemple, l’historique des requêtes peut être utilisé pour observer comment les analystes accèdent à ces ensembles de données individuels par rapport à d’autres ensembles de données et découvrir des similitudes dans les modèles d’accès. Ces similitudes peuvent être utilisées pour relancer le processus d’intégration des données. De même, ML peut être utilisé pour le mappage d’entités sur des ensembles de données. À un moment donné, les humains doivent s’impliquer dans la finalisation de l’intégration des données, mais plus les techniques de Data Fabric peuvent automatiser les étapes clés du processus, moins les humains ont de travail à faire, ce qui les rend moins susceptibles de devenir un goulot d’étranglement.

L’approche du maillage de données centré sur l’humain

Le maillage de données adopte une approche totalement différente de ce même problème d’intégration de données. Bien que le ML et les techniques automatisées ne soient certainement pas découragées dans le maillage de données, fondamentalement, les humains jouent toujours un rôle central dans le processus d’intégration. Néanmoins, ces humains ne forment pas une équipe centralisée, mais plutôt un ensemble d’experts du domaine.

Chaque jeu de données appartient à un domaine particulier qui possède une expertise dans ce jeu de données. Cette équipe est chargée de mettre cet ensemble de données à la disposition du reste de l’entreprise en tant que produit de données. Si un autre ensemble de données arrive et que, s’il est intégré à un ensemble de données existant, il augmenterait l’utilité de l’ensemble de données d’origine, la valeur du produit de données d’origine augmenterait si l’intégration des données était effectuée.

Dans la mesure où ces équipes d’experts du domaine sont incitées lorsque la valeur du produit de données qu’elles produisent augmente, elles seront motivées à effectuer elles-mêmes le travail acharné de l’intégration des données. En fin de compte, l’intégration est effectuée par des experts du domaine qui comprennent bien les données des pièces automobiles, au lieu d’une équipe centralisée qui ne connaît pas la différence entre un radiateur et une calandre.

Transformer le rôle des humains dans la gestion des données

En résumé, la structure de données nécessite toujours une équipe humaine centrale qui exécute des fonctions critiques pour l’orchestration globale de la structure. Néanmoins, en théorie, il est peu probable que cette équipe devienne un goulot d’étranglement organisationnel car une grande partie de son travail est automatisée par les processus d’intelligence artificielle dans le tissu.

En revanche, dans le maillage de données, l’équipe humaine n’est jamais sur le chemin critique d’une tâche effectuée par des consommateurs ou des producteurs de données. Cependant, l’accent est beaucoup moins mis sur le remplacement des humains par des machines, et à la place, l’accent est mis sur le transfert de l’effort humain vers les équipes réparties d’experts du domaine qui sont les plus impliqués dans son exécution.

En d’autres termes, la structure de données consiste fondamentalement à éliminer l’effort humain, tandis que le maillage de données concerne une utilisation plus intelligente et plus efficace de l’effort humain.

Bien sûr, il semblerait de prime abord qu’éliminer l’effort humain soit toujours mieux que de le réaffecter. Cependant, malgré les incroyables avancées récentes que nous avons réalisées en ML, nous n’en sommes toujours pas au point aujourd’hui où nous pouvons faire entièrement confiance aux machines pour effectuer ces activités clés de gestion et d’intégration de données qui sont aujourd’hui effectuées par des humains.

Tant que les humains sont toujours impliqués dans le processus, il est important de se demander comment ils peuvent être utilisés le plus efficacement. De plus, certaines idées du data fabric sont assez complémentaires au data mesh et peuvent être utilisées conjointement (et vice versa). Ainsi, la question de savoir lequel utiliser aujourd’hui (maillage de données ou tissu de données) et s’il est même question de l’un par rapport à l’autre en premier lieu n’est pas évidente. En fin de compte, une solution optimale prendra probablement les meilleures idées de chacune de ces approches.

Daniel Abadi est professeur Darnell Kanal d’informatique à l’Université du Maryland, College Park et scientifique en chef à éclat d’étoile.

DataDecisionMakers

Bienvenue dans la communauté VentureBeat !

DataDecisionMakers est l’endroit où les experts, y compris les techniciens travaillant sur les données, peuvent partager des informations et des innovations liées aux données.

Si vous souhaitez en savoir plus sur les idées de pointe et les informations à jour, les meilleures pratiques et l’avenir des données et de la technologie des données, rejoignez-nous sur DataDecisionMakers.

Vous pourriez même envisager de rédiger votre propre article !

En savoir plus sur DataDecisionMakers

Leave a Reply

Your email address will not be published.