Architecture moderne en médaillon de l’entrepôt de données sur Microsoft Fabric

Microsoft Fabric

Power BI

Cet exemple décrit une architecture en médaillon pour un entrepôt de données moderne orienté SQL (MDW). Un entrepôt de données moderne utilise des magasins de données BASÉS sur SQL pour organiser des données structurées pour l’analytique et la création de rapports. Cette architecture implémente les couches bronze, argent et or dans Fabric Data Warehouse et utilise Fabric Data Factory pour orchestrer l’ingestion et la transformation des données.

Fabric Data Warehouse stocke les données relationnelles au format Delta dans OneLake et prend en charge le développement T-SQL via des tables, des vues, des transactions et des procédures stockées. Power BI, les clients SQL et d’autres applications consomment des données organisées à partir de la couche or.

Important

Les modèles de médaillon recommandés Fabric utilisent un lac pour chaque couche ou utiliser des lacs pour les couches bronze et argent et un entrepôt pour la couche d’or. Cette architecture utilise des entrepôts pour les trois couches, car les données restent structurées et sont transformées à l’aide de SQL tout au long du processus. Lakehouses est mieux adapté au traitement basé sur Spark, aux charges de travail de science des données et à de grands volumes de données non structurées ou semi-structurées. Pour une implémentation lakehouse-first qui prend en charge les données Spark et non structurées, consultez Greenfield Lakehouse sur Microsoft Fabric.

Architecture

Téléchargez un fichier PowerPoint de cette architecture.

Dans le diagramme, Mirroring gère la réplication des bases de données opérationnelles, et les pipelines Fabric Data Factory ingèrent des sources non mises en miroir dans la couche bronze.

Flux de données

Le flux de données suivant correspond au diagramme précédent :

Les bases de données opérationnelles, les applications SaaS, les fichiers et d’autres systèmes sources produisent des données.
L’ingestion amène les données sources dans Fabric via deux chemins d’accès. Pour les bases de données opérationnelles prises en charge, la mise en miroir dans Fabric réplique en continu les données dans un élément de base de données mis en miroir dans OneLake. Un entrepôt CTAS ou une étape INSERT ... SELECT stocke ensuite ces données dans l’entrepôt Bronze. Pour les fichiers, les applications SaaS et les autres sources non mises en miroir, utilisez les pipelines Fabric Data Factory ou le langage T-SQL d’un entrepôt de données, comme COPY INTO, pour charger des tables de bronze.
La couche bronze stocke les données brutes, peu traitées dans les tables d’entrepôt. Les métadonnées d’ingestion, telles que les horodatages de chargement et les identificateurs sources, prennent en charge l’audit et le retraitement.
La première étape de transformation (Bronze to silver) valide et transforme les données bronze en couche argent.
La couche argent contient des données nettoyées, dédupliquées et conformes. Lorsque l’analyse historique est requise, les tables Silver conservent les modifications sources avec les dates effectives et les indicateurs de ligne actuelle.
Les procédures stockées ou les jobs dbt mettent généralement en œuvre l’étape Bronze to silver en utilisant des modèles SQL tels que CREATE TABLE AS SELECT (CTAS), INSERT ... SELECT et MERGE.
La couche or fournit des schémas en étoile prêts pour la consommation, des data marts et des tables préagrégées.
La deuxième étape de transformation (Silver to gold) transforme les données de la couche Silver en entités métier, dimensions, faits et agrégats dans la couche Gold.
Power BI utilise des données de niveau or au moyen de modèles sémantiques. D’autres consommateurs, tels que les clients SQL, les notebooks et les applications, peuvent interroger le point de terminaison SQL de l’entrepôt.

Components

Fabric Data Warehouse fournit les tables de calcul et relationnelleS T-SQL pour les couches bronze, argent et or.
OneLake stocke les données d’entrepôt au format Delta et stocke les données répliquées par la mise en miroir de Fabric.
La mise en miroir dans Fabric réplique en continu les bases de données opérationnelles prises en charge dans OneLake.
Fabric Data Factory ingère des données et orchestre les procédures stockées, les pipelines et d’autres activités de transformation.
Power BI fournit des modèles sémantiques, des rapports et des tableaux de bord sur des données gold organisées.

Conseils de conception

Les directives suivantes décrivent comment mettre en œuvre les couches bronze, argent et or et organiser les espaces de travail associés. Adaptez ces recommandations aux sources de données et aux exigences de gouvernance de votre charge de travail et aux compétences de votre équipe.

Couche bronze : ingestion de données brutes

La couche bronze ingère des données brutes et capture toutes les données sources sous sa forme d’origine sans appliquer de logique métier. Il sert de système d’enregistrement, permettant la traçabilité complète et le retraitement. Les tables de cette couche reflètent étroitement les schémas sources et évitent intentionnellement le filtrage, la déduplication ou l’enrichissement. Les colonnes de métadonnées facultatives, telles que les horodatages d’ingestion ou les noms de fichiers sources, prennent souvent en charge l’audit.

Pour les bases de données opérationnelles prises en charge, utilisez la mise en miroir dans Fabric pour répliquer en continu des tables sources dans OneLake. Pour les sources de type fichier, SaaS ou non prises en charge, utilisez les pipelines Fabric Data Factory, COPY INTO pour l’ingestion en masse, ou OPENROWSET avec CTAS ou INSERT ... SELECT pour stocker de façon persistante les données de fichiers externes dans l’entrepôt de données bronze.

À ce stade, l’ingestion limite les transformations au minimum afin que la couche bronze reste la source de référence rejouable. Si nécessaire pour les sources non mises en miroir, une procédure stockée en bronze (ou modèle dbt équivalent) peut normaliser les enregistrements entrants et ajouter des métadonnées de charge.

Les meilleures pratiques pour la couche bronze mettent l’accent sur la préservation de toutes les données brutes, notamment les enregistrements non valides, l’utilisation de l’ingestion par lots pour éviter les problèmes de petit fichier, l’alignement des schémas étroitement avec les systèmes sources et l’automatisation des flux de travail d’ingestion à l’aide de Fabric pipelines pour garantir la cohérence et la fiabilité à grande échelle.

Couche silver : nettoyage et mise en conformité des données

La couche argent se concentre sur le nettoyage et la conformité des données en affinant les données bronze à l’aide des règles de qualité des données, de la normalisation, de la déduplication et de l’intégration entre plusieurs sources. Il produit finalement une source unique de vérité pour les données nettoyées et fiables.

Vous implémentez généralement des transformations à ce stade à l’aide de T-SQL, en utilisant des modèles tels que les instructions CREATE TABLE AS SELECT (CTAS), INSERT … SELECT et MERGE pour prendre en charge à la fois le traitement par lots et le traitement incrémentiel. Bien que Fabric Data Warehouse ne prenne pas en charge les vues matérialisées, vous pouvez utiliser des vues de lake matérialisées, mises en œuvre à l’aide de Spark, pour générer des tables Delta. Le point de terminaison d’analyse SQL expose ces tables Delta sous forme de tables que l’entrepôt peut lire.

Les meilleures pratiques pour la couche argent incluent la conception de transformations idempotentes, l’application cohérente des règles de qualité des données et l’utilisation de MERGE pour les mises à jour incrémentielles. Lorsque la charge de travail nécessite une historisation, conservez les versions de ligne avec des dates de début et de fin effectives et un indicateur de ligne actuel. Les dimensions Gold peuvent utiliser cet historique pour mettre en œuvre une gestion des dimensions à évolution lente (SCD) de type 1 ou de type 2.

Couche or : Données préparées pour l’analyse

La couche gold fournit des données sélectionnées, directement exploitables par l’entreprise, optimisées pour l’analyse, le reporting et leur exploitation par des outils décisionnels tels que Power BI. Cette couche est conçue autour des modèles de modélisation analytique, généralement à l’aide de schémas en étoile avec des tables de faits et de dimensions, des data marts spécifiques au domaine et des tables récapitulatives pré-agrégées pour prendre en charge des requêtes performantes et une analyse intuitive.

Vous dérivez généralement des tables d’or exclusivement à partir de données argent et vous les exposez aux utilisateurs finaux et aux outils de création de rapports.

Utilisez des clés de substitution stables pour les dimensions afin que les faits ne dépendent pas des clés système source mutables. Fabric Data Warehouse prend en charge les BIGINT IDENTITY colonnes pour la génération de clés de substitution. Les valeurs d’identité sont uniques, mais ne sont pas garanties d’être séquentielles ou ordonnées, et les lacunes peuvent se produire. Si ces limitations ne conviennent pas à la charge de travail, générez et conservez des clés de substitution dans la logique de transformation et conservez un mappage durable à chaque clé naturelle. Ne régénérez pas les clés de substitution pendant une actualisation complète.

Les meilleures pratiques pour la couche or incluent la modélisation des données pour s’aligner étroitement sur les cas d’usage analytiques et métier, préaggréger les données dans la mesure du possible pour améliorer les performances, appliquer des contrôles de sécurité tels que la sécurité au niveau des lignes (RLS), la sécurité au niveau des colonnes (CLS) et le masquage des données, et documenter soigneusement la traçabilité et les transformations de données.

Stratégie d’espace de travail

Une stratégie d’espace de travail définit la façon dont les couches bronze, argent et or sont logiquement et physiquement séparées pour équilibrer la gouvernance, la sécurité et la simplicité opérationnelle. Vous pouvez implémenter des couches à l’aide d’espaces de travail distincts par couche, que nous vous recommandons lorsque des limites de sécurité fortes, une propriété claire ou une séparation stricte des responsabilités sont requises. Par exemple, vous devez isoler l’ingestion de données brutes des données métiers organisées.

Vous pouvez également implémenter des couches dans un espace de travail unique à l’aide d’entrepôts distincts pour les données bronze, argent et or. Cette approche peut réduire la surcharge de gestion et simplifier le développement et les tests intercouches tout en préservant la séparation au niveau de l’entrepôt entre les couches de médaillon.

Le choix entre ces approches dépend généralement de facteurs tels que l’échelle organisationnelle, les exigences de sécurité, la structure d’équipe et la maturité de gouvernance. De nombreuses entreprises adoptent un modèle hybride à mesure que leur implémentation Fabric évolue. Nous vous recommandons d’utiliser des espaces de travail distincts lorsque des limites d’isolation, de gouvernance et de propriété sont requises.

Conseils d’implémentation

Fabric Data Warehouse fournit une cohérence transactionnelle et un traitement fiable des données sur les couches bronze, argent et or. Utilisez des écritures par lots pour réduire les problèmes liés aux fichiers de petite taille et améliorer l’efficacité du stockage et des requêtes. Utilisez des MERGEinstructions pour gérer les données arrivées tardivement ou modifiées dans les scénarios de traitement incrémentiel.

Conservez les transactions de courte durée pour réduire la contention et optimiser la concurrence, en particulier dans les environnements d’ingestion élevée. Surveillez activement les performances et l’état de fonctionnement à l’aide des insights des requêtes Fabric et des vues de gestion dynamique (DMV). La séparation architecturale des charges de travail de lecture et d’écriture dans Fabric permet aux travaux d’ingestion et de transformation de s’exécuter simultanément sans bloquer les requêtes analytiques, ce qui garantit des performances prévisibles pour l’analytique et les rapports en aval.

Utilisez des procédures stockées T-SQL et les pipelines de Fabric Data Factory pour la transformation SQL native et l’orchestration. Les équipes qui préfèrent des modèles ET des tests SQL modulaires peuvent utiliser l’adaptateur dbt géré par Microsoft pour Fabric Data Warehouse. Exécutez des tests d’unicité, d’intégrité référentielle et de valeurs autorisées comme critères de validation du déploiement ou du pipeline avant de publier des données vers les couches en aval.

Alternatives

Cette architecture inclut plusieurs composants que vous pouvez remplacer par d'autres services ou approches Azure, en fonction des exigences fonctionnelles et non fonctionnelles de votre charge de travail. Considérez les alternatives suivantes et leurs compromis.

Pour les scénarios qui mettent en évidence l’ingénierie des données à grande échelle, l’analytique avancée, l’apprentissage automatique ou les données non structurées, une architecture lakehouse-first sur Microsoft Fabric peut être mieux adaptée. Dans cette approche, une Fabric lakehouse sert de magasin de données principal dans OneLake, et les transformations sont principalement implémentées à l’aide d’outils basés sur Spark, tels que des notebooks ou Dataflow Gen2. Ce modèle fournit les outils de calcul distribué, de notebooks et de Machine Learning qui ne sont pas l’objectif principal de cette architecture d’entrepôt de données axée d’abord sur SQL.

Pour les organisations qui se concentrent fortement sur la science des données, l’IA ou le traitement distribué complexe, Azure Databricks est une autre alternative. Azure Databricks est généralement sélectionné lorsque les charges de travail nécessitent une intégration approfondie avec des frameworks Machine Learning open source, un contrôle précis sur l’exécution de Spark ou une portabilité multicloud.

Pour des analyses quasiment en temps réel ou pilotées par les événements, Fabric Real-Time Intelligence, Azure Event Hubs ou Azure Stream Analytics peuvent être plus adaptées qu’une conception de médaillon orienté lot centrée sur Fabric Data Warehouse.

Détails du scénario

Fabric Data Warehouse correspond fortement à cette architecture de médaillon lorsque l’objectif principal est de fournir des données gérées et prêtes à l’analytique à grande échelle à l’aide de modèles SQL familiers.

Scénario 1 : sémantique relationnelle et performances SQL pour les jeux de données organisés et prêts pour l’analytique

Fabric Data Warehouse convient parfaitement, car il fournit des tables et vues relationnelles, des transactions ACID et des opérations T-SQL sur les données Delta. Ce jeu de fonctionnalités prend en charge les charges de travail où les données sont déjà nettoyées et conformes et doivent être interrogées de manière cohérente via SQL.

Exemple : Une compagnie aérienne crée des jeux de données gold organisés pour les opérations de vol et l’analytique des revenus. Les analystes s’appuient sur des performances de requête SQL stables pour évaluer les tendances de performances à temps, la rentabilité des itinéraires et l’utilisation de l’équipage. L’utilisation des tables et vues de l’entrepôt garantit la cohérence transactionnelle et le comportement de requête fiable, ce qui est plus difficile à garantir avec un accès ad hoc basé sur des fichiers.

Scénario 2 : Gouvernance centralisée avec une approche centrée sur SQL

Fabric Data Warehouse permet une gouvernance centralisée par le biais des autorisations d'espace de travail, de la sécurité au niveau de l'objet et de la traçabilité intégrée, tout en exposant des données via une interface SQL familière aux équipes d'ingénierie d'analytique. Cette approche réduit les frictions opérationnelles, simplifie le contrôle d’accès et accélère l’adoption entre les équipes sans introduire de nouveaux paradigmes d’accès.

Exemple : Une entreprise globale applique une séparation stricte des tâches : les équipes de plateforme gèrent l’ingestion et les transformations, et les équipes d’analyse consomment uniquement des données organisées. En exposant uniquement les tables de la couche Gold via un entrepôt et en gouvernant les accès de manière centralisée, l’organisation évite tout accès non contrôlé aux données brutes ou intermédiaires tout en conservant un flux de travail SQL familier.

Scénario 3 : Consommation optimisée pour la BI pour les rapports et les tableaux de bord

L’entrepôt est optimisé pour une forte concurrence et des charges de travail à forte dominante de lecture, ce qui en fait un excellent choix lorsque de nombreux utilisateurs métiers consultent des tableaux de bord et des rapports reposant sur des modèles sémantiques cohérents. Cette optimisation est particulièrement importante lorsque les performances, la stabilité et le comportement de requête prévisible sont requis pendant les pics d’utilisation.

Exemple : Les équipes financières et opérationnelles accèdent aux tableaux de bord Power BI pendant les heures d’activité pour surveiller les indicateurs de performance clés tels que le chiffre d’affaires, l’efficacité opérationnelle et la conformité du contrat SLA. Fabric Data Warehouse isole les charges de travail SELECT et non-SELECT dans des pools de calcul distincts, réduisant ainsi la contention directe entre les requêtes de tableau de bord et l’ingestion dans l’entrepôt de données.

Scénario 4 : Prise en charge de la modélisation dimensionnelle pour une couche or réutilisable

Fabric Data Warehouse s’aligne naturellement sur les schémas de modélisation dimensionnelle, y compris les tables de faits et de dimensions, que vous utilisez couramment dans la couche Gold afin d’exposer des jeux de données réutilisables, adaptés aux besoins métier. Ces modèles simplifient l’analytique, réduisent la duplication logique et favorisent des définitions de métriques cohérentes entre les équipes.

Exemple : Une organisation de vente au détail crée des tables de dimension partagées pour les clients, les produits et les magasins, ainsi que des tables de faits pour les ventes et l’inventaire. Ces jeux de données gold sont réutilisés sur plusieurs rapports et unités commerciales Power BI, ce qui garantit que les indicateurs de performance clés tels que les ventes nettes ou le chiffre d’affaires des stocks sont définis une fois et appliqués de manière cohérente.

Considerations

Ces considérations implémentent les piliers de l’infrastructure Azure Well-Architected, qui est un ensemble d’ensembles guidants que vous pouvez utiliser pour améliorer la qualité d’une charge de travail.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez la liste de contrôle de révision de conception pour la fiabilité.

Passez en revue la fiabilité dans Microsoft Fabric pour le modèle de résilience documenté, y compris le comportement interzone et les considérations régionales. Validez les attentes de récupération par rapport à ces conseils pour les besoins de votre région et de votre charge de travail.

Pour les scénarios de reprise d’activité inter-régions, concevez et documentez une stratégie de récupération qui s’aligne sur les exigences organisationnelles et le modèle de responsabilité partagée.

Fabric Data Warehouse prend en charge PRIMARY KEY, FOREIGN KEYet UNIQUEles contraintes de table uniquement en tant que NOT ENFORCED. L’entrepôt ne valide pas l’unicité ou l’intégrité référentielle. La logique d’ingestion et de transformation doit détecter les enregistrements dupliqués ou orphelins et les empêcher d’atteindre des couches en aval.

Security

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez la liste de vérification de la révision de conception pour sécurité.

Microsoft Fabric offre des fonctionnalités permettant de gérer, de contrôler et d’auditer les paramètres de sécurité en fonction des exigences organisationnelles. Tenez compte des pratiques de sécurité suivantes :

Utilisez Microsoft Entra ID’authentification unique (SSO) pour authentifier les utilisateurs et fournir une gestion cohérente des identités sur les appareils et les emplacements.
Appliquez des autorisations basées sur l’espace de travail pour contrôler qui peut créer, modifier ou consommer des artefacts Fabric.
Utilisez Fabric contrôles de sécurité réseau entrants et sortants lors de l’accès aux données ou aux services à l’intérieur ou à l’extérieur de votre réseau. Ces contrôles incluent l’accès conditionnel, les liens privés, l’accès à l’espace de travail approuvé et les points de terminaison privés gérés.
Utilisez Fabric journaux d’audit pour suivre l’activité des utilisateurs, les modifications de configuration et l’accès aux données sur l’ensemble de la plateforme.

Pour plus d’informations, consultez la section Sécurité dans Fabric.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez la liste de contrôle de révision de conception pour l’optimisation des coûts.

Microsoft Fabric fournit des réservations de capacité pour un nombre défini d’unités de capacité (UC). Les réservations d’un an peuvent aider à réduire les coûts des charges de travail à état stable prévisibles.

Pour optimiser l’utilisation de la capacité Fabric, tenez compte des pratiques suivantes :

Commencez par les capacités d’essai ou les SKU F avec paiement à l’utilisation pour comprendre le comportement des charges de travail. Exécutez une preuve de concept étendue avec des charges de travail d’ingestion, de transformation et de création de rapports représentatives. Surveillez la consommation de CU et extrapolez les résultats pour estimer les besoins de production. Vous pouvez faire évoluer les capacités Fabric à mesure que la demande augmente.
Analysez l’historique d’utilisation pour identifier les périodes de pointe et les périodes creuses. Planifiez des charges de travail non critiques ou d’arrière-plan pendant les périodes de faible demande afin de réduire la pression continue sur les CU.
Réduisez la consommation inutile de calcul en optimisant les requêtes SQL, les expressions d’analyse des données (DAX) et les travaux en arrière-plan.
Fabric prend en charge le bursting et le lissage pour absorber les pics à court terme dans la demande de calcul et répartir la consommation de charge de travail en arrière-plan au fil du temps. Ces fonctionnalités permettent de dimensionner les capacités d’utilisation moyenne plutôt que les pics de demande. Pour plus d’informations, veuillez consulter la section Évaluer et optimiser votre capacité Fabric.
Coordonnez les transformations longues et les opérations d’actualisation pour éviter les chevauchements de charges de travail de calcul élevées sur la même capacité. Pour plus d’informations, consultez la gestion des charges de travail dans Fabric Data Warehouse.

Gardez à l’esprit les considérations de tarification suivantes :

Le volume de stockage OneLake, la période de rétention et les modèles d’accès aux données affectent directement le coût total. Estimer la croissance des données attendue par couche de médaillon et aligner la rétention avec les exigences métier et de conformité.
Tarification de Microsoft Fabric repose sur une capacité F attribuée, mesurée en CU. Les licences Power BI par utilisateur sont distinctes et ne fournissent pas de capacité Fabric.

Utilisez l’estimation preconfigurée dans la calculatrice de prix Azure pour obtenir un coût de démarrage pour cette architecture. Ajustez les valeurs pour qu’elles correspondent à votre charge de travail attendue.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus opérationnels qui déploient, surveillent et gèrent une charge de travail en production. Pour plus d’informations, consultez la liste de vérification de la révision de conception pour l’excellence opérationnelle.

Microsoft Fabric offre une visibilité opérationnelle intégrée sur l’ingénierie des données, l’entreposage et les charges de travail d’analytique. Utilisez l’application Métriques de capacité Fabric pour surveiller la consommation de capacité, identifier les artefacts gourmands en ressources et comprendre comment les charges de travail interactives et en arrière-plan contribuent à l’utilisation globale. Ces insights aident les équipes à prendre des décisions opérationnelles éclairées sur la mise à l’échelle, la planification et l’optimisation.

Configurez des alertes proactives afin que les administrateurs de capacité puissent identifier les conditions d’utilisation ou de limitation élevées tôt et répondre avant que l’impact de l’utilisateur ne se produise.

Efficacité des performances

L’efficacité des performances fait référence à la capacité d’une charge de travail à mettre à l’échelle et à répondre efficacement à la demande des utilisateurs. Pour plus d’informations, consultez la liste de vérification de la révision de conception pour l’efficacité des performances.

Microsoft Fabric comprend plusieurs mécanismes permettant de gérer les performances et l’utilisation de la capacité :

L’absorption des pics de charge et le lissage permettent de traiter plus rapidement les pics temporaires de demande de calcul tout en répartissant l’utilisation dans le temps. Les opérations interactives sont généralement lisses au fil des minutes, et les opérations en arrière-plan sont lisses sur des fenêtres plus longues.
Une limitation est appliquée lorsqu’une capacité connaît une utilisation soutenue des ressources de calcul supérieure aux limites de son SKU attribué. La limitation du débit retarde ou rejette les nouvelles opérations pour protéger la stabilité de la plateforme.
L’application Fabric Capacity Metrics fournit une visibilité détaillée de la consommation de capacité et distingue les opérations interactives (telles que les requêtes de rapport) et les opérations en arrière-plan (telles que l’ingestion ou l’actualisation du modèle). Cette distinction permet d’optimiser les performances ciblées pour différents types de charges de travail.

Contributors

Microsoft conserve cet article. Les contributeurs suivants ont écrit cet article.

Prabhjot Kaur | Architecte de solution cloud senior

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Commentaires

Cette page a-t-elle été utile ?