Timeout delle query di Azure Synapse Analytics

Question

Negli ultimi tempi abbiamo dovuto affrontare un problema nella produzione. Esiste un'istanza DW2500c di Azure sinapsi Analytics (in precedenza DWH). Tutto ha funzionato bene fino a poco tempo fa un team ha distribuito un'app Web da cui le aziende possono accedere ai dati. I dati vengono estratti dal DWH. Quello che abbiamo notato è che c'è stata un'improvvisa ondata di query e sessioni che ha causato una crisi di concorrenza. Ho allegato le statistiche DWH statsDalla documentazione, posso vedere che il numero massimo di sessioni consentite è 1024. Ciò indica che non era il conteggio delle sessioni che era un problema, ma il numero di query simultanee (300+) e le query probabilmente sono andate in una coda interna in attesa di risorse essere liberato. Stavo facendo delle ricerche sulla gestione del carico di lavoro e stavo pensando che avremmo potuto fare un tentativo. Dobbiamo ancora controllare quali sono le assegnazioni correnti per i gruppi del carico di lavoro e vedere se è necessario aumentare la concorrenza o aumentare la memoria. Abbiamo provato ad aumentare il livello da 2000 a 2500 ma non è stato d'aiuto. Ma volevo avere un'opinione generale, qual è il modo migliore per evitare questo tipo di scenario?

Answer 1

Dovresti dare un'occhiata da vicino alla classe di risorse con cui la webapp accede al database. cioè è una classe statica come quella staticrc80che alloca la stessa quantità di memoria indipendentemente dalla DWU corrente, o una classe di risorse dinamiche come quella largercche alloca una quantità dinamica di memoria a seconda della DWU. Se gli sviluppatori di webapp non hanno specificato esplicitamente alcuna classe di risorse, è molto probabile che sia in esecuzione in smallrc.

Forse i progettisti di webapp pensavano che la loro app fosse più importante di ogni altra cosa e si sono assegnati una classe di risorse avide. Ad ogni modo, questo sarà istruttivo. Dovrai quindi discutere con gli architetti responsabili della webapp, Synapse e gli amministratori di database che si occupano di Synapse sulla pianificazione della capacità.

Anche questo problema dovrebbe essere diventato evidente nel test di carico. Oggigiorno è facile testare più utenti con applicazioni web, ad esempio test di carico Azure DevOps , Selenium ecc. Chiedi agli sviluppatori di app web i risultati del loro test di carico.

In alternativa, ci sono alcune cose che puoi fare:

• Prova la nuova funzione di memorizzazione nella cache del set di risultati in Synapse che memorizza nella cache i risultati delle query quando abilitata. Le query in esecuzione sulla cache non vengono conteggiate nel limite di concorrenza. Tuttavia, questo tipo di query si basa su molte query simili, ma questa funzione potrebbe ridurre il problema e migliorare le prestazioni.
• Poiché SQL Data Warehouse e ora Synapse non sono famosi per la concorrenza massiccia, è possibile utilizzare modelli alternativi, ad esempio hub e spoke, in cui si scaricano determinate tabelle nei normali database SQL di Azure (che non hanno gli stessi problemi di concorrenza) e forse si mettono anche in pausa il tuo Synapse (il tuo hub). Fai in modo che gli utenti della tua webapp si connettano al DB SQL (il raggio).
• Un'altra caratteristica nuova e intrigante di Synapse è SQL on-demand . Ciò consentirebbe una variazione di hub e spoke in cui è possibile eseguire il dump delle tabelle in Azure Data Lake utilizzando CREATE EXTERNAL TABLEe quindi convincere gli utenti dell'app Web a connettersi all'endpoint SQL on-demand anziché a quello Synapse. In teoria, sarebbe solo una modifica della stringa di connessione per loro e risolverebbe il tuo problema di concorrenza. Non è possibile perfezionare le query e la copertura T-SQL su richiesta di SQL è un po 'più limitata, ma è certamente un modello interessante e lo sto esaminando in questo momento.
• un'altra alternativa collaudata sarebbe quella di mettere Azure Analysis Services (AAS) o Power BI davanti al database Synapse per scaricare il lavoro.

HTH