Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a:✅ endpoint di analisi SQL e magazzino in Microsoft Fabric
Questo articolo descrive l'architettura e la gestione del carico di lavoro in Fabric Data Warehouse.
Elaborazione dati
L'endpoint di analisi di Warehouse e SQL condivide la stessa architettura di elaborazione sottostante. Man mano che Fabric recupera o inserisce dati, un motore distribuito gestisce sia i dati di piccole che su larga scala e le funzioni di calcolo.
Il sistema di elaborazione è serverless in quanto la capacità di calcolo back-end aumenta e riduce in modo autonomo per soddisfare le esigenze del carico di lavoro.
Quando viene inviata una query, il front-end SQL esegue l'ottimizzazione delle query per determinare il piano migliore in base alle dimensioni e alla complessità dei dati. Dopo aver generato il piano, viene assegnato al motore DQP (Distributed Query Processing). Il DQP orchestra l'esecuzione distribuita della query suddividendola in query più piccole eseguite nei nodi di calcolo back-end. Ogni query di piccole dimensioni è un'attività e rappresenta un'unità di esecuzione distribuita. Legge i file da OneLake, unisce i risultati di altre attività, raggruppa o ordina i dati recuperati da altre attività. Per i processi di inserimento, scrive anche i dati nelle tabelle di destinazione appropriate.
Quando i dati vengono elaborati, i risultati vengono restituiti al front-end SQL per il servizio all'utente o all'applicazione chiamante.
Elasticità e resilienza
La capacità di calcolo del back-end beneficia di un'architettura di provisioning rapida. Anche se non esiste alcun contratto di servizio per l'assegnazione di risorse, in genere i nuovi nodi vengono acquisiti entro pochi secondi. Con l'aumento della domanda di risorse, i nuovi carichi di lavoro utilizzano la capacità scalata. Il ridimensionamento è un'operazione online e l'elaborazione delle query non viene interrotta.
Il sistema è a tolleranza di errore e se un nodo diventa non integro, le operazioni in esecuzione nel nodo vengono ridistribuite ai nodi integri per il completamento.
L'endpoint di analisi di warehouse e SQL offre capacità a scoppi che consente ai carichi di lavoro di usare più risorse per ottenere prestazioni migliori e l'uso di lo smoothing per offrire supporto ai clienti che creano picchi improvvisi durante i periodi di picco e hanno capacità inattiva che rimane inutilizzata in altri momenti. L'ottimizzazione semplifica la gestione della capacità distribuendo l'analisi del carico di lavoro per garantire che i processi dei clienti vengano eseguiti senza intoppi ed efficientemente.
Pianificazione e allocazione delle risorse
Lo schedulatore dell'elaborazione delle query distribuite opera a livello di attività. Le interrogazioni vengono rappresentate al pianificatore come un grafo aciclico diretto (DAG) di attività. Questo concetto è familiare agli utenti di Spark. Un DAG consente il parallelismo e la concorrenza come attività che non dipendono l'una dall'altra possono essere eseguite simultaneamente o fuori ordine.
Quando arrivano le query, le attività vengono pianificate in base ai principi FIFO (First-In-First-Out). Se è presente una capacità inattiva, il scheduler potrebbe usare un approccio "best fit" per ottimizzare la concorrenza.
Quando il scheduler identifica una pressione nella gestione delle risorse, avvia un'operazione di scalabilità. Il ridimensionamento viene gestito in modo autonomo e la topologia back-end aumenta man mano che aumenta la concorrenza. Poiché l'acquisizione dei nodi richiede alcuni secondi, il sistema non è ottimizzato per prestazioni di frazione di secondo coerenti delle query che richiedono l'elaborazione distribuita.
Quando la pressione diminuisce, la topologia del backend si riduce e rilascia la risorsa nella regione.
Isolamento del pool di calcolo
Si applica a:✅ Magazzino in Microsoft Fabric
L'SKU di capacità assegnato a una workspace determina la capacità totale di calcolo disponibile per l'endpoint SQL di analisi. Questo calcolo viene suddiviso in modo uniforme (50/50) in due pool di risorse isolate per le query utente da usare:
-
SELECT Pool : gestisce tutte le
SELECTquery. -
Pool non SELECT : gestisce tutte le query non
SELECT, ad esempio ETL o operazioni di inserimento.
Ogni pool viene ridimensionato in modo indipendente in base alla domanda di query, ma non supera mai 50% del calcolo totale per l'endpoint di analisi SQL. Questa separazione impedisce la contesa delle risorse, assicurando che i carichi di lavoro di inserimento vengano eseguiti in risorse di calcolo dedicate ottimizzate per ETL senza influire sulle query di lettura. Il risultato è un miglioramento delle prestazioni e dell'affidabilità per entrambi i tipi di query.
Nota
L'isolamento del pool SELECT e del pool non-SELECT è la gestione autonoma del carico di lavoro predefinita applicata a ogni area di lavoro. Tuttavia, gli amministratori dell'area di lavoro possono personalizzare questa operazione usando pool SQL personalizzati.
Sessioni
L'endpoint di analisi di Warehouse e SQL ha un limite di sessione utente di 724 per area di lavoro. Quando viene raggiunto questo limite, verrà restituito un errore: The user session limit for the workspace is 724 and has been reached.
Nota
Poiché Microsoft Fabric è una piattaforma SaaS, esistono molte connessioni di sistema eseguite per ottimizzare continuamente l'ambiente. I DMV mostrano sia le sessioni di sistema che quelle utente. Per altre informazioni, vedere Monitorare connessioni, sessioni e richieste usando DMV.
Procedure consigliate
L'area di lavoro di Microsoft Fabric fornisce un limite di isolamento naturale del sistema di calcolo distribuito. I carichi di lavoro possono sfruttare questo limite per gestire sia i costi che le prestazioni.
I collegamenti OneLake possono essere usati per creare repliche di sola lettura di tabelle in altre aree di lavoro per distribuire il carico tra più motori SQL, creando un limite di isolamento. Ciò può aumentare in modo efficace il numero massimo di sessioni che eseguono query di sola lettura.
