Comportamento di dimensionamento, scalabilità e accodamento di SQL Warehouse

Questo articolo illustra come dimensionare, scalare e gestire le code di query per i Databricks SQL Warehouses al fine di ottimizzare le prestazioni e i costi. Databricks consiglia di usare un sql warehouse serverless per la maggior parte dei carichi di lavoro. I data warehouse SQL serverless offrono prestazioni ed efficienza ottimali gestendo in modo dinamico le risorse per le query.

Gestione di SQL Warehouse serverless

I warehouse SQL serverless usano Intelligent Workload Management (IWM) per gestire automaticamente i carichi di lavoro di query. IWM è un set di funzionalità basate sull'intelligenza artificiale che elaborano le query in modo rapido e conveniente senza dover gestire l'infrastruttura.

Gestione intelligente del carico di lavoro e scalabilità automatica

IWM usa modelli di Machine Learning per gestire in modo dinamico le risorse di calcolo:

• Quando arriva una nuova query, IWM stima i requisiti delle risorse e verifica la capacità disponibile.
  • Se la capacità esiste, la query viene avviata immediatamente.
  • In caso contrario, la query viene inserita in una coda.
• IWM monitora continuamente la coda. Se i tempi di attesa aumentano, l'autoscaler apre rapidamente più cluster per elaborare le query in coda.
• Quando la domanda scende, IWM riduce le risorse per ridurre i costi mantenendo al tempo stesso una capacità sufficiente per gestire i carichi di picco recenti.

Questo approccio offre:

• Scalabilità rapida per mantenere bassa la latenza delle query.
• Velocità effettiva elevata mediante l'ammissione di query non appena è disponibile l'hardware.
• Ridimensionamento rapido per risparmiare sui costi durante la bassa domanda.

Dimensionamento di un SQL Warehouse Serverless

Le dimensioni del cluster ,ad esempio X-Small, Medium, Large, determinano le risorse di calcolo disponibili per un singolo cluster. Il ridimensionamento automatico aggiunge o rimuove i cluster di tali dimensioni in base alle esigenze.

Usare le linee guida seguenti per scegliere le dimensioni appropriate:

• Iniziare con un unico warehouse più grande e consentire alle funzionalità serverless di gestire la concorrenza e le prestazioni. In genere è più efficiente ridurre le dimensioni, se necessario, rispetto a iniziare con dimensioni ridotte e poi ingrandire.
• Se le query vengono distribuite su disco, aumentare le dimensioni del cluster. Verificare la presenza di eccedenze nel profilo di query.
• Per i carichi di lavoro con molte query simultanee, configurare un numero massimo di cluster sufficiente per gestire i carichi di picco. Monitorare la metrica Peak Queued Queries (Query in coda di picco) nella pagina di monitoraggio del magazzino.

Monitoraggio delle prestazioni del magazzino

È possibile monitorare e ridimensionare qualsiasi sql warehouse usando questi strumenti. Il numero massimo di query in una coda per tutti i tipi di magazzino è 1.000.

• Pagina Monitoraggio: Nella scheda Monitoraggio di SQL Warehouse, selezionare Peak Queued Queries (Query in coda di picco). Un valore coerente superiore a 0 indica che potrebbero essere necessarie dimensioni del cluster maggiori o più cluster.
• Cronologia delle query: Esamina le prestazioni storiche delle query per identificare i colli di bottiglia.
• Profilo di query: Esamina i piani di esecuzione per metriche come byte trasferiti su disco, che indica che le dimensioni del data warehouse potrebbero essere troppo ridotte.

Magazzini SQL classici e professionali

I warehouse classici e pro usano un modello di ridimensionamento manuale in cui si configura il numero di cluster.

Ridimensionamento e approvvigionamento di cluster

Quando si crea un warehouse classico o pro, scegliere una dimensione del cluster e impostare il numero minimo e massimo di cluster. Questi SKU hanno un limite fisso di un cluster per 10 query simultanee.

La dimensione dell'istanza di tutti i worker è Standard_E8ds_v4.

Ogni driver e lavoratore dispone di un disco gestito SSD Premium LRS (Archiviazione con ridondanza locale) da 256 GB collegato. I dischi collegati vengono fatturati ogni ora.

Quota vCPU di Azure necessaria per i warehouse SQL classici e professionali

Per avviare un warehouse SQL classico o professionale, è necessario disporre di una quota di VCPU di Azure adeguata per le istanze di Standard_E8ds_v4 nell'account Azure. Usare le seguenti linee guida per determinare la quota di vCPU necessaria:

Se hai solo uno o due SQL warehouse, verifica di avere disponibili 8 vCPU di Azure per ogni core nel cluster. In questo modo si garantisce un'adeguata vCPU di Azure per consentire il nuovo provisioning del magazzino, che avviene circa ogni 24 ore. Potresti dover aumentare il moltiplicatore se i magazzini SQL utilizzano la scalabilità automatica o il bilanciamento del carico multicluster.

• Man mano che aumenta il numero di warehouse SQL, è possibile usare una vCPU di Azure compresa tra 4 e 8 per ogni core nel cluster. Databricks consiglia di iniziare con un numero maggiore e monitorare la stabilità.
• Le vCPU di Azure usate da SQL Warehouse si aggiungono alle vCPU di Azure usate dai cluster usati da Data Science & Engineering o da carichi di lavoro non Databricks.

Per richiedere una quota aggiuntiva di VCPU di Azure, vedere Quota standard: Aumentare i limiti per serie di VM nella documentazione di Azure.

Accodamento e logica di scalabilità automatizzata

Per i warehouse classici e pro, la scalabilità automatica aggiunge cluster in base al tempo stimato per elaborare tutte le query in esecuzione e in coda:

• 2-6 minuti di caricamento delle query: aggiungere 1 cluster.
• 6-12 minuti: aggiungere 2 cluster.
• 12-22 minuti: aggiungere 3 cluster.
• Oltre 22 minuti: aggiungere 3 cluster, più 1 aggiuntivo per ogni 15 minuti extra di carico.

Regole aggiuntive:

• Se una query attende nella coda per 5 minuti, il magazzino aumenta.
• Se il carico rimane basso per 15 minuti consecutivi, il magazzino si riduce al minimo necessario per gestire il carico massimo da quel periodo.