Partager via

Évaluer et optimiser votre capacité Microsoft Fabric

  • Article

Cet article explique comment évaluer et optimiser la charge sur vos capacités Microsoft Fabric. Il décrit également des stratégies pour résoudre les situations de surcharge et vous fournit des conseils pour optimiser le calcul pour chacune des expériences Fabric.

Bien que le modèle de capacité Fabric simplifie l’installation et active la collaboration, il existe un risque élevé d’épuiser les ressources de calcul partagées d’une capacité. Il peut également s’agir du cas où vous payez plus de ressources que nécessaire. Ces situations peuvent survenir lorsque la conception de certaines expériences Fabric ne suit pas les meilleures pratiques.

Il est important de réduire le risque d’épuisement des ressources partagées, Fabric, en tant que service géré, qui traite automatiquement ces situations de deux façons.

  • Le bursting et le lissage garantissent que les activités gourmandes en UC sont effectuées rapidement sans nécessiter de référence SKU plus élevée (et peuvent être exécutées à tout moment de la journée).
  • La limitation retarde ou rejette les opérations lorsqu’une capacité subit une demande soutenue et élevée pour l’UC (au-dessus de la limite de référence SKU).

Le lissage réduit la probabilité de limitation (bien que la limitation puisse toujours se produire). Lissage est la façon dont l’utilisation est allouée par rapport aux limites, mais elle est indépendante de l’exécution des travaux. Lissage ne change pas les performances, il répartit simplement la comptabilité du calcul consommé sur une période plus longue, de sorte qu’une référence SKU plus grande n’est pas nécessaire pour gérer le calcul de pointe.

Pour en savoir plus sur la capacité fabric, consultez les concepts et licences de Microsoft Fabric et les capacités fabric : tout ce que vous devez savoir sur les nouveautés.

Outils de planification et budgétisation

La planification de la taille d’une capacité peut être un défi. Cela est dû au fait que le calcul requis peut varier considérablement en raison des opérations effectuées, de la façon dont elles sont exécutées (par exemple, l’efficacité d’une requête DAX ou du code Python dans un notebook) ou le niveau de concurrence.

Pour vous aider à déterminer la taille de capacité appropriée, vous pouvez provisionner des capacités d’évaluation ou des références SKU de paiement à l’utilisation pour mesurer la taille de capacité réelle requise avant d’acheter une instance réservée de référence SKU F.

Conseil

C’est toujours une bonne stratégie pour commencer petit, puis augmenter progressivement la taille de votre capacité si nécessaire.

Surveiller les capacités

Vous devez surveiller l’utilisation pour tirer le meilleur parti de vos capacités. Avant tout, il est important de comprendre que les opérations Fabric sont interactives ou en arrière-plan. Par exemple, les requêtes DAX à partir d’un rapport Power BI sont des requêtes à la demande qui sont des opérations interactives, tandis que les actualisations de modèle sémantique sont des opérations en arrière-plan. Pour plus d’informations sur les opérations et la façon dont elles consomment des ressources dans Fabric, consultez les opérations Fabric.

La surveillance peut vous révéler que la limitation est en cours. La limitation peut se produire lorsqu’il existe de nombreuses opérations interactives longues ou longues. En règle générale, les opérations en arrière-plan liées aux expériences SQL et Spark sont lissées, ce qui signifie qu’elles sont réparties sur une période de 24 heures.

L’application des métriques de capacité de Fabric est la meilleure façon de surveiller et de visualiser l’utilisation récente. L’application se décompose en type d’élément (modèle sémantique, notebook, pipeline et autres) et vous aide à identifier les éléments ou opérations qui utilisent des niveaux élevés de calcul (afin qu’ils puissent être optimisés).

Les administrateurs peuvent utiliser l’espace de travail de surveillance Administration pour en savoir plus sur les éléments fréquemment utilisés (et l’adoption globale). Ils peuvent également utiliser le hub de supervision pour afficher les activités actuelles et récentes dans le locataire. Des informations supplémentaires sur certaines opérations peuvent également être disponibles à partir d’Analytique des journaux d'activité ou des journaux de passerelle de données locale.

Gérer une utilisation élevée du calcul

Lorsqu’une capacité est fortement utilisée et commence à afficher la limitation ou le rejet, il existe trois stratégies pour la résoudre : optimiser, monter en puissance et effectuer un scale-out.

Il est recommandé de configurer des notifications pour apprendre quand l’utilisation de la capacité dépasse un seuil défini. Envisagez également d’utiliser des paramètres spécifiques à la charge de travail pour limiter la taille des opérations (par exemple, le délai d’expiration de la requête Power BI ou les limites de ligne ou les paramètres de l’espace de travail Spark).

Optimize

Les créateurs de contenu doivent toujours optimiser la conception de leurs éléments Fabric pour s’assurer qu’il est efficace et utilise les ressources de calcul les moins possibles. Des conseils spécifiques pour chaque expérience Fabric sont fournis plus loin dans cet article.

Monter en puissance

Vous effectuez un scale-up d’une capacité pour augmenter temporairement ou définitivement la taille de la référence SKU (avec plus de capacité de calcul). Le scale-up garantit qu’il existe suffisamment de ressources de calcul disponibles pour tous les éléments d’une capacité et éviter la limitation.

Vous pouvez également redimensionner, suspendre et reprendre des références SKU Fabric F pour s’aligner sur les modèles de consommation.

Scale-out

Vous effectuez un scale-out en déplaçant certains de vos espaces de travail ou éléments vers une capacité fabric différente pour répartir la charge de travail. Il peut s’agir d’une bonne option lorsque différentes stratégies de capacité, paramètres ou administrateurs sont nécessaires. L’approvisionnement de plusieurs capacités est également une bonne stratégie pour isoler le calcul pour les éléments à priorité élevée, ainsi que pour le contenu libre-service ou de développement. Par exemple, les cadres de votre organisation attendent des rapports et des tableaux de bord très réactifs. Ces rapports et tableaux de bord peuvent résider dans une capacité distincte dédiée aux rapports exécutifs.

Vous pouvez également envisager de déplacer des espaces de travail Power BI vers une capacité partagée, à condition que les consommateurs disposent de licences Power BI Pro qui leur permettent de continuer à accéder au contenu.

Optimisation du calcul par expérience Fabric

Les expériences et les éléments de Fabric fonctionnent différemment, de sorte que vous ne les optimisez pas nécessairement de la même façon. Cette section répertorie les éléments Fabric en fonction de l’expérience et des actions que vous pouvez effectuer pour les optimiser.

Entrepôt de données Fabric

Data Warehouse utilise une architecture serverless et ses nœuds sont automatiquement gérés par le service. L’utilisation de la capacité est calculée en fonction des secondes d’unité de capacité active par requête plutôt que du temps pendant lequel les nœuds front-end et back-end sont provisionnés.

Toutes les opérations de Data Warehouse sont des opérations en arrière-plan, et elles sont lissées sur une période de 24 heures.

Le point de terminaison d’analytique SQL vise à fournir des performances par défaut. À cette fin, il existe moins d’options de réglage des requêtes disponibles par rapport aux pools SQL Server ou Azure Synapse Analytics dédiés à SQL.

Voici quelques points à prendre en compte pour réduire le calcul.

  • Écrivez des requêtes à l’aide du T-SQL le plus optimal possible. Dans la mesure du possible, limitez le nombre de colonnes, de calculs, d’agrégations et d’autres opérations susceptibles d’augmenter inutilement l’utilisation des ressources de requête.
  • Concevoir des tables pour utiliser les plus petits types de données possibles. Votre choix de type de données peut influencer considérablement les plans de requête générés par le moteur SQL. Par exemple, la réduction d’un champ VARCHAR de la longueur 500 à 25 ou de la modification de DECIMAL(32, 8) en DECIMAL(10, 2) peut entraîner une diminution significative des ressources allouées pour une requête.
  • Utilisez la conception de schéma en étoile pour réduire le nombre de lignes lues et pour réduire les jointures de requête.
  • Vérifiez que les statistiques existent et qu’elles sont à jour. Les statistiques jouent un rôle essentiel dans la génération du plan d’exécution le plus optimal. Ils sont créés automatiquement au moment de l’exécution, mais vous devrez peut-être les mettre à jour manuellement, en particulier une fois les données chargées ou mises à jour. Envisagez de créer des statistiques à l’aide de l’option FULLSCAN plutôt que de s’appuyer sur les statistiques générées automatiquement qui utilisent l’échantillonnage.
  • Utilisez des vues intégrées pour surveiller les requêtes et l’utilisation, en particulier lors de la résolution des problèmes.
    • La vue de gestion dynamique (DMV) sys.dm_exec_requests fournit des informations sur toutes les requêtes en cours d’exécution active, mais elle ne stocke pas d’informations historiques. La boîte à outils Fabric fournit une requête qui utilise cette DMV et rend le résultat de la requête convivial en se joignant à d’autres affichages pour fournir des détails tels que le texte de la requête.
    • Les insights sur les requêtes, qui est une fonctionnalité de l’entrepôt de données Fabric, fournissent une vue holistique de l’activité des requêtes historiques sur le point de terminaison d’analytique SQL. Plus précisément, la vue queryinsights.exec_requests_history fournit des informations sur chaque requête SQL complète. Il présente tous les détails pertinents pour chaque exécution de requête qui peuvent être corrélés avec les ID d’opération trouvés dans l’application de métriques de capacité. Les colonnes les plus importantes pour la surveillance de l’utilisation de la capacité sont les suivantes : distributed_statement_id, commande (texte de requête), start_time et end_time.

Engineering données Fabric et science des données Fabric

Les expériences de Ingénieurs Données et de Science des données utilisent le calcul Spark pour traiter, analyser et stocker des données dans un lac Fabric. Le calcul Spark est configuré et mesuré en termes de vCore. Toutefois, Fabric utilise des unités de gestion cloud comme mesure du calcul consommé par différents éléments, notamment les notebooks Spark, les définitions de travaux Spark et les travaux lakehouse.

Dans Spark, un cu se traduit par deux vCore spark de calcul. Par exemple, lorsqu’un client achète une référence SKU F64, 128 cœurs virtuels Spark sont disponibles pour les expériences Spark.

Toutes les opérations Spark sont des opérations en arrière-plan, et elles sont lisses sur une période de 24 heures.

Pour plus d’informations, consultez Facturation et rapports d’utilisation dans Fabric Spark.

Voici quelques points à prendre en compte pour réduire le calcul.

  • Essayez toujours d’écrire du code Spark efficace. Pour plus d’informations, consultez Optimiser les travaux Apache Spark dans Azure Synapse Analytics et La nécessité d’optimiser l’écriture sur Apache Spark.
  • Réservez les exécuteurs requis pour vos travaux Spark afin de libérer des ressources pour d’autres travaux ou charges de travail Spark. Sinon, vous augmentez la probabilité que les travaux Spark échouent avec un état HTTP 430, ce qui signifie trop de requêtes pour la capacité. Vous pouvez afficher le nombre d’exécuteurs alloués à un notebook dans le hub de surveillance Fabric, où vous pouvez également déterminer le nombre réel d’exécuteurs utilisés par le notebook. Les travaux Spark réservent uniquement les nœuds requis et autorisent les soumissions parallèles dans les limites de la référence SKU.
  • Le pool Spark ne peut être configuré que pour utiliser le nombre maximal de vCore pris en charge par la référence SKU. Toutefois, vous pouvez effectuer un scale-out des charges de travail d’ingénierie des données en acceptant des travaux Spark parallèles dans les limites de la référence SKU. Cette approche est communément appelée facteur de rafale, et elle est activée par défaut pour les charges de travail Spark au niveau de la capacité. Pour plus d’informations, consultez Limitation de la concurrence et mise en file d'attente.
  • Les sessions Spark actives peuvent accumuler l’utilisation de la CU sur une capacité. Pour cette raison, il est important d’arrêter les sessions Spark actives quand elles ne sont pas utilisées. Notez que cette période d’expiration de session par défaut est définie sur 20 minutes. Les utilisateurs peuvent modifier le délai d’expiration de session dans un notebook ou la définition de travail Spark.

Informations en temps réel

La consommation de la CU de base de données KQL est calculée en fonction du nombre de secondes pendant lesquelles la base de données est active et du nombre de vCore utilisés. Par exemple, lorsque votre base de données utilise quatre vCore et est active pendant 10 minutes, vous consommerez 2 400 (4 x 10 x 60) secondes de CU.

Toutes les opérations de base de données KQL sont des opérations interactives.

Un mécanisme de mise à l'échelle automatique est utilisé pour déterminer la taille de votre base de données KQL. Il garantit que les performances les plus optimisées et les meilleures performances sont obtenues en fonction des modèles d’utilisation.

Pour permettre la disponibilité des données à d’autres moteurs Fabric, la base de données KQL se synchronise avec OneLake. En fonction du nombre de lectures et de transactions d’écriture effectuées par votre base de données KQL, les CU sont utilisées à partir de votre capacité. Il utilise les compteurs OneLake Read and Write, qui sont équivalents aux opérations de lecture et d’écriture sur les comptes Azure Data Lake Storage (ADLS) Gen2.

Data Factory

Cette section s’intéresse aux optimisations des flux de données et des pipelines de données dans Data Factory.

Toutes les opérations sont des opérations en arrière-plan, et elles sont lisses sur une période de 24 heures.

Voici quelques points à prendre en compte pour réduire le calcul.

  • Évitez une logique Power Query inefficace pour réduire et optimiser les transformations de données coûteuses, telles que la fusion et le tri.
  • Efforcez-vous d’obtenir Query Folding dans la mesure du possible. Elle peut améliorer les performances de vos dataflows en réduisant la quantité de données à transférer entre la source de données et la destination. Lorsque Query Folding ne se produit pas, Power Query récupère toutes les données de la source de données et effectue des transformations localement, ce qui peut être inefficace et lent.
  • Désactivez la mise en lots lors de l’utilisation de petits volumes de données et/ou effectuez des transformations simples. La préproduction peut être nécessaire dans certains cas, par exemple lorsque vous chargez Data Warehouse.
  • Évitez d’actualiser les données plus fréquemment que la source de données requise. Par exemple, si la source de données n’est mise à jour qu’une fois toutes les 24 heures, l’actualisation des données toutes les heures ne fournit plus de valeur. Au lieu de cela, envisagez d’actualiser les données à une fréquence appropriée pour vous assurer qu’elles sont à jour et exactes.

Power BI

Les opérations de Power BI sont soit interactives, soit en arrière-plan.

Les opérations interactives suivantes entraînent généralement une utilisation élevée du calcul.

  • Modèles sémantiques qui ne suivent pas les meilleures pratiques. Par exemple, ils peuvent ne pas adopter la conception de schéma en étoile avec des relations un-à-plusieurs. Elles peuvent également inclure des filtres de sécurité au niveau des lignes (SNL) complexes et coûteux. Envisagez d’utiliser l’éditeur tabulaire et Best Practice Analyzer pour déterminer si les bonnes pratiques sont suivies.
  • Les mesures DAX sont inefficaces.
  • Les pages de rapport contiennent trop de visuels, ce qui peut entraîner une actualisation visuelle lente.
  • Les visuels de rapport affichent des résultats de cardinalité élevée (trop de lignes ou de colonnes) ou contiennent trop de mesures.
  • La capacité rencontre une concurrence élevée, car il y a trop d’utilisateurs pour la taille de la capacité. Envisagez d’activer le scale-out des requêtes pour améliorer l’expérience utilisateur pour les modèles sémantiques haute concurrence (mais cela n’entraîne pas de calcul total).

Les opérations en arrière-plan suivantes entraînent généralement une utilisation élevée du calcul.

  • Transformations de données inefficaces ou trop complexes dans la logique Power Query.
  • Absence de Query Folding ou d’actualisation incrémentielle pour les tables de faits volumineuses.
  • Le bursting de rapports, c’est-à-dire lorsqu’un grand nombre de rapports Power BI ou de rapports paginés sont générés en même temps.

Contenu connexe

D’autres questions ? Essayez de demander à la Communauté Fabric.