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, tous disponibles dans un stockage unifié dans OneLake.

Personas et ensembles de compétences

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

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 4

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 avec Fabric Data Factory pour importer des données dans la base de données Fabric SQL.

Étape suivante