Share via

Dimensionnement, mise à l'échelle et comportement de mise en file d'attente de l'entrepôt SQL

  • Article

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. À l’aide des fonctionnalités de prédiction basées sur l’IA pour analyser les requêtes entrantes et déterminer l’E/S prédictive la plus rapide et plus efficace, IWM fonctionne pour garantir que les charges de travail disposent rapidement de la bonne quantité de ressources. La principale différence réside dans les fonctionnalités d’IA de Databricks SQL pour répondre dynamiquement aux demandes de charge de travail plutôt que d’utiliser des seuils statiques.

Cette réactivité garantit :

  • Montée en puissance rapide pour acquérir plus de ressources de calcul lorsque cela est nécessaire pour maintenir une latence faible.
  • Admission de requête plus proche de la limitation du matériel.
  • Réduction rapide de la capacité pour minimiser les coûts lorsque la demande est faible, assurant des performances constantes avec des coûts et des ressources optimisés.

Lorsqu’une requête arrive à l’entrepôt, IWM prédit le coût de la requête. 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 à être exécutée 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 nouveaux clusters. Avec les entrepôts SQL sans serveur, de nouveaux clusters peuvent être ajoutés rapidement et plusieurs clusters peuvent être créés à la fois. 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.