Maillage de données : un nouveau paradigme pour la gestion des données


Le maillage de données est une nouvelle façon de penser comment utiliser les données pour créer de la valeur organisationnelle.

Les praticiens de pointe commencent sérieusement à implémenter le maillage de données. Il est important de noter que le maillage de données n'est pas un outil unique ou une architecture de référence rigide. Il s'agit plutôt d'un modèle architectural et organisationnel conçu pour combler les lacunes de décennies de défis et d'échecs en matière de données.

Tout aussi important, c'est une nouvelle façon de réfléchir à la façon d'exploiter les données à grande échelle dans une organisation et des écosystèmes. Selon nous, le maillage de données deviendra le paradigme déterminant pour la prochaine génération d'excellence des données.

Dans cette analyse de rupture, nous accueillons le fondateur et créateur du maillage de données, auteur, leader d'opinion, technologue Zhamak Dehghani, qui nous aidera à mieux comprendre certains des principes fondamentaux du maillage de données et l'avenir de la gestion décentralisée des données.

Focus d'aujourd'hui

Premièrement, Dehghani est le directeur des technologies émergentes chez Thoughtworks North America. Elle est une leader d'opinion, une praticienne, une ingénieure en logiciel et une architecte passionnée par les solutions technologiques décentralisées et les architectures de données.

Depuis que nous l'avons invitée pour la dernière fois il y a moins d'un an, elle a écrit deux livres – un sur Data Mesh et un autre intitulé Software Architecture : The Hard Parts, tous deux publiés par O'Reilly Media Inc.

Nous allons préparer le terrain en partageant des données de recherche sur les technologies d'entreprise sur le profil de dépenses dans certains des secteurs de données clés. Nous allons ensuite plonger et examiner les quatre principes clés du maillage de données et parler un peu plus de certaines des dépendances dans les flux de données. Et nous allons vraiment creuser un peu le principe n ° 3 autour des plateformes de données en libre-service.

À cette fin, nous parlerons de certains des apprentissages que Dehghani a capturés depuis qu'elle s'est lancée dans le voyage du maillage de données avec ses collègues et clients. Et nous voulons spécifiquement parler de modèles réussis pour créer l'expérience de maillage de données.

Nous donnerons ensuite des conseils pratiques et nous terminerons par des exercices de réflexion et des questions courantes de la communauté.

Les thèmes liés aux données arrivent en tête des graphiques de dépenses

La première chose que nous voulons introduire est le climat des dépenses sur certains secteurs de données et leurs contiguïtés. Pour ce faire, nous utiliserons le graphique XY ci-dessous.

Le graphique illustre les profils de dépenses dans l'ensemble de données ETR pour certains des secteurs liés aux données dans la taxonomie ETR. L'axe Y montre le score net ou la dynamique des dépenses et l'axe horizontal est la part de marché ou la présence dans l'ensemble de données.

La ligne rouge à 40 % représente un niveau élevé de vélocité des dépenses. Au cours des huit derniers trimestres environ, nous avons vu l'apprentissage automatique et l'intelligence artificielle, l'automatisation des processus robotiques, les conteneurs et le cloud comme les quatre domaines dans lesquels les directeurs de l'information et les acheteurs de technologies ont affiché les scores nets les plus élevés. Comme nous l'avons dit, ce qui est si impressionnant pour le cloud, c'est qu'il est à la fois omniprésent et qu'il démontre une vitesse élevée. Et nous avons tracé trois autres domaines liés aux données, base de données/entrepôt de données d'entreprise, analyse/intelligence d'affaires/big data et stockage. Les deux premiers, bien que sous la ligne rouge, sont toujours surélevés. Le marché du stockage continue de progresser. Et nous avons tracé la technologie de l'information externalisée juste pour équilibrer le graphique pour le contexte.

Nous soulignons que ces domaines, IA, automatisation, conteneurs et cloud, sont tous pertinents pour les données et représentent des blocs de construction fondamentaux pour les architectures de données. La base de données et les analyses sont directement liées, tout comme le stockage. Cela vous donne donc une image des dépenses par secteur.

Les outils de données ne manquent pas

Le graphique ci-dessus est une taxonomie élaborée par Matt Turck, qui est un investisseur en capital-risque et qu'il a appelé le paysage MAD – Machine learning AI and Data. Le point clé ici est que les outils ne manquent pas dans le paysage du Big Data. Nous n'avons pas besoin de plus d'outils pour réussir le maillage de données.

Selon Dehghani :

Je pense que nous avons beaucoup d'outils. Ce qui manque, c'est une méta-architecture qui définit le paysage de manière à ce qu'il soit en phase avec la croissance organisationnelle, puis définit cette méta-architecture de manière à ce que ces outils puissent réellement interagir et s'intégrer très bien. Les clients ont actuellement de nombreux défis à relever pour choisir le bon outil, quelle que soit la voie technologique qu'ils suivent. Soit ils doivent se lancer dans une solution Big Data et ensuite essayer d'adapter les autres solutions intégrées autour de celle-ci, soit, comme vous le voyez, accéder à ce menu de grandes listes d'applications et passer beaucoup de temps à essayer d'intégrer et assemblez ces deux choses. J'espère donc que le maillage de données créera ce type de méta-architecture pour que les outils interagissent et se connectent et je pense que notre conversation d'aujourd'hui autour de la plate-forme de données en libre-service éclaire, espérons-le, cela.

Les quatre principes de base d'une architecture de maillage de données

Le graphique ci-dessus décrit les quatre principes importants qui sous-tendent le concept de maillage de données.

Une grande frustration que nous entendons de la part des praticiens est que les équipes de données n'ont pas de contexte de domaine. L'équipe de données est séparée des secteurs d'activité et, par conséquent, elle doit constamment changer de contexte et, par conséquent, il y a un manque d'alignement avec les objectifs commerciaux. Le principe n°1 consiste donc à mettre la propriété des données de bout en bout entre les mains du domaine ou des métiers.

Le principe n° 2 concerne les données en tant que produit, ce qui fait parfois mal au cerveau des gens, mais c'est un élément clé. L'idée est que les données sont utilisées pour créer des produits qui peuvent être monétisés, ou des services qui peuvent réduire les coûts ou sauver des vies. Cependant, une organisation mesure la valeur, les données sont un ingrédient qui peut être conditionné pour la consommation.

Cela conduit au principe n°3 – l'infrastructure de données en libre-service, que nous allons détailler un peu aujourd'hui. Une plate-forme de données en libre-service réduit les points d'étranglement organisationnels. La nuance ici est que plutôt que de simplement permettre le libre-service pour les spécialistes techniques, la plate-forme devrait servir un plus large éventail de généralistes avec un contexte commercial ou de domaine.

Et enfin, le principe n°4 se rapporte à une question que l'on se pose toujours lors de l'introduction du maillage de données aux publics : comment imposer la gouvernance dans un modèle fédéré.

Les quatre principes sont interdépendants

Zhamak Dehghani explique ces interrelations dans ce clip et décrit les relations entre les quatre principes comme suit :

Principe n°1 : Pousser la redevabilité vers les domaines

La cause première que nous essayons de résoudre est le cloisonnement des données à l'extérieur de l'endroit où l'action se produit, où les données sont produites, où les données doivent être partagées, où les données sont utilisées. Dans le cadre de l'entreprise. La cause première du problème de centralisation est résolue par la distribution de la responsabilité dans celui-ci, vers les domaines et ces domaines, cette distribution de la responsabilité, la responsabilité technique, vers les domaines s'est déjà produite. Au cours de la dernière décennie environ, nous avons assisté à la transition d'un groupe informatique général répondant à tous les besoins de l'organisation à des groupes technologiques au sein du département informatique, ou même en dehors de l'informatique, s'alignant pour créer des applications et des services que les différentes unités commerciales avoir besoin.

Alors, à quoi sert le maillage de données, il étend simplement ce modèle et dit : « OK, nous alignons l'entreprise sur la technologie et les données maintenant, n'est-ce pas ? » Ainsi, à la fois l'application des données en ML ou la génération d'informations dans les domaines liés aux besoins des domaines, ainsi que le partage des données que les domaines génèrent avec le reste de l'organisation.

Principe n°2 : Les données en tant que produit sont un briseur de silo

Mais au moment où vous faites cela, vous devez alors résoudre d'autres problèmes qui peuvent survenir et cela donne naissance au deuxième principe, qui concerne les données en tant que produit, comme moyen d'empêcher le silo de données dans le domaine. Donc, en changeant l'orientation des domaines qui produisent maintenant des données, je vais simplement créer cette collecte de données pour moi-même et qui a également satisfait mes besoins. En fait, la responsabilité du domaine est de partager les données en tant que produit avec toutes les merveilleuses caractéristiques d'un produit et je pense que cela conduit à des implications architecturales et techniques vraiment intéressantes sur ce qui constitue réellement les données en tant que produit.

Principe n°3 : La plateforme de données en libre-service permet aux généralistes

Mais une fois que vous faites cela, alors c'est le point dans la conversation que le CIO dit : « Eh bien, comment puis-je même gérer les coûts d'exploitation si je décentralise la création et le partage des données vers mes équipes techniques, vers mes équipes d'application ? Dois-je aller embaucher une centaine d'ingénieurs de données supplémentaires ? » Et je pense que c'est le rôle d'une plate-forme de données en libre-service dans la manière dont elle permet et renforce les technologies généralistes que nous avons déjà dans les domaines techniques, que la majorité des développeurs utilisent de nos jours. Ainsi, la plateforme de données tente de mobiliser les technologies généralistes pour devenir des producteurs de données, pour devenir des consommateurs de données, et repenser vraiment les outils dont ces personnes ont besoin. La plate-forme est destinée à donner de l'autonomie aux équipes de domaine, à les responsabiliser et à réduire le coût de possession de la création et de la gestion des produits de données.

Principe n°4 – Automatiser la gouvernance décentralisée

Le dernier principe répond à la question suivante : « Comment puis-je toujours garantir que ces différents produits de données sont interopérables, sécurisés, respectueux de la vie privée, maintenant de manière décentralisée ? » Lorsque nous respectons la souveraineté ou la propriété de domaine de chaque domaine, et cela conduit à cette idée – du point de vue d'un modèle opérationnel – d'appliquer une sorte de fédération où les propriétaires de domaine sont responsables de l'interopérabilité de leur produit de données. Ils ont des incitations qui sont alignées sur l'harmonie globale du maillage de données ainsi que du point de vue technologique, en pensant à ces données comme un produit avec un nouvel objectif, avec un objectif que toutes ces politiques qui doivent être respectées par ces produits de données , comme la confidentialité, comme la confidentialité, pouvons-nous coder ces politiques en tant qu'unités de calcul et exécutables, puis les coder dans des produits de tous les jours afin d'obtenir l'automatisation, la gouvernance grâce à l'automatisation ?

C'est la relation, la relation complexe, entre les quatre principes.

Objectifs du maillage de données

L'objectif du maillage de données, selon Dehghani, est d'échanger une nouvelle unité de valeur entre les producteurs et les consommateurs de données et cette unité de valeur est un produit de données. Un objectif est de réduire la « charge cognitive » sur notre cerveau et de simplifier la manière dont les données sont présentées aux producteurs et aux consommateurs. Et le faire en libre-service élimine les tapes sur l'épaule ou les e-mails ou les tickets pour savoir où se trouvent les données, comment les utiliser correctement, qui y a accès, etc.

Dehghani a souligné les points suivants :

Initialement, lorsque toute cette idée d'une innovation basée sur les données a vu le jour et que nous avions besoin de toutes sortes de piles technologiques, nous avons centralisé la création des données et l'utilisation des données, et c'est OK lorsque vous commencez pour la première fois où l'expertise et les connaissances sont pas encore diffusé et ce n'est le privilège que de très peu de personnes dans l'organisation. Mais, alors que nous sommes passés à un cycle d'innovation axé sur les données dans l'organisation et que nous apprenons comment les données peuvent débloquer de nouveaux programmes, de nouveaux modèles d'expérience, de nouveaux produits, il est alors vraiment, vraiment important de faire parler les consommateurs et les producteurs à chacun autre directement sans courtier au milieu.

Parce que même si avoir ce courtier centralisé pourrait être un modèle rentable, mais si nous incluons le coût d'une opportunité manquée pour quelque chose que nous aurions pu innover mais que nous avons raté cette opportunité à cause de mois de recherche des bonnes données, alors le rapport coût-avantage paramètres et changements de formule. Donc, pour avoir cette innovation basée sur les données, intégrée dans chaque domaine, chaque équipe, nous devons activer un modèle où le producteur peut directement, peer-to-peer, découvrir les données, les comprendre et les utiliser. Le test décisif pour cela serait partir d'une hypothèse selon laquelle, en tant que data scientist, je pense qu'il existe un modèle, et il y a un aperçu du comportement du client qui, si j'ai accès à toutes les différentes informations sur le client, tous les différents points de contact, je pourrais peut-être découvrir ce modèle et personnaliser l'expérience de mon client. Le test décisif va de cette hypothèse à la recherche de toutes les différentes sources, être capable de comprendre, puis être capable de les connecter et ensuite de les transformer en formation d'apprentissage automatique et le reste est, je suppose, connu comme un produit intelligent .

Comparer les modèles de données monolithiques traditionnels au maillage de données

Le côté gauche du graphique ci-dessus est une description organisée des observations de Dehghani sur la plupart des plates-formes de données monolithiques. Ils sont optimisés pour le contrôle, ils sont au service d'une équipe centralisée qui s'est constituée autour de rôles hyper-spécialisés. De plus, les piles opérationnelles exécutant des logiciels d'entreprise sur Kubernetes et des microservices sont isolées des clusters Spark gérant les données analytiques. Etc.

Alors que les caractéristiques du maillage de données sont affichées sur le côté droit du graphique. Il propose une plus grande autonomie et la gestion du code, des pipelines de données et de la politique en tant qu'entités indépendantes par rapport à une seule unité. Il a été dit plus tôt que nous devons permettre aux généralistes et emprunter à tant d'autres exemples dans l'industrie. C'est donc une architecture basée sur une pensée décentralisée qui peut être appliquée à n'importe quel domaine.

Dehghani explique dans ce clip comme suit :

Si je choisis un point clé de cette comparaison, c'est l'accent mis sur la plate-forme de données. Ainsi, les capacités de la plate-forme doivent présenter une expérience continue d'un développeur d'applications créant une application qui génère des données. Disons que j'ai une application de commerce électronique qui génère des données pour le produit de données qui présente et partage maintenant ces données en tant que faits temporels et immuables qui peuvent être utilisés à des fins d'analyse pour les scientifiques des données qui utilisent ces données pour personnaliser l'expérience du déploiement de ce modèle de ML maintenant de nouveau à cette application de commerce électronique. Donc, si vous regardez vraiment ce voyage continu, les murs entre ces plates-formes séparées que nous avons construites doivent tomber.

Les plates-formes sous-jacentes qui prennent en charge les systèmes opérationnels par rapport aux plates-formes de données par rapport aux modèles de ML, elles doivent en quelque sorte bien jouer ensemble car, en tant qu'utilisateur, je vais probablement tomber de la falaise chaque fois que je passe par ces étapes de cette chaîne de valeur. Ainsi, l'interopérabilité de nos solutions de données et de nos solutions opérationnelles doit augmenter considérablement car, jusqu'à présent, nous avons réussi à exécuter des systèmes opérationnels et des applications à une extrémité de l'organisation, à exécuter des analyses de données à une autre et à créer un pipeline de spaghetti. pour les connecter ensemble.

Aucune des extrémités n'est heureuse. J'entends des scientifiques des données, des analystes de données, pointer du doigt le développeur d'applications en disant : "Vous ne développez pas votre base de données de la bonne manière." Et les applications pointées du doigt disent : « Ma base de données sert à exécuter mon application. Il n'a pas été conçu pour partager des données analytiques. Ainsi, ce qu'un maillage de données essaie de faire, c'est de rapprocher ces deux mondes, puis la plate-forme elle-même doit se rapprocher et se transformer en un ensemble continu de services et de capacités, par opposition à ces grandes piles isolées et disjointes.

API, interfaces, plans et expérience de la plate-forme de maillage de données

Le diagramme ci-dessus creuse plus profondément dans la plate-forme. Il décrit les différents plans au sein de la plate-forme et les entrées et sorties de la plate-forme. Les plans représentent des fonctionnalités telles que l'infrastructure sous-jacente dans le plan utilitaire : un plan qui permet de découvrir et de partager des produits de données, et un plan qui applique les politiques.

Dehghani explique le schéma dans ce clip et ci-dessous :

Une plate-forme indépendante de la technologie avec des points de connexion cohérents

Lorsque nous pensons aux capacités qui permettent de créer notre application, de s'appuyer sur nos produits de données, de créer de meilleures solutions analytiques, nous sautons généralement trop rapidement à la fin de la mise en œuvre réelle de ces technologies, n'est-ce pas ? « Dois-je aller acheter un catalogue de données ? Ou ai-je besoin d'une sorte d'entrepôt pour le stocker ? » Ce que j'essaie de nous élever en quelque sorte, c'est de nous forcer à penser aux interfaces sur les API, aux expériences que la plate-forme doit fournir pour exécuter ces produits de données sécurisés, sûrs, fiables et performants et, si vous concentrez-vous sur les interfaces, l'implémentation en dessous peut être remplacée.

Ainsi, vous pouvez échanger l'un contre l'autre au fil du temps. C'est le but d'avoir ces sucettes et de se concentrer et de souligner quelle est l'interface qui fournit une certaine capacité comme le stockage, comme la gestion du cycle de vie des produits de données, etc.

Le but des plans, le plan d'expérience de maillage, l'expérience des produits de données et le plan utilitaire, nous donne vraiment un langage pour classer différents ensembles d'interfaces et de capacités qui fonctionnent bien ensemble pour fournir ce voyage cohérent d'un consommateur de données de développeur de produits de données.

L'avion utilitaire

Les trois avions sont vraiment autour, OK, dans la couche inférieure, nous avons beaucoup d'utilitaires. Nous avons ce genre de tableau d'outillage de données MAD de Matt Turck. Donc, nous avons beaucoup d'utilitaires en ce moment. Ils gèrent la gestion des flux de travail. Ils font du traitement des données. Vous avez votre lien d'étincelle. Vous avez votre stockage. Vous avez votre stockage de lac. Vous avez votre série temporelle de stockage. Nous avons beaucoup d'outils à ce niveau.

Construire un plan de produits de données

La couche que nous devons en quelque sorte imaginer et construire aujourd'hui que nous n'achetons pas encore, pour autant que je sache, est cette couche qui nous permet d'échanger cette unité de valeur. Pour créer et gérer ces produits de données. Ainsi, le langage, les API et l'interface de ce plan d'expérience produit ne sont pas, oh, j'ai besoin de ce stockage ou j'ai besoin de ce traitement de flux de travail. C'est que j'ai un produit de données. Il doit fournir certains types de données. Je dois donc être capable de modéliser mes données.

Dans le cadre de ce produit de données, j'ai besoin d'écrire un code de traitement qui maintient ces données constamment en vie car elles reçoivent en amont, disons, les interactions des utilisateurs avec un site Web et génèrent le profil de mes utilisateurs. Donc je dois être capable d'écrire ça. Je dois servir les données. Je dois garder les données en vie et je dois fournir un ensemble de SLO et de garanties pour mes données, afin qu'une bonne documentation, afin que quelqu'un qui consulte le produit de données sache quelle est la cadence d'actualisation, quelle est la conservation des données , et beaucoup d'autres SLO que je dois fournir.

Un plan de gouvernance et de politique

Enfin, je dois être capable d'appliquer et de garantir certaines politiques en termes de contrôle d'accès, de cryptage de la confidentialité, etc. Donc, en tant que développeur de produits de données, je travaille simplement avec cette unité, une unité complètement autonome et autonome, et la plate-forme devrait me donner des moyens de provisionner cette unité et de tester cette unité, etc.

C'est un peu pourquoi j'insiste sur l'expérience, et, bien sûr, nous n'avons pas affaire à un ou deux produits de données. Nous avons affaire à un maillage de produits de données. Donc, au niveau du type d'expérience au niveau du maillage, nous avons besoin d'un ensemble de capacités et d'interfaces pour pouvoir rechercher dans le maillage les bonnes données, pour pouvoir explorer le graphe de connaissances qui émerge de cette interconnexion de produits de données, et nous devons être en mesure d'observer le maillage pour toute anomalie.

Avons-nous créé l'un de ces produits de données de référence géants dans lesquels toutes les données entrent et dont toutes les données sortent ? Avons-nous trouvé un goulot d'étranglement? Pour pouvoir faire ces capacités au niveau du maillage, nous devons avoir un certain niveau d'API et d'interfaces.

Et, une fois que nous avons décidé ce qui constitue cela pour satisfaire cette expérience de maillage, alors nous pouvons prendre du recul et dire : « OK, maintenant, quel genre d'outil dois-je construire ou acheter pour les satisfaire ? » Et ce n'est pas ce à quoi la communauté des données ou la partie données de nos organisations sont habituées. Je pense que, traditionnellement, nous sommes très à l'aise avec l'achat d'un outil et ensuite changer la façon dont nous travaillons pour servir l'outil et c'est légèrement l'inverse de ce modèle avec lequel nous pourrions être à l'aise.

Conseils pratiques pour ceux qui implémentent le maillage de données

Le maillage de données n'est pas un projet de 60 ou 90 jours. Il s'agit d'un état d'esprit organisationnel, d'une évolution architecturale (ou d'une sorte de révolution) et d'une manière complètement différente de penser à la valeur des données à grande échelle. Mais les changements proposés par le maillage de données doivent être abordés de manière réfléchie et mis en œuvre sur une période de temps dans un modèle de maturité.

Dans ce clip, Dheghani décrit le schéma et quelques conseils pratiques supplémentaires :

Le graphique ci-dessus était quelques points de départ pour les personnes qui se lancent dans la construction ou l'achat de la plate-forme permettant la création de maillage. Donc, c'était un peu l'accent sur l'angle de la plate-forme et je pense que le premier est ce dont nous venons de discuter. Au lieu de penser aux mécanismes que vous construisez, pensez aux expériences que vous permettez. Identifiez qui sont les gens. Quelle est la personnalité des data scientists ? Je veux dire, les data scientists ont un large éventail de personnalités, ou le développeur de produits de données est le même. Quelle est la personnalité que je dois développer aujourd'hui ou activer et responsabiliser aujourd'hui ? Quels ensembles de compétences ont-ils? Et donc, en pensant aux mécanismes d'expérience, je pense que nous sommes à ce point vraiment magique. Je veux dire, combien de fois dans notre vie, nous rencontrons un vide complet, une sorte d'espace blanc dans une certaine mesure pour innover.

Alors profitons de cette opportunité et utilisons un peu de créativité tout en étant pragmatique. Bien sûr, nous avons besoin de solutions aujourd'hui ou hier. Mais, pour toujours penser à l'expérience comme non à des mécanismes que nous devons acheter. C'était en quelque sorte la première étape et ce qui est bien, c'est qu'il existe un chemin itératif vers la maturité de votre maillage de données. Je veux dire, si vous avez commencé par réfléchir à : quels sont les cas d'utilisation initiaux que je dois activer ? De quels produits de données dépendent ces cas d'utilisation et que nous devons déverrouiller ? Et quelle est la personnalité ou les compétences générales de mon développeur de produits de données ? Quelles sont les interfaces que je dois activer ? Vous pouvez commencer avec la plate-forme la plus simple possible pour vos deux premiers cas d'utilisation, puis penser, d'accord, au prochain ensemble de développeurs de données, ils ont un ensemble différent de besoins.

Peut-être qu'aujourd'hui, j'active simplement l'interrogation des données de type SQL. Demain, j'active l'accès aux données basé sur des fichiers de data scientist le lendemain de l'activation de l'aspect streaming. Donc, vous avez ce genre de chemin évolutif devant vous, et ne pensez pas que vous devez commencer par tout construire. Je veux dire, l'une des choses que nous avons faites est d'adopter cette approche de récolte que vous travaillez en collaboration avec ces domaines techniques et interfonctionnels qui construisent les produits de données et voyez comment ils utilisent ces utilitaires et récoltent ce qu'ils construisent comme solutions pour eux-mêmes dans la plate-forme.

Mais, en fin de compte, nous devons penser à la mobilisation de la plus grande population de technologies dont nous disposons. Il faut penser à diffuser la technologie et à la rendre disponible et accessible par les technologues généralistes ; et reconnaître que nous avons parcouru un long chemin.

Nous avons déjà vécu ce genre de changements de paradigme en termes de développement mobile, en termes de programmation fonctionnelle, en termes de fonctionnement du cloud. Ce n'est pas que nous ayons du mal à apprendre quelque chose de nouveau, mais nous devons apprendre quelque chose qui fonctionne bien avec le reste de l'outillage que nous avons dans notre boîte à outils en ce moment. Donc, encore une fois, placez ce généraliste comme l'un de vos personnages centraux, pas la seule personne bien sûr, nous aurons des spécialistes. Bien sûr, nous aurons toujours des spécialistes des data scientists, mais tout problème qui peut être résolu comme un problème d'ingénierie général, et je pense qu'il y a beaucoup d'aspects du maillage de données qui peuvent être juste un simple problème d'ingénierie. Approche-le de cette façon, puis créons les outils pour responsabiliser ces généralistes.

Les mots comptent

Nous terminerons avec quelques réflexions de la communauté et des questions que nous recevons souvent.

Les données sont plus que le nouveau pétrole

Le pétrole est une ressource limitée. Les données ne le sont pas. Les mêmes données exactes peuvent être utilisées pour de nombreux cas d'utilisation et applications différents, mais un seul litre d'huile ne peut être utilisé que dans une seule application.

Voici comment Dehghani décrit sa réaction à cette expression souvent utilisée :

Je ne réponds pas à ces données que ce soit l'or ou le pétrole ou toute autre ressource rare, car, comme vous l'avez dit, cela évoque une émotion très différente. Cela n'évoque pas l'émotion de "Je veux utiliser ça". J'ai l'impression que j'ai besoin de le cacher, de le récupérer et de le garder pour moi et de ne le partager avec personne. Il n'évoque pas cette émotion de partage. Je pense vraiment que les données et, avec un petit astérisque, et je pense que la définition des données change, et c'est pourquoi je continue à utiliser le langage des produits de données ou du quantum de données. Les données deviennent l'élément le plus important et essentiel de l'existence du calcul. Qu'est-ce que je veux dire par là ? Je veux dire que beaucoup d'applications que nous avons écrites jusqu'à présent sont basées sur la logique, la logique impérative.

Si cela se produit, faites ceci ou faites l'autre, et nous nous dirigeons vers un monde où ces applications générant des données que nous regardons ensuite et les données générées deviennent la source, les modèles que nous pouvons explorer, pour construire notre applications, comme dans, organisent la liste de lecture hebdomadaire pour Dave, chaque lundi, en fonction de ce qu'il a écouté et d'autres personnes ont écouté en fonction de son profil. Nous nous dirigeons donc vers un monde qui ne concerne pas tant les applications utilisant nécessairement les données pour gérer leurs activités. Ces données sont vraiment, vraiment, la pierre angulaire des applications du futur. Et puis je pense que nous devons repenser la définition des données, et c'est peut-être pour une conversation différente, mais, je pense vraiment que nous devons faire converger le traitement et les données ensemble, la substance et le traitement ensemble, pour avoir un unité qui est composable, réutilisable, digne de confiance.

Et c'est l'idée derrière le type de produit de données en tant qu'unité atomique de ce que nous construisons à partir de solutions futures.

Les données sont-elles un actif qui devrait un jour figurer sur une ligne du bilan ?

« Les données sont notre atout le plus précieux » est une autre expression populaire. Mais l'idée de partager des actifs est quelque peu antithétique à la notion de partage de données.

Voici comment Dehghani le voit :

Je pense qu'il est en fait intéressant que vous ayez mentionné cela parce que j'ai lu la nouvelle politique en Chine selon laquelle les directeurs financiers ont en fait un élément de ligne autour des données qu'ils capturent. Nous n'avons pas besoin d'aller à la conversation politique autour de l'autoritarisme de la collecte de données et du pouvoir qui crée et de la société qui en découle, mais à part cela, cette grande conversation, cette petite conversation, à part, je pense que vous avez raison. Je veux dire, les données en tant qu'actif génèrent un comportement différent. Cela crée différentes mesures de performance que nous mesurerions. Je veux dire, avant que la conversation sur le maillage de données n'existe, nous mesurions le succès de nos équipes de données par les téraoctets de données qu'elles collectaient, par les milliers de tables qu'elles avaient estampillées comme données dorées.

Il n'y a pas de ligne directe que je puisse voir entre cela et la valeur générée par les données. Mais si nous inversons cela, c'est pourquoi je pense que c'est plutôt nocif car cela conduit à de mauvaises mesures et métriques pour mesurer le succès. Donc, si vous inversez cela à un peu de réflexion sur le produit ou à quelque chose que vous partagez pour ravir l'expérience des utilisateurs, vos mesures sont très différentes. Vos mesures sont le bonheur de l'utilisateur, la diminution du délai pour qu'il l'utilise réellement et en tire de la valeur, la croissance de la population des utilisateurs. Cela fonctionne dans un type très différent de mesures de comportement et de réussite.

Puis-je enfin retirer mon entrepôt de données ?

Lac de données, hub de données, entrepôt de données, buckets S3… ce sont des nœuds sur le maillage de données. Ils ne doivent pas être éliminés, mais le maillage de données devrait plutôt inclure l'une de ces technologies.

Dehghani donne son point de vue dans ce clip :

Je pense que le vrai changement est d'un entrepôt de données centralisé à un entrepôt de données où il s'adapte. Je pense que si nous venons de traverser cette pièce centralisée, nous sommes tous d'accord pour dire que l'entreposage de données offre des fonctionnalités intéressantes qui sont toujours nécessaires, peut-être en tant que nœud périphérique du maillage, qui optimise certaines requêtes, disons les rapports financiers, et nous veulent toujours diriger une bonne partie des données dans un nœud qui est juste pour ces rapports financiers et cela nécessite la précision et la vitesse de fonctionnement que la technologie d'entrepôt fournit. Je pense donc que la technologie a définitivement sa place.

Là où cela s'effondre, c'est lorsque vous voulez avoir un entrepôt pour gérer toutes vos données et modéliser canoniquement vos données parce que vous devez mettre tellement d'énergie à exploiter ce modèle et à créer ces schémas de flocon de neige très complexes et fragiles et ainsi de suite que c'est tout tu fais. Vous dépensez de l'énergie contre l'entropie de votre organisation pour essayer de maîtriser ce modèle et le modèle est constamment en décalage avec ce qui se passe dans la réalité, car la réalité de l'entreprise évolue plus rapidement que notre capacité à tout modéliser en un seul canonique. représentation. Je pense que c'est celui que nous devons remettre en question, pas nécessairement l'application d'un entrepôt de données sur un nœud.

Le manque de normes est la lacune flagrante aujourd'hui

Dehghani a spécifiquement envisagé le maillage de données comme étant indépendant de la technologie. Et bien sûr, nous aimons toujours évaluer la plate-forme technologique d'un fournisseur spécifique via un filtre de maillage de données. La réalité est – selon le graphique de Matt Turck que nous avons montré plus tôt – qu'il existe de nombreuses technologies qui peuvent être des nœuds dans le maillage de données, ou faciliter le partage de données ou la gouvernance, etc. Mais il y a clairement un manque de standardisation.

Nous ne sommes pas convaincus que la communauté des fournisseurs conduira cela – mais peut-être que, comme Kubernetes, Google ou un autre géant de l'Internet apportera quelque chose à l'open source qui résoudra le problème et cela deviendra une norme de facto.

Nous avons demandé à Dehghani de décrire en détail ses réflexions sur les types de normes nécessaires et d'où viendront-elles. Elle partage ses réflexions dans ce clip résumé ci-dessous :

Les fournisseurs ne sont pas aujourd'hui incités à créer ces normes ouvertes parce que la majorité des fournisseurs, pas tous, mais le modèle opérationnel de certains fournisseurs consiste à amener vos données sur ma plate-forme, puis à m'apporter vos calculs et tout se passera bien et cela sera formidable pour une partie des clients, une partie des environnements où cette complexité dont nous parlons n'existe pas. So, we need, yes, other players, perhaps, maybe some of the cloud providers or people that are more incentivized to open their platform, in a way, for data sharing. So as a starting point, I think standardization around data sharing. If you look at the spectrum right now, we have de facto standards.

It’s not even a standard for something like SQL. I mean, everybody’s bastardized SQL and extended it with so many things that I don’t even know what the standard SQL is anymore, but we have that for some form of a querying. But, beyond that, I know, for example, folks at Databricks are starting to create some standards around their data sharing and sharing the data in different models. So I think data sharing as a concept, the same way that APIs were about capability sharing. We need to have the data APIs, or analytical data APIs, and data sharing extended to go beyond simply SQL or languages like that.

I think we need standards around computational policies. This is, again, something that is formulating in the operational world. We have a few standards around, how do you articulate access control? How do you identify the agents who are trying to access with different authentication? We need to bring some of those or add our own data-specific articulation of policies.

Something as simple as identity management across different technologies is nonexistent. If you want to secure your data across three different technologies, there is no common way of saying who’s the agent that is acting to access the data. Can I ask that to kids and authorize them? Those are some of the very basic building blocks.

And then, the gravy on top would be new standards around enriched kind of semantic modeling of the data, so we have a common language to describe the semantic of the data in different nodes, and then relationship between them.

We have prior work with RDF and folks that we’re focused on, I guess, linking data across the web with the kind of the data web, work that we had in the past. We need to revisit those and see their practicality in an enterprise context. So, data modeling, rich language for data semantic modeling and data connectivity. Most importantly, I think those are some of the items on my wish list.

We’ll leave it there for now. Many thanks to Zhamak Dehghani for her continued excellent work and contributions to our program. For a deeper dive on this topic, you can check out this session Dehghani did with her colleagues and hear the added perspectives of a data scientist.

Keep in touch

Remember we publish each week on this site and siliconangle.com. These episodes are all available as podcasts wherever you listen. Email david.vellante@siliconangle.com, DM @dvellante on Twitter and comment on our LinkedIn posts.

Also, check out this ETR Tutorial we created, which explains the spending methodology in more detail. Note: ETR is a separate company from Wikibon and SiliconANGLE. If you would like to cite or republish any of the company’s data, or inquire about its services, please contact ETR at legal@etr.ai.

Here’s the full video analysis:

Image: WrightStudio

All statements made regarding companies or securities are strictly beliefs, points of view and opinions held by SiliconANGLE media, Enterprise Technology Research, other guests on theCUBE and guest writers. Such statements are not recommendations by these individuals to buy, sell or hold any security. The content presented does not constitute investment advice and should not be used as the basis for any investment decision. You and only you are responsible for your investment decisions.


Show your support for our mission by joining our Cube Club and Cube Event Community of experts. Join the community that includes Amazon Web Services and Amazon.com CEO Andy Jassy, Dell Technologies founder and CEO Michael Dell, Intel CEO Pat Gelsinger and many more luminaries and experts.



Source link

Un emplacement commerce électronique permet de se lancer à moindres frais pendant rapport aux entreprises classiques. De plus, vous avez la possibilité vous lancer autrement rapidement. La gérance d’un site e-commerce ne demande pas de présence physique à un endroit précis, sauf peut-être quant au stockage et la préparation des commandes que vous avez la possibilité tout à fait externaliser, ou encore mieux si vous ne possédez pas de réserve (on en parlera plus tardivement dans l’article).