Partager via

Stocker des données dans Microsoft Fabric

Microsoft Fabric fournit plusieurs options de stockage conçues pour prendre en charge l’analytique, le traitement en temps réel et les rapports opérationnels au sein d’une plateforme unifiée. Le choix de l’expérience de stockage appropriée vous permet d’optimiser les performances, de gérer les coûts et d’aligner votre architecture de données avec les exigences de charge de travail. Quelle que soit sa source ou sa méthode de préparation, toutes les données atterrissent dans une base de stockage unifiée appelée OneLake.

Cet article explique comment les données sont stockées dans Fabric et décrit les expériences de stockage principales disponibles. Les sections suivantes couvrent :

  • OneLake : lac de données unifié et logique qui sous-tend toutes les charges de travail Fabric.
  • Lakehouse : Stockez et analysez des données structurées et non structurées à l’aide de tables Delta.
  • Entrepôt : stockez les données relationnelles optimisées pour l’analytique SQL hautes performances.
  • Eventhouse – Stocker et interroger des données d’événements en temps réel et en volume élevé.
  • Bases de données et autres expériences de stockage : comprendre les fonctionnalités de stockage supplémentaires disponibles dans Fabric.

Utilisez cette vue d’ensemble pour comprendre le fonctionnement de chaque option de stockage et choisir le meilleur ajustement pour vos scénarios analytiques et opérationnels.

Lakehouse pour le stockage de données flexible

Un Lakehouse est un élément de stockage principal dans Fabric qui utilise OneLake pour stocker des données dans les formats de fichier et de table. Un Lakehouse représente une structure de dossiers organisée dans OneLake et inclut une interface SQL. A Lakehouse stocke les données sous forme de fichiers Delta Parquet. Vous pouvez organiser des fichiers bruts tels que des fichiers CSV ou des images dans des dossiers, et vous pouvez créer des tables Delta managées pour les données structurées. Ce modèle prend en charge les données structurées et non structurées dans le même environnement.

Fabric provisionne automatiquement un point de terminaison d’analytique SQL pour chaque Lakehouse. Vous et des outils tels que Power BI peuvent interroger des tables Delta à l’aide de Transact-SQL, comme si vous interrogez une base de données relationnelle. Lakehouse combine l’extensibilité et la flexibilité d’un lac de données avec les fonctionnalités de base de l’entrepôt, notamment l’interrogation directe de tables et la gestion des schémas.

Entrepôt pour l’analytique structurée

Un entrepôt dans Fabric offre une expérience traditionnelle de l’entrepôt de données SQL (avec des tables, des vues SQL, des procédures stockées, etc.) sur le stockage unifié de Fabric. Lorsque vous créez un entrepôt, il stocke les données au format OneLake au format Delta en tant qu’ensemble organisé de tables Delta avec une interface ANSI SQL en haut. L’entrepôt fournit des performances de calcul et d’optimisation dédiées pour les requêtes SQL complexes et les charges de travail de style BI. Il prend en charge des fonctionnalités telles que l’indexation, les procédures stockées et les transactions ACID robustes sur les tables.

L’entrepôt et Lakehouse partagent le même stockage OneLake sous-jacent. Vous pouvez les intégrer à l’aide de raccourcis ou d’autres fonctionnalités d’interopérabilité si nécessaire. Toutefois, vous les conservez généralement séparément pour différents cas d’usage. L’entrepôt est idéal pour les données structurées de schéma en étoile relationnel que vous avez besoin d'explorer avec SQL. Vous pouvez utiliser des pipelines Fabric pour charger des données dans l’entrepôt. Power BI peut se connecter à l’aide de Direct Lake ou directQuery pour récupérer des données sans importation.

Guide de décision : Lakehouse vs. Warehouse

Les entrepôts et les lakehouses servent des rôles distincts mais complémentaires.

  • Les entrepôts sont optimisés pour l'entreposage de données structurées à l'échelle de l'entreprise avec une prise en charge complète de T-SQL, des transactions ACID et une application stricte des schémas, idéale pour l'informatique décisionnelle et la création de rapports. Choisissez un entrepôt pour les charges de travail SQL régies, hautes performances et un Lakehouse pour le traitement Big Data, l’analytique exploratoire et les scénarios qui impliquent des formats de données variés ou une intégration avec un lac externe.

  • Lakehouses offre un stockage flexible et évolutif pour les données structurées et non structurées, prenant en charge l’ingénierie des données basée sur Spark et l’analytique SQL en lecture seule via des points de terminaison automatiques.

De nombreuses organisations tirent parti d'une utilisation conjointe des deux : les Lakehouses pour l'ingestion et la préparation des données, et les entrepôts pour l'analytique avancée et la génération de rapports détaillés. Pour en savoir plus, consultez le guide de décision.

Bases de données mises en miroir pour la réplication en quasi temps réel

Une base de données mise en miroir dans Fabric est une copie répliquée en continu d’une base de données opérationnelle externe, telle qu’Azure SQL Database, SQL Server, Azure Cosmos DB ou Snowflake. Fabric stocke les données mises en miroir dans OneLake au format Delta Lake.

La mise en miroir synchronise les changements de source dans Fabric en temps quasi-réel sans nécessiter de pipelines traditionnels d'extraction, de transformation et de chargement. Après la réplication, les données sont immédiatement interrogeables via des points de terminaison SQL et sont disponibles dans les charges de travail Fabric, notamment Power BI, les notebooks Spark et les pipelines.

Cette architecture prend en charge les scénarios de traitement transactionnel et analytique hybride (HTAP), où vous analysez les données opérationnelles tout en conservant l’intégrité du système source.

Eventhouse pour l’analytique des événements en temps réel

Un Eventhouse fournit un environnement d’analytique en temps réel évolutif conçu pour ingérer, stocker et analyser des volumes élevés de données d’événements. Il s’agit du moteur de base pour les charges de travail d'intelligence en temps réel.

Un Eventhouse héberge une ou plusieurs bases de données Kusto Query Language basées sur le moteur Kusto. Ces bases de données indexent et partitionnent automatiquement les données en fonction du temps d’ingestion. Vous interrogez des données à l’aide du langage de requête Kusto.

Eventhouse convient parfaitement aux données de télémétrie, aux journaux de sécurité, aux enregistrements de conformité et aux transactions financières où l’analytique à faible latence et l’ingestion à grande échelle sont requises.

Base de données SQL pour les charges de travail transactionnelles

Les bases de données SQL dans Fabric prennent en charge les charges de travail d’analytique transactionnelle et opérationnelle. Ils offrent une expérience de base de données relationnelle entièrement managée avec prise en charge de T-SQL, notamment la définition de données (DDL), la manipulation (DML) et les fonctionnalités d’interrogation (DQL). Vous pouvez utiliser des procédures stockées, des vues et des fonctions pour créer des solutions transactionnelles et analytiques.

Les bases de données SQL utilisent un service de mise en miroir automatique pour répliquer des tables transactionnelles dans OneLake pour l’analytique. Lorsque vous créez une base de données SQL, Fabric démarre un moteur de réplication qui capture les opérations d’insertion, de mise à jour et de suppression via le flux de modification du moteur SQL et écrit ces modifications dans OneLake en tant que fichiers Delta Parquet. La réplication se produit en quasi-temps réel et démarre automatiquement. Toutes les tables prises en charge sont mises en miroir par défaut. Ce comportement garantit que la copie OneLake reste synchronisée avec la base de données opérationnelle.

Les bases de données SQL s’intègrent à d’autres expériences Fabric telles que Power BI, notebooks, fonctions de données utilisateur, pipelines et outils externes via le protocole TDS. Cette intégration vous permet de créer des solutions de bout en bout, de l’ingestion et de la transformation des données à la visualisation et aux rapports, sans quitter l’environnement Fabric. La plateforme gère automatiquement l’indexation et l’optimisation des performances. Vous n’avez donc pas besoin de régler ou de gérer manuellement l’infrastructure.

Cosmos DB pour les charges de travail NoSQL distribuées

Cosmos DB dans Microsoft Fabric est une base de données NoSQL entièrement managée et distribuée conçue pour des applications à haut débit et distribuées à l’échelle mondiale. Il prend en charge les modèles de schéma flexibles et les données JSON semi-structurées.

Cosmos DB est automatiquement mis en miroir dans OneLake au format Delta pour prendre en charge l’analytique sans affecter les performances opérationnelles. La réplication est continue et en quasi-temps réel et ne nécessite aucune configuration manuelle.

Après la réplication, les données sont accessibles via un point de terminaison d’analytique SQL. Vous pouvez interroger des données à l’aide de Transact-SQL, créer des vues et les intégrer à Power BI, notebooks et pipelines.

Le point de terminaison d’analytique SQL fournit une interface en lecture seule pour les données mises en miroir, ce qui garantit que les requêtes analytiques n’interfèrent pas avec les opérations transactionnelles. Cette architecture prend en charge le traitement transactionnel et analytique hybride (HTAP), ce qui vous permet d’unifier les charges de travail opérationnelles et analytiques au sein d’une plateforme unique.

Modèle sémantique pour la logique métier et la création de rapports

Les modèles sémantiques fournissent la couche structurée et organisée qui définit la logique métier, les mesures, les hiérarchies, les relations et les métadonnées sur les données brutes dans Microsoft Fabric. Ils rendent les données interprétables et réutilisables dans toute la plateforme pour les expériences d’analytique.

Les modèles sémantiques dans Fabric sont étroitement intégrés au modèle de capacité de la plateforme et à la structure de l’espace de travail. Les modèles sémantiques prennent en charge trois modes de requête : Importation, DirectQuery et Direct Lake. Chaque mode offre différents compromis entre les performances, l’actualisation et l’extensibilité :

  • Le mode d’importation copie les données de la source dans le modèle sémantique pendant les actualisations planifiées ou manuelles. Ce mode offre les performances de requête les plus rapides, car Power BI fonctionne sur des données en mémoire, mais il introduit une latence entre les mises à jour sources et la visibilité des rapports. Le mode d’importation est idéal pour les tableaux de bord hautes performances où les données en temps réel ne sont pas critiques.

  • Le mode DirectQuery envoie des requêtes directement au système source au moment de l’exécution sans stocker de données dans le modèle sémantique. Cette approche garantit des résultats à jour, mais elle peut entraîner des performances plus lentes selon la réactivité du système source. DirectQuery convient aux scénarios où la fraîcheur des données est plus importante que la vitesse, comme la création de rapports opérationnels.

  • Le mode Direct Lake permet à Power BI d’interroger directement les tables Delta stockées dans OneLake. Il combine les caractéristiques de performance de l’importation avec l’actualisation de DirectQuery. Il évite la duplication des données et utilise l’architecture native du lac pour l’analytique évolutive et en temps quasi réel. Direct Lake est recommandé pour l’analytique à grande échelle sur les données gérées par Fabric.

Les modèles sémantiques permettent également l’IA conversationnelle, la recherche sémantique, les rapports d’entreprise et le raisonnement inter-domaines en regroupant des fonctionnalités avancées telles que Fabric Data Agents, Power BI Copilot, Ontologies et rapports Power BI. Les utilisateurs professionnels peuvent également accéder aux modèles sémantiques via Excel, où ils peuvent explorer des données et des insights dans une interface de tableau croisé dynamique qui utilise des données actives à partir du modèle sémantique.

Guide de décision : Choisir le magasin de données approprié

Microsoft Fabric fournit plusieurs options de magasin de données, chacune optimisée pour des charges de travail spécifiques :

  • Lakehouse pour l’ingénierie des données à grande échelle et le stockage en format ouvert comme Delta et Iceberg, avec prise en charge des moteurs Spark et SQL.
  • Entrepôt pour l’analyse relationnelle structurée, avec des fonctionnalités SQL à haute performance et du rapportage d’entreprise.
  • Eventhouse pour la télémétrie en temps réel et l'analyse des journaux à l’aide du langage de requête Kusto.
  • Base de données SQL pour les charges de travail transactionnelles et l’analytique opérationnelle.
  • Cosmos DB pour les applications NoSQL distribuées à l’échelle mondiale, les applications multimodèles avec un accès à faible latence.

La sélection du magasin approprié dépend de la structure des données, des exigences de latence, de la complexité des requêtes et des besoins d’intégration. Pour plus d’informations, consultez Choisir le magasin approprié.

Contenu connexe

  • Last updated on