Partager via

Gestion des charges de travail

  • Article

S’applique à : point de terminaison d’analytique SQL et entrepôt dans Microsoft Fabric

Cet article décrit l'architecture et la gestion de la charge de travail derrière l'entreposage de données dans Microsoft Fabric.

Traitement des données

L’entrepôt et le point de terminaison d’analytique SQL partagent la même architecture de traitement sous-jacente. Au fur et à mesure que les données sont récupérées ou ingérées, il exploite un moteur distribué conçu pour les données à petite et à grande échelle et les fonctions de calcul.

Le système de traitement est serverless dans la mesure où la capacité de calcul du backend augmente et diminue de manière autonome pour répondre aux demandes de charge de travail.

Schéma du moteur SQL.

Lorsqu'une requête est soumise, l'interface SQL (FE) effectue une optimisation de la requête pour déterminer le meilleur plan en fonction de la taille et de la complexité des données. Une fois le plan généré, il est transmis au moteur de traitement distribué des requêtes (DQP). Le DQP orchestre l'exécution distribuée de la requête en la divisant en requêtes plus petites qui sont exécutées sur les nœuds de calcul principaux. Chaque petite requête est appelée une tâche et représente une unité d'exécution distribuée. Il lit le(s) fichier(s) de OneLake, joint les résultats d'autres tâches, groupes ou ordonne les données extraites d'autres tâches. Pour les tâches d'ingestion, il écrit également des données dans les tables de destination appropriées.

Lorsque les données sont traitées, les résultats sont renvoyés à l'interface SQL pour être renvoyés à l'utilisateur ou à l'application appelante.

Élasticité et résilience

La capacité de calcul backend bénéficie d'une architecture de provisionnement rapide. Bien qu'il n'y ait pas de SLA sur l'affectation des ressources, les nouveaux nœuds sont généralement acquis en quelques secondes. À mesure que la demande de ressources augmente, de nouvelles charges de travail utilisent la capacité évolutive. La mise à l'échelle est une opération en ligne et le traitement des requêtes est ininterrompu.

Diagramme illustrant le provisionnement rapide des ressources.

Le système est tolérant aux pannes et si un nœud devient défectueux, les opérations exécutées sur le nœud sont redistribuées aux nœuds sains pour être terminées.

L’entrepôt et le point de terminaison d’analytique SQL fournissent une capacité burstable qui permet aux charges de travail d’utiliser davantage de ressources pour obtenir de meilleures performances et d’utiliser le lissage pour offrir un secours aux clients qui créent des pics soudains pendant leurs pics de pointe, alors qu’ils ont beaucoup de capacité inactive inutilisée. Le lissage simplifie la gestion de la capacité en répartissant l’évaluation du calcul pour que les travaux du client s’exécutent de manière fluide et efficace.

Planification et ressourcement

Le planificateur de traitement de requête distribué fonctionne au niveau de la tâche. Les requêtes sont représentées pour le planificateur sous la forme d'un graphe acyclique dirigé (DAG) de tâches. Ce concept est familier aux utilisateurs de Spark. Un DAG permet le parallélisme et la concurrence, car des tâches qui ne dépendent pas les unes des autres peuvent être exécutées simultanément ou dans le désordre.

Au fur et à mesure que les requêtes arrivent, leurs tâches sont planifiées sur la base des principes du premier entré, premier sorti (FIFO). S'il y a de la capacité inactive, le planificateur peut utiliser une approche "best fit" pour optimiser la simultanéité.

Lorsque le planificateur identifie une pression de ressourcement, il appelle une opération de mise à l'échelle. La mise à l'échelle est gérée de manière autonome et la topologie backend se développe à mesure que la simultanéité augmente. Comme il faut quelques secondes pour acquérir des nœuds, le système n'est pas optimisé pour des performances cohérentes en moins d'une seconde des requêtes qui nécessitent un traitement distribué.

Lorsque la pression diminue, la topologie backend se réduit et libère les ressources dans la région.

Isolement de l'ingestion

S’applique à : Warehouse dans Microsoft Fabric

Dans le pool de calcul principal de Warehouse dans Microsoft Fabric, les activités de chargement sont isolées des ressources des charges de travail analytiques. Cela améliore les performances et la fiabilité, car les tâches d'ingestion peuvent s'exécuter sur des nœuds dédiés optimisés pour ETL et n'entrent pas en concurrence avec d'autres requêtes ou applications pour les ressources.

Diagramme illustrant l'isolement des activités d'ingestion.

Sessions

L’entrepôt et le point de terminaison d’analytique SQL ont une limite de session utilisateur de 724 par espace de travail. Lorsque cette limite est atteinte, une erreur est retournée : The user session limit for the workspace is 724 and has been reached.

Remarque

Comme Microsoft Fabric est une plateforme SaaS, il existe de nombreuses connexions système qui s’exécutent pour optimiser en permanence l’environnement. Les vues de gestion dynamique affichent à la fois les sessions système et utilisateur. Pour plus d'informations, consultez Surveiller en utilisant les DMV.

Bonnes pratiques

L'espace de travail Microsoft Fabric fournit une limite d'isolation naturelle du système de calcul distribué. Les charges de travail peuvent tirer parti de cette limite pour gérer à la fois les coûts et les performances.

Les raccourcis OneLake peuvent être utilisés pour créer des répliques en lecture seule de tables dans d'autres espaces de travail afin de répartir la charge sur plusieurs moteurs SQL en créant une limite d'isolation. Cela peut augmenter efficacement le nombre maximal de sessions exécutant des requêtes en lecture seule.

Schéma illustrant l'isolement de deux espaces de travail, par exemple, l'espace de travail Finance et Marketing.

Contenu connexe