Guide de décision Microsoft Fabric : choisir un magasin de données
Utilisez ce guide de référence et les exemples de scénarios pour vous aider à choisir un magasin de données pour vos charges de travail Microsoft Fabric.
Propriétés du magasin de données
Utilisez ces informations pour comparer les magasins de données Fabric tels que l’entrepôt de données, lakehouse, Eventhouse, SQL Database et Power BI Datamart, en fonction du volume de données, du type, du personnage développeur, de l’ensemble de compétences, des opérations et d’autres fonctionnalités. Ces comparaisons sont organisées dans les deux tableaux suivants :
| Lakehouse | Entrepôt | Eventhouse | |
|---|---|---|---|
| Volume de données | Illimité | Illimité | Illimité |
| Type de données | données non structurées, données semi-structurées, Données structurées |
Données structurées | données non structurées, données semi-structurées, Données structurées |
| Personnage de développeur principal | Ingénieur de données, data scientist | développeur de l’entrepôt de données, architecte de données, développeur de base de données | Développeur d’applications, scientifique des données, ingénieur données |
| Compétence principale de développement | Spark (Scala, PySpark, Spark SQL, R) | SQL | Aucun code, KQL, SQL |
| Données organisées par | Dossiers et fichiers, bases de données et tables | Bases de données, schémas et tables | Bases de données, schémas et tables |
| Lire les opérations | Spark,T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| Opérations d’écriture | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, écosystème de connecteurs |
| Transactions à plusieurs tables | Non | Oui | Oui, pour l’ingestion multi-tables |
| Interface de développement principale | Notebooks Spark, définitions de travaux Spark | Scripts SQL | Jeu de requêtes KQL, base de données KQL |
| Sécurité | SNL, CLS**, niveau de table (T-SQL), aucun pour Spark | Niveau d’objet, SNL, CLS, DDL/DML, Dynamic Data Masking | RLS |
| Accéder aux données via des raccourcis | Oui | Oui | Oui |
| Peut être une source pour les raccourcis | Oui (fichiers et tables) | Oui (tables) | Oui |
| Interroger des éléments | Oui | Oui | Oui |
| Analytique avancée | Interface pour le traitement des données à grande échelle, parallélisme intégré des données et tolérance de panne | Interface pour le traitement des données à grande échelle, parallélisme intégré des données et tolérance de panne | Éléments natifs de série chronologique, fonctionnalités complètes des données géospatiales et des requêtes |
| Prise en charge avancée de la mise en forme | Les tables définies à l’aide de PARQUET, CSV, AVRO, JSON et tout format de fichier compatible avec Apache Hive | Les tables définies à l’aide de PARQUET, CSV, AVRO, JSON et tout format de fichier compatible avec Apache Hive | Indexation complète pour le texte libre et les données semi-structurées comme JSON |
| Latence d’ingestion | Disponibles instantanément pour l’interrogation | Disponibles instantanément pour l’interrogation | L’ingestion des données mises en file d’attente, ou diffusées en continu a une latence de quelques secondes |
* Spark prend en charge la lecture à partir de tables à l’aide de raccourcis, ne prend pas encore en charge l’accès aux vues, aux procédures stockées, aux fonctions, etc.
| Base de données SQL Fabric | Datamart Power BI | |
|---|---|---|
| Volume de données | 4 To | Jusqu’à 100 Go |
| Type de données | Données structurées, données semi-structurées, non structurée |
Données structurées |
| Personnage de développeur principal | développeur IA, développeur d’applications, développeur de base de données, administrateur de base de données | Scientifique des données, analyste Données |
| Compétence principale de développement | SQL | Pas de code, SQL |
| Données organisées par | Bases de données, schémas, tables | Base de données, tables, requêtes |
| Lire les opérations | T-SQL | Spark,T-SQL |
| Opérations d’écriture | T-SQL | Dataflows, T-SQL |
| Transactions à plusieurs tables | Oui, conformité ACID complète | Non |
| Interface de développement principale | Scripts SQL | Power BI |
| Sécurité | Niveau d’objet, SNL, CLS, DDL/DML, Dynamic Data Masking | Éditeur RLS intégré |
| Accéder aux données via des raccourcis | Oui | Non |
| Peut être une source pour les raccourcis | Oui (tables) | Non |
| Interroger des éléments | Oui | Non |
| Analytique avancée | Fonctionnalités analytiques T-SQL, données répliquées vers Delta Parquet dans OneLake pour l’analytique | Interface pour le traitement des données avec réglage automatisé du niveau de performance |
| Prise en charge avancée de la mise en forme | Prise en charge des tables pour OLTP, JSON, vecteur, graph, XML, spatial, clé-valeur | Les tables définies à l’aide de PARQUET, CSV, AVRO, JSON et tout format de fichier compatible avec Apache Hive |
| Latence d’ingestion | Disponibles instantanément pour l’interrogation | Disponibles instantanément pour l’interrogation |
** Sécurité au niveau des colonnes disponible sur la plateforme lakehouse via un point de terminaison d’analytique SQL, à l’aide de T-SQL.
Scénarios
Consultez ces scénarios pour obtenir de l’aide sur le choix d’un magasin de données dans Fabric.
Scénario 1
Susan, une développeur professionnelle, débute avec Microsoft Fabric. Ils sont prêts à commencer le nettoyage, la modélisation et l’analyse des données, mais doivent décider de créer un entrepôt de données ou un lakehouse. Après examen des détails du tableau précédent, les principaux points de décision sont l’ensemble de compétences disponibles et la nécessité de transactions à plusieurs tables.
Susan a passé de nombreuses années à créer des entrepôts de données sur des moteurs de base de données relationnelle, et elle est familiarisée avec la syntaxe et les fonctionnalités SQL. En pensant à l’équipe plus grande, les principaux consommateurs de ces données sont également qualifiés avec les outils analytiques SQL et SQL. Susan décide d’utiliser un entrepôt de données Fabric, qui permet à l’équipe d’interagir principalement avec T-SQL, tout en permettant à tous les utilisateurs Spark de l’organisation d’accéder aux données.
Susan crée un lakehouse et accède aux fonctionnalités de l’entrepôt de données avec le point de terminaison d’analytique SQL lakehouse. À l’aide du portail Fabric, crée des raccourcis vers les tables de données externes et les place dans le /Tablesdossier. Susan peut désormais écrire des requêtes T-SQL qui référencent des raccourcis pour interroger les données Delta Lake dans le lakehouse. Les raccourcis apparaissent automatiquement sous forme de tables dans le point de terminaison analytique SQL et peuvent être interrogés avec T-SQL à l’aide de noms en trois parties.
Scénario 2
Rob, ingénieur données, doit stocker et modéliser plusieurs téraoctets de données dans Fabric. L’équipe a un mélange de compétences PySpark et T-SQL. La plupart des membres de l’équipe exécutant des requêtes T-SQL sont des consommateurs et n’ont donc pas besoin d’écrire des instructions INSERT, UPDATE ou DELETE. Les développeurs restants sont à l’aise de travailler dans des notebooks et, étant donné que les données sont stockées dans Delta, ils peuvent interagir avec une syntaxe SQL similaire.
Rob décide d’utiliser un lakehouse, qui permet à l’équipe d’ingénierie des données d’utiliser ses diverses compétences sur les données, tout en permettant aux membres de l’équipe qui sont hautement qualifiés en T-SQL de consommer les données.
Scénario 3
Ash, développeur citoyen, est développeur Power BI. Ils connaissent Excel, Power BI et Office. Ils doivent créer un produit de données pour une unité commerciale. Ils savent qu’ils n’ont pas tout à fait les compétences nécessaires pour créer un entrepôt de données ou un lakehouse, et ceux-ci semblent être trop pour leurs besoins et leurs volumes de données. Ils passent en revue les détails du tableau précédent et constatent que les principaux points de décision sont leurs propres compétences et leur besoin d’un libre-service, d’aucune fonctionnalité de code et d’un volume de données inférieur à 100 Go.
Ash travaille avec des analystes métier familiarisés avec Power BI et Microsoft Office, et sait qu’ils disposent déjà d’un abonnement à capacité Premium. Quand ils pensent à leur plus grande équipe, ils se rendent compte que les principaux consommateurs de ces données peuvent être des analystes, familiarisés avec les outils analytiques sans code et SQL. Ash décide d’utiliser un datamart Power BI, qui permet à l’équipe d’interagir rapidement avec la création de la fonctionnalité, à l’aide d’une expérience sans code. Les requêtes peuvent être exécutées via Power BI et T-SQL, tout en permettant à tous les utilisateurs Spark de l’organisation d’accéder aux données.
Scénario 4
Daisy est une analyste commerciale expérimentée dans l’utilisation de Power BI pour analyser les goulots d’étranglement de la chaîne logistique pour une grande chaîne de vente au détail mondiale. Ils doivent créer une solution de données évolutive qui peut gérer des milliards de lignes de données et peut être utilisée pour créer des tableaux de bord et des rapports qui peuvent être utilisés pour prendre des décisions métier. Les données proviennent d’usines, de fournisseurs, d’expéditeurs et d’autres sources dans différents formats structurés, semi-structurés et non structurés.
Daisy décide d’utiliser un Eventhouse en raison de sa scalabilité, de ses temps de réponse rapides et de ses fonctionnalités d’analyse avancées, notamment l’analyse de séries chronologiques, les fonctions géospatiales et un mode de requête directe rapide dans Power BI. Les requêtes peuvent être exécutées à l’aide de Power BI et de KQL pour comparer les périodes actuelles et précédentes, identifier rapidement les problèmes émergents ou fournir des analyses géospatiaux des routes terrestres et maritimes.
Scénario 5
Kirby est un architecte d’applications expérimenté dans le développement d’applications .NET pour les données opérationnelles. Ils ont besoin d’une base de données à accès concurrentiel élevé avec une conformité complète des transactions ACID et des clés étrangères fortement appliquées pour l’intégrité relationnelle. Kirby souhaite bénéficier du réglage automatique du niveau de performance pour simplifier la gestion quotidienne des bases de données.
Kirby choisit une base de données SQL dans Fabric, avec le même moteur SQL en tant que base de données Azure SQL. Les bases de données SQL dans Fabric sont automatiquement mises à l’échelle pour répondre à la demande tout au long de la journée. Ils disposent de la capacité complète des tables transactionnelles et de la flexibilité des niveaux d’isolation des transactions à partir d’un format sérialisable pour lire une capture instantanée validée. La base de données SQL dans Fabric crée et dépose automatiquement des index non groupés en cluster suivant des signaux forts des plans d’exécution observés au fil du temps.
Dans le scénario de Kirby, les données de l’application opérationnelle doivent être jointes à d’autres données dans Fabric : dans Spark, dans un entrepôt et à partir d’événements en temps réel dans un Eventhouse. Chaque base de données Fabric inclut un point de terminaison d’analytique SQL, afin que les données soient accessibles en temps réel à partir de Spark ou avec des requêtes Power BI à l’aide du mode DirectLake. Ces solutions de création de rapports évitent la surcharge des charges de travail analytiques dans les bases de données primaires et empêchent la dénormalisation. Kirby dispose également de données opérationnelles existantes dans d’autres bases de données SQL et doit importer ces données sans transformation. Pour importer des données opérationnelles existantes sans aucune conversion de type de données, Kirby conçoit des pipelines de données avec Fabric Data Factory pour importer des données dans la base de données Fabric SQL.