Gestion des charges de travail
S’applique à :
Point de terminaison et entrepôt SQL dans Microsoft Fabric
Cet article décrit l’architecture et la gestion des charges de travail derrière l’entreposage de données dans Microsoft Fabric.
Important
Microsoft Fabric est actuellement en préversion. Certaines informations portent sur un produit en préversion susceptible d’être substantiellement modifié avant sa publication. Microsoft ne donne aucune garantie, expresse ou implicite, concernant les informations fournies ici.
Traitement des données
L’entrepôt et le point de terminaison SQL partagent la même architecture de traitement sous-jacente. À mesure que les données sont récupérées ou ingérées, elles tirent parti d’un moteur distribué conçu pour les fonctions de calcul et de données à petite et grande échelle.
Le système de traitement est serverless, car la capacité de calcul back-end est mise à l’échelle de manière autonome pour répondre aux demandes de charge de travail.
Lorsqu’une requête est envoyée, le serveur frontal SQL (FE) effectue l’optimisation des requêtes 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 remis au moteur de traitement des requêtes distribuées (DQP). Le DQP orchestre l’exécution distribuée de la requête en la divisant en requêtes plus petites exécutées sur des nœuds de calcul principaux. Chaque petite requête est appelée tâche et représente une unité d’exécution distribuée. Il lit le ou les fichiers à partir de OneLake, joint les résultats d’autres tâches, groupes ou commandes des données récupérées à partir d’autres tâches. Pour les travaux 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 retournés au serveur frontal SQL pour qu’il soit renvoyé à l’utilisateur ou à l’application appelante.
Élasticité et résilience
La capacité de calcul back-end bénéficie d’une architecture d’approvisionnement rapide. Bien qu’il n’existe aucun contrat SLA sur l’attribution des ressources, de nouveaux nœuds sont généralement acquis en quelques secondes. À mesure que la demande de ressources augmente, les nouvelles charges de travail tirent parti de la capacité de scale-out. La mise à l’échelle est une opération en ligne et le traitement des requêtes est ininterrompu.
Le système est tolérant aux pannes et si un nœud devient défectueux, les opérations qui s’exécutent sur le nœud sont redistribuées aux nœuds sains pour être terminées.
Planification et ressources
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 graphique acyclique dirigé (DAG) de tâches. Ce concept est familier aux utilisateurs Spark. Un DAG autorise le parallélisme et la concurrence, car les tâches qui ne dépendent pas les unes des autres peuvent être exécutées simultanément ou dans le désordre.
À mesure que les requêtes arrivent, leurs tâches sont planifiées en fonction des principes FIFO (premier entré, premier sorti). S’il existe une capacité inactive, le planificateur peut utiliser une approche « la mieux adaptée » pour optimiser l’accès concurrentiel.
Lorsque le planificateur identifie la pression des ressources, il appelle une opération de mise à l’échelle. La mise à l’échelle est gérée de manière autonome et la topologie back-end augmente à mesure que l’accès concurrentiel augmente. Comme l’acquisition de nœuds prend quelques secondes, le système n’est pas optimisé pour des performances inférieures à la seconde cohérentes des requêtes qui nécessitent un traitement distribué.
Lorsque la pression diminue, la topologie back-end redescece et libère les ressources dans la région.
Isolation de l’ingestion
S’applique à : Entrepôt dans Microsoft Fabric
Dans le pool de calcul principal d’Entrepôt dans Microsoft Fabric, les activités de chargement sont fournies comme isolation des ressources des charges de travail analytiques. Cela améliore les performances et la fiabilité, car les travaux d’ingestion peuvent s’exécuter sur des nœuds dédiés qui sont optimisés pour ETL et qui ne sont pas en concurrence avec d’autres requêtes ou applications pour les ressources.
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 les coûts et les performances.
Les raccourcis OneLake peuvent être utilisés pour créer des réplicas 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.
