Instructions sur les performances de l’entrepôt de données Fabric
S’applique à :✅ Entrepôt dans Microsoft Fabric
Il s’agit de conseils pour vous aider à comprendre les performances de votre entrepôt dans Microsoft Fabric. Dans cet article, vous trouverez des conseils et des articles importants sur lesquels vous pouvez vous concentrer. L’entrepôt dans Microsoft Fabric est une plateforme SaaS où les activités telles que la gestion des charges de travail, la concurrence et la gestion du stockage sont gérées en interne par la plateforme. En plus de cette gestion des performances interne, vous pouvez toujours améliorer vos performances en développant des requêtes performantes sur des entrepôts bien conçus.
Performances d’exécution à froid (cache froid)
La mise en cache avec le disque SSD local et la mémoire est automatique. Les 1 à 3 premières exécutions d’une requête sont nettement plus lentes que les exécutions suivantes. Si vous rencontrez des problèmes de performances d’exécution à froid, voici quelques suggestions pour les améliorer :
Si les performances de la première exécution sont déterminantes, essayez de créer manuellement des statistiques. Consultez l’article sur les statistiques pour mieux comprendre le rôle des statistiques et obtenir des conseils sur la façon de créer des statistiques manuelles pour améliorer les performances de vos requêtes. Toutefois, si les performances de la première exécution ne sont pas critiques, vous pouvez vous appuyer sur des statistiques automatiques qui seront générées lors de la première requête et qui continueront à être exploitées dans les exécutions suivantes (tant que les données sous-jacentes ne changent pas de manière significative).
Si vous utilisez Power BI, utilisez le mode Direct Lake si possible.
Métriques pour l’analyse des performances
Actuellement, le hub de supervision n’inclut pas Warehouse. Si vous choisissez Data Warehouse, vous ne pourrez pas accéder au hub de supervision à partir de la barre de navigation.
Les administrateurs d’infrastructure pourront accéder au rapport Utilisation de la capacité et métriques pour obtenir des informations à jour sur l’utilisation de la capacité, y compris Entrepôt.
Utiliser des vues de gestion dynamique (DMV) pour surveiller l’exécution des requêtes
Vous pouvez utiliser des vues de gestion dynamiques (DMV) pour surveiller l'état des connexions, des sessions et des requêtes dans l'entrepôt.
Statistiques
L’entrepôt utilise un moteur de requête pour créer un plan d’exécution pour une requête SQL donnée. Lorsque vous envoyez une requête, l’optimiseur de requête tente d’énumérer tous les plans possibles et de choisir le candidat le plus efficace. Pour déterminer le plan qui nécessiterait le moins de surcharge, le moteur doit être en mesure d’évaluer la quantité de travail ou de lignes qui peut être traitée par chaque opérateur. Ensuite, en fonction du coût de chaque plan, il choisit celui qui a le moins de travail estimé. Les statistiques sont des objets qui contiennent des informations pertinentes sur vos données, afin de permettre à l’optimiseur de requête d’estimer ces coûts.
Vous pouvez également mettre à jour manuellement les statistiques après chaque chargement ou mise à jour des données pour vous assurer que le meilleur plan de requête peut être créé.
Pour plus d’informations sur les statistiques et la façon d’augmenter les statistiques créées automatiquement, consultez Statistiques dans l’entrepôt de données Fabric.
Instructions relatives à l’ingestion de données
Il existe quatre options pour l’ingestion de données dans un entrepôt :
- COPIE (Transact-SQL)
- Pipelines de données
- Flux de données
- Ingestion entre entrepôts
Pour vous aider à déterminer l’option qui vous convient le mieux et pour passer en revue certaines meilleures pratiques d’ingestion de données, consultez Ingestion de données.
Regrouper les instructions INSERT dans des lots (éviter les insertions de ruissellement)
Le chargement unique d’une petite table avec une instruction INSERT, comme dans l’exemple ci-dessous, peut constituer la meilleure approche en fonction de vos besoins. Toutefois, si vous avez besoin de charger des milliers ou millions de lignes au cours d’une journée, l’utilisation d’instructions INSERTS de singleton n’est peut-être pas optimale.
INSERT INTO MyLookup VALUES (1, 'Type 1')
Pour obtenir des conseils sur la façon de gérer ces scénarios de chargement progressif, consultez les Meilleures pratiques pour l’ingestion de données.
Minimiser la taille des transactions
Les instructions INSERT, UPDATE et DELETE s’exécutent dans une transaction. En cas d’échec, elles doivent être restaurées. Pour minimiser le risque d’une restauration longue, réduisez autant que possible les tailles de transactions. Vous pouvez réduire la taille des transactions en fractionnant les instructions INSERT, UPDATE et DELETE. Par exemple, si vous avez une instruction INSERT dont l’exécution devrait prendre une heure, vous pouvez la fractionner en quatre parties. Chaque exécution sera ensuite raccourcie à 15 minutes.
Envisagez d'utiliser CTAS (Transact-SQL) pour écrire les données que vous souhaitez conserver dans une table plutôt que d'utiliser DELETE. Si une instruction CTAS prend le même temps, son exécution est plus sûre, car elle effectue une journalisation des transactions minimale et peut être annulée rapidement si nécessaire.
Colocaliser les applications clientes et Microsoft Fabric
Si vous utilisez des applications client, assurez-vous que vous utilisez Microsoft Fabric dans une région proche de votre ordinateur client. Les exemples d’applications clientes incluent Power BI Desktop, SQL Server Management Studio et Azure Data Studio.
Utiliser la conception de données de schéma en étoile
Un schéma en étoile organise les données dans des tables de faits et les tables de dimension. Il facilite le traitement analytique en dénormalisant les données des systèmes OLTP hautement normalisés, en ingérant des données transactionnelles et en master données d’entreprise dans une structure de données commune, nettoyée et vérifiée qui réduit les jointures au moment de la requête, réduit le nombre de lignes lues et facilite les agrégations et le traitement de regroupement.
Pour plus d’informations sur la conception de l’entrepôt, consultez Tables dans l’entrepôt de données.
Réduire les tailles de jeu de résultats de requête
La réduction de la taille du jeu de résultats de requête vous aide à éviter des problèmes côté client occasionnés par des résultats de requête volumineux. Les jeux de résultats de l’éditeur de requêtes SQL sont limités aux 10 000 premières lignes pour éviter ces problèmes dans cette interface utilisateur basée sur le navigateur. Si vous devez retourner plus de 10 000 lignes, utilisez SQL Server Management Studio (SSMS) ou Azure Data Studio.
Choisissez le meilleur type de données pour améliorer le niveau de performance
Lorsque vous définissez vos tables, utilisez le type de données le plus petit possible pour vos données afin d'améliorer les performances des requêtes. Cette recommandation est importante pour les colonnes CHAR et VARCHAR. Si la valeur la plus longue dans une colonne est de 25 caractères, définissez la colonne en tant que VARCHAR(25). Évitez de définir toutes les colonnes de caractères ayant une grande longueur par défaut.
Utilisez des types de données de type Integer si possible. Les opérations de tri (SORT), de jointure (JOIN) et de regroupement (GROUP BY) sont effectuées plus rapidement sur des entiers que sur des données caractères.
Pour plus d’informations sur les types de données pris en charge, consultez Types de données.
Performances du point de terminaison d’analytique SQL
Pour obtenir des informations et des recommandations sur les performances du point de terminaison SQL analytics, voir Considérations sur les performances du point de terminaison SQL analytics.
Compactage des données
La compression des données consolide les fichiers Parquet plus petits en fichiers moins volumineux, ce qui optimise les opérations de lecture. Ce processus permet également de gérer efficacement les lignes supprimées en les éliminant des fichiers Parquet immuables. Le processus de compression des données implique la réécriture de tables ou de segments de tables dans de nouveaux fichiers Parquet optimisés pour les performances. Pour plus d’informations, consultez Blog : compression automatique des données pour l’entrepôt Fabric.
Le processus de compression des données est intégré en toute transparence à l’entrepôt. À mesure que les requêtes sont exécutées, le système identifie les tables qui pourraient tirer parti de la compression et effectuer des évaluations nécessaires. Il n’existe aucun moyen manuel de déclencher la compression des données.