Linee guida sulle prestazioni di Fabric Data Warehouse
Si applica a✅: Warehouse in Microsoft Fabric
Queste sono linee guida che consentono di comprendere le prestazioni del magazzino in Microsoft Fabric. In questo articolo sono disponibili indicazioni e articoli importanti su cui concentrarsi. Il magazzino in Microsoft Fabric è una piattaforma SaaS in cui le attività come la gestione dei carichi di lavoro, la concorrenza e la gestione dell'archiviazione vengono gestite internamente dalla piattaforma. Oltre a questa gestione delle prestazioni interna, è comunque possibile migliorare le prestazioni sviluppando query con prestazioni elevate su magazzini ben progettati.
Prestazioni dell'esecuzione a freddo (cache a freddo)
La memorizzazione nella cache con unità SSD locale e memoria è automatica. Le prime 1-3 esecuzioni di una query hanno prestazioni notevolmente più lente rispetto alle esecuzioni successive. Se si verificano problemi di prestazioni dell'esecuzione a freddo, ecco un paio di operazioni che è possibile eseguire per migliorare le prestazioni dell'esecuzione a freddo:
Se le prestazioni della prima esecuzione sono fondamentali, provare a creare manualmente le statistiche. Vedere l'articolo sulle statistiche per comprendere meglio il ruolo delle statistiche e per indicazioni su come creare statistiche manuali per migliorare le prestazioni delle query. Tuttavia, se le prestazioni della prima esecuzione non sono critiche, è possibile basarsi su statistiche automatiche che verranno generate nella prima query e continueranno a essere sfruttate nelle esecuzioni successive (purché i dati sottostanti non cambino significativamente).
Se si usa Power BI, usare la modalità Direct Lake laddove possibile.
Metriche e monitoraggio delle prestazioni
Attualmente, l'Hub di monitoraggio non include il Warehouse. Se si sceglie Data Warehouse, non sarà possibile accedere all'Hub di monitoraggio dalla barra di spostamento.
Gli amministratori di Fabric potranno accedere al report di Utilizzo capacità e metriche per ottenere informazioni aggiornate che monitorano l'utilizzo della capacità che include Warehouse.
Usare la DMV (vista a gestione dinamica) per monitorare l'esecuzione di query
È possibile usare le DMV per monitorare la connessione, la sessione e lo stato della richiesta nel Warehouse.
Statistiche
Warehouse usa un motore di query per creare un piano di esecuzione per una determinata query SQL. Quando si invia una query, Query Optimizer tenta di enumerare tutti i piani possibili e scegliere il candidato più efficiente. Per determinare quale piano richiederebbe il minor sovraccarico, il motore deve essere in grado di valutare la quantità di lavoro o righe che potrebbero essere elaborate da ogni operatore. Quindi, in base al costo di ogni piano, sceglie quello con la minor quantità di lavoro stimato. Le statistiche sono oggetti che contengono informazioni rilevanti sui dati, per consentire a Query Optimizer di stimare questi costi.
È anche possibile aggiornare manualmente le statistiche dopo ogni caricamento o aggiornamento dei dati per garantire che sia possibile creare il piano di query migliore.
Per altre informazioni sulle statistiche e su come aumentare le statistiche create automaticamente, vedere Statistiche nel data warehousing di Fabric.
Linee guida per l'inserimento dati
Esistono quattro opzioni per l'inserimento dati in un warehouse:
- COPY (Transact-SQL)
- Pipeline di dati
- Dataflows
- Inserimento tra warehouse
Per determinare quale opzione è la migliore per l'utente e per esaminare alcune procedure consigliate per l'inserimento dei dati, vedere Inserire i dati.
Raggruppare le istruzioni INSERT in batch (evitare inserimenti a cascata)
Un caricamento in una sola volta in una tabella di piccole dimensioni con un'istruzione INSERT, come mostrato nel seguente esempio, può essere l'approccio migliore a seconda delle esigenze. Se tuttavia è necessario caricare migliaia o milioni di righe nel corso della giornata, le singole operazioni INSERT non costituiscono la soluzione ottimale.
INSERT INTO MyLookup VALUES (1, 'Type 1')
Per indicazioni su come gestire questi scenari di caricamento a cascata, vedere Procedure consigliate per l'inserimento di dati.
Ridurre al minimo le dimensioni delle transazioni
In una transazione vengono eseguite le istruzioni INSERT, UPDATE e DELETE. Quando hanno esito negativo, occorre eseguire il rollback. Per ridurre il rischio di un rollback prolungato, ridurre al minimo le dimensioni delle transazioni, quando possibile. Tale riduzione può essere eseguita suddividendo in parti le istruzioni INSERT, UPDATE e DELETE. Se, ad esempio, si dispone di un'istruzione INSERT che si prevede richieda 1 ora, è possibile suddividerla in quattro parti. Ogni esecuzione verrà accorciata a 15 minuti.
Prendere in considerazione l'uso di CTAS (Transact-SQL) per scrivere i dati da mantenere in una tabella, invece di usare DELETE. Se un'operazione CTAS richiede la stessa quantità di tempo, è molto più sicura da eseguire, perché prevede una registrazione delle transazioni minima e può essere annullata rapidamente, se necessario.
Collocare applicazioni client e Microsoft Fabric
Se si usano applicazioni client, assicurarsi di usare Microsoft Fabric in un'area vicina al computer client. Gli esempi di applicazioni client includono Power BI Desktop, SQL Server Management Studio e Azure Data Studio.
Utilizzare la progettazione dei dati dello schema star
Uno schema star organizza i dati in tabelle fact e tabelle delle dimensioni. Semplifica l'elaborazione analitica denormalizzando i dati da sistemi OLTP altamente normalizzati, inserendo dati transazionali e dati master aziendali in una struttura di dati comune, pulita e verificata che riduce al minimo le unioni in fase di query, riduce il numero di righe lette e facilita le aggregazioni e l'elaborazione di raggruppamenti.
Per altre indicazioni sulla progettazione del Warehouse, vedere Tabelle nell'archiviazione dati.
Ridurre le dimensioni dei set di risultati delle query
La riduzione delle dimensioni dei set di risultati delle query contribuisce a evitare problemi lato client causati da numerosi risultati delle query. I set di risultati dell'editor di query SQL sono limitati alle prime 10.000 righe per evitare questi problemi in questa interfaccia utente basata su browser. Se è necessario restituire più di 10.000 righe, usare SQL Server Management Studio (SSMS) o Azure Data Studio.
Scegliere il tipo di dati migliore per le prestazioni
Quando si definiscono le proprie tabelle, per migliorare le prestazioni di query usare il più piccolo tipo di dati in grado di supportare i dati. Questo consiglio è importante per le colonne CHAR e VARCHAR. Se il valore più lungo in una colonna è di 25 caratteri, definire la colonna come VARCHAR(25). Evitare di definire tutte le colonne di tipo carattere con una lunghezza predefinita elevata.
Se possibile, usare tipi di dati basati su integer. Le operazioni SORT, JOIN e GROUP BY vengono completate più velocemente su numeri interi che non su dati di tipo carattere.
Per i tipi di dati supportati e altre informazioni, vedere tipi di dati.
Prestazioni degli endpoint di analisi SQL
Per informazioni e consigli sulle prestazioni dell'endpoint di analisi SQL, vedere considerazioni sulle prestazioni degli endpoint di analisi SQL.
Compattazione dei dati
La compattazione dei dati consolida i file Parquet più piccoli in meno file di dimensioni maggiori, ottimizzando le operazioni di lettura. Questo processo consente anche di gestire in modo efficiente le righe eliminate eliminandole dai file Parquet non modificabili. Il processo di compattazione dei dati comporta la riscrizione di tabelle o segmenti di tabelle in nuovi file Parquet ottimizzati per le prestazioni. Per altre informazioni, vedere Blog: Compattazione automatica dei dati per Fabric Warehouse.
Il processo di compattazione dei dati è perfettamente integrato nel magazzino. Durante l'esecuzione delle query, il sistema identifica le tabelle che potrebbero trarre vantaggio dalla compattazione ed esegue le valutazioni necessarie. Non esiste un modo manuale per attivare la compattazione dei dati.