Architecture d’une plateforme de données unifiée

Cet article aide les décideurs à prendre des décisions d’architecture pour leur landing zone Azure afin de créer une plateforme de données unifiée.

Les organisations doivent déterminer quelles mises à jour de leur zone d’atterrissage de plateforme nécessitent et comment les charges de travail Azure doivent s’intégrer à la plateforme de données unifiée. Sans architecture claire, les données peuvent rester isolées entre les charges de travail et les plateformes ou se déplacer entre elles sans gouvernance et sécurité cohérentes. Cet article fournit des conseils pour mettre à jour la zone d’accueil de la plateforme et concevoir des zones d’accueil de charge de travail afin que les charges de travail Azure puissent produire des données pour Microsoft Fabric et consommer les données gouvernées qu’elle contient.

Architectures et arbre de décision

Architecture conceptuelle d’une plateforme de données unifiée pour l’IA et l’analytique.

Détails

Architecture conceptuelle détaillée d’une plateforme de données unifiée pour l’IA et l’analytique.

Arbre de décision

Le flux pose une série de questions oui-ou-non. Chaque « Oui » mène à des conseils spécifiques. La première question pose si l’organisation a besoin d’aide pour comprendre les priorités des données ou créer des compétences pour obtenir plus de valeur à partir des données. Si c’est le cas, l’aide consiste à préparer des personnes par le biais de rôles, de formation et d’activités de préparation. La deuxième question pose la question de savoir si l’organisation a besoin d’un moyen unifié d’accéder aux données entre les clouds et les charges de travail pour prendre en charge l’analytique et l’IA. Si c’est le cas, l’aide consiste à utiliser Microsoft Fabric comme plateforme de données unifiée. La troisième question pose si l’organisation a besoin d’aide pour transformer les données opérationnelles en valeur métier ou en alimentant en toute sécurité les données dans des systèmes IA, tels que Microsoft Foundry. Si c’est le cas, la recommandation est d'intégrer les services Azure avec Fabric. La quatrième question pose si l’organisation a besoin d’aide pour contrôler l’accès aux données ou pour sécuriser les données de manière cohérente. Si c’est le cas, l’aide consiste à définir des bases de référence de gouvernance et de sécurité à l’aide de Microsoft Purview et des contrôles associés. La cinquième question pose si l’organisation a besoin d’aide pour définir des normes organisationnelles cohérentes pour traiter, sécuriser et consommer des produits de données pour l’analytique et l’IA. Si c’est le cas, l’aide consiste à définir des normes opérationnelles pour les produits de données, la sécurité et la gestion du cycle de vie. Le flux se termine par l’adoption de l’IA et l’adoption d’agents IA une fois que la plateforme et les normes de données unifiées sont en place.

L’arbre de décision de Microsoft pour vous guider dans votre plateforme de données unifiée.

1. Azure landing zone

Comment mettre à jour notre landing zone Azure ? La plateforme de données unifiée doit utiliser l’architecture existante de landing zone Azure de l’organisation. L’organisation ne doit pas créer une architecture Azure distincte uniquement pour les charges de travail de Microsoft Fabric ou de données.

1.1. Mises à jour de la landing zone de la plateforme

Quelles modifications sont requises pour la zone d’accueil de la plateforme ? La landing zone de la plateforme doit continuer à fournir les fonctionnalités Azure partagées utilisées au sein de l’organisation. L’organisation doit conserver sa hiérarchie des groupes de gestion existante, sauf si une nouvelle exigence réglementaire, de sécurité, de souveraineté ou opérationnelle nécessite une portée de la stratégie différente.

Base de référence de la gouvernance : l’équipe de plateforme doit évaluer chaque Azure service introduit par la plateforme de données unifiée par rapport à la base de référence de stratégie existante. La révision doit identifier si les contrôles existants s’appliquent et si des contrôles supplémentaires sont nécessaires. Les références de stratégie de sécurité intégrées pertinentes sont les suivantes :

• Azure Databricks
• Azure Machine Learning
• Azure Data Lake Storage
• Machines virtuelles (calcul)
• Emplacements autorisés

1.2. Zones d’accueil de charge de travail

Que devons-nous placer dans les zones de destination pour les charges de travail ? Les ressources Azure qui prennent en charge la plateforme de données unifiée doivent résider dans des zones d’atterrissage de charge de travail, sauf si elles fournissent une fonctionnalité Azure de base définie par l’architecture de zone d’atterrissage Azure de l’organisation.

Service	Positionnement classique du groupe d’administration
Microsoft Purview	Zone d’atterrissage pour charge de travail interne
Capacité Microsoft Fabric	Zone d’atterrissage pour charge de travail interne
Charge de travail Azure (consommant un produit de données ou de l’IA)	Zone de destination interne, en ligne ou locale pour les charges de travail
bases de données Azure	Zone de destination interne, en ligne ou locale pour les charges de travail
Azure Databricks	Zone d’atterrissage pour charge de travail interne
Azure Machine Learning	Zone d’atterrissage pour charge de travail interne
Azure Data Lake Storage	Zone d’atterrissage pour charge de travail interne
Infrastructure d’IA (entraînement/GPU)	Zone d’atterrissage pour charge de travail interne

1.3 intégration de Fabric

Comment les charges de travail Azure doivent-elles s’intégrer à Microsoft Fabric ? Les workloads Azure doivent s’intégrer à Microsoft Fabric par le biais de modèles à l’échelle de l’organisation approuvés pour rendre les données disponibles via OneLake et consommer des produits de données gouvernés. L'intégration à Fabric ne doit pas changer le placement de la charge de travail.

L’architecture doit prendre en charge les produits de données créés dans Fabric et les produits de données créés via d’autres plateformes approuvées, telles que Azure Databricks. Le modèle d’intégration doit identifier le système de référence et éviter une duplication inutile du traitement ou des données. Consultez intégration d’Azure Databricks à OneLake et raccourci Azure Data Lake Storage (ADLS) Gen2.

L’organisation doit définir les modèles d’intégration pris en charge par le biais de ses normes opérationnelles.

2. Architecture Microsoft Fabric

Comment l’organisation doit-elle concevoir Microsoft Fabric ? Microsoft Fabric doit fournir la plateforme partagée via laquelle les domaines de données créent, publient et consomment des produits de données. L’organisation doit établir une architecture Fabric commune avant que les domaines de données déploient des produits de données de production.

Déploiement de capacité Fabric 2.1

Comment déployer les capacités Fabric ? Chaque domaine de données doit déployer ses capacités Fabric via son abonnement de la zone d’arrivée du workload désignée. Le domaine de données doit gérer sa capacité de Fabric au sein de son budget approuvé et des normes à l’échelle de l’organisation.

• Exigences en matière de capacité : un domaine de données doit ajouter une capacité Fabric lorsque les ressources existantes ne peuvent pas répondre à une exigence approuvée en matière de performances, d'isolation, régionale ou de cycle de vie. Le domaine de données ne doit pas ajouter une capacité Fabric uniquement pour organiser les produits de données ou les équipes.

• Conditions requises pour l’abonnement Azure : un domaine de données ne doit utiliser un autre abonnement de zone d’atterrissage de charge de travail que lorsqu’une limite de gouvernance Azure distincte ou une limite administrative distincte est requise. Un autre espace de travail, environnement ou produit de données ne justifie pas lui-même un autre abonnement.

• Capacités de Fabric partagées : plusieurs domaines de données peuvent partager une capacité de Fabric lorsque les ressources partagées fournissent des performances acceptables et une meilleure utilisation des ressources.

• Déploiement régional : l’organisation doit établir une région Azure par défaut pour la capacité Fabric. Les domaines de données doivent utiliser cette région, sauf si une exigence approuvée justifie une autre région. Les exceptions acceptables incluent la résidence légale, la souveraineté des données, la latence, la disponibilité des fonctionnalités Fabric ou une conception de récupération d’urgence approuvée. Un emplacement pratique ou l’emplacement de l’équipe ne constitue pas une raison valable pour choisir une autre région. Consultez la prise en charge multigéographique de Fabric et les modèles de déploiement de Fabric.

• Approbation d’exception : l’organisation doit définir qui approuve le recours à une autre région ou à une capacité Fabric partagée entre les domaines de données. Une demande d’exception doit identifier l’exigence, les produits de données affectés, le coût attendu et les conditions de sortie.

2.2 workspaces Fabric

Comment utiliser les espaces de travail ? Les espaces de travail Fabric doivent fournir le cadre de travail permettant aux domaines de données de créer et de gérer des produits de données dans Microsoft Fabric. Chaque domaine de données doit déterminer sa structure d’espace de travail conformément aux normes à l’échelle de l’organisation.

• Utilisation de l’espace de travail : créez un espace de travail distinct lorsque les éléments Fabric nécessitent une autre limite administrative, d’accès, de déploiement ou de réseau.

• Organisation de l’espace de travail. Les domaines de données doivent associer les espaces de travail connexes aux domaines Fabric. Les domaines Fabric regroupent logiquement les espaces de travail Fabric et prennent en charge la gouvernance déléguée, mais l'attribution de domaine ne détermine pas l'accès aux éléments Fabric. Consultez les meilleures pratiques pour la planification et la création de domaines dans Microsoft Fabric.

3. Architecture de Microsoft Purview

Comment devons-nous concevoir Microsoft Purview ? L’architecture Microsoft Purview doit refléter les domaines de données de l’organisation sans traiter les domaines de gouvernance Purview, les domaines Data Map, les collections ou les domaines Fabric comme interchangeables.

3.1 placement de compte Microsoft Purview

Où devons-nous déployer le compte Purview ? L’organisation doit placer la ressource Azure Microsoft Purview dans une zone d’accueil de charge de travail interne. L’abonnement et la région sélectionnés doivent répondre aux exigences réglementaires et opérationnelles de l’organisation.

L’organisation doit attribuer la responsabilité du service Purview de manière centralisée. Les domaines de données doivent recevoir une autorité déléguée pour leurs métadonnées et concepts métier par le biais de rôles Purview approuvés. Ils ne doivent pas déployer des environnements Purview distincts uniquement pour obtenir une autonomie administrative.

Consultez Microsoft Purview FAQ.

3.2 Structure de Purview

Comment devons-nous structurer Purview ? L’organisation doit établir ses domaines de gouvernance et sa structure de mappage de données avant que les domaines de données commencent à inscrire des sources de données et à publier des produits de données.

• Domaines de gouvernance : les domaines de gouvernance fournissent le contexte métier des produits de données et des concepts connexes. Ils peuvent inclure des termes de glossaire, des objectifs et des résultats clés et des éléments de données critiques. Les domaines de gouvernance doivent initialement s’aligner sur les domaines de données de l’organisation. Utilisez une limite différente lorsque la responsabilité de gouvernance l’exige. Consultez les domaines de gouvernance.

• Structure de la Data Map : les domaines de la Data Map doivent représenter des limites d’administration technique ou de cycle de vie de niveau supérieur. Étant donné que les domaines Data Map sont limités, utilisez-les pour de grands périmètres d’administration technique plutôt que pour la mise en miroir des domaines de données organisationnels.

• Collections doivent fournir un accès plus précis à l’administration et aux métadonnées au sein d’un domaine Data Map. L’organisation doit utiliser des collections lorsque les équipes opérationnelles ont besoin d’une responsabilité déléguée pour l’enregistrement et l’analyse des sources de données. Les collections peuvent également séparer les sources de production et de non-production lorsque ces sources ne justifient pas un autre domaine Data Map. Chaque source de données doit être inscrite dans une seule collection au sein d’un domaine Data Map. Les ressources analysées à partir de cette source restent associées à cette structure. L’organisation doit donc définir des règles de placement des sources avant la prise en main à grande échelle.

Consultez les domaines de gouvernance et les recommandations relatives Domaines et architecture des collections Microsoft Purview et meilleures pratiques.