Dimensionnement, mise à l'échelle et comportement de mise en file d'attente de l'entrepôt SQL
Cet article explique le comportement de dimensionnement des clusters, de mise en file d'attente et de mise à l'échelle automatique des entrepôts SQL.
Dimensionnement d’un entrepôt SQL serverless
Commencez toujours par une plus grande taille de t-shirt pour votre entrepôt SQL serverless que vous pensez que vous aurez besoin et que vous aurez besoin de la taille à mesure que vous testez. Évitez de commencer avec une taille de t-shirt petite pour votre entrepôt SQL sans serveur pour augmenter par la suite. En général, commencez avec un seul entrepôt SQL sans serveur et comptez sur Azure Databricks pour ajuster la taille avec des clusters sans serveur, en mettant l'accent sur la priorisation des charges de travail et des lectures rapides de données. Consultez la Mise à l’échelle automatique et mise en file d’attente des requêtes serverless.
- Pour réduire la latence des requêtes pour un entrepôt SQL serverless donné :
- Si les requêtes se déversent sur le disque, augmentez la taille du t-shirt.
- Si les requêtes sont hautement parallélisables, augmentez la taille du t-shirt.
- Si vous exécutez plusieurs requêtes à la fois, ajoutez d’autres clusters pour la mise à l’échelle automatique.
- Pour réduire les coûts, essayez de descendre dans la taille du t-shirt sans se déverser sur le disque ou augmenter considérablement la latence.
- Pour vous aider à ajuster correctement la taille de votre entrepôt SQL sans serveur, utilisez les outils suivants :
- Page de surveillance : examinez le nombre maximal de requêtes. Si le pic de file d’attente est généralement supérieur à un, ajoutez des clusters. Le nombre maximal de requêtes dans une file d’attente pour tous les types d’entrepôts SQL est de 1 000. Consultez Superviser un entrepôt SQL.
- Historique des requêtes. Consulter l'Historique des requêtes.
- Profils de requête (recherchez octets déversés sur le disque supérieur à 1). Voir Profil de requête.
Remarque
Pour les entrepôts SQL serverless, les tailles de cluster peuvent, dans certains cas, utiliser des types d’instances différents de ceux listés dans la documentation des entrepôts SQL pro et classiques pour une taille de cluster équivalente. En général, le rapport prix/performances des tailles de cluster pour les entrepôts SQL serverless est similaire à celui des entrepôts SQL pro et classiques.
Mise à l’échelle automatique et mise en file d’attente des requêtes serverless.
La Gestion Intelligente des Charges de Travail (GICT) est un ensemble de fonctionnalités qui améliore la capacité des entrepôts SQL sans serveur à traiter rapidement et de manière rentable un grand nombre de requêtes. Il gère dynamiquement les charges de travail à l’aide de modèles Machine Learning pour prédire les demandes en ressources des requêtes entrantes tout en surveillant la capacité de calcul disponible de l’entrepôt en temps réel. Le suivi de ces valeurs et d’autres signaux dans l’entrepôt permet à IWM de répondre aux modifications des demandes de charge de travail.
Cette gestion dynamique permet à IWM d’effectuer les opérations suivantes :
- Augmenter l’échelle du calcul rapidement pour maintenir une faible latence.
- Fournissez une admission de requête à des taux plus proches de la limitation du matériel.
- Réduire l’échelle rapidement pour réduire les coûts lorsque la demande est faible.
Lorsqu’une requête arrive à l’entrepôt, IWM prédit son coût. En même temps, IWM surveille en temps réel la capacité de calcul disponible de l’entrepôt. Ensuite, à l’aide de modèles Machine Learning, IWM prédit si la requête entrante dispose du calcul nécessaire disponible sur le calcul existant. Si elle ne dispose pas de la capacité de calcul nécessaire, la requête est ajoutée à la file d'attente. Si elle dispose de la capacité de calcul nécessaire, la requête commence à s’exécuter immédiatement.
IWM surveille la file d’attente toutes les 10 secondes environ. Si la file d'attente ne diminue pas assez rapidement, l'autoscaling se met en marche pour fournir rapidement plus d'espace de calcul. Une fois la nouvelle capacité ajoutée, les requêtes en file d'attente sont admises dans les nouvelles ressources de calcul. Avec les entrepôts SQL serverless, vous pouvez ajouter du calcul supplémentaire rapidement. Le nombre maximal de requêtes dans une file d’attente pour tous les types d’entrepôts SQL est de 1 000.
Tailles de cluster pour les entrepôts SQL professionnels et classiques
Le tableau de cette section met en correspondance la taille des clusters d’entrepôt SQL avec la taille du pilote de cluster Azure Databricks et le nombre de workers. La taille du pilote s’applique uniquement aux entrepôts SQL pro et classiques.
| Taille du cluster | Type d’instance pour le pilote (s’applique uniquement aux entrepôts SQL pro et classiques) | Nombre de rôles de travail |
|---|---|---|
| 2x-Small | Standard_E8ds_v4 | 1 x Standard_E8ds_v4 |
| X-Small | Standard_E8ds_v4 | 2 x Standard_E8ds_v4 |
| Petite | Standard_E16ds_v4 | 4 x Standard_E8ds_v4 |
| Moyenne | Standard_E32ds_v4 | 8 x Standard_E8ds_v4 |
| grand | Standard_E32ds_v4 | 16 x Standard_E8ds_v4 |
| X-Large | Standard_E64ds_v4 | 32 x Standard_E8ds_v4 |
| 2X-Large | Standard_E64ds_v4 | 64 x Standard_E8ds_v4 |
| 3X-Large | Standard_E64ds_v4 | 128 x Standard_E8ds_v4 |
| 4X-Large | Standard_E64ds_v4 | 256 x Standard_E8ds_v4 |
La taille d’instance de tous les rôles de travail est Standard_E8ds_v4.
Chaque pilote et rôle de travail dispose de huit disques managés LRS standard de 128 Go attachés. Les disques attachés sont facturés toutes les heures.
Quota Azure vCPU requis pour les entrepôts SQL classiques et professionnels
Pour démarrer un entrepôt SQL classique ou professionnel, vous devez disposer d'un quota Azure vCPU adéquat pour les instances Standard_E8ds_v4 dans votre compte Azure. Utilisez les instructions suivantes pour déterminer le quota de processeurs virtuels requis :
- Si vous n’avez qu’un ou deux entrepôts SQL, vérifiez que vous disposez de 8 processeurs virtuels Azure disponibles pour chaque cœur du cluster. Ceci vous permet d’avoir le nombre adéquat de processeurs virtuels Azure pour le reprovisionnement de votre entrepôt, qui se produit approximativement toutes les 24 heures. Si vos entrepôts SQL utilisent la mise à l’échelle automatique ou l’équilibrage de charge multicluster, vous devrez peut-être augmenter le multiplicateur.
- À mesure que le nombre d’entrepôts SQL augmente, prévoyez entre 4 et 8 processeurs virtuels Azure pour chaque cœur du cluster. Databricks recommande de commencer avec un plus grand nombre et de surveiller la stabilité.
- Les processeurs virtuels Azure utilisés par des entrepôts SQL s’ajoutent aux processeurs virtuels Azure utilisés par les clusters des charges de travail Ingénierie et Science des données ou des charges de travail non-Databricks.
Pour demander un quota de processeurs virtuels Azure supplémentaire, consultez Quota standard : augmenter les limites par série de machines virtuelles dans la documentation Azure.
Remarque
Les informations contenues dans ce tableau peuvent varier en fonction de la disponibilité du produit ou de la région et du type d'espace de travail.
Mise en file d’attente et mise à l’échelle automatique pour les entrepôts SQL professionnels et classiques
Azure Databricks limite le nombre de requêtes sur un cluster affecté à un entrepôt SQL en fonction du coût du calcul de leurs résultats. La mise à l’échelle des clusters par entrepôt est basée sur le débit des requêtes, le taux de requêtes entrantes et la taille de la file d’attente. Azure Databricks recommande un cluster pour 10 requêtes simultanées. Le nombre maximal de requêtes dans une file d’attente pour tous les types d’entrepôts SQL est de 1 000.
Azure Databricks ajoute des clusters en fonction du temps nécessaire pour traiter toutes les requêtes en cours d’exécution, toutes les requêtes en file d’attente et les requêtes entrantes attendues dans les deux prochaines minutes.
- Si moins de 2 minutes, ne pas mettre à l’échelle.
- Si entre 2 et 6 minutes, ajouter 1 cluster.
- Si entre 6 et 12 minutes, ajouter 2 clusters.
- Si entre 12 et 22 minutes, ajouter 3 clusters.
Dans le cas contraire, Azure Databricks ajoute 3 clusters plus 1 cluster pendant 15 minutes supplémentaires de charge de requête attendue.
De plus, un entrepôt est toujours mis à l’échelle si une requête attend 5 minutes dans la file d’attente.
Si la charge est faible pendant 15 minutes, Azure Databricks effectue un scale-down de l’entrepôt SQL. Il conserve suffisamment de clusters pour gérer la charge maximale au cours des 15 dernières minutes. Par exemple, si la charge maximale était de 25 requêtes simultanées, Azure Databricks conserve 3 clusters.
Mise en file d'attente des requêtes pour les entrepôts SQL classiques et professionnels
Azure Databricks met en file d’attente les requêtes quand tous les clusters affectés à l’entrepôt exécutent des requêtes à pleine capacité ou quand l’entrepôt est dans l’état STARTING. Le nombre maximal de requêtes dans une file d’attente pour tous les types d’entrepôts SQL est de 1 000.
Les requêtes de métadonnées (par exemple DESCRIBE <table>) et les requêtes de modification d’état (par exemple SET) ne sont jamais mises en file d’attente, sauf si l’entrepôt est dans l’état STARTING.