Partager via

Guide de décision Microsoft Fabric : choisir un magasin de données

  • Article

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

Entrepôt Lakehouse Datamart Power BI Base de données KQL (Eventhouse)
Volume de données Illimité Illimité Jusqu’à 100 Go Illimité
Type de données Données structurées Non structuré, semi-structuré, structuré Données structurées Non structuré, semi-structuré, structuré
Personnage de développeur principal Développeur d'entrepôt de données, ingénieur SQL Ingénieur de données, data scientist Développeur citoyen Citoyen Scientifique des données, Ingénieur Données, Scientifique des données, Ingénieur SQL
Ensemble de compétences de développeur principal SQL Spark(Scala, PySpark, Spark SQL, R) Pas de code, SQL Aucun code, KQL, SQL
Données organisées par Bases de données, schémas et tables Dossiers et fichiers, bases de données et tables Base de données, tables, requêtes Bases de données, schémas et tables
Lire les opérations T-SQL, Spark (prend en charge la lecture à partir de tables à l’aide de raccourcis, ne prend pas encore en charge l’accès aux vues, les procédures stockées, les fonctions, etc.) Spark,T-SQL Spark,T-SQL,Power BI KQL, T-SQL, Spark, Power BI
Opérations d’écriture T-SQL Spark(Scala, PySpark, Spark SQL, R) Dataflows, T-SQL KQL, Spark, écosystème de connecteurs
Transactions à plusieurs tables Oui No Non Oui, pour l’ingestion de plusieurs tables. Consultez Mise à jour de la stratégie.
Interface de développement principale Scripts SQL Notebooks Spark, définitions de travaux Spark Power BI Jeu de requêtes KQL, base de données KQL
Sécurité Niveau objet (table, vue, fonction, procédure stockée, etc.), niveau colonne, niveau ligne, DDL/DML, masquage des données dynamique Niveau ligne, niveau table (lors de l'utilisation de T-SQL), aucun pour Spark Éditeur RLS intégré Sécurité de niveau ligne
Accéder aux données via des raccourcis Oui, par le biais d’un lakehouse à l’aide de noms en trois parties Oui No Oui
Peut être une source pour les raccourcis Oui (tables) Oui (fichiers et tables) Non Oui
Interroger des éléments Oui, interroger des tables lakehouse et entrepôt de données Oui, interroger sur les tables lakehouse et d’entrepôt de données ; interroger sur les lakehouses (y compris les raccourcis à l’aide de Spark) Non Oui, interrogez les bases de données, les lakehouses et les entrepôts KQL avec des raccourcis
Analytique avancée Éléments natifs de série chronologique, fonctionnalités de stockage géospatial complet et de requête
Prise en charge avancée de la mise en forme Indexation complète pour le texte libre et les données semi-structurées comme JSON
Latence d’ingestion Ingestion mise en file d’attente, Ingestion de streaming a une latence de quelques secondes

Remarque

Eventhouse est un espace de travail pour plusieurs bases de données KQL. La base de données KQL est en disponibilité générale, tandis qu’Eventhouse est en préversion. Pour plus d’informations, consultez Présentation d’Eventhouse (préversion).

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, 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. À 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 équipe plus importante, 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 une base de données KQL en raison de sa scalabilité, de ses temps de réponse rapides, 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.

Contenu connexe