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 dietro il data warehousing in Microsoft Fabric.
Elaborazione dati
L'endpoint di analisi di Warehouse e SQL condivide la stessa architettura di elaborazione sottostante. Man mano che i dati vengono recuperati o inseriti, sfrutta un motore distribuito creato per dati di piccole e grandi dimensioni e 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. Ognuna delle query più piccole è definita attività e rappresenta un'unità di esecuzione distribuita. Tale attività legge i file nelle risorse di OneLake, unisce i risultati generati da altre attività e 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 SQL e data warehouse offre capacità di burst che consente ai carichi di lavoro di utilizzare più risorse per ottenere prestazioni migliori e di utilizzare lo smoothing per offrire sollievo ai clienti che creano picchi improvvisi durante i periodi di punta, anche se hanno una grande capacità inutilizzata. 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à disponibile, il pianificatore potrebbe utilizzare un approccio "più adatto" 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 dell'ingestione
Si applica a:✅ Magazzino in Microsoft Fabric
Nel pool di calcolo back-end di Warehouse in Microsoft Fabric, le attività di caricamento ricevono un isolamento delle risorse dai carichi di lavoro analitici. Ciò migliora le prestazioni e l'affidabilità, poiché i processi di inserimento possono essere eseguiti in nodi dedicati ottimizzati per ETL e non competono con altre query o applicazioni per le risorse.
Sessioni
L'endpoint di analisi di Warehouse e SQL ha un limite di sessione utente di 2048 per area di lavoro. Quando viene raggiunto questo limite, verrà restituito un errore: The user session limit for the workspace is 2048 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 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.
