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 les mises à jour nécessaires à leur zone d’atterrissage de plateforme et la manière dont 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 recommandations pour mettre à jour la zone d’atterrissage de plateforme et concevoir l’architecture des zones d’atterrissage des charges de travail, afin que les charges de travail Azure puissent produire des données pour Microsoft Fabric et consommer les données gouvernées qui en proviennent.

Architectures et arbre de décision

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 zone d’atterrissage de plateforme

Quelles modifications faut-il apporter à la zone d’atterrissage de 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 existante de groupes d’administration, sauf si une nouvelle exigence réglementaire, de sécurité, de souveraineté ou opérationnelle impose un périmètre de stratégie différent.

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 aux stratégies intégrées pertinentes incluent :

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

1.2. Zones d’atterrissage de charges de travail

Que devons-nous inclure dans les zones d’atterrissage des charges de travail ? Les ressources Azure qui prennent en charge la plateforme de données unifiée doivent se trouver dans les zones d’atterrissage des charges de travail, sauf si elles fournissent une fonctionnalité fondamentale de la plateforme Azure définie par l’architecture des zones d’atterrissage Azure de l’organisation.

1.3 intégration de Fabric

Comment les charges de travail Azure doivent-elles s’intégrer à Microsoft Fabric ? Les charges de travail Azure doivent s’intégrer à Microsoft Fabric selon des modèles approuvés à l’échelle de l’organisation, permettant de mettre les données à disposition via OneLake et de 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 sur 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 l’abonnement de sa zone d’atterrissage de charge de travail 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 relatives à la capacité : un domaine de données doit ajouter une capacité Fabric lorsque les ressources existantes ne permettent pas de répondre à une exigence approuvée en matière de performances, d’isolation, de région 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.

• Exigences relatives aux abonnements Azure : un domaine de données ne doit utiliser un autre abonnement de zone d’atterrissage de charge de travail que lorsqu’une frontière distincte de gouvernance ou d’administration Azure est nécessaire. 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 définir 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. La commodité ou l’emplacement de l’équipe ne constituent pas des raisons suffisantes pour choisir une autre région. Consultez Prise en charge multigéographique dans Fabric et Modèles de déploiement Fabric.

• Approbation des exceptions : l’organisation doit définir qui approuve le recours à une autre région ou le partage d’une capacité Fabric entre plusieurs 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 Espaces de travail 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’atterrissage 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 la 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 : les collections doivent permettre une administration plus précise et un accès plus granulaire aux métadonnées au sein d’un domaine de Data Map. L’organisation doit utiliser des collections lorsque les équipes opérationnelles ont besoin de responsabilités déléguées pour inscrire et analyser les 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 de procéder à une intégration à grande échelle.

Consultez Domaines de gouvernance et recommandations relatives aux domaines et Architecture et bonnes pratiques concernant les domaines et les collections Microsoft Purview.