Considérations relatives à la conception pour les plateformes de données en libre-service
Le maillage de données est une nouvelle approche intéressante pour la conception et le développement de l’architecture des données. Contrairement à l’architecture de données traditionnelle, le maillage de données sépare la responsabilité entre les domaines de données fonctionnels qui se concentrent sur la création de produits de données et une équipe de plateforme qui se concentre sur les fonctionnalités techniques. Cette séparation des responsabilités doit être reflétée dans votre plateforme. Vous devez trouver un équilibre entre la fourniture de fonctionnalités indépendantes du domaine et l’activation de vos équipes de domaine pour modéliser, traiter et distribuer leurs données au sein de votre organisation.
Le choix du bon niveau de granularité du domaine et des règles de découplage à l’aide de plateformes n’est pas facile. Cet article contient plusieurs scénarios qui vous fournissent des conseils détaillés.
Analyse de niveau cloud
Lorsque vous souhaitez créer un maillage de données avec Azure, nous vous recommandons d’adopter l’l’analyse à l’échelle du cloud. Cette infrastructure est une architecture de référence déployable et est fournie avec des modèles open source et des meilleures pratiques. L’architecture de l’analyse à l’échelle du cloud comporte deux principaux blocs de construction fondamentaux pour tous les choix de déploiement :
- Zone d’atterrissage de gestion des données : base de votre architecture de données. Elle contient toutes les fonctionnalités critiques pour la gestion des données, telles que le catalogue de données, la traçabilité des données, le catalogue d’API, la gestion des données de référence, et ainsi de suite.
- Zones d’atterrissage des données : abonnements qui hébergent vos solutions d’analytique et d’IA. Elles incluent des fonctionnalités clés pour l’hébergement d’une plateforme d’analyse.
Le diagramme suivant présente une vue d’ensemble d’une plateforme d’analyse à l’échelle du cloud avec une zone d’atterrissage de gestion des données et une zone d’atterrissage des données unique. Tous les services Azure ne sont pas représentés dans le diagramme. Il a été simplifié pour mettre en évidence les concepts fondamentaux inhérents à l’organisation des ressources au sein de son architecture.
L’infrastructure d’analyse basée sur le cloud n’est pas explicite concernant le type exact d’architecture de données que vous devez provisionner. Vous pouvez l’utiliser pour de nombreuses solutions d’analyse à l’échelle du cloud courantes, notamment les entrepôts de données (entreprise), les lacs de données, les data lakehouse et les maillages de données. Tous les exemples de solutions de cet article utilisent l’architecture de maillage de données.
Comprenez que toutes les architectures adhèrent aux principes de maillage de données : propriété du domaine, données en tant que produit, plateforme de données en libre-service et gouvernance de calcul fédérée. Différents chemins d’accès peuvent tous conduire à un maillage de données. Il n’existe pas de réponse correcte ou incorrecte. Vous devez faire le bon compromis pour les besoins de votre organisation.
Zone d’atterrissage de données unique
Le modèle de déploiement le plus simple pour la création d’une architecture de maillage de données implique une zone d’atterrissage de gestion des données et une zone d’atterrissage de données. L’architecture des données dans un tel scénario ressemble à ce qui suit :
Dans ce modèle, tous vos domaines de données fonctionnels résident dans la même zone d’atterrissage des données. Un abonnement unique contient un ensemble standard de services. Les groupes de ressources séparent différents domaines de données et produits de données. Les services de données standard, comme Azure Data Lake Store, Azure Logic Apps et Azure Synapse Analytics, s’appliquent à tous les domaines.
Tous les domaines de données suivent les principes de maillage de données : les données suivent la propriété du domaine et les données sont traitées comme des produits. La plateforme est entièrement en libre-service, bien qu’il existe des variantes limitées des services. Tous les domaines doivent respecter et se conformer fortement aux mêmes principes de gestion des données.
Cette option de déploiement peut être utile pour les petites entreprises ou les nouveaux projets qui souhaitent adopter le maillage de données, mais sans compliquer les choses. Ce déploiement peut également constituer un point de départ pour une organisation qui prévoit de créer une infrastructure plus complexe. Dans ce cas, envisagez de vous étendre à plusieurs zones d’atterrissage ultérieurement.
Zones d’atterrissage alignées sur le système source et alignées sur les consommateurs
Dans le modèle précédent, nous n’avons pas pris en compte d’autres abonnements ou applications locales. Vous pouvez légèrement modifier le modèle précédent en ajoutant une zone d’atterrissage alignée sur le système source pour gérer toutes les données entrantes. L’incorporation des données est un processus difficile. Deux zones d’atterrissage de données peuvent donc être utiles. L’incorporation reste l’une des parties les plus difficiles de l’utilisation des données à grande échelle. L’incorporation nécessite également souvent des outils supplémentaires pour répondre à l’intégration, car ses défis diffèrent de ceux de l’intégration. Elle permet de faire la distinction entre fournir des données et consommer des données.
Dans l’architecture située à gauche de ce diagramme, les services facilitent l’intégration de toutes les données, telles que la capture des changements de données, les services permettant d’extraire des API ou les services de lacs de données permettant de créer dynamiquement des jeux de données. Les services de cette plateforme peuvent extraire des données à partir d’environnements locaux, d’environnements cloud ou de fournisseurs SaaS. Ce type de plateforme présente généralement plus de surcharge, car on compte davantage de couplage avec les applications opérationnelles sous-jacentes. Vous devrez peut-être la traiter différemment des autres utilisations de données.
Dans l’architecture située à droite du diagramme, l’organisation optimise la consommation et dispose de services axés sur la transformation des données en valeur. Ces services peuvent inclure le Machine Learning, la création de rapports, etc.
Ces domaines d’architecture suivent tous les principes de maillage de données. Les domaines prennent la propriété des données et sont autorisés à distribuer directement des données à d’autres domaines.
Zones d’atterrissage de données hub, génériques et spéciales
L’option de déploiement suivante est une autre itération de la conception précédente. Ce déploiement suit une topologie de maillage régie : les données sont distribuées via un hub central, dans lequel les données sont partitionnées par domaine, isolées logiquement et non intégrées. Le hub de ce modèle utilise sa propre zone d’atterrissage de données (indépendante du domaine) et peut être détenu par une équipe de gouvernance des données centrale qui supervise les données distribuées aux autres domaines. Le hub transporte également des services qui facilitent l’intégration des données.
Pour les domaines qui nécessitent des services standard pour consommer, utiliser, analyser et créer de nouvelles données, utilisez une zone d’atterrissage de données générique. Cet abonnement unique contient un ensemble de services standard. Appliquez également la virtualisation des données, car la plupart de vos produits de données sont déjà conservés dans le hub et vous n’avez pas besoin de plus de duplication de données.
Ce déploiement offre des « zones spéciales », des zones d’atterrissage supplémentaires que vous pouvez provisionner lorsqu’il n’est pas possible de regrouper logiquement des domaines. Elles peuvent être nécessaires lorsque des limites régionales ou légales s’appliquent, ou lorsque vos domaines ont des exigences uniques et contrastées. Vous pourriez également en avoir besoin dans des situations où une forte gouvernance mondiale des filiales est appliquée avec des exceptions pour les activités à l’étranger.
Si votre organisation doit contrôler les données distribuées et consommées par quels domaines, le déploiement de hub est une bonne option. Cela constitue également une option si vous traitez des problèmes de variante de temps et non volatiles pour les consommateurs de données volumineuses. Vous pouvez fortement normaliser la conception du produit de données, ce qui permet à vos domaines de voyager dans le temps et d’effectuer des redistributions. Ce modèle est particulièrement courant dans l’industrie financière.
Zones d’atterrissage de données fonctionnelles et alignées de manière régionale
L’approvisionnement de plusieurs zones d’atterrissage de données peut vous aider à regrouper des domaines fonctionnels en fonction de la cohésion et de l’efficacité pour travailler et partager des données. Toutes vos zones d’atterrissage de données adhèrent aux mêmes contrôles et audits, mais vous pouvez toujours disposer d’une flexibilité et de modifications de conception entre différentes zones d’atterrissage de données.
Déterminez les domaines de données fonctionnels que vous souhaitez regrouper logiquement pour une zone d’atterrissage de données partagées. Par exemple, vous pouvez implémenter les mêmes modèles si vous avez des limites régionales. La propriété, la sécurité ou les limites légales peuvent vous forcer à séparer des domaines. La flexibilité, le rythme de modification et la séparation ou la vente de vos fonctionnalités sont également des facteurs importants à prendre en compte.
Vous trouverez d’autres conseils et meilleures pratiques dans les domaines de données.
Les différentes zones d’atterrissage ne sont pas autonomes. Elles peuvent se connecter aux lacs de données hébergés dans d’autres zones. Cela permet aux domaines de collaborer dans votre entreprise. Vous pouvez également appliquer la persistance polyglotte pour combiner différentes technologies de magasin de données. La persistance polyglotte permet à vos domaines de lire directement les données d’autres domaines sans dupliquer les données.
Lors du déploiement de plusieurs zones d’atterrissage de données, sachez qu’il existe une surcharge de gestion attachée à chaque zone d’atterrissage de données. Vous devez appliquer le peering de réseaux virtuels entre toutes les zones d’atterrissage de données, vous devez gérer des points de terminaison privés supplémentaires, etc.
Le déploiement de plusieurs zones d’atterrissage de données représente une bonne option si votre architecture de données est volumineuse. Vous pouvez ajouter d’autres zones d’atterrissage à votre architecture pour répondre aux besoins courants de différents domaines. Ces zones d’atterrissage supplémentaires utilisent l’appairage de réseaux virtuels pour se connecter à la zone d’atterrissage de gestion des données ainsi qu’à toutes les autres zones d’atterrissage. Le peering vous permet de partager des jeux de données et des ressources entre les zones d’atterrissage. Le fractionnement des données entre des zones distinctes vous permet de répartir les charges de travail entre vos abonnements et ressources Azure. Cette approche permet d’implémenter organiquement le maillage de données.
Entreprises à grande échelle nécessitant différentes zones de gestion des données
Les grandes entreprises qui opèrent à l’échelle mondiale peuvent avoir des exigences de gestion des données contrastées entre différentes parties de leur organisation. Vous pouvez déployer plusieurs zones d’atterrissage de données et de gestion des données ensemble pour résoudre ce problème. Le diagramme suivant illustre un exemple de ce type d’architecture :
Plusieurs zones d’atterrissage de gestion des données peuvent justifier votre surcharge et la complexité de votre intégration. Par exemple, une autre zone d’atterrissage de gestion des données serait judicieuse pour les situations dans lesquelles les (méta)données de votre organisation ne doivent pas être vues par toute personne extérieure à votre organisation.
Conclusion
La transition vers le maillage de données est un changement culturel impliquant des nuances, des compromis et des considérations. Vous pouvez utiliser l’analyse à l’échelle du cloud pour obtenir les meilleures pratiques et les ressources exécutables. Les architectures de référence de cet article offrent des points de départ pour vous permettre de démarrer votre implémentation.