Maillage de données d'entreprise

En matière de logiciel d'entreprise, le maillage de données est une nouvelle approche de réflexion sur les données reposant sur une architecture distribuée pour la gestion des données. L'idée est de rendre les données plus accessibles et disponibles pour les utilisateurs en connectant directement les propriétaires de données, les producteurs de données et les consommateurs de données. Le maillage de données permet d'améliorer les résultats commerciaux des solutions centrées sur les données et d'adopter des architectures de données modernes.

Du point de vue de l'entreprise, le maillage de données apporte de nouvelles idées à la réflexion sur les produits de données. En d'autres termes, il s'agit de considérer les données comme un produit qui exécute une tâche, par exemple, améliorer la prise de décision, aider à détecter la fraude ou aligner l'entreprise sur les changements dans le contexte de la chaîne d'approvisionnement. Pour créer des produits de données à forte valeur ajoutée, les entreprises doivent faire face aux changements de culture et de mentalité et s'engager à adopter une approche plus transversale de la modélisation de domaines d'activité.

Du côté de la technologie, le point de vue d'Oracle sur le maillage de données implique trois nouveaux aspects importants pour l'architecture orientée données :

1. Des outils qui fournissent des produits de données en tant que collectes de données, événements de données et analyses de données
2. Des architectures de données distribuées et décentralisées qui aident les entreprises qui choisissent de passer d'architectures monolithiques à une informatique multicloud et hybride, ou qui doivent opérer de manière décentralisée à l'échelle mondiale
3. Des données en mouvement pour les entreprises qui ne peuvent pas dépendre uniquement de données centralisées, statiques et par lots, mais qui se tournent plutôt vers des registres de données orientés événements et des pipelines orientés flux en continu pour des événements de données en temps réel fournissant des analyses plus rapides

D'autres préoccupations importantes, telles que les outils en libre-service pour les utilisateurs non techniques et les puissants modèles de gouvernance des données fédérée, sont tout aussi importantes pour l'architecture du maillage de données que pour d'autres méthodes de gestion des données plus centralisées et classiques.

Une approche de maillage de données est un changement de paradigme qui consiste à considérer les données comme un produit. Le maillage de données introduit des changements organisationnels et de processus dont les entreprises auront besoin pour gérer les données en tant qu'immobilisation tangible de l'entreprise. La perspective d'Oracle pour l'architecture du maillage de données nécessite une harmonisation sur les domaines de données organisationnels et analytiques.

Un maillage de données vise à lier les producteurs de données directement aux utilisateurs professionnels et, dans la mesure du possible, à retirer l'intermédiaire informatique des projets et les processus qui ingèrent, préparent et transforment les ressources de données.

Oracle a travaillé sur le maillage des données pour fournir à ses clients une plateforme capable de répondre à ces besoins technologiques émergents. Il s'agit notamment d'outils pour les produits de données, d'architectures décentralisées orientées événements et de modèles de transmission en continu pour les données en mouvement. Pour la modélisation de domaines de produits de données et d'autres préoccupations sociotechniques, Oracle s'aligne sur le travail effectué par l'expert du maillage de données, Zhamak Dehghani.

Les architectures de données monolithiques du passé sont malheureusement complexes, coûteuses et rigides. Au cours des années, il est devenu évident que la plupart du temps et des coûts liés à la plateforme d'entreprise numérique, des applications à l'analyse, sont imputés aux efforts d'intégration. Par conséquent, la plupart des initiatives de plateforme ont échoué.

Bien que le maillage des données ne soit pas une solution miracle pour les architectures de données centralisées et monolithiques, les principes, pratiques et technologies de la stratégie de maillage des données sont conçus pour résoudre certains des objectifs de modernisation les plus urgents et non résolus pour les initiatives commerciales axées sur les données.

Voici certaines des tendances technologiques qui ont conduit à l'émergence du maillage de données en tant que solution :

La première étape la plus importante à suivre pour mettre en place un maillage de données est d'adopter une nouvelle façon de penser. La volonté d'inclure les pratiques acquises en matière d'innovation est le tremplin vers une modernisation réussie de l'architecture de données.

En voici les domaines :

• Le design thinking, une méthodologie éprouvée pour résoudre les problèmes non résolus, appliquée aux domaines de données d'entreprise pour la création de produits de données exceptionnels
• La théorie « Jobs to be done », appliquant une innovation centrée sur le client dont le processus est axé sur les résultats pour s'assurer que les produits de données d'entreprise résolvent des problèmes commerciaux concrets

Les méthodologies de design thinking apportent des techniques éprouvées qui aident à briser les cloisons des services au sein de l'entreprise qui bloquent fréquemment l'innovation transversale. La théorie « Jobs to be done » est la base essentielle pour concevoir des produits de données qui répondent à des objectifs spécifiques des consommateurs finaux - ou à des travaux à effectuer - elle définit le but du produit.

Bien que l'approche des produits de données ait initialement émergé de la communauté de la data science, elle est maintenant appliquée à tous les aspects de la gestion des données. Au lieu de créer des architectures technologiques monolithiques, le maillage de données se concentre sur les consommateurs de données et les résultats commerciaux.

Bien que la réflexion sur les produits de données puisse s'appliquer à d'autres architectures de données, il s'agit d'une partie essentielle d'un maillage de données. Si vous souhaitez accéder à des exemples pragmatiques sur l'application de la réflexion sur les produits de données, l'équipe d'Intuit a rédigé une analyse détaillée de leurs expériences.

Les produits de toute nature, des matières premières aux articles de votre magasin local, sont produits en tant qu'actifs de valeur, destinés à être consommés et ont un travail spécifique à faire. Les produits de données peuvent prendre diverses formes, selon le domaine d'activité ou le problème à résoudre, et peuvent inclure :

• Analyses : rapports et tableaux de bord historiques/en temps réel
• Ensembles de données : collectes de données dans différentes formes/formats
• Modèles : objets de domaine, modèles de données, fonctionnalités de machine learning
• Algorithmes : modèles de ML, scoring, règles métier
• Services de données et API : documents, charges utiles, API REST, etc.

Un produit de données est créé pour la consommation, généralement détenu en dehors du service informatique et nécessite le suivi d'attributs supplémentaires, tels que :

• Carte des parties prenantes : qui possède, créé et utilise ce produit ?
• Packaging et documentation : comment ce produit est-il utilisé ? Comment est-il étiqueté ?
• Objectif et valeur : quelle est la valeur implicite/explicite du produit ? Existe-t-il un amortissement dans le temps ?
• Qualité et cohérence : quels sont les indicateurs clés de performances et les contrats de niveau de service d'utilisation ? Est-ce vérifiable ?
• Provenance, cycle de vie et gouvernance : les données sont-elles fiables et explicables ?

Les systèmes informatiques décentralisés sont une réalité moderne, et avec l'essor des applications SaaS et de l'infrastructure de cloud public (IaaS), la décentralisation des applications et des données est appelé à durer. Les architectures logicielles d'applications passent de monolithes centralisés du passé aux microservices distribués (un maillage de services). L'architecture des données suivra la même tendance vers la décentralisation, les données devenant plus distribuées sur une plus grande variété de sites physiques et sur de nombreux réseaux. Nous appelons cela un maillage de données.

Un maillage est une topologie de réseau qui permet à un grand groupe de noeuds non hiérarchiques de collaborer.

Voici quelques exemples courants de technologie :

• WiFiMesh : de nombreux noeuds travaillent ensemble pour une meilleure couverture
• ZWave/Zigbee : réseaux de dispositifs domestiques intelligents à faible énergie
• Maillage 5G : connexions de cellules plus fiables et résilientes
• Starlink : maillage par satellite à large bande à l'échelle mondiale
• Maillage de services : moyen de fournir des contrôles unifiés sur les microservices décentralisés (logiciels applicatifs)

Le maillage de données est aligné sur ces concepts de maillage et fournit un moyen décentralisé de distribuer des données sur des réseaux virtuels/physiques et sur de grandes distances. Les architectures monolithiques d'intégration de données héritées, telles que les outils ETL et de fédération de données, et plus récemment encore, les services de cloud public, tels qu'AWS Glue, nécessitent une infrastructure hautement centralisée.

Une solution complète de maillage de données doit pouvoir fonctionner dans une structure multicloud, couvrant potentiellement les systèmes sur site, les clouds publics multiples et même les réseaux périphériques.

Dans un monde où les données sont fortement distribuées et décentralisées, le rôle de la sécurité de l'information est primordial. Contrairement aux systèmes monolithes très centralisés, les systèmes distribués doivent déléguer les activités nécessaires pour authentifier et autoriser différents utilisateurs à différents niveaux d'accès. Il est difficile de déléguer en toute sécurité la responsabilité sur les réseaux.

Voici quelques remarques à prendre en compte :

• Chiffrement au repos : données/événements écrits dans le stockage
• Authentification distribuée : pour les services et les banques de données, tels que mTLS, les certificats, SSO, les banques de clés secrètes et les coffres de données
• Chiffrement en mouvement : données/événements circulant en mémoire
• Gestion des identités : services de type LDAP/IAM, interplates-formes
• Autorisations distribuées : pour que les adresses de service protègent les données
  Par exemple : Open Policy Agent (OPA) sidecar pour placer le point de décision de stratégie (PDP) dans le cluster container/K8S où l'adresse de microservice est traitée. LDAP/IAM peut être n'importe quel service compatible JWT.
• Masquage déterministe : pour brouiller les informations d'identification personnelle de manière fiable et cohérente

La sécurité au sein de n'importe quel système informatique peut être complexe, et il est encore plus difficile de fournir une haute sécurité au sein des systèmes distribués. Il s'agit toutefois de problèmes pouvant être résolus.

Un principe fondamental du maillage de données est la notion de distribution de la propriété et de la responsabilité. La bonne pratique consiste à fédérer la propriété des produits et des domaines de données avec les personnes d'une entreprise qui sont les plus proches des données. En pratique, cela peut s'aligner sur des données source (par exemple, des sources de données brutes, telles que les systèmes opérationnels d'enregistrement/applications) ou sur des données analytiques (par exemple, typiquement des données composites ou agrégées formatées pour une utilisation facile par les consommateurs de données). Dans les deux cas, les producteurs et les consommateurs des données s'harmonisent souvent sur les unités opérationnelles plutôt que sur les organisations informatiques.

Les anciennes méthodes d'organisation des domaines de données tombent régulièrement dans le piège de s'aligner sur les solutions technologiques, telles que les outils ETL, les data warehouses, les data lakes ou l'organisation structurelle d'une entreprise (ressources humaines, marketing et autres secteurs d'activité). Il serait préférable lorsqu'un problème métier survient, que les domaines de données s'alignent sur la portée du problème en cours de résolution, au contexte d'un processus métier particulier ou à la famille d'applications dans un domaine de problème spécifique. Dans les grandes entreprises, ces domaines de données sont généralement répartis entre les organisations internes et les empreintes technologiques.

La décomposition fonctionnelle des domaines de données est prioritaire dans le maillage de données. Diverses méthodologies de décomposition des données pour la modélisation de domaines peuvent être adaptées à l'architecture du maillage de données, y compris la modélisation classique du data warehouse (comme Kimball et Inmon) ou la modélisation du coffre-fort de données, mais la méthodologie la plus courante actuellement testée dans l'architecture du maillage de données est la conception pilotée par domaine (DDD). L'approche DDD est née de la décomposition fonctionnelle des microservices et s'applique maintenant dans un contexte de maillage de données.

Oracle a permis de mettre en avant l'importance des données en mouvement en tant qu'ingrédient clé d'un maillage de données moderne. Les données en mouvement sont essentielles pour sortir le maillage des données de l'univers historique du traitement par lots centralisé et monolithique. Les capacités des données en mouvement répondent à plusieurs questions fondamentales relatives au maillage de données, telles que :

• Comment accéder aux produits de données harmonisés avec la source en temps réel ?
• Quels outils peuvent fournir les moyens de distribuer des transactions de données fiables sur un maillage de données physiquement décentralisé ?
• Lorsque je dois rendre les événements de données disponibles en tant qu'API de produit de données, que puis-je utiliser ?
• Pour les produits de données analytiques qui doivent être constamment à jour, comment puis-je m'aligner sur les domaines de données et garantir la confiance et la validité ?

Ces questions ne sont pas seulement une question de détails d'implémentation, elles sont d'une importance centrale pour l'architecture de données elle-même. Une conception orientée domaine pour les données statiques utilisera des techniques et des outils différents d'un processus dynamique de données en mouvement de la même conception. Par exemple, dans les architectures de données dynamiques, le registre de données est la source centrale d'informations fiables pour les événements de données.

Les livres sont un composant fondamental du fonctionnement d'une architecture de données distribuée. Comme pour un livre comptable, un livre de données enregistre les transactions au fur et à mesure.

Lorsque nous distribuons le livre, les événements de données deviennent réexécutables dans n'importe quel emplacement. Certains livres ressemblent un peu à un enregistreur de vol d'avion utilisé pour la haute disponibilité et la reprise après sinistre.

Contrairement aux banques de données centralisées et monolithiques, les livres distribués sont spécialement conçus pour assurer le suivi des événements atomiques et/ou des transactions qui surviennent dans d'autres systèmes (externes).

Un maillage de données n'est pas qu'un seul type de livre. En fonction des cas d'utilisation et des exigences, un maillage de données peut utiliser différents types de livres de données basés sur les événements, notamment :

• Livre d'événements à usage général, tel que Kafka ou Pulsar
• Livre d'événements de données : outils de CDC/réplication distribués
• Middleware de messagerie, notamment ESB, MQ, JMS et AQ
• Livre de blockchain pour des transactions sécurisées, immuables et multipartites

Ensemble, ces livres peuvent agir comme une sorte de journal d'événements durable pour l'ensemble de l'entreprise, fournissant une liste d'événements de données en cours d'exécution sur les systèmes d'enregistrement et d'analyse.

Les flux de données multi-langage n'ont jamais été aussi présents. Ils varient en fonction des types d'événement, des données traitées et de la sémantique des transactions. Un maillage de données doit prendre en charge les types de flux nécessaires pour divers workloads de données d'entreprise.

Bien sûr, il existe plus de trois attributs d'un maillage de données. Nous nous sommes concentrés sur les trois points ci-dessus comme un moyen d'attirer l'attention sur les attributs qu'Oracle pense être certains des aspects nouveaux et uniques de l'approche innovante du maillage de données.

Les autres attributs importants du maillage de données sont les suivants :

• Outils en libre-service : le maillage des données rejoint la tendance générale de la gestion des données vers le libre-service. Les développeurs citoyens devront de plus en plus être issus des rangs des propriétaires de données.
• Gouvernance des données : le maillage des données a également adopté la tendance de longue date vers un modèle de gouvernance fédérée plus formalisé, tel que défendu par les directeurs des données, les architectes de données et les fournisseurs de catalogues de données depuis de nombreuses années.
• Utilisabilité des données : conformément aux principes du maillage de données, il existe de nombreux travaux de base pour s'assurer que les produits de données sont hautement utilisables. Les principes applicables aux produits de données concerneront les données qui sont précieuses, utilisables et susceptibles d'être partagées.

Au-delà de la migration directe des architectures de données monolithiques vers le cloud, de nombreuses entreprises cherchent également à supprimer leurs anciennes applications centralisées et à passer à une architecture d'applications de microservices plus moderne.

Toutefois, les monolithes d'applications héritées dépendent généralement de bases de données massives, ce qui soulève la question de savoir comment mettre en œuvre le plan de migration pour réduire les perturbations, les risques et les coûts. Un maillage de données peut fournir une capacité informatique opérationnelle importante aux clients qui effectuent des transitions par étapes d'une architecture monolithique à une architecture maillée. Par exemple :

• Déchargement de sous-domaine des transactions de base de données, tel que le filtrage des données par « contexte limité »
• Réplication bidirectionnelle des transactions pour les migrations par phases
• Synchronisation entre plateformes, par exemple mainframe vers DBaaS

Dans le jargon des architectes de microservices, cette approche utilise une boîte d'envoi de transaction bidirectionnelle pour activer le schéma de migration du figuier étrangleur, un contexte limité à la fois.

Les applications stratégiques requièrent des indicateurs clés de performances et des contrats de niveau de service très élevés en matière de résilience et de continuité. Que ces applications soient monolithiques, de microservices ou intermédiaires, elles ne peuvent pas tomber en panne !

Pour les systèmes stratégiques, un modèle de données distribué de cohérence finale n'est généralement pas acceptable. Toutefois, ces applications doivent fonctionner dans de nombreux data centers Cela soulève la question de la continuité d'activité : Comment exécuter mes applications sur plusieurs data centers tout en garantissant des données correctes et cohérentes ?

Que les architectures monolithiques utilisent des ensembles de données distribués ou que les microservices soient configurés pour la haute disponibilité intersite, le maillage de données offre des données correctes et à grande vitesse à toute distance.

Un maillage de données peut fournir la base de données décentralisées, mais 100 % correctes sur tous les sites. Par exemple :

• Transactions logiques à très faible latence (interplate-forme)
• Garantie compatible ACID pour des données correctes
• Résolution multiactive, bidirectionnelle et des conflits

Une plateforme moderne de type maillage de services utilise des événements pour l'échange de données. Plutôt que de dépendre du traitement par lots au niveau des données, les données traitées circulent en permanence lorsque des événements se produisent dans l'application ou la banque de données.

Pour certaines architectures, les microservices doivent échanger des données traitées entre eux. D'autres modèles nécessitent un échange entre des applications monolithiques ou des banques de données. La question suivante se pose : Comment échanger de manière fiable les charges utiles de données des microservices entre mes applications et banques de données ?

Un maillage de données peut fournir la technologie de base pour l'échange de données centré sur les microservices. Par exemple :

• Microservice vers microservice en contexte
• Microservice vers microservice dans tous les contextes
• Monolithe vers/depuis le microservice

Les modèles de microservices, tels que le sourcing d'événements, le CQRS et les boîtes d'envoi de transactions, sont des solutions couramment comprises. Un maillage de données fournit les outils et les structures permettant de rendre ces modèles répétables et fiables à grande échelle.

Au-delà des modèles de conception de microservices, le besoin d'intégration d'entreprise s'étend à d'autres systèmes informatiques, tels que les bases de données, les processus métier, les applications et les périphériques physiques de tous types. Un maillage de données constitue la base de l'intégration des données en mouvement.

Les données en mouvement sont généralement pilotées par les événements. Une action utilisateur, un événement de périphérique, une étape de processus ou une validation de banque de données peuvent tous lancer un événement avec des données traitées. Ces données traitées sont cruciales pour l'intégration des systèmes d'Internet des Objets (IoT), des processus métier et des bases de données, des data warehouses et des data lakes.

Un maillage de données fournit la technologie de base pour une intégration en temps réel dans toute l'entreprise. Par exemple :

• Connexion d'événements réels relatifs aux appareils aux systèmes informatiques
• Intégration des processus métier dans les systèmes ERP
• Harmonisation des bases de données opérationnelles avec les banques de données analytiques

Les grandes entreprises disposeront naturellement d'un mélange d'anciens et de nouveaux systèmes, de monolithes et de microservices, de banques de données opérationnelles et analytiques ; un maillage de données peut aider à unifier ces ressources dans différents domaines commerciaux et de données.

Les banques de données analytiques peuvent inclure des data marts, des data warehouses, des cubes OLAP, des data lakes et des technologies de data lakehouse.

En règle générale, il n'existe que deux méthodes pour importer des données dans ces banques de données analytiques :

• Chargement par lots/microbatch sur un planificateur de temps
• Ingestion des flux : chargement continu d'événements de données

Un maillage de données constitue la base d'une fonctionnalité d'ingestion de flux de données. Par exemple :

• Evénements de données provenant de bases de données ou de banques de données
• Evénements d'appareils à partir de la télémétrie des dispositifs physiques
• Journalisation des événements d'application ou transactions métier

L'inclusion d'événements par flux peut réduire l'impact sur les systèmes sources, améliorer la fidélité des données (important pour la data science) et permettre des analyses en temps réel.

Une fois ingérés dans les banques de données analytiques, il est généralement nécessaire que les pipelines de données préparent et transforment les données à travers différentes phases de données ou zones de données. Ce processus d'amélioration des données est souvent nécessaire pour les produits de données analytiques en aval.

Un maillage de données peut fournir une couche de pipeline de données gérée de manière indépendante qui fonctionne avec les banques de données analytiques, fournissant les services de base suivants :

• Détection et préparation des données en libre accès
• Gouvernance des ressources de données dans différents domaines
• Préparation des données et transformation en formats de produits de données requis
• Vérification des données par une stratégie garantissant la cohérence

Ces pipelines de données doivent pouvoir fonctionner sur différentes banques de données physiques (telles que des magasins, des entrepôts ou des lacs) ou en tant que flux de données de propagation au sein de plateformes de données analytiques prenant en charge les flux de données, telles qu'Apache Spark et d'autres technologies de data lakehouse.

Les événements se déroulent en permanence. L'analyse des événements dans un flux peut être cruciale pour comprendre ce qui se passe de moment en moment.

Ce type d'analyse basée sur des séries temporelles des flux d'événements en temps réel peut être important pour les données d'appareils IoT du monde réel et pour comprendre ce qui se passe dans vos data centers informatiques ou dans les transactions financières, telles que la surveillance des fraudes.

Un maillage de données complet comprend les fonctionnalités de base permettant d'analyser des événements de toutes catégories, dans de nombreux types de fenêtres temporelles d'événement. Par exemple :

• Analyse simple du flux d'événements (événements Web)
• Surveillance de l'activité de l'entreprise (événements SOAP/REST)
• Traitement d'événements complexes (corrélation multi-flux)
• Analyse des événements de données (sur les transactions de base de données/ACID)

Comme les pipelines de données, les analyses de diffusion en continu peuvent s'exécuter dans une infrastructure de data lakehouse établie ou séparément, en tant que services natifs du cloud.

Ceux qui sont à la pointe de l'intégration des données recherchent l'intégration de données opérationnelles et analytiques en temps réel à partir d'un ensemble diversifié de banques de données résilientes. Les innovations ont été constantes et rapides à mesure que l'architecture de données évolue dans les analyses de flux de données. La haute disponibilité opérationnelle a conduit à des analyses en temps réel, et l'automatisation de l'ingénierie des données simplifie la préparation des données, permettant ainsi aux data scientists et aux analystes de disposer d'outils en libre accès.