La stratégie de limitation de Fabric

  • Article

La limitation se produit lorsque la capacité d’un locataire consomme plus de ressources de capacité que celles achetées. Une limitation trop importante peut entraîner une dégradation de l’expérience de l’utilisateur final. Un locataire Fabric peut créer plusieurs capacités et attribuer des espaces de travail à une capacité spécifique pour la facturation et le dimensionnement.

La limitation est appliquée au niveau de la capacité, ce qui signifie qu’alors qu’une capacité, ou un ensemble d’espaces de travail, peut voir ses performances réduites en raison d’une surcharge, d’autres capacités peuvent continuer à fonctionner normalement. Dans les cas où les fonctionnalités telles que les artefacts OneLake sont produites dans une capacité et consommées par une autre, l’état de limitation de la capacité consommatrice détermine si les appels à l’artefact sont limités.

Équilibre entre performances et fiabilité

Fabric est conçu pour fournir des performances très rapides à ses clients en permettant aux opérations d’accéder à plus de ressources de CU (Unités de capacité) que celles allouées à la capacité. Les tâches qui peuvent prendre plusieurs minutes pour se terminer sur d’autres plateformes peuvent être terminées en quelques secondes sur Fabric. Pour éviter de pénaliser les utilisateurs lorsque les charges opérationnelles augmentent, Fabric lisse ou établit une moyenne de l’utilisation des CU d’une opération sur une durée minimale de 5 minutes, voire plus pour les requêtes à forte intensité de CU mais à courte durée d’exécution. Ce comportement vous permet de bénéficier d’une performance rapide et constante sans subir de limitation.

Pour les opérations en arrière-plan qui ont de longs runtimes et consomment de lourdes charges de CU, Fabric lisse leur utilisation de CU sur une période de 24 heures. Le lissage élimine la nécessité pour les scientifiques des données et les administrateurs de base de données de passer du temps à créer des planifications de travail pour répartir la charge CU au cours de la journée afin d’éviter que les comptes ne se figent. Avec un lissage de CU de 24 heures, les tâches planifiées peuvent toutes s’exécuter simultanément sans provoquer de pics à tout moment pendant la journée, et vous pouvez profiter de performances constamment rapides sans perdre de temps à gérer les planifications des tâches.

Les opérations en cours d’exécution ne sont pas limitées

Quand une capacité entre dans un état limité, elle affecte uniquement les opérations demandées après la limitation de la capacité. Toutes les opérations, y compris celles de longue durée et qui ont été soumises avant le début de la limitation, sont autorisées à s’exécuter jusqu’à leur terme. Ce comportement vous garantit que les opérations sont terminées, même pendant les pics de CU.

Déclencheurs de limitation et étapes de limitation

Après le lissage, certains comptes peuvent encore connaître des pics d’utilisation de CU pendant les pics d’activité. Pour faciliter la gestion de ces pics, les administrateurs peuvent configurer des alertes par e-mail pour être avertis lorsqu’une capacité consomme 100 % de ses CU provisionnées. Ce modèle indique que la capacité peut tirer parti de l’équilibrage de charge et que l’administrateur doit envisager d’augmenter la taille du SKU. Il est important de noter que, pour les SKU F, vous pouvez les augmenter et les diminuer manuellement à tout moment dans les paramètres d’administration. Toutefois, même lorsqu’une capacité fonctionne à son plein potentiel de CU, Fabric n’applique pas de limitation. Cela garantit que les utilisateurs ont constamment des performances rapides sans rencontrer de perturbations.

La première phase de limitation commence lorsqu’une capacité a consommé toutes ses ressources CU disponibles pour les 10 prochaines minutes. Par exemple, si vous avez acheté 10 unités de CU, puis consommé 50 unités par minute, vous créerez un report de 40 unités par minute. Après deux minutes et demie, vous auriez accumulé un report de 100 unités, empruntées aux fenêtres futures. À ce stade, où la capacité a déjà épuisé toutes les capacités pour les 10 prochaines minutes, Fabric lance son premier niveau de limitation et toutes les nouvelles opérations interactives sont retardées de 20 secondes lors de l’envoi. Si le report atteint une heure complète, les requêtes interactives sont rejetées, mais les opérations planifiées en arrière-plan continuent d’être exécutées. Si la capacité accumule une durée totale de 24 heures de report, la capacité entière est figée jusqu’à ce que le report soit réglé.

Consommation lissée future

Remarque

Microsoft s’efforce d’améliorer la flexibilité du client dans le cadre de l’utilisation du service, tout en équilibrant la nécessité de gérer l’utilisation de la capacité du client. Pour cette raison, Microsoft peut modifier ou mettre à jour la stratégie de limitation Fabric.

Utilisation Limites de stratégie Impact de l’expérience de la stratégie de la plateforme
Utilisation <= 10 minutes Protection contre le dépassement Les travaux peuvent consommer 10 minutes d’utilisation future de la capacité sans limitation.
Utilisation < 10 minutes <= 60 minutes Retard des travaux interactifs Les travaux interactifs demandés par l’utilisateur sont retardés de 20 secondes lors de l’envoi.
Utilisation < 60 minutes <= 24 heures Rejet des travaux interactifs Les travaux interactifs demandés par l’utilisateur sont rejetés.
Utilisation > 24 heures Rejet des travaux en arrière-plan Toutes les requêtes sont rejetées.

Report de la réduction de l’utilisation des capacités

Chaque fois qu’une capacité a une capacité inactive, le système rembourse les niveaux de report.

Si vous avez 100 minutes de CU et un report de 200 minutes de CU, et que vous n’avez pas d’opérations en cours d’exécution, il faut deux minutes pour compenser votre report. Dans cet exemple, le système n’est pas limité, car il y a 2 minutes de report. Les retards de limitation ne commencent pas tant qu’il n’est pas à 10 minutes de report.

Si vous devez payer votre report plus rapidement, vous pouvez augmenter temporairement la taille de votre SKU pour générer une capacité inactive plus élevée appliquée à votre report.

Le comportement de limitation est spécifique à Fabric

Bien que la plupart des produits Fabric suivent les règles de limitation mentionnées précédemment, il existe certaines exceptions.

Par exemple, les flux d’événements Fabric ont de nombreuses opérations qui peuvent s’exécuter pendant des années une fois qu’ils sont démarrés. La limitation des nouvelles opérations de flux d’événements n’aurait pas de sens. Par conséquent, la quantité de CU allouée pour maintenir le flux ouvert est réduite tant que la capacité n’est pas à nouveau en bon état.

L’Analyse en temps réel constitue une autre exception : elle ne serait pas en temps réel si les opérations étaient retardées de 20 secondes. Par conséquent, l’Analyse en temps réel ignore la première phase de limitation avec des retards de 20 secondes à 10 minutes de report et attend jusqu’à la phase de rejet à 60 minutes de report pour commencer la limitation. Ce comportement garantit que les utilisateurs peuvent continuer à bénéficier de performances en temps réel, même pendant les périodes de forte demande.

De même, presque toutes les opérations dans la catégorie Entrepôt sont signalées comme étant en arrière-plan pour tirer parti du lissage de 24 heures de l’activité qui permet d’avoir des modèles d’utilisation plus flexibles. Si vous classez tout l’entrepôt de données comme étant en arrière-plan, les pics d’utilisation de CU ne déclenchent pas trop rapidement de limitation. Certaines requêtes peuvent déclencher une chaîne d’opérations limitées différemment. Cela peut faire en sorte qu’une opération en arrière-plan soit soumise à une limitation en tant qu’opération interactive.

Classifications interactives et en arrière-plan pour la limitation et le lissage

Certains administrateurs peuvent remarquer que les opérations sont parfois classées comme interactives et lissées en arrière-plan, ou vice versa. Cette distinction se produit parce que les systèmes de limitation de Fabric doivent appliquer des règles de limitation avant qu’une requête ne commence à s’exécuter. Le lissage se produit une fois que le travail a commencé à s’exécuter et que la consommation de CU peut être mesurée.

Les systèmes de limitation tentent de classer avec précision les opérations lors de la soumission, mais parfois la classification d’une opération peut changer après l’application de la limitation. Lorsque l’opération commence à s’exécuter, des informations plus détaillées sur la requête sont disponibles. Dans les scénarios ambigus, les systèmes de limitation tendent à classer les opérations en arrière-plan, ce qui est dans l’intérêt de l’utilisateur.

Suivre les opérations rejetées

L’exploration de l’application Métriques de capacité Microsoft Fabric permet aux administrateurs de voir les opérations qui ont été rejetées lors d’un événement de limitation. Les informations sur ces opérations sont limitées, car elles n’ont jamais été autorisées à démarrer. L’administrateur peut voir le produit, l’utilisateur, l’ID d’opération et l’heure à laquelle la requête a été envoyée. Les utilisateurs finaux reçoivent un message d’erreur lorsqu’une requête est rejetée leur demandant de réessayer ultérieurement.

Contenu connexe