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 de l'entrepôt de données
Utilisez ces informations pour comparer les magasins de données Fabric tels que l’entrepôt, lakehouse, Eventhouse, sql database et Power BI datamart, en fonction du volume de données, du type, de la personne du 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 :
| Tableau 1 sur 2 | Lakehouse | Entrepôt | Eventhouse |
|---|---|---|---|
| Volume de données | Illimité | Illimité | Illimité |
| type de données | Non structuré données semi-structurées, données structurées |
Données structurées, données semi-structurées (JSON) |
Non structuré données semi-structurées, données structurées |
| Personnage de développeur principal | Ingénieur données, scientifique des données | Développeur de l’entrepôt de données, architecte de données, ingénieur données, développeur de base de données | Développeur d’applications, scientifique des données, ingénieur données |
| compétence de développement principale | 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 |
| Opérations de lecture | 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 principal | Notebooks Spark, définitions de travaux Spark | Scripts SQL | Ensemble de requêtes KQL, base de données KQL |
| Sécurité | SNL, CLS**, niveau de table (T-SQL), aucun pour Spark | au niveau de l’objet, RLS, CLS, DDL/DML, masquage dynamique des données | SNL |
| Accéder aux données via des raccourcis | Oui | Oui, via le point de terminaison d’analytique SQL | Oui |
| peut être une source pour les raccourcis | Oui (fichiers et tables) | Oui (tables) | Oui |
| Interroger des éléments | Oui | Oui | Oui |
| Analyse avancée | Interface pour le traitement des données à grande échelle, le parallélisme intégré des données et la tolérance de panne | Interface pour le traitement des données à grande échelle, le parallélisme intégré des données et la tolérance de panne | Éléments natifs Time Series, capacités géospatiales et de requête complètes |
| Prise en charge avancée de la mise en forme | Tables définies à l’aide de PARQUET, CSV, AVRO, JSON et n’importe quel format de fichier compatible Apache Hive | Tables définies à l’aide de PARQUET, CSV, AVRO, JSON et n’importe quel format de fichier compatible Apache Hive | Indexation complète pour le texte libre et les données semi-structurées comme JSON |
| latence d’ingestion | Disponible instantanément pour les requêtes | Disponible instantanément pour la requête | L’ingestion en file d’attente et l’ingestion de streaming ont 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, procédures stockées, fonctions, etc.
| Table 2 sur 2 | base de données SQL Fabric | Power BI Datamart |
|---|---|---|
| Volume de données | 4 To | Jusqu’à 100 Go |
| type de données | Données structurées, données semi-structurées, Non structuré |
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 de données |
| compétence de développement principale | SQL | Aucun code, SQL |
| Données organisées par | Bases de données, schémas, tables | Base de données, tables, requêtes |
| Opérations de lecture | 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 principal | Scripts SQL | Power BI |
| Sécurité | Niveau d’objet, RLS, CLS, DDL/DML, masquage dynamique des données | É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 |
| Analyses avancées | 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é des performances |
| Prise en charge avancée de la mise en forme | Prise en charge des tables pour OLTP, JSON, vecteur, graph, XML, spatial, clé-valeur | Tables définies à l’aide de PARQUET, CSV, AVRO, JSON et n’importe quel format de fichier compatible Apache Hive |
| latence d’ingestion | Disponible instantanément pour la consultation | Disponible instantanément pour consultation |
** 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
Passez en revue ces scénarios pour obtenir de l’aide sur le choix d’un magasin de données dans Fabric.
Scénario 1
Susan, développeur professionnel, est une nouveauté de Microsoft Fabric. Ils sont prêts à commencer à nettoyer, modéliser et analyser des données, mais doivent décider de créer un entrepôt de données ou un lakehouse. Après avoir examiné les détails du tableau précédent, les points de décision principaux sont l’ensemble de compétences disponible 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 relationnelles et est familiarisé avec la syntaxe et les fonctionnalités SQL. En pensant à la grande équipe, les principaux consommateurs de ces données sont également qualifiés en SQL et en outils d'analyse 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 entrepôt de données et interagit avec lui à l’aide de T-SQL comme ses autres bases de données SQL Server. La plupart du code T-SQL existant qu’elle a écrit pour créer son entrepôt sur SQL Server fonctionnera sur l’entrepôt de données Fabric pour faciliter la transition. Si elle choisit, elle peut même utiliser les mêmes outils qui fonctionnent avec ses autres bases de données, comme SQL Server Management Studio. À l’aide de l’éditeur SQL dans le portail Fabric, Susan et d’autres membres de l’équipe écrivent des requêtes analytiques qui référencent d’autres entrepôts de données et tables Delta dans lakehouses simplement en utilisant des noms en trois parties pour effectuer des requêtes inter-bases de données.
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 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 dans les notebooks et, étant donné que les données sont stockées dans Delta, elles sont en mesure d’interagir avec une syntaxe SQL similaire.
Rob décide d’utiliser un lakehouse, ce qui permet à l’équipe d’ingénierie des données de mettre à profit ses compétences variées sur les données, tout en offrant aux membres de l’équipe hautement qualifiés en T-SQL la possibilité d’exploiter les données.
Scénario 3
Ash, un développeur citoyen, est un 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 voient que les principaux points de décision sont leurs propres compétences et leur besoin d’un libre-service, aucune fonctionnalité de code et le volume de données de moins de 100 Go.
Ash travaille avec des analystes d’entreprise familiarisés avec Power BI et Microsoft Office, et sait qu’ils disposent déjà d’un abonnement de capacité Premium. Comme ils pensent à leur équipe plus grande, ils réalisent que les principaux consommateurs de ces données sont des analystes, familiarisés avec les outils analytiques sans code et SQL. Ash décide d’utiliser un datamart Power BI, ce qui permet à l’équipe de développer rapidement la fonctionnalité grâce à une expérience sans code. Les requêtes peuvent être exécutées via Power BI et T-SQL, tout en permettant également à tous les utilisateurs Spark de l’organisation d’accéder aux données.
Scénario 4
Daisy est analyste métier expérimenté avec l’utilisation de Power BI pour analyser les goulots d’étranglement de la chaîne d’approvisionnement 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 qui peuvent être utilisées 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 rapide, de fonctionnalités d’analytique avancées, notamment l’analyse de série chronologique, les fonctions géospatiales et le mode de requête direct 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 une analyse géospatinelle 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 des performances pour simplifier la gestion quotidienne des bases de données.
Kirby décide d’une base de données SQL dans Fabric, avec le même moteur de base de données SQL qu’Azure SQL Database. 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 supprime automatiquement des index non cluster en fonction 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 soulagent la base de données opérationnelle principale de la surcharge des charges de travail analytiques et évitent 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 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.