Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :✅ Point de terminaison d'analyses SQL et entrepôt de données dans Microsoft Fabric
Cet article décrit l’architecture et la gestion des charges de travail dans Fabric Data Warehouse.
Traitement des données
L’entrepôt et le point de terminaison d’analytique SQL partagent la même architecture de traitement sous-jacente. À mesure que Fabric récupère ou ingère des données, un moteur distribué gère à la fois les données de 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.
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 attribué au moteur DQP (Distributed Query Processing). 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 une tâche et représente une unité d’exécution distribuée. Il lit les fichiers de OneLake, joint les résultats d’autres tâches, groupes ou commande les données récupérées à partir 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 d'accord sur le niveau de service (SLA) concernant l’attribution de ressources, les nouveaux nœuds sont généralement déployés en quelques secondes. À mesure que la demande de ressources augmente, de nouvelles charges de travail utilisent la capacité étendue. 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 exécutées sur le nœud sont redistribuées aux nœuds sains pour être terminées.
Le point de terminaison d’entrepôt et d’analytique SQL offre une capacité élastique qui permet aux charges de travail d’utiliser davantage de ressources pour obtenir de meilleures performances et d’utiliser le lissage pour offrir un soutien aux clients qui créent des pics soudains pendant leurs pics et qui ont une capacité inactive laissée inemployée à d’autres moments. 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 les tâches qui ne dépendent pas les unes des autres peuvent être exécutées simultanément ou hors ordre.
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 existe une capacité inactive, le planificateur peut utiliser une approche de "meilleur ajustement" pour optimiser l'exécution simultanée.
Lorsque le planificateur identifie une pression sur les ressources, il appelle une opération d'extension. 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.
Isolation du pool de calcul
S'applique à :✅ Entrepôt dans Microsoft Fabric
La référence SKU de capacité affectée à un espace de travail détermine la capacité de calcul totale disponible pour le point de terminaison analytique SQL. Ce calcul est divisé uniformément (50/50) en deux pools de ressources isolés pour que les requêtes utilisateur utilisent :
-
SELECT Pool : gère toutes les
SELECTrequêtes. -
Pool non-SELECT - gère toutes les requêtes non-
SELECT, telles que les opérations ETL ou d'ingestion.
Chaque pool est mis à l’échelle indépendamment en fonction de la demande de requête, mais ne dépasse jamais 50% du calcul total pour le point de terminaison d’analyse SQL. Cette séparation empêche la contention des ressources, ce qui garantit que les charges de travail d’ingestion s’exécutent sur un calcul dédié optimisé pour ETL sans avoir d’impact sur les requêtes de lecture. Le résultat est une amélioration des performances et de la fiabilité des deux types de requêtes.
Remarque
L’isolation du SELECT pool et du non-SELECT pool est la gestion autonome des charges de travail par défaut appliquée à chaque espace de travail. Toutefois, les administrateurs d’espace de travail peuvent le personnaliser à l’aide de pools SQL personnalisés.
Séances
Le point de terminaison Warehouse et SQL Analytics 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. DMVs affichent les deux types de sessions : système et utilisateur. Pour plus d’informations, consultez Surveiller les connexions, sessions et requêtes à l’aide de vues de gestion dynamique.
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.
