Dimensionnement, mise à l'échelle et comportement de mise en file d'attente du SQL warehouse
Cet article explique comment dimensionner, monter en charge et gérer les files d'attente de query pour les Databricks SQL warehouses afin d'optimiser les performances et le coût. Databricks recommande d'utiliser un SQL Warehouse serverless pour la plupart des charges de travail. Les SQL Warehouse Serverless offrent les meilleures performances et l'efficacité en gérant dynamiquement les ressources pour vos queries.
Gestion des Serverless SQL Warehouse
Les Serverless SQL warehouses utilisent l' Intelligent Workload Management (IWM) pour gérer automatiquement les query Workload. L'IWM est un ensemble de fonctionnalités basées sur l'IA qui traitent les requêtes rapidement et à moindre coût, sans que vous ayez à gérer l'infrastructure.
Gestion intelligente des Workload et autoscaling
IWM utilise des Modèle de machine learning pour gérer dynamiquement les compute ressources :
-
Lorsqu'une nouvelle query arrive, IWM prédit ses besoins en ressources et vérifie la capacité disponible.
- Si la capacité est disponible, la query démarre immédiatement.
- Dans le cas contraire, la query est placée dans une file d'attente.
-
IWM surveille en permanence la file d'attente. Si les temps d'attente augmentent, l'autoscaler provisionne rapidement davantage de clusters pour traiter les queries en file d'attente.
-
Lorsque la demande diminue, IWM réduit les ressources pour réduire les coûts tout en conservant une capacité suffisante pour gérer les pics de charge récents.
Cette approche fournit :
- Mise à l'échelle rapide pour maintenir une faible latence des query.
- High throughput en admettant les queries dès que le matériel est disponible.
- Mise à l'échelle rapide à la baisse pour économiser des coûts en période de faible demande.
Dimensionnement d'un SQL Warehouse Serverless
La taille du cluster (par exemple, X-Small, Medium, Large) détermine les ressources de compute disponibles pour un seul cluster. L'autoscaler ajoute ou supprime des clusters de cette taille selon les besoins.
Veuillez utiliser les directives suivantes pour vous aider à choisir la bonne taille :
- Start with a single larger warehouse and let Serverless features manage concurrency and performance. Il est généralement plus efficace de réduire la taille si nécessaire que de start petit et de monter en charge.
- Si les queries subissent un spilling sur le disque, augmentez la taille du cluster. Vérifiez les spill dans le profil de requête.
- Pour les charges de travail avec de nombreuses requêtes simultanées, configurez un nombre maximal de clusters suffisant pour gérer les charges de pointe. Surveillez la métrique Peak Queued Queries sur la page de monitoring du warehouse.
Pour les SQL Warehouses serverless, les tailles de cluster peuvent, dans certains cas, utiliser des types d’instances différents de ceux répertoriés dans la documentation pour les SQL Warehouses Pro et classiques pour une taille de cluster équivalente. En général, le rapport prix/performances des tailles de cluster pour les SQL Warehouses serverless est similaire à celui des SQL Warehouses Pro et classiques.
Délai d'expiration de l'instruction
Bêta
Les délais d'expiration des instructions au niveau du warehouse sont en version bêta. Un administrateur de workspace doit activer l'aperçu **Délai d'expiration des instructions du warehouse** à partir de la page **Aperçus**. Voir Gérer les aperçus Databricks.
Vous pouvez définir un délai d'expiration d'instruction sur un seul SQL warehouse afin que les queries de longue durée sur ce warehouse soient interrompues après une durée spécifiée. Utilisez un délai d'expiration au niveau du warehouse lorsque différents warehouses exécutent des charges de travail avec des durées d'exécution prévues différentes.
Définissez le délai d'expiration à l'aide du champ statement_timeout dans les APIs de création ou de mise à jour warehouse. Pour plus de détails, y compris la plage de valeurs, la suppression du délai d'expiration et le comportement de redémarrage, consultez Délai d'expiration au niveau du warehouse.
Lorsque le délai d'expiration est défini à plusieurs niveaux, la session l'emporte sur le warehouse, qui l'emporte sur le Workspace. Pour plus de détails, voir Priorité.
monitoring des performances de la warehouse
Vous pouvez surveiller et redimensionner n'importe quel SQL warehouse à l'aide de ces outils. Le nombre maximum de queries dans une file d'attente pour tous les types de warehouse est de 1 000.
- Page de monitoring : sur l'onglet de monitoring du SQL Warehouse, vérifiez les requêtes mises en file d'attente maximales . Une valeur constante supérieure à 0 indique que vous pourriez avoir besoin d'une taille de cluster plus importante ou de plus de clusters.
- Historique des requêtes : examinez les performances des requêtes historiques pour identifier les goulots d'étranglement.
- Profil de requête : examinez les plans d'exécution pour des métriques telles que les octets spilled to disk , ce qui indique que la taille du warehouse pourrait être trop petite.
SQL Warehouse classiques et pro
Les warehouses Classic et Pro utilisent un modèle de mise à l'échelle manuel où vous configurez le nombre de clusters.
Dimensionnement et provisionnement de clusters
Aperçu public
La taille de cluster 5X-Large est en aperçu public pour les SQL Warehouse pro et Serverless dans toutes les régions. Les administrateurs du Workspace peuvent contrôler l'accès à cette fonctionnalité à partir de la page Previews . Consultez Gérer les aperçus Databricks.
Lors de la création d’un warehouse classique ou Pro, choisissez une taille de cluster et définissez le nombre minimal et maximal de clusters. Ces SKU ont une limite fixe d’un cluster pour 10 requêtes simultanées.
Le tableau suivant présente les tailles de clusters avec le nombre correspondant de Driver et de Worker. Tous les Worker utilisent des instances i3.2xlarge.
Taille du cluster | Type d'instance Driver | Nombre de Worker |
|---|---|---|
XXS | i3.2xlarge | 1 |
XS | i3.2xlarge | 2 |
Petit (Small) | i3.4xlarge | 4 |
Medium | i3.8xlarge | 8 |
Large | i3.8xlarge | 16 |
XL | i3.16xlarge | 32 |
XXL | i3.16xlarge | 64 |
XXXL | i3.16xlarge | 128 |
XXXXL | i3.16xlarge | 256 |
5X-Large | i3.16xlarge | 512 |
Zones de disponibilité (AZ) pour les SQL Warehouse pro et classiques
Pour les SQL warehouses, les zones de disponibilité AWS sont définies sur **auto** (Auto-AZ), où la zone de disponibilité est sélectionnée automatiquement en fonction des adresses IP disponibles dans les sous-réseaux du workspace. Nouvelles tentatives Auto-AZ dans d'autres zones de disponibilité si AWS renvoie des erreurs de capacité insuffisante. Pour plus d'informations sur les zones de disponibilité, consultez la documentation AWS.
Les informations de ce tableau peuvent varier en fonction de la disponibilité du produit ou de la région et du type de workspace.
Logique de mise en file d'attente et de dimensionnement automatique
Pour les warehouses classiques et professionnels, l'autoscaling ajoute des clusters en fonction du temps estimé pour traiter toutes les queries en cours d'exécution et en file d'attente :
- 2 à 6 minutes de chargement de query : ajoutez 1 cluster.
- De 6 à 12 minutes : ajoutez 2 clusters.
- De 12 à 22 minutes : Ajoutez 3 clusters.
- Au-delà de 22 minutes : ajoutez 3 clusters plus 1 de plus pour chaque tranche supplémentaire de 15 minutes de charge.
Règles supplémentaires :
- Si une query attend dans la file d'attente pendant 5 minutes, le warehouse monte en charge.
- Si la charge reste faible pendant 15 minutes consécutives, le warehouse se redimensionne au minimum nécessaire pour gérer la charge maximale de cette période.