Utiliser Microsoft Fabric pour concevoir une solution BI d'entreprise

Microsoft Fabric

Stockage Blob Azure

Microsoft Entra ID

Power BI

Cet article explique comment transférer des données d’un entrepôt de données local vers un environnement cloud, puis utiliser un modèle décisionnel (BI) pour servir les données. Vous pouvez utiliser cette approche comme objectif final ou comme première étape vers une modernisation complète avec des composants basés sur le cloud.

Ce guide s’appuie sur le scénario de bout en bout de Microsoft Fabric. Il existe plusieurs options pour extraire des données à partir d'un serveur SQL local, comme les pipelines Fabric Data Factory, la mise en miroir, le travail de copie et les flux d’événements en temps réel Fabric pour la capture de données modifiées (CDC) pour SQL. Après l’extraction, les données sont transformées pour l’analyse.

Architecture

Le diagramme montre les types d’entrée, tels que les flux de données, les bases de données, les services de données, les données non structurées et les données structurées. Les composants de la phase d’ingestion reçoivent l’entrée de données. Les composants de phase d’ingestion sont Azure Event Hubs, Azure IoT Hub, les pipelines Fabric, les flux d’événements RTI (Fabric Real-Time Intelligence), la mise en miroir et les travaux de copie. Fabric OneLake est le stockage principal de la phase Store via plusieurs options telles qu’un lakehouse Fabric, un entrepôt Fabric, un entrepôt d'événements Fabric ou des bases de données mises en miroir. Ensuite, les données passent à la phase de traitement pour les flux d’événements Fabric et les ensembles de requêtes KQL afin de traiter les données en temps réel, ainsi que pour les notebooks Spark, les scripts SQL et Dataflow Gen2 destinés aux charges de travail par lots. Certaines données des modèles Machine Learning passent à la phase d’enrichissement, qui inclut Microsoft Foundry et Azure Machine Learning. Les autres données passent à la phase Serve, qui inclut les agents de données Power BI, Fabric et les raccourcis OneLake. Les données sont générées aux utilisateurs professionnels, à l’analytique, aux applications et aux jeux de données partagés.

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

Flux de travail

Le flux de travail suivant correspond au diagramme précédent.

Source de données

• Une base de données SQL Server dans Azure contient les données sources. Pour simuler l’environnement local, les scripts de déploiement de ce scénario configurent une base de données Azure SQL. L’exemple de base de données AdventureWorks est utilisé comme schéma de données source et échantillon de données. Pour plus d’informations, consultez Copier et transformer des données vers et depuis SQL Server.

Ingestion et stockage de données

• Fabric OneLake est un lac de données unique, unifié et logique pour toute votre organisation. Ce SaaS fournit différentes options de stockage de données telles que Fabric Lakehouse pour les charges de travail de lakehouse d’ingénierie des données, Fabric Warehouse pour les charges de travail d’entrepôt de données et Fabric Eventhouse pour les jeux de données de série chronologique et de journal de volume élevé.

• Les pipelines Fabric Data Factory vous permettent de créer des flux de travail d’extraction, de transformation, de chargement (ETL) et de fabrique de données complexes qui peuvent effectuer de nombreuses tâches différentes à grande échelle. Les fonctionnalités de flux de contrôle sont intégrées aux pipelines de données qui vous permettent de générer une logique de flux de travail, qui fournit des boucles et des conditions. Dans cette architecture, les frameworks pilotés par les métadonnées permettent l’ingestion incrémentielle de plusieurs tables à grande échelle.

• La mise en miroir Fabric Data Factory vous permet d’éviter les processus ETL complexes et d’intégrer votre patrimoine SQL Server existant avec le reste de vos données dans Fabric. Vous pouvez répliquer en continu vos bases de données SQL Server existantes directement dans Fabric OneLake. Le travail de copie Fabric Data Factory facilite le déplacement des données de votre source vers votre destination sans avoir besoin de pipelines. Les transferts de données peuvent être configurés via des modèles intégrés pour la copie par lots et incrémentielle, avec prise en charge des performances évolutives.

• Les flux d'événements Fabric fournissent une ingestion de données en temps réel à haut débit à partir d'une base de données SQL Server hébergée sur une machine virtuelle en utilisant l'extraction CDC. Ce modèle convient aux cas d’usage qui nécessitent des tableaux de bord en temps réel et des alertes.

Analyse et rapports

• L’approche de modélisation des données de ce scénario combine le modèle d’entreprise et le modèle sémantique BI. Les références SKU Fabric fournissent le calcul pour les modèles sémantiques Power BI. Power BI peut accéder aux données via la connectivité Import, DirectQuery ou Direct Lake.

Components

• azure SQL Database est un serveur SQL PaaS hébergé par Azure. Dans cette architecture, SQL Database fournit les données sources et illustre le flux de données pour le scénario de migration.

• OneLake est un lac de données unifié basé sur le cloud pour stocker des données structurées et non structurées au sein de l’organisation. Dans cette architecture, OneLake sert de couche de stockage centrale. Il utilise des artefacts tels que Fabric Lakehouse, Fabric Warehouse, Fabric Eventhouse et les bases de données mises en miroir pour conserver et organiser différents types de données pour l’analytique et la création de rapports.

• Fabric Data Warehouse est une offre SaaS qui héberge les charges de travail de l’entrepôt de données pour les jeux de données volumineux. Dans cette architecture, Fabric Data Warehouse sert de magasin final pour les jeux de données dimensionnels et prend en charge l’analytique et la création de rapports.

• Power BI est un outil décisionnel hébergé sur le calcul Fabric. Il présente et visualise les données dans ce scénario, ce qui permet aux utilisateurs professionnels d’interagir avec des tableaux de bord et des rapports basés sur les données de Fabric Data Warehouse et d’autres sources.

• Microsoft Entra ID est une suite de solutions réseau et d’identité multicloud qui prend en charge le flux d’authentification et d’autorisation. Dans cette architecture, Microsoft Entra ID fournit un accès sécurisé aux utilisateurs qui se connectent aux ressources Power BI et Fabric.

Détails du scénario

Dans ce scénario, une organisation dispose d’une base de données SQL qui contient un entrepôt de données local volumineux. L’organisation souhaite utiliser Fabric pour ingérer et analyser les données et fournir des insights analytiques aux utilisateurs via Power BI.

Quand utiliser cette architecture

Vous pouvez utiliser diverses méthodes pour répondre aux exigences en intelligence économique de l'entreprise à l'échelle de l'organisation. Différents aspects définissent les exigences métier, comme les investissements technologiques actuels, les compétences humaines, la chronologie de la modernisation, les objectifs futurs et si vous préférez la plateforme en tant que service (PaaS) ou le logiciel en tant que service (SaaS).

Tenez compte des approches de conception suivantes :

• Un lakehouse dans Fabric

• Fabric et Azure Databricks pour les clients qui ont déjà investi dans Azure Databricks et Power BI et souhaitent moderniser avec Fabric

• Décisionnel entreprise pour les petites et moyennes entreprises qui utilisent un écosystème Azure SQL et Fabric

• Entreposage de données de bout en bout sur Fabric pour les clients qui préfèrent une solution SaaS

L’architecture de cet article suppose que vous utilisez un lakehouse Fabric ou un entrepôt Fabric comme couche persistante du modèle sémantique d’entreprise et que vous utilisez Power BI pour l'intelligence d'affaires. Cette approche SaaS offre la flexibilité nécessaire pour répondre aux différentes exigences et préférences de l’entreprise.

Authentication

Microsoft Entra ID authentifie les utilisateurs qui se connectent aux tableaux de bord et applications Power BI. L’authentification unique connecte les utilisateurs aux données de l’entrepôt Fabric et du modèle sémantique Power BI. L’autorisation se produit à la source.

Chargement incrémentiel

Lorsque vous exécutez un processus ETL ou ELT automatisé, vous devez charger uniquement les données modifiées depuis l’exécution précédente. Ce processus est appelé charge incrémentielle. En revanche, un chargement complet contient toutes les données. Pour effectuer une charge incrémentielle, déterminez comment identifier les données modifiées. Vous pouvez utiliser une approche de valeur de marque d’eau élevée, qui suit la dernière valeur d’une colonne date-heure ou d’une colonne entière unique dans la table source.

Vous pouvez utiliser tables temporelles dans SQL Server. Les tables temporelles sont des tables avec version système qui stockent l’historique des modifications de données. Le moteur de base de données enregistre automatiquement l’historique de chaque modification dans une table d’historique distincte. Pour interroger les données historiques, vous pouvez ajouter une clause FOR SYSTEM_TIME à une requête. En interne, le moteur de base de données interroge la table d’historique, mais cette opération est transparente pour l’application.

Les tables temporelles prennent en charge les données de dimension, qui peuvent changer au fil du temps. Les tables de faits représentent généralement des transactions immuables, telles qu’une vente, où la conservation de l’historique des versions système n’est pas significative. Au lieu de cela, les transactions ont généralement une colonne qui représente la date de transaction. La colonne peut être utilisée comme valeur de filigrane. Par exemple, dans l’entrepôt de données AdventureWorks, les tables SalesLT.* ont un champ LastModified.

Les étapes suivantes décrivent le flux général du pipeline ELT :

1. Pour chaque table de la base de données source, effectuez le suivi de l’heure de coupure lors de l’exécution du dernier travail ELT. Stockez ces informations dans l’entrepôt de données. Lors de la configuration initiale, toutes les heures sont définies sur 1-1-1900.

2. Lors de l’étape d’exportation des données, l’heure de coupure est transmise sous la forme d’un paramètre à un ensemble de procédures stockées dans la base de données source. Ces procédures stockées interrogent tous les enregistrements modifiés ou créés après le délai d’arrêt. Pour toutes les tables de l’exemple, vous pouvez utiliser la colonne ModifiedDate.

3. Lorsque la migration des données est terminée, mettez à jour la table qui stocke les heures de coupure.

Pipeline de données

Ce scénario utilise l’exemple de base de données AdventureWorks comme source de données. Le modèle de chargement incrémentiel des données garantit que seules les données modifiées ou ajoutées après l’exécution du pipeline la plus récente sont chargées.

Infrastructure d’ingestion pilotée par les métadonnées

L’infrastructure d’ingestion pilotée par les métadonnées dans les pipelines Fabric Data Factory charge de manière incrémentielle toutes les tables contenues dans la base de données relationnelle. L’article fait référence à un entrepôt de données en tant que source, mais il peut être remplacé par une base de données Azure SQL en tant que source.

1. Sélectionnez une colonne de filigrane. Choisissez une colonne dans votre table source qui permet de suivre les enregistrements nouveaux ou modifiés. Cette colonne contient généralement des valeurs qui augmentent lorsque les lignes sont ajoutées ou mises à jour (comme un horodatage ou un ID). Utilisez la valeur la plus élevée de cette colonne comme point de référence pour savoir où vous vous êtes arrêté.

2. Mettez en place une table pour stocker la valeur la plus récente du marqueur.

3. Créez un pipeline qui inclut les activités suivantes :

   • Deux activités de consultation. La première activité obtient la dernière valeur de marqueur (où nous nous étions arrêtés la dernière fois). La deuxième activité obtient la nouvelle valeur de filigrane à laquelle nous nous arrêtons cette fois-ci. Les deux valeurs sont passées à l’activité de copie.

   • Activité de copie qui recherche des lignes où la colonne de filigrane a une valeur comprise entre l'ancien et le nouveau filigrane. Il copie ensuite ces données de votre entrepôt de données vers votre lakehouse en tant que nouveau fichier.

   • Activité de procédure stockée qui enregistre la nouvelle valeur de filigrane pour déterminer le point de départ du prochain cycle de pipeline.

   

L’image suivante montre un pipeline terminé. Pour plus d’informations, consultez Ingestion incrémentielle.

Charger des données dans un entrepôt de données Fabric

L’activité de copie copie les données de la base de données SQL dans l’entrepôt de données Fabric. Dans Azure, la base de données SQL de cet exemple utilise une connexion configurée dans le portail Fabric sous Gérer les connexions et les passerelles.

Utiliser des pipelines Fabric Data Factory

Les pipelines dans Fabric Data Factory définissent un ensemble ordonné d’activités pour terminer un modèle de charge incrémentiel. Les déclencheurs manuels ou automatiques démarrent le pipeline.

Transformer les données

Si la transformation est nécessaire, utilisez des dataflows Fabric pour concevoir des transformations ETL à faible code et assistées par l’IA qui remodelent les données. Les dataflows Fabric s’appuient sur le moteur Power Query pour appliquer ces transformations et écrire les résultats dans Fabric Data Warehouse.

Dans un environnement de production, utilisez des notebooks Fabric pour implémenter des transformations ETL qui fonctionnent bien pour les jeux de données volumineux via une infrastructure de calcul distribuée pilotée par Apache Spark.

Note

Utilisez le moteur d’exécution natif pour exécuter l’ingénierie des données ou les charges de travail ETL.

Utiliser Power BI avec des capacités Fabric pour accéder, modéliser et visualiser des données

Les capacités d’infrastructure dans Power BI prennent en charge plusieurs modes de stockage pour la connexion à des sources de données Azure :

• Importation : Charge les données dans le modèle sémantique de Power BI pour des requêtes en mémoire.

• DirectQuery : Exécute des requêtes directement sur le stockage relationnel sans charger de données en mémoire.

• Modèle composite : Combine le mode Importation pour certaines tables avec DirectQuery pour d’autres dans le même jeu de données.

• Lac direct : Interroge les tables delta stockées dans OneLake à partir d’un modèle sémantique d’espace de travail Fabric. Il est optimisé pour l’analyse interactive des tables volumineuses en chargeant des données en mémoire à la demande.

Ce scénario utilise le tableau de bord DirectQuery, car il présente une petite quantité de données et une faible complexité du modèle. DirectQuery délègue la requête au moteur de calcul sous-jacent et utilise des fonctionnalités de sécurité sur la source. DirectQuery garantit que les résultats sont toujours cohérents avec les données sources les plus récentes.

Le mode d’importation peut fournir la latence de requête la plus faible. Envisagez le mode Importation si les facteurs suivants sont vrais :

• Le modèle s’adapte entièrement à la mémoire de Power BI.
• La latence des données entre les actualisations est acceptable.
• Vous avez besoin de transformations complexes entre le système source et le modèle final.

Dans ce cas, les utilisateurs veulent un accès complet aux données les plus récentes sans retard dans l’actualisation de Power BI, et ils veulent toutes les données historiques, qui dépassent la capacité du jeu de données Power BI. Un jeu de données Power BI peut gérer 25 gigaoctets (Go) à 400 Go, en fonction de la taille de capacité. Le modèle de données du pool SQL dédié se trouve déjà dans un schéma en étoile et ne nécessite pas de transformation. DirectQuery est donc un choix approprié.

Utilisez Power BI pour gérer des modèles volumineux, des rapports paginés et des pipelines de déploiement. Tirez parti du point de terminaison Azure Analysis Services intégré. Vous pouvez également avoir une capacité dédiée avec une proposition de valeur unique.

Lorsque le modèle BI augmente ou que la complexité du tableau de bord augmente, vous pouvez basculer vers des modèles composites et importer des parties de tables de recherche via tables hybrides, et importer des données prédéfinies. Vous pouvez activer mise en cache des requêtes dans Power BI pour les jeux de données importés et utiliser tables doubles pour la propriété du mode de stockage.

Dans le modèle composite, les jeux de données servent de couche directe virtuelle. Lorsque les utilisateurs interagissent avec des visualisations, Power BI génère des requêtes SQL dans Fabric Data Warehouse. Power BI détermine s’il faut utiliser un stockage en mémoire ou DirectQuery en fonction de l’efficacité. Le moteur décide quand passer de la mémoire à DirectQuery et envoie la logique à l’entrepôt de données Fabric. Selon le contexte des tables de requête, ils peuvent servir de modèles composites mis en cache (importés) ou non mis en cache. Vous pouvez choisir la table à mettre en cache en mémoire, combiner des données à partir d’une ou plusieurs sources DirectQuery, ou combiner les données sources DirectQuery et les données importées.

Lorsque vous utilisez DirectQuery avec un entrepôt de données Fabric ou lakehouse, effectuez les actions suivantes :

• Utilisez Fabric Z-Order et V-Order pour améliorer les performances des requêtes en optimisant le stockage des données de table sous-jacentes dans les fichiers de format delta.

• Utilisez les vues matérialisées de Fabric Lakehouse pour pré-calculer, stocker et gérer des données de manière similaire à une table. Les requêtes qui utilisent toutes les données ou un sous-ensemble des données dans des vues matérialisées peuvent obtenir des performances plus rapides sans avoir à référencer directement la vue matérialisée définie pour l’utiliser.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Reliability

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

L’article Fiabilité explique comment Fabric prend en charge la fiabilité, y compris la résilience régionale par le biais de zones de disponibilité, ainsi que la récupération interrégion et la continuité de l’activité. Fabric fournit un commutateur de récupération d’urgence sur la page des paramètres de la capacité. Il est disponible lorsque les jumelages régionaux Azure s’alignent sur la présence du service Fabric. Lorsque le paramètre de capacité de récupération d’urgence est activé, la réplication interrégion est activée en tant que fonctionnalité de récupération d’urgence pour les données OneLake.

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 en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

La modernisation du cloud introduit des problèmes de sécurité, tels que les violations de données, les infections par les programmes malveillants et l’injection de code malveillante. Vous avez besoin d’un fournisseur de cloud ou d’une solution de service capable de répondre à vos préoccupations, car des mesures de sécurité insuffisantes peuvent créer des problèmes majeurs.

Ce scénario traite les problèmes de sécurité les plus exigeants en utilisant une combinaison de contrôles de sécurité en couches, notamment les contrôles réseau, identité, confidentialité et autorisation. Un entrepôt de données Fabric stocke la plupart des données. Power BI accède aux données via DirectQuery via l’authentification unique. Utilisez l’ID Microsoft Entra pour l’authentification. Il existe également des contrôles de sécurité étendus pour l’autorisation des données dans les pools approvisionnés.

Tenez compte des problèmes de sécurité courants suivants :

• Définissez qui peut voir les données.

  • Assurez-vous que vos données sont conformes aux directives fédérales, locales et d’entreprise pour atténuer les risques de violation des données. Fabric fournit des fonctionnalités complètes de protection des données pour prendre en charge la sécurité et promouvoir la conformité.

  • La sécurité OneLake contrôle tous les accès aux données OneLake avec différentes autorisations héritées de l’élément parent ou des autorisations d’espace de travail.

    • Un espace de travail est un environnement collaboratif permettant de créer et de gérer des éléments. Les rôles d’espace de travail peuvent être gérés à ce niveau.

    • Un élément est un ensemble de fonctionnalités regroupées en un seul composant. Un élément de données est un sous-type d’élément qui permet de stocker des données dans celui-ci à l’aide de OneLake. Les éléments héritent des autorisations des rôles de l’espace de travail, mais peuvent également disposer d’autorisations supplémentaires. Les dossiers d’un élément sont utilisés pour stocker et gérer des données, telles que Tables/ ou Files/.

• Déterminez comment vérifier l’identité d’un utilisateur.

  • Utilisez Fabric pour contrôler qui peut accéder aux données via le contrôle d’accès et l’authentification.

• Choisissez une technologie de sécurité réseau pour protéger l’intégrité, la confidentialité et l’accès de vos réseaux et données.

  • Aidez à sécuriser Fabric à l’aide des options de sécurité réseau .

• Choisissez des outils pour détecter et vous avertir des menaces.

  • Fabric n’a pas de détection intégrée des menaces. Nous vous recommandons d’utiliser la combinaison du Gestionnaire de conformité Microsoft Purview pour configurer des alertes et passer en revue les journaux d’audit pour suivre les activités des utilisateurs.

• Déterminez comment protéger les données sur Fabric OneLake.

  • Aidez à protéger les données sur Fabric à l’aide d’étiquettes de confidentialité de Microsoft Purview Information Protection. Les étiquettes telles que Général, Confidentiel et Hautement Confidentiel sont largement utilisées dans les applications Microsoft Office telles que Word, PowerPoint et Excel pour protéger les informations sensibles. Ils suivent automatiquement les données de l’élément à l’élément, car elles transitent par Fabric, de la source de données à l’utilisateur professionnel.

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 Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

Cette section décrit les détails de tarification des différents services utilisés dans la solution et explique les décisions prises pour ce scénario à l’aide d’un exemple de jeu de données. Utilisez la configuration de départ dans la calculatrice de prix Azure et ajustez-la en fonction de votre scénario. Pour plus d’informations sur les références SKU Fabric, consultez vue d’ensemble des tarifs Fabric. Pour plus d’informations sur la façon de générer une estimation de la consommation globale de Fabric, consultez l’estimateur de capacité Fabric.

Architecture extensible de la structure

Fabric est une architecture serverless pour la plupart des charges de travail que vous pouvez utiliser pour mettre à l’échelle vos niveaux de calcul et de stockage indépendamment. Les ressources de calcul entraînent des coûts en fonction de l’utilisation. Vous pouvez mettre à l’échelle ou suspendre ces ressources à la demande. Les ressources de stockage entraînent des coûts par Go, de sorte que vos coûts augmentent à mesure que vous ingérez des données.

Pipelines d'usine de textile

Trois composants principaux influencent le prix d’un pipeline :

• Activités de pipeline de données pour l’orchestration : Pour optimiser le coût, réduisez le temps total d’orchestration en implémentant des flux parallèles.

• Dataflow Gen2 pour le calcul : Pour optimiser les coûts, simplifiez les pipelines ETL en filtrant les données inutiles et en traitant l’extraction incrémentielle.

• Déplacement des données pour le travail de copie ou l’activité de copie : Pour optimiser le coût, configurez le travail de copie avec l’extraction incrémentielle et ajustez le débit pour l’activité de copie.

Pour plus d’informations, consultez l’onglet Compteurs de tarification Data Factory sur la tarification de Data Factory.

Le prix varie en fonction des composants ou des activités, de la fréquence et du calcul global associé à l’orchestration. Tout déplacement de données résultant d’activités de pipeline ou d’un travail de copie entraîne un coût. Toutefois, le calcul associé au déplacement des données via la mise en miroir Fabric est gratuit et le coût de stockage des données mises en miroir est libre jusqu’à la taille de capacité. Par exemple, si vous achetez une capacité F64, vous recevez 64 téraoctets (To) de stockage exclusivement utilisés pour la mise en miroir. Le stockage OneLake est facturé si la limite de stockage de mise en miroir libre est dépassée ou lorsque la capacité est suspendue.

Guide de décision de la charge de travail Fabric

Utilisez ce guide de décision pour sélectionner un magasin de données pour vos charges de travail Fabric. Toutes les options sont disponibles dans le stockage unifié dans OneLake.

Le point de terminaison SQL pour Fabric Lakehouse ou Fabric Warehouse offre la possibilité d’exécuter des requêtes ad hoc pour l’analyse. Il permet également aux modèles sémantiques Power BI d’importer ou d’interroger directement les données. Le coût associé à un lakehouse ou un entrepôt équivaut à la consommation des unités de calcul pour les requêtes SQL sur l'endpoint SQL. Pour optimiser les coûts, implémentez Z-Ordering et V-Ordering dans Fabric Lakehouse pour améliorer les performances des requêtes. Pour Data Warehouse, optimisez les requêtes pour lire des lots plus petits.

Stockage OneLake

Le stockage OneLake est facturé à un tarif de paiement à l’utilisation par Go de données utilisées et n’utilise pas d’unités de capacité Fabric (UC). Les éléments Fabric tels que les lakehouses et les entrepôts consomment du stockage OneLake. Pour plus d’informations, consultez la tarification Fabric.

Pour optimiser les coûts de OneLake, concentrez-vous sur la gestion du volume de stockage en supprimant régulièrement les données inutilisées, y compris les données dans le stockage de suppression réversible et en optimisant les opérations de lecture/écriture. Le stockage OneLake est facturé séparément du calcul. Il est donc important de surveiller l’utilisation avec l’application de métriques de capacité Fabric. Pour réduire les coûts de stockage, calculés en fonction de l’utilisation quotidienne moyenne au cours du mois, envisagez de réduire la quantité de données stockées.

Power BI

Ce scénario utilise des espaces de travail Power BI avec des améliorations de performances intégrées pour répondre aux besoins analytiques exigeants. Pour optimiser le coût, implémentez l’actualisation incrémentielle pour l’extraction en mode Importation. Implémentez le mode Direct Lake pour créer des rapports sur des jeux de données plus volumineux lorsque cela est possible pour réduire la charge globale sur les capacités de Fabric.

Pour plus d’informations, consultez tarification de Power BI.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.

• Utilisez un pipeline de mise en production Azure DevOps et GitHub Actions pour automatiser le déploiement d’un artefact d’espace de travail Fabric dans plusieurs environnements. Pour plus d’informations, consultez Intégration continue et livraison continue pour un espace de travail Fabric.

• Placez chaque charge de travail dans un modèle de déploiement distinct et stockez les ressources dans les systèmes de contrôle de code source. Vous pouvez déployer les modèles ensemble ou individuellement dans le cadre d’un processus d’intégration continue et de livraison continue (CI/CD). Cette approche simplifie le processus d’automatisation. Cette architecture comporte quatre charges de travail principales :

  • L’entrepôt de données et les ressources associées
  • Pipelines de Data Factory
  • Ressources Power BI, notamment des tableaux de bord, des applications et des jeux de données
  • Scénario simulé de site local vers le cloud

• Envisagez la préproduction de vos charges de travail dans la mesure du possible. Déployez votre charge de travail à différentes étapes. Exécutez des vérifications de validation à chaque étape avant de passer à la phase suivante. Cette approche envoie des mises à jour à vos environnements de production de manière contrôlée et réduit les problèmes de déploiement imprévus. Utilisez déploiement bleu-vert et stratégies de mise à jour des de mise à jour des environnements de production en direct.

• Utilisez une stratégie de restauration pour gérer les déploiements ayant échoué. Par exemple, vous pouvez automatiquement relancer un déploiement antérieur réussi à partir de votre historique de déploiement. Utilisez l’indicateur --rollback-on-error dans Azure CLI.

• Utilisez l'application Métriques de capacité Fabric pour une surveillance complète de la consommation de capacité Fabric. Utilisez la surveillance de l’espace de travail pour une surveillance détaillée des journaux de télémétrie de l’espace de travail Fabric.

• Utilisez l’estimateur de capacité Fabric pour estimer vos besoins en capacité fabric.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

Cet article utilise la capacité Fabric F64 pour démontrer les fonctionnalités d'intelligence d'affaires. Les capacités Power BI dédiées dans Fabric vont de F64 à la taille maximale du SKU. Pour plus d’informations, consultez la tarification Fabric.

Pour déterminer la capacité dont vous avez besoin, effectuez les actions suivantes :

• Évaluer la de charge sur votre capacité.

• Installez l’application de métriques de capacité Fabric pour une surveillance continue.

• Envisagez d’utiliser des techniques d’optimisation de capacité liées à la charge de travail.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• Bibhu Acharya | Architecte de solution cloud principal

Autres contributeurs :

• Jim McLeod | Architecte de solution cloud
• Miguel Myers | Responsable du programme principal
• Galina Polyakova | Architecte de solution cloud senior
• George Stevens | Ingénieur solution

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

Étapes suivantes

• Qu’est-ce que Power BI Premium ?
• Qu’est-ce que Microsoft Entra ID ?
• Qu’est-ce que Fabric ?
• Qu’est-ce que Data Factory dans Fabric ?
• Qu'est-ce qu’Azure SQL ?

Ressources associées

• Conception de l’architecture des bases de données
• Analytique de bout en bout avec Microsoft Fabric

Cet article explique comment transférer des données d’un entrepôt de données local vers un environnement cloud, puis utiliser un modèle décisionnel (BI) pour servir les données. Vous pouvez utiliser cette approche comme objectif final ou comme première étape vers une modernisation complète avec des composants basés sur le cloud.

Ce guide s’appuie sur le scénario de bout en bout de Microsoft Fabric. Il existe plusieurs options pour extraire des données à partir d'un serveur SQL local, comme les pipelines Fabric Data Factory, la mise en miroir, le travail de copie et les flux d’événements en temps réel Fabric pour la capture de données modifiées (CDC) pour SQL. Après l’extraction, les données sont transformées pour l’analyse.

Architecture

Le diagramme montre les types d’entrée, tels que les flux de données, les bases de données, les services de données, les données non structurées et les données structurées. Les composants de la phase d’ingestion reçoivent l’entrée de données. Les composants de phase d’ingestion sont Azure Event Hubs, Azure IoT Hub, les pipelines Fabric, les flux d’événements RTI (Fabric Real-Time Intelligence), la mise en miroir et les travaux de copie. Fabric OneLake est le stockage principal de la phase Store via plusieurs options telles qu’un lakehouse Fabric, un entrepôt Fabric, un entrepôt d'événements Fabric ou des bases de données mises en miroir. Ensuite, les données passent à la phase de traitement pour les flux d’événements Fabric et les ensembles de requêtes KQL afin de traiter les données en temps réel, ainsi que pour les notebooks Spark, les scripts SQL et Dataflow Gen2 destinés aux charges de travail par lots. Certaines données des modèles Machine Learning passent à la phase d’enrichissement, qui inclut Microsoft Foundry et Azure Machine Learning. Les autres données passent à la phase Serve, qui inclut les agents de données Power BI, Fabric et les raccourcis OneLake. Les données sont générées aux utilisateurs professionnels, à l’analytique, aux applications et aux jeux de données partagés.

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

Flux de travail

Le flux de travail suivant correspond au diagramme précédent.

Source de données

• Une base de données SQL Server dans Azure contient les données sources. Pour simuler l’environnement local, les scripts de déploiement de ce scénario configurent une base de données Azure SQL. L’exemple de base de données AdventureWorks est utilisé comme schéma de données source et échantillon de données. Pour plus d’informations, consultez Copier et transformer des données vers et depuis SQL Server.

Ingestion et stockage de données

• Fabric OneLake est un lac de données unique, unifié et logique pour toute votre organisation. Ce SaaS fournit différentes options de stockage de données telles que Fabric Lakehouse pour les charges de travail de lakehouse d’ingénierie des données, Fabric Warehouse pour les charges de travail d’entrepôt de données et Fabric Eventhouse pour les jeux de données de série chronologique et de journal de volume élevé.

• Les pipelines Fabric Data Factory vous permettent de créer des flux de travail d’extraction, de transformation, de chargement (ETL) et de fabrique de données complexes qui peuvent effectuer de nombreuses tâches différentes à grande échelle. Les fonctionnalités de flux de contrôle sont intégrées aux pipelines de données qui vous permettent de générer une logique de flux de travail, qui fournit des boucles et des conditions. Dans cette architecture, les frameworks pilotés par les métadonnées permettent l’ingestion incrémentielle de plusieurs tables à grande échelle.

• La mise en miroir Fabric Data Factory vous permet d’éviter les processus ETL complexes et d’intégrer votre patrimoine SQL Server existant avec le reste de vos données dans Fabric. Vous pouvez répliquer en continu vos bases de données SQL Server existantes directement dans Fabric OneLake. Le travail de copie Fabric Data Factory facilite le déplacement des données de votre source vers votre destination sans avoir besoin de pipelines. Les transferts de données peuvent être configurés via des modèles intégrés pour la copie par lots et incrémentielle, avec prise en charge des performances évolutives.

• Les flux d'événements Fabric fournissent une ingestion de données en temps réel à haut débit à partir d'une base de données SQL Server hébergée sur une machine virtuelle en utilisant l'extraction CDC. Ce modèle convient aux cas d’usage qui nécessitent des tableaux de bord en temps réel et des alertes.

Analyse et rapports

• L’approche de modélisation des données de ce scénario combine le modèle d’entreprise et le modèle sémantique BI. Les références SKU Fabric fournissent le calcul pour les modèles sémantiques Power BI. Power BI peut accéder aux données via la connectivité Import, DirectQuery ou Direct Lake.

Components

• azure SQL Database est un serveur SQL PaaS hébergé par Azure. Dans cette architecture, SQL Database fournit les données sources et illustre le flux de données pour le scénario de migration.

• OneLake est un lac de données unifié basé sur le cloud pour stocker des données structurées et non structurées au sein de l’organisation. Dans cette architecture, OneLake sert de couche de stockage centrale. Il utilise des artefacts tels que Fabric Lakehouse, Fabric Warehouse, Fabric Eventhouse et les bases de données mises en miroir pour conserver et organiser différents types de données pour l’analytique et la création de rapports.

• Fabric Data Warehouse est une offre SaaS qui héberge les charges de travail de l’entrepôt de données pour les jeux de données volumineux. Dans cette architecture, Fabric Data Warehouse sert de magasin final pour les jeux de données dimensionnels et prend en charge l’analytique et la création de rapports.

• Power BI est un outil décisionnel hébergé sur le calcul Fabric. Il présente et visualise les données dans ce scénario, ce qui permet aux utilisateurs professionnels d’interagir avec des tableaux de bord et des rapports basés sur les données de Fabric Data Warehouse et d’autres sources.

• Microsoft Entra ID est une suite de solutions réseau et d’identité multicloud qui prend en charge le flux d’authentification et d’autorisation. Dans cette architecture, Microsoft Entra ID fournit un accès sécurisé aux utilisateurs qui se connectent aux ressources Power BI et Fabric.

Détails du scénario

Dans ce scénario, une organisation dispose d’une base de données SQL qui contient un entrepôt de données local volumineux. L’organisation souhaite utiliser Fabric pour ingérer et analyser les données et fournir des insights analytiques aux utilisateurs via Power BI.

Quand utiliser cette architecture

Vous pouvez utiliser diverses méthodes pour répondre aux exigences en intelligence économique de l'entreprise à l'échelle de l'organisation. Différents aspects définissent les exigences métier, comme les investissements technologiques actuels, les compétences humaines, la chronologie de la modernisation, les objectifs futurs et si vous préférez la plateforme en tant que service (PaaS) ou le logiciel en tant que service (SaaS).

Tenez compte des approches de conception suivantes :

• Un lakehouse dans Fabric

• Fabric et Azure Databricks pour les clients qui ont déjà investi dans Azure Databricks et Power BI et souhaitent moderniser avec Fabric

• Décisionnel entreprise pour les petites et moyennes entreprises qui utilisent un écosystème Azure SQL et Fabric

• Entreposage de données de bout en bout sur Fabric pour les clients qui préfèrent une solution SaaS

L’architecture de cet article suppose que vous utilisez un lakehouse Fabric ou un entrepôt Fabric comme couche persistante du modèle sémantique d’entreprise et que vous utilisez Power BI pour l'intelligence d'affaires. Cette approche SaaS offre la flexibilité nécessaire pour répondre aux différentes exigences et préférences de l’entreprise.

Authentication

Microsoft Entra ID authentifie les utilisateurs qui se connectent aux tableaux de bord et applications Power BI. L’authentification unique connecte les utilisateurs aux données de l’entrepôt Fabric et du modèle sémantique Power BI. L’autorisation se produit à la source.

Chargement incrémentiel

Lorsque vous exécutez un processus ETL ou ELT automatisé, vous devez charger uniquement les données modifiées depuis l’exécution précédente. Ce processus est appelé charge incrémentielle. En revanche, un chargement complet contient toutes les données. Pour effectuer une charge incrémentielle, déterminez comment identifier les données modifiées. Vous pouvez utiliser une approche de valeur de marque d’eau élevée, qui suit la dernière valeur d’une colonne date-heure ou d’une colonne entière unique dans la table source.

Vous pouvez utiliser tables temporelles dans SQL Server. Les tables temporelles sont des tables avec version système qui stockent l’historique des modifications de données. Le moteur de base de données enregistre automatiquement l’historique de chaque modification dans une table d’historique distincte. Pour interroger les données historiques, vous pouvez ajouter une clause FOR SYSTEM_TIME à une requête. En interne, le moteur de base de données interroge la table d’historique, mais cette opération est transparente pour l’application.

Les tables temporelles prennent en charge les données de dimension, qui peuvent changer au fil du temps. Les tables de faits représentent généralement des transactions immuables, telles qu’une vente, où la conservation de l’historique des versions système n’est pas significative. Au lieu de cela, les transactions ont généralement une colonne qui représente la date de transaction. La colonne peut être utilisée comme valeur de filigrane. Par exemple, dans l’entrepôt de données AdventureWorks, les tables SalesLT.* ont un champ LastModified.

Les étapes suivantes décrivent le flux général du pipeline ELT :

1. Pour chaque table de la base de données source, effectuez le suivi de l’heure de coupure lors de l’exécution du dernier travail ELT. Stockez ces informations dans l’entrepôt de données. Lors de la configuration initiale, toutes les heures sont définies sur 1-1-1900.

2. Lors de l’étape d’exportation des données, l’heure de coupure est transmise sous la forme d’un paramètre à un ensemble de procédures stockées dans la base de données source. Ces procédures stockées interrogent tous les enregistrements modifiés ou créés après le délai d’arrêt. Pour toutes les tables de l’exemple, vous pouvez utiliser la colonne ModifiedDate.

3. Lorsque la migration des données est terminée, mettez à jour la table qui stocke les heures de coupure.

Pipeline de données

Ce scénario utilise l’exemple de base de données AdventureWorks comme source de données. Le modèle de chargement incrémentiel des données garantit que seules les données modifiées ou ajoutées après l’exécution du pipeline la plus récente sont chargées.

Infrastructure d’ingestion pilotée par les métadonnées

L’infrastructure d’ingestion pilotée par les métadonnées dans les pipelines Fabric Data Factory charge de manière incrémentielle toutes les tables contenues dans la base de données relationnelle. L’article fait référence à un entrepôt de données en tant que source, mais il peut être remplacé par une base de données Azure SQL en tant que source.

1. Sélectionnez une colonne de filigrane. Choisissez une colonne dans votre table source qui permet de suivre les enregistrements nouveaux ou modifiés. Cette colonne contient généralement des valeurs qui augmentent lorsque les lignes sont ajoutées ou mises à jour (comme un horodatage ou un ID). Utilisez la valeur la plus élevée de cette colonne comme point de référence pour savoir où vous vous êtes arrêté.

2. Mettez en place une table pour stocker la valeur la plus récente du marqueur.

3. Créez un pipeline qui inclut les activités suivantes :

   • Deux activités de consultation. La première activité obtient la dernière valeur de marqueur (où nous nous étions arrêtés la dernière fois). La deuxième activité obtient la nouvelle valeur de filigrane à laquelle nous nous arrêtons cette fois-ci. Les deux valeurs sont passées à l’activité de copie.

   • Activité de copie qui recherche des lignes où la colonne de filigrane a une valeur comprise entre l'ancien et le nouveau filigrane. Il copie ensuite ces données de votre entrepôt de données vers votre lakehouse en tant que nouveau fichier.

   • Activité de procédure stockée qui enregistre la nouvelle valeur de filigrane pour déterminer le point de départ du prochain cycle de pipeline.

   

L’image suivante montre un pipeline terminé. Pour plus d’informations, consultez Ingestion incrémentielle.

Charger des données dans un entrepôt de données Fabric

L’activité de copie copie les données de la base de données SQL dans l’entrepôt de données Fabric. Dans Azure, la base de données SQL de cet exemple utilise une connexion configurée dans le portail Fabric sous Gérer les connexions et les passerelles.

Utiliser des pipelines Fabric Data Factory

Les pipelines dans Fabric Data Factory définissent un ensemble ordonné d’activités pour terminer un modèle de charge incrémentiel. Les déclencheurs manuels ou automatiques démarrent le pipeline.

Transformer les données

Si la transformation est nécessaire, utilisez des dataflows Fabric pour concevoir des transformations ETL à faible code et assistées par l’IA qui remodelent les données. Les dataflows Fabric s’appuient sur le moteur Power Query pour appliquer ces transformations et écrire les résultats dans Fabric Data Warehouse.

Dans un environnement de production, utilisez des notebooks Fabric pour implémenter des transformations ETL qui fonctionnent bien pour les jeux de données volumineux via une infrastructure de calcul distribuée pilotée par Apache Spark.

Note

Utilisez le moteur d’exécution natif pour exécuter l’ingénierie des données ou les charges de travail ETL.

Utiliser Power BI avec des capacités Fabric pour accéder, modéliser et visualiser des données

Les capacités d’infrastructure dans Power BI prennent en charge plusieurs modes de stockage pour la connexion à des sources de données Azure :

• Importation : Charge les données dans le modèle sémantique de Power BI pour des requêtes en mémoire.

• DirectQuery : Exécute des requêtes directement sur le stockage relationnel sans charger de données en mémoire.

• Modèle composite : Combine le mode Importation pour certaines tables avec DirectQuery pour d’autres dans le même jeu de données.

• Lac direct : Interroge les tables delta stockées dans OneLake à partir d’un modèle sémantique d’espace de travail Fabric. Il est optimisé pour l’analyse interactive des tables volumineuses en chargeant des données en mémoire à la demande.

Ce scénario utilise le tableau de bord DirectQuery, car il présente une petite quantité de données et une faible complexité du modèle. DirectQuery délègue la requête au moteur de calcul sous-jacent et utilise des fonctionnalités de sécurité sur la source. DirectQuery garantit que les résultats sont toujours cohérents avec les données sources les plus récentes.

Le mode d’importation peut fournir la latence de requête la plus faible. Envisagez le mode Importation si les facteurs suivants sont vrais :

• Le modèle s’adapte entièrement à la mémoire de Power BI.
• La latence des données entre les actualisations est acceptable.
• Vous avez besoin de transformations complexes entre le système source et le modèle final.

Dans ce cas, les utilisateurs veulent un accès complet aux données les plus récentes sans retard dans l’actualisation de Power BI, et ils veulent toutes les données historiques, qui dépassent la capacité du jeu de données Power BI. Un jeu de données Power BI peut gérer 25 gigaoctets (Go) à 400 Go, en fonction de la taille de capacité. Le modèle de données du pool SQL dédié se trouve déjà dans un schéma en étoile et ne nécessite pas de transformation. DirectQuery est donc un choix approprié.

Utilisez Power BI pour gérer des modèles volumineux, des rapports paginés et des pipelines de déploiement. Tirez parti du point de terminaison Azure Analysis Services intégré. Vous pouvez également avoir une capacité dédiée avec une proposition de valeur unique.

Lorsque le modèle BI augmente ou que la complexité du tableau de bord augmente, vous pouvez basculer vers des modèles composites et importer des parties de tables de recherche via tables hybrides, et importer des données prédéfinies. Vous pouvez activer mise en cache des requêtes dans Power BI pour les jeux de données importés et utiliser tables doubles pour la propriété du mode de stockage.

Dans le modèle composite, les jeux de données servent de couche directe virtuelle. Lorsque les utilisateurs interagissent avec des visualisations, Power BI génère des requêtes SQL dans Fabric Data Warehouse. Power BI détermine s’il faut utiliser un stockage en mémoire ou DirectQuery en fonction de l’efficacité. Le moteur décide quand passer de la mémoire à DirectQuery et envoie la logique à l’entrepôt de données Fabric. Selon le contexte des tables de requête, ils peuvent servir de modèles composites mis en cache (importés) ou non mis en cache. Vous pouvez choisir la table à mettre en cache en mémoire, combiner des données à partir d’une ou plusieurs sources DirectQuery, ou combiner les données sources DirectQuery et les données importées.

Lorsque vous utilisez DirectQuery avec un entrepôt de données Fabric ou lakehouse, effectuez les actions suivantes :

• Utilisez Fabric Z-Order et V-Order pour améliorer les performances des requêtes en optimisant le stockage des données de table sous-jacentes dans les fichiers de format delta.

• Utilisez les vues matérialisées de Fabric Lakehouse pour pré-calculer, stocker et gérer des données de manière similaire à une table. Les requêtes qui utilisent toutes les données ou un sous-ensemble des données dans des vues matérialisées peuvent obtenir des performances plus rapides sans avoir à référencer directement la vue matérialisée définie pour l’utiliser.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Reliability

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

L’article Fiabilité explique comment Fabric prend en charge la fiabilité, y compris la résilience régionale par le biais de zones de disponibilité, ainsi que la récupération interrégion et la continuité de l’activité. Fabric fournit un commutateur de récupération d’urgence sur la page des paramètres de la capacité. Il est disponible lorsque les jumelages régionaux Azure s’alignent sur la présence du service Fabric. Lorsque le paramètre de capacité de récupération d’urgence est activé, la réplication interrégion est activée en tant que fonctionnalité de récupération d’urgence pour les données OneLake.

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 en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

La modernisation du cloud introduit des problèmes de sécurité, tels que les violations de données, les infections par les programmes malveillants et l’injection de code malveillante. Vous avez besoin d’un fournisseur de cloud ou d’une solution de service capable de répondre à vos préoccupations, car des mesures de sécurité insuffisantes peuvent créer des problèmes majeurs.

Ce scénario traite les problèmes de sécurité les plus exigeants en utilisant une combinaison de contrôles de sécurité en couches, notamment les contrôles réseau, identité, confidentialité et autorisation. Un entrepôt de données Fabric stocke la plupart des données. Power BI accède aux données via DirectQuery via l’authentification unique. Utilisez l’ID Microsoft Entra pour l’authentification. Il existe également des contrôles de sécurité étendus pour l’autorisation des données dans les pools approvisionnés.

Tenez compte des problèmes de sécurité courants suivants :

• Définissez qui peut voir les données.

  • Assurez-vous que vos données sont conformes aux directives fédérales, locales et d’entreprise pour atténuer les risques de violation des données. Fabric fournit des fonctionnalités complètes de protection des données pour prendre en charge la sécurité et promouvoir la conformité.

  • La sécurité OneLake contrôle tous les accès aux données OneLake avec différentes autorisations héritées de l’élément parent ou des autorisations d’espace de travail.

    • Un espace de travail est un environnement collaboratif permettant de créer et de gérer des éléments. Les rôles d’espace de travail peuvent être gérés à ce niveau.

    • Un élément est un ensemble de fonctionnalités regroupées en un seul composant. Un élément de données est un sous-type d’élément qui permet de stocker des données dans celui-ci à l’aide de OneLake. Les éléments héritent des autorisations des rôles de l’espace de travail, mais peuvent également disposer d’autorisations supplémentaires. Les dossiers d’un élément sont utilisés pour stocker et gérer des données, telles que Tables/ ou Files/.

• Déterminez comment vérifier l’identité d’un utilisateur.

  • Utilisez Fabric pour contrôler qui peut accéder aux données via le contrôle d’accès et l’authentification.

• Choisissez une technologie de sécurité réseau pour protéger l’intégrité, la confidentialité et l’accès de vos réseaux et données.

  • Aidez à sécuriser Fabric à l’aide des options de sécurité réseau .

• Choisissez des outils pour détecter et vous avertir des menaces.

  • Fabric n’a pas de détection intégrée des menaces. Nous vous recommandons d’utiliser la combinaison du Gestionnaire de conformité Microsoft Purview pour configurer des alertes et passer en revue les journaux d’audit pour suivre les activités des utilisateurs.

• Déterminez comment protéger les données sur Fabric OneLake.

  • Aidez à protéger les données sur Fabric à l’aide d’étiquettes de confidentialité de Microsoft Purview Information Protection. Les étiquettes telles que Général, Confidentiel et Hautement Confidentiel sont largement utilisées dans les applications Microsoft Office telles que Word, PowerPoint et Excel pour protéger les informations sensibles. Ils suivent automatiquement les données de l’élément à l’élément, car elles transitent par Fabric, de la source de données à l’utilisateur professionnel.

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 Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

Cette section décrit les détails de tarification des différents services utilisés dans la solution et explique les décisions prises pour ce scénario à l’aide d’un exemple de jeu de données. Utilisez la configuration de départ dans la calculatrice de prix Azure et ajustez-la en fonction de votre scénario. Pour plus d’informations sur les références SKU Fabric, consultez vue d’ensemble des tarifs Fabric. Pour plus d’informations sur la façon de générer une estimation de la consommation globale de Fabric, consultez l’estimateur de capacité Fabric.

Architecture extensible de la structure

Fabric est une architecture serverless pour la plupart des charges de travail que vous pouvez utiliser pour mettre à l’échelle vos niveaux de calcul et de stockage indépendamment. Les ressources de calcul entraînent des coûts en fonction de l’utilisation. Vous pouvez mettre à l’échelle ou suspendre ces ressources à la demande. Les ressources de stockage entraînent des coûts par Go, de sorte que vos coûts augmentent à mesure que vous ingérez des données.

Pipelines d'usine de textile

Trois composants principaux influencent le prix d’un pipeline :

• Activités de pipeline de données pour l’orchestration : Pour optimiser le coût, réduisez le temps total d’orchestration en implémentant des flux parallèles.

• Dataflow Gen2 pour le calcul : Pour optimiser les coûts, simplifiez les pipelines ETL en filtrant les données inutiles et en traitant l’extraction incrémentielle.

• Déplacement des données pour le travail de copie ou l’activité de copie : Pour optimiser le coût, configurez le travail de copie avec l’extraction incrémentielle et ajustez le débit pour l’activité de copie.

Pour plus d’informations, consultez l’onglet Compteurs de tarification Data Factory sur la tarification de Data Factory.

Le prix varie en fonction des composants ou des activités, de la fréquence et du calcul global associé à l’orchestration. Tout déplacement de données résultant d’activités de pipeline ou d’un travail de copie entraîne un coût. Toutefois, le calcul associé au déplacement des données via la mise en miroir Fabric est gratuit et le coût de stockage des données mises en miroir est libre jusqu’à la taille de capacité. Par exemple, si vous achetez une capacité F64, vous recevez 64 téraoctets (To) de stockage exclusivement utilisés pour la mise en miroir. Le stockage OneLake est facturé si la limite de stockage de mise en miroir libre est dépassée ou lorsque la capacité est suspendue.

Guide de décision de la charge de travail Fabric

Utilisez ce guide de décision pour sélectionner un magasin de données pour vos charges de travail Fabric. Toutes les options sont disponibles dans le stockage unifié dans OneLake.

Le point de terminaison SQL pour Fabric Lakehouse ou Fabric Warehouse offre la possibilité d’exécuter des requêtes ad hoc pour l’analyse. Il permet également aux modèles sémantiques Power BI d’importer ou d’interroger directement les données. Le coût associé à un lakehouse ou un entrepôt équivaut à la consommation des unités de calcul pour les requêtes SQL sur l'endpoint SQL. Pour optimiser les coûts, implémentez Z-Ordering et V-Ordering dans Fabric Lakehouse pour améliorer les performances des requêtes. Pour Data Warehouse, optimisez les requêtes pour lire des lots plus petits.

Stockage OneLake

Le stockage OneLake est facturé à un tarif de paiement à l’utilisation par Go de données utilisées et n’utilise pas d’unités de capacité Fabric (UC). Les éléments Fabric tels que les lakehouses et les entrepôts consomment du stockage OneLake. Pour plus d’informations, consultez la tarification Fabric.

Pour optimiser les coûts de OneLake, concentrez-vous sur la gestion du volume de stockage en supprimant régulièrement les données inutilisées, y compris les données dans le stockage de suppression réversible et en optimisant les opérations de lecture/écriture. Le stockage OneLake est facturé séparément du calcul. Il est donc important de surveiller l’utilisation avec l’application de métriques de capacité Fabric. Pour réduire les coûts de stockage, calculés en fonction de l’utilisation quotidienne moyenne au cours du mois, envisagez de réduire la quantité de données stockées.

Power BI

Ce scénario utilise des espaces de travail Power BI avec des améliorations de performances intégrées pour répondre aux besoins analytiques exigeants. Pour optimiser le coût, implémentez l’actualisation incrémentielle pour l’extraction en mode Importation. Implémentez le mode Direct Lake pour créer des rapports sur des jeux de données plus volumineux lorsque cela est possible pour réduire la charge globale sur les capacités de Fabric.

Pour plus d’informations, consultez tarification de Power BI.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.

• Utilisez un pipeline de mise en production Azure DevOps et GitHub Actions pour automatiser le déploiement d’un artefact d’espace de travail Fabric dans plusieurs environnements. Pour plus d’informations, consultez Intégration continue et livraison continue pour un espace de travail Fabric.

• Placez chaque charge de travail dans un modèle de déploiement distinct et stockez les ressources dans les systèmes de contrôle de code source. Vous pouvez déployer les modèles ensemble ou individuellement dans le cadre d’un processus d’intégration continue et de livraison continue (CI/CD). Cette approche simplifie le processus d’automatisation. Cette architecture comporte quatre charges de travail principales :

  • L’entrepôt de données et les ressources associées
  • Pipelines de Data Factory
  • Ressources Power BI, notamment des tableaux de bord, des applications et des jeux de données
  • Scénario simulé de site local vers le cloud

• Envisagez la préproduction de vos charges de travail dans la mesure du possible. Déployez votre charge de travail à différentes étapes. Exécutez des vérifications de validation à chaque étape avant de passer à la phase suivante. Cette approche envoie des mises à jour à vos environnements de production de manière contrôlée et réduit les problèmes de déploiement imprévus. Utilisez déploiement bleu-vert et stratégies de mise à jour des de mise à jour des environnements de production en direct.

• Utilisez une stratégie de restauration pour gérer les déploiements ayant échoué. Par exemple, vous pouvez automatiquement relancer un déploiement antérieur réussi à partir de votre historique de déploiement. Utilisez l’indicateur --rollback-on-error dans Azure CLI.

• Utilisez l'application Métriques de capacité Fabric pour une surveillance complète de la consommation de capacité Fabric. Utilisez la surveillance de l’espace de travail pour une surveillance détaillée des journaux de télémétrie de l’espace de travail Fabric.

• Utilisez l’estimateur de capacité Fabric pour estimer vos besoins en capacité fabric.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

Cet article utilise la capacité Fabric F64 pour démontrer les fonctionnalités d'intelligence d'affaires. Les capacités Power BI dédiées dans Fabric vont de F64 à la taille maximale du SKU. Pour plus d’informations, consultez la tarification Fabric.

Pour déterminer la capacité dont vous avez besoin, effectuez les actions suivantes :

• Évaluer la de charge sur votre capacité.

• Installez l’application de métriques de capacité Fabric pour une surveillance continue.

• Envisagez d’utiliser des techniques d’optimisation de capacité liées à la charge de travail.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• Bibhu Acharya | Architecte de solution cloud principal

Autres contributeurs :

• Jim McLeod | Architecte de solution cloud
• Miguel Myers | Responsable du programme principal
• Galina Polyakova | Architecte de solution cloud senior
• George Stevens | Ingénieur solution

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

Étapes suivantes

• Qu’est-ce que Power BI Premium ?
• Qu’est-ce que Microsoft Entra ID ?
• Qu’est-ce que Fabric ?
• Qu’est-ce que Data Factory dans Fabric ?
• Qu'est-ce qu’Azure SQL ?

Ressources associées

• Conception de l’architecture des bases de données
• Analytique de bout en bout avec Microsoft Fabric