Linee guida sulle prestazioni in Fabric Data Warehouse

Si applica a✅: Warehouse in Microsoft Fabric

Questo articolo contiene procedure consigliate per l'inserimento dati, la gestione delle tabelle, la preparazione dei dati, le statistiche e l'esecuzione di query in warehouse ed endpoint di analisi SQL. L'ottimizzazione e l'ottimizzazione delle prestazioni possono presentare sfide uniche, ma offrono anche opportunità preziose per ottimizzare le funzionalità delle soluzioni dati.

Per monitorare le prestazioni nel warehouse, vedere Monitorare il data warehouse di Fabric.

Ottimizzazione dei tipi di dati

La scelta dei tipi di dati corretti è essenziale per prestazioni ed efficienza di archiviazione nel warehouse. Le linee guida seguenti consentono di garantire che la progettazione dello schema supporti query veloci, archiviazione efficiente e gestibilità.

Per altre informazioni sui tipi di dati supportati da Fabric Data Warehouse, vedere Tipi di dati in Fabric Data Warehouse.

Associare i tipi di dati alla semantica dei dati

Per garantire chiarezza e prestazioni, è importante allineare il tipo di dati di ogni colonna alla natura e al comportamento effettivi dei dati archiviati.

• Usare data, ora o datetime2(n) per i valori temporali anziché archiviarli come stringhe.
• Usare i tipi integer per i valori numerici, a meno che non sia necessaria la formattazione (ad esempio, zeri iniziali).
• Usare i tipi di carattere (char, varchar) quando si mantiene la formattazione è essenziale (ad esempio, numeri che possono iniziare con zero, codici prodotto, numeri con trattini).

Usare tipi integer per numeri interi

Quando si archiviano valori come identificatori, contatori o altri numeri interi, preferire tipi integer (smallint, int, bigint) a numeri decimali/. I tipi integer richiedono meno spazio di archiviazione rispetto ai tipi di dati che consentono cifre a destra del separatore decimale. Di conseguenza, consentono operazioni aritmetiche e di confronto più veloci e migliorano l'indicizzazione e le prestazioni delle query.

Tenere presente gli intervalli di valori per ogni tipo di dati Integer supportato da Fabric Data Warehouse. Per altre informazioni, int, bigint, smallint (Transact-SQL).

Prendere in considerazione l'uso di precisione e scala decimale e numerica

Se è necessario usare decimal/numeric, quando si crea la colonna, scegliere la precisione e la scala più piccole che possano contenere i dati. L'eccessiva precisione del provisioning aumenta i requisiti di archiviazione e può degradare le prestazioni con l'aumento dei dati.

• Prevedere la crescita e le esigenze previste del magazzino. Ad esempio, se si prevede di archiviare non più di quattro cifre a destra del separatore decimale, usare decimal(9,4) o decimal(19,4) per l'archiviazione più efficiente.
• Specificare sempre precisione e scala durante la creazione di una colonnanumericadecimale/. Quando viene creata in una tabella definita come semplicemente decimal, senza specificare (p,s) per precisione e scala, viene creata una colonna decimale numerica/ come decimal(18,0). Un decimale con una precisione di 18 utilizza 9 byte di spazio di archiviazione per riga. Una scala di 0 non archivia i dati a destra del separatore decimale. Per molti numeri interi aziendali, smallint, int, bigint sono molto più efficienti di decimal(18,0). Ad esempio, qualsiasi numero intero di nove cifre può essere archiviato come tipo di dati integer per 4 byte di archiviazione per riga.

Per informazioni complete, vedere decimale e numerico (Transact-SQL).

Considerare quando usare varchar al posto di char

Usare varchar(n) anziché char(n) per le colonne stringa, a meno che non sia esplicitamente richiesto il riempimento a lunghezza fissa. Una colonna varchar archivia solo la lunghezza effettiva della stringa per riga, oltre a un sovraccarico ridotto e riduce lo spazio sprecato, migliorando così l'efficienza di I/O.

• Usare varchar(n) per valori come nomi, indirizzi e descrizioni, perché hanno valori ampiamente variabili. Le statistiche e la stima dei costi delle query sono più accurate quando la lunghezza del tipo di dati è più precisa per i dati effettivi.
• Usare char(n) quando si sa che la stringa sarà a lunghezza fissa ogni volta. Ad esempio, l'archiviazione della stringa 000000000 come char(9) ha senso se la stringa è sempre esattamente 9 caratteri numerici che possono iniziare con zero.
• La lunghezza n nella dichiarazione del tipo di dati della colonna è rappresentata dai byte di archiviazione. Per i set di caratteri con codifica multibyte, come UTF-8, la codifica di Fabric Data Warehouse utilizza 1 byte di archiviazione per i caratteri latini e i numeri. Esistono tuttavia caratteri Unicode che richiedono più di 1 byte, ad esempio caratteri giapponesi che richiedono 3 byte da archiviare, quindi il numero di caratteri Unicode effettivamente archiviati può essere minore della lunghezza ndel tipo di dati . Per altre informazioni, vedere Argomenti char e varchar.

Evitare colonne nullable quando possibile

Definire le colonne come NOT NULL quando il modello di dati consente. Per impostazione predefinita, una colonna in una tabella consente valori NULL. Le colonne nullable presentano le caratteristiche seguenti:

• Aggiungono un sovraccarico di metadati.
• Può ridurre l'efficacia delle ottimizzazioni e delle statistiche delle query.
• Può influire sulle prestazioni nelle query analitiche su larga scala.

Inserimento e preparazione dei dati in un warehouse

COPY INTO

Il comando T-SQL COPY INTO è il modo consigliato per inserire dati da Azure Data Lake Storage in Fabric Data Warehouse. Per altre informazioni ed esempi, vedere Inserire dati nel warehouse usando l'istruzione COPY.

Prendere in considerazione i consigli seguenti per ottenere prestazioni ottimali:

• Dimensioni file: Assicurarsi che ogni file che si sta inserendo sia idealmente compreso tra 100 MB e 1 GB per ottimizzare la velocità effettiva. Ciò consente di ottimizzare il processo di inserimento e migliorare le prestazioni.
• Numero di file: Per ottimizzare il parallelismo e le prestazioni delle query, mirare a generare un numero elevato di file. Classificare in ordine di priorità la creazione del maggior numero possibile di file mantenendo al contempo una dimensione minima di 100 MB.
• Caricamento parallelo: Utilizzare più COPY INTO istruzioni in esecuzione in parallelo per caricare i dati in tabelle diverse. Questo approccio può ridurre significativamente la finestra ETL/ELT a causa del parallelismo.
• Dimensioni della capacità: per volumi di dati di dimensioni maggiori, è consigliabile aumentare la capacità dell'infrastruttura per ottenere le risorse di calcolo aggiuntive necessarie per supportare un numero aggiuntivo di elaborazione parallela e volumi di dati più grandi.

Fabric Data Warehouse supporta anche BULK INSERT l'istruzione che è un sinonimo di COPY INTO. La stessa raccomandazione si applica all'istruzione BULK INSERT .

CTAS o INSERT

Usare CREATE TABLE AS SELECT (CTAS) o INSERT combinati con SELECT FROM i comandi tabelle/scorciatoie di Lakehouse. Questi metodi potrebbero essere più efficienti e efficienti rispetto all'uso di pipeline, consentendo trasferimenti di dati più veloci e affidabili. Per altre informazioni ed esempi, vedere Inserire dati in Warehouse usando Transact-SQL.

Il concetto di aumento del numero di parallelismo e scalabilità a capacità di infrastruttura di dimensioni maggiori si applica anche alle operazioni CTAS/INSERT per aumentare la velocità effettiva.

Leggere i dati da Azure Data Lake Storage o da Blob Storage con OPENROWSET

La funzione OPENROWSET consente di leggere file CSV o Parquet da Azure Data Lake o Azure Blob Storage, senza inserirli nel Magazzino Dati. Per altre informazioni ed esempi, vedere Esplorare il contenuto dei file usando la funzione OPENROWSET.

Durante la lettura dei dati tramite la funzione OPENROWSET, prendere in considerazione i consigli seguenti per ottenere prestazioni ottimali:

• Parquet: Provare a usare Parquet invece di CSV o convertire CSV in Parquet, se si esegue spesso una query sui file. Parquet è un formato a colonne. Poiché i dati sono compressi, le dimensioni dei file sono inferiori ai file CSV che contengono gli stessi dati. Fabric Data Warehouse ignora le colonne e le righe non necessarie in una query quando si leggono file Parquet.
• Dimensioni file: Assicurarsi che ogni file che si sta inserendo sia idealmente compreso tra 100 MB e 1 GB per ottimizzare la velocità effettiva. Ciò consente di ottimizzare il processo di inserimento e migliorare le prestazioni. È preferibile avere file di dimensioni uguali.
• Numero di file: Per ottimizzare il parallelismo e le prestazioni delle query, mirare a generare un numero elevato di file. Classificare in ordine di priorità la creazione del maggior numero possibile di file mantenendo al contempo una dimensione minima di 100 MB.
• Partizione: Partizionare i dati archiviando le partizioni in cartelle o nomi di file diversi se il carico di lavoro li filtra in base alle colonne di partizione.
• Valutazione: Provare a impostare ROWS_PER_BATCH in modo che corrisponda al numero di righe nei file sottostanti se si ritiene che non si ottengano le prestazioni previste.
• Dimensioni capacità: Per volumi di dati di dimensioni maggiori, prendere in considerazione la possibilità di aumentare le dimensioni dello SKU per ottenere più risorse di calcolo necessarie per supportare un numero aggiuntivo di elaborazione parallela e volumi di dati di dimensioni maggiori.

Evitare inserimenti, aggiornamenti ed eliminazioni a goccia

Per garantire un layout di file efficiente e prestazioni ottimali delle query in Fabric Data Warehouse, evitare di usare molte piccole transazioni INSERT, UPDATE e DELETE. Queste modifiche a livello di riga generano un nuovo file Parquet per ogni operazione, generando un numero elevato di file di piccole dimensioni e gruppi di righe frammentati. Questa frammentazione porta a:

• Maggiore latenza di query dovuta all'analisi inefficiente dei file.
• Costi di archiviazione e calcolo più elevati.
• Maggiore dipendenza dai processi di compattazione in background.

Approcci consigliati:

• Transazioni batch che scrivono nel Fabric Data Warehouse.
  • Ad esempio, anziché molte piccole istruzioni INSERT, organizza i dati insieme in anticipo e inseriscili in un'unica INSERT istruzione.
• Usare COPY INTO per gli inserimenti bulk ed eseguire aggiornamenti ed eliminazioni in batch quando possibile.
• Mantenere una dimensione minima importata del file di 100 MB per garantire una formazione efficiente dei gruppi di righe.
• Per altre indicazioni e procedure consigliate per l'inserimento dei dati, vedere Procedure consigliate per l'inserimento dei dati in un warehouse.

Compattazione dei dati

In Fabric Data Warehouse, la compattazione dei dati è un processo di ottimizzazione in background in Fabric Data Warehouse che unisce file Parquet di piccole dimensioni inefficienti in un minor numero di file di dimensioni maggiori. Spesso questi file vengono creati da operazioni frequenti INSERT, UPDATE o DELETE. La compattazione dei dati riduce la frammentazione dei file, migliora l'efficienza del gruppo di righe e migliora le prestazioni complessive delle query.

Anche se il motore del data warehouse Fabric risolve automaticamente la frammentazione nel tempo tramite la compattazione dei dati, le prestazioni potrebbero degradare fino al completamento del processo. La compattazione dei dati viene eseguita automaticamente senza l'intervento dell'utente per Fabric Data Warehouse.

La compattazione dei dati non si applica a Lakehouse. Per le tabelle Lakehouse a cui si accede tramite endpoint di analisi SQL, è importante seguire le procedure consigliate di Lakehouse ed eseguire manualmente il comando OPTIMIZE dopo modifiche significative ai dati per mantenere un layout di archiviazione ottimale.

V-Order in Fabric Data Warehouse

V-Order è un'ottimizzazione del tempo di scrittura nel formato di file parquet che consente letture veloci in Microsoft Fabric. V-Order in Fabric Data Warehouse migliora le prestazioni delle query applicando l'ordinamento e la compressione ai file di tabella.

Per impostazione predefinita, L'ordine virtuale è abilitato in tutti i magazzini per garantire che le operazioni di lettura, in particolare le query analitiche, siano il più veloci ed efficienti possibile.

Tuttavia, V-Order introduce un piccolo sovraccarico di inserimento, evidente nei carichi di lavoro intensivi di scrittura. Per questo motivo, la disabilitazione dell'ordine V deve essere considerata solo per i magazzini che sono rigorosamente ad alta intensità di scrittura e non usati per interrogazioni frequenti. È importante notare che una volta disabilitato l'ordine V in un magazzino, non può essere riabilitato.

Prima di decidere di disabilitare V-Order, gli utenti devono testare accuratamente le prestazioni del carico di lavoro per garantire che il compromesso sia giustificato. Un modello comune consiste nell'usare un data warehouse di staging con V-Order disabilitato per un'ingestione ad alta velocità, la trasformazione dei dati e per inserire i dati risultanti in un data warehouse abilitato per V-Order per migliorare le prestazioni di lettura. Per altre informazioni, vedere Disabilitare V-Order on Warehouse in Microsoft Fabric.

Clonare tabelle anziché copiare tabelle

I cloni di tabelle in Fabric Data Warehouse offrono un modo rapido ed efficiente per creare tabelle senza copiare dati. Con un approccio di clonazione zero-copy, vengono duplicati solo i metadati della tabella, mentre i file di dati sottostanti sono referenziati direttamente da OneLake. Ciò consente agli utenti di creare copie di tabelle coerenti e affidabili quasi immediatamente, senza il sovraccarico della duplicazione completa dei dati.

I cloni zero-copy sono ideali per scenari come sviluppo, test e backup, offrendo una soluzione a prestazioni elevate e efficiente per l'archiviazione che consente di ridurre i costi dell'infrastruttura.

• Le tabelle clonate copiano anche tutte le funzionalità di sicurezza chiave dall'origine, tra cui Row-Level Security (RLS), Column-Level Security (CLS) e Dynamic Data Masking (DDM), senza la necessità di riapplicare i criteri dopo la clonazione.
• I cloni possono essere creati a partire da un punto specifico nel tempo entro il periodo di conservazione dei dati, supportando le funzionalità di spostamento temporale.
• Le tabelle clonate esistono indipendentemente dall'origine, le modifiche apportate all'origine non influiscono sul clone e le modifiche apportate al clone non influiscono sull'origine. L'origine o il clone possono essere eliminati in modo indipendente.

Prestazioni delle query

Statistiche

Le statistiche sono oggetti persistenti che rappresentano i dati nelle colonne delle tabelle. Query Optimizer usa le statistiche per selezionare e stimare il costo di un piano di query. Fabric Data Warehouse e l'endpoint di analisi SQL di Lakehouse usano e mantengono automaticamente le statistiche degli istogrammi, le statistiche di lunghezza media delle colonne e le statistiche di cardinalità delle tabelle. Per altre informazioni, vedere Statistiche in Fabric Data Warehouse.

• I comandi CREATE STATISTICS e UPDATE STATISTICS T-SQL sono supportati per le statistiche istogramma a colonna singola. È possibile sfruttarli se è presente una finestra sufficientemente grande tra le trasformazioni della tabella e il carico di lavoro della query, ad esempio durante una finestra di manutenzione o altri tempi di inattività. In questo modo si riduce la probabilità che SELECT le query debbano prima aggiornare le statistiche.
• Cerchi di definire lo schema della tabella che mantenga la parità dei tipi di dati nei confronti comuni delle colonne. Ad esempio, se si sa che le colonne verranno spesso confrontate tra loro nella clausola WHERE o usate come predicato JOIN ... ON, assicurarsi che i tipi di dati corrispondano. Se non è possibile usare esattamente gli stessi tipi di dati, usare tipi di dati simili compatibili per la conversione implicita. Evitare conversioni esplicite di dati. Per altre informazioni si veda Conversioni di tipi di dati.

Quando si filtrano le tabelle lakehouse nella colonna timestamp prima del runtime di Apache Spark 3.5.0, le statistiche a livello di rowgroup per le colonne timestamp non vengono generate. Questa mancanza di statistiche rende difficile per i sistemi, come Fabric Warehouse, applicare l'eliminazione dei rowgroup (nota anche come scorrimento dei predicati), un'ottimizzazione delle prestazioni che ignora i rowgroup irrilevanti durante l'esecuzione della query. Senza queste statistiche, potrebbe essere necessario filtrare le query che coinvolgono colonne timestamp per analizzare più dati, causando una riduzione significativa delle prestazioni. È possibile aggiornare il runtime di Apache Spark in Fabric. Apache Spark 3.5.0 e versioni successive possono generare statistiche a livello di rowgroup per le colonne timestamp. È quindi necessario ricreare la tabella e inserire i dati per generare statistiche a livello di rowgroup.

Prestazioni della cache a freddo

La prima esecuzione di una query in Fabric Data Warehouse può essere imprevistamente più lenta rispetto alle esecuzioni successive. Questa operazione è nota come avvio a freddo, causata dall'inizializzazione del sistema o dalle attività di ridimensionamento che preparano l'ambiente per l'elaborazione.

L'avvio a freddo si verifica in genere quando:

• I dati vengono caricati da OneLake in memoria perché sono accessibili per la prima volta e non sono ancora memorizzati nella cache.
• Se si accede ai dati per la prima volta, l'esecuzione della query viene ritardata fino a quando non vengono generate automaticamente le statistiche necessarie.
• Fabric Data Warehouse sospende automaticamente i nodi dopo un certo periodo di inattività per ridurre i costi e aggiunge nodi come parte della scalabilità automatica. La ripresa o la creazione di nodi richiede in genere meno di un secondo.

Queste operazioni possono aumentare la durata della query. Gli avvii a freddo possono essere parziali. Alcuni nodi di calcolo, dati o statistiche potrebbero essere già disponibili o memorizzati nella cache, mentre la query attende che altri siano disponibili. Per ulteriori informazioni, vedere Cache nel data warehousing di Fabric.

È possibile rilevare gli effetti di avvio a freddo causati dal recupero di dati dall'archiviazione remota in memoria eseguendo una query sulla vista queryinsights.exec_requests_history . Controllare la data_scanned_remote_storage_mb colonna:

• Il valore diverso da zero in data_scanned_remote_storage_mb indica un avvio a freddo. I dati sono stati recuperati da OneLake durante l'esecuzione della query. Le visualizzazioni successive devono essere più veloci in queryinsights.exec_requests_history.
• Un valore zero in data_scanned_remote_storage_mb è lo stato perfetto in cui tutti i dati vengono memorizzati nella cache. Non sono state necessarie modifiche al nodo o dati da OneLake per gestire i risultati della query.

Query su tabelle con colonne di tipo stringa

Usare la lunghezza di colonna stringa più piccola che possa contenere i valori. Fabric Warehouse è costantemente in miglioramento; Tuttavia, è possibile che si verifichino prestazioni non ottimali se si usano tipi di dati stringa di grandi dimensioni, in particolare oggetti di grandi dimensioni (LOB). Ad esempio, per il tipo di dati di una customer_name colonna, considerare i requisiti aziendali e i dati previsti e usare una lunghezza n appropriata quando si dichiara varchar(n), ad esempio varchar(100), anziché varchar(8000) o varchar(max). Le statistiche e la stima dei costi delle query sono più accurate quando la lunghezza del tipo di dati è più precisa per i dati effettivi.

• In T-SQL di Fabric Data Warehouse vedere le linee guida per la scelta della lunghezza appropriata per i tipi di dati stringa.
• Le colonne stringa della tabella Lakehouse senza lunghezza definita in Spark vengono riconosciute da Fabric Warehouse come varchar(8000). Per ottenere prestazioni ottimali, usare l'istruzione in SparkSQL per definire la CREATE TABLE colonna stringa come varchar(n), dove n è la lunghezza massima della colonna che può contenere valori.

Transazioni e concorrenza

Fabric Data Warehouse è basato su un'architettura moderna nativa del cloud che combina l'integrità transazionale, l'isolamento degli snapshot e il calcolo distribuito per offrire concorrenza elevata e coerenza su larga scala. Per altre informazioni, vedere Transazioni nelle tabelle warehouse.

Fabric Data Warehouse supporta transazioni conformi a ACID usando l'isolamento dello snapshot. Questo significa che:

• Le operazioni di lettura e scrittura possono essere raggruppate in una singola transazione usando T-SQL standard (BEGIN TRANSACTION, COMMIT, ROLLBACK)
• Semantica tutto-o-niente: se una transazione si estende su più tabelle e un'operazione ha esito negativo, viene annullata l'intera transazione.
• Coerenza di lettura: SELECT le query all'interno di una transazione visualizzano uno snapshot coerente dei dati, non influenzato dalle scritture simultanee.

Supporto delle transazioni di Fabric Warehouse:

• DDL (Data Definition Language) all'interno delle transazioni: È possibile includere CREATE TABLE all'interno di un blocco di transazioni.
• Transazioni tra database: Supportato all'interno della stessa area di lavoro, incluse le letture dagli endpoint di analisi SQL.
• Rollback dei dati basato su file Parquet: Poiché Fabric Data Warehouse archivia i dati in file Parquet non modificabili, i rollback sono veloci. I rollback ripristinano semplicemente le versioni precedenti dei file.
• Compattazione automatica dei dati e checkpoint:la compattazione dei dati ottimizza le prestazioni di archiviazione e lettura unendo piccoli file Parquet e rimuovendo righe eliminate logicamente.
• Checkpoint automatico: Ogni operazione di scrittura (INSERT, UPDATE, DELETE) aggiunge un nuovo file di log JSON al log delle transazioni Delta Lake. Nel corso del tempo, questo può comportare centinaia o migliaia di file di log, in particolare in scenari di inserimento in streaming o ad alta frequenza. Il checkpoint automatico migliora l'efficienza di lettura dei metadati riepilogando i log delle transazioni in un singolo file di checkpoint. Senza checkpoint, ogni lettura deve analizzare l'intera cronologia del log delle transazioni. Con il checkpointing, vengono letti solo il file del checkpoint più recente e i log successivi. Ciò riduce drasticamente l'analisi di I/O e metadati, soprattutto per tabelle aggiornate di grandi dimensioni o di frequente.

La compattazione e il checkpoint sono fondamentali per l'integrità delle tabelle, in particolare in ambienti a esecuzione prolungata o a concorrenza elevata.

Controllo e isolamento della concorrenza

Fabric Data Warehouse usa esclusivamente l'isolamento dello snapshot. I tentativi di modificare il livello di isolamento tramite T-SQL vengono ignorati.

Procedure consigliate con le transazioni

• Usare transazioni esplicite in modo saggio. Sempre COMMIT o ROLLBACK. Non lasciare aperte le transazioni.
  • Mantenere le transazioni di breve durata. Evitare transazioni a esecuzione prolungata che contengono blocchi inutilmente, soprattutto per le transazioni esplicite contenenti DDL. Ciò può causare conflitti con SELECT le istruzioni nelle viste del catalogo di sistema (ad esempio sys.tables) e può causare problemi con il portale di Fabric che si basa sulle viste del catalogo di sistema.
• Aggiungere la logica di riprovare con ritardo nelle pipeline o nelle app per gestire i conflitti transitori.
  • Usare il backoff esponenziale per evitare tempeste di ritentativi che peggiorano le interruzioni temporanee della rete.
  • Per altre informazioni, vedere Modello di ripetizione dei tentativi.
• Monitorare i blocchi e i conflitti nel magazzino.
  • Usare sys.dm_tran_locks per controllare i blocchi correnti.

Ridurre le dimensioni dei set di dati restituiti

Le query con dimensioni elevate dei dati nell'esecuzione intermedia delle query o nel risultato finale della query potrebbero riscontrare un problema di prestazioni delle query maggiore. Per ridurre le dimensioni del set di dati restituito, prendere in considerazione le strategie seguenti:

• Partizionare tabelle di grandi dimensioni in Lakehouse.
• Limitare il numero di colonne restituite. SELECT * può essere costoso.
• Limitare il numero di righe restituite. Esegui il filtraggio dei dati nel magazzino il più possibile, non nelle applicazioni client.
  • Provare a filtrare prima di creare un join per ridurre il set di dati all'inizio dell'esecuzione della query.
  • Filtrare colonne a bassa cardinalità per ridurre il set di dati di grandi dimensioni prima dei JOIN.
  • Le colonne con cardinalità elevata sono ideali per l'applicazione di filtri e JOIN. Questi vengono spesso usati nelle WHERE clausole e traggono vantaggio dall'applicazione del predicato in fase precedente nell'esecuzione della query per escludere i dati.
• In Fabric Data Warehouse, dato che i vincoli di chiave primaria e chiave univoca non vengono applicati, le colonne con questi vincoli non sono necessariamente buone candidate per i JOIN.

Piani delle query e suggerimenti delle query

In Fabric Data Warehouse Query Optimizer genera un piano di esecuzione di query per determinare il modo più efficiente per eseguire una query SQL. Gli utenti avanzati potrebbero prendere in considerazione l'analisi dei problemi di prestazioni delle query utilizzando il piano di esecuzione della query o aggiungendo suggerimenti per la query.

• Gli utenti possono usare SHOWPLAN_XML in SQL Server Management Studio per visualizzare il piano senza eseguire la query.
• È possibile aggiungere hint di query facoltativi a un'istruzione SQL per fornire istruzioni aggiuntive all'ottimizzatore di query prima della generazione del piano. L'aggiunta di hint per la query richiede una conoscenza avanzata dei carichi di lavoro di query, pertanto viene in genere usata dopo l'implementazione di altre procedure consigliate, ma il problema persiste.

Operazioni non scalabili

Fabric Data Warehouse si basa su un'architettura MPP (Massively Parallel Processing), in cui le query vengono eseguite in più nodi di calcolo. In alcuni scenari, l'esecuzione a nodo singolo è giustificata.

• L'intera esecuzione del piano di query richiede un solo nodo di calcolo.
• Un sottoalbero di piano può rientrare in un nodo di calcolo.
• L'intera query o parte della query deve essere eseguita in un singolo nodo per soddisfare la semantica della query. Ad esempio, operazioni TOP, ordinamento globale, query che richiedono di ordinare i risultati delle esecuzioni parallele per produrre un singolo risultato o unire i risultati per la fase finale.

In questi casi, gli utenti possono ricevere un messaggio di avviso "Viene rilevata una o più operazioni non scalabili" e la query potrebbe essere eseguita lentamente o non riuscire dopo un'esecuzione prolungata.

• Valutare la possibilità di ridurre le dimensioni del set di dati filtrato della query.
• Se la semantica della query non richiede l'esecuzione a nodo singolo, provare a forzare un piano di query distribuito con FORCE DISTRIBUTED PLAN, ad esempio OPTION (FORCE DISTRIBUTED PLAN);.

Eseguire query sull'endpoint di analisi SQL

È possibile usare l'endpoint di analisi SQL per eseguire query sulle tabelle Lakehouse popolate con Spark SQL, senza copiare o inserire dati nel warehouse.

Le procedure consigliate seguenti si applicano all'esecuzione di query sui dati del warehouse in Lakehouse tramite l'endpoint di analisi SQL. Per altre informazioni sulle prestazioni degli endpoint di analisi SQL, vedere Considerazioni sulle prestazioni degli endpoint di analisi SQL.

Eseguire regolarmente la manutenzione delle tabelle Lakehouse.

In Microsoft Fabric, il Magazzino ottimizza automaticamente i layout dei dati ed esegue la gestione dei rifiuti e la compattazione. Per una Lakehouse si ha un maggiore controllo sulla manutenzione delle tabelle. L'ottimizzazione e il vuoto delle tabelle sono necessari e possono ridurre significativamente il tempo di analisi necessario per set di dati di grandi dimensioni. La manutenzione delle tabelle nel Lakehouse si estende anche alle scorciatoie e può aiutare a migliorare significativamente le prestazioni lì.

Ottimizzare le tabelle del lakehouse o le scorciatoie con molti piccoli file.

La presenza di molti file di piccole dimensioni comporta un sovraccarico per la lettura dei metadati dei file. Usare il comando OPTIMIZE nel portale di Fabric o in un notebook per combinare file di piccole dimensioni in file di dimensioni maggiori. Ripetere questo processo quando il numero di file cambia significativamente.

Per ottimizzare una tabella in un Lakehouse in Fabric, aprire il Lakehouse nel portale di Fabric. In Esplora risorse fare clic con il pulsante destro del mouse sulla tabella, selezionare Manutenzione. Scegliere le opzioni nella pagina Esegui comandi di manutenzione , quindi selezionare Esegui adesso.

Eseguire query sulle tabelle lakehouse o sui collegamenti rapidi che si trovano nella stessa area

Fabric utilizza le risorse di calcolo dove si trova la capacità del Fabric. L'esecuzione di query sui dati, ad esempio in Azure Data Lake Storage o in OneLake, in un'altra area comporta un sovraccarico delle prestazioni a causa della latenza di rete. Assicurarsi che i dati si trovano nella stessa area. A seconda dei requisiti di prestazioni, è consigliabile mantenere solo tabelle di piccole dimensioni come le tabelle delle dimensioni in un'area remota.

Filtrare tabelle e collegamenti lakehouse sulle stesse colonne

Se spesso si filtrano le righe della tabella in colonne specifiche, prendere in considerazione il partizionamento della tabella.

Il partizionamento funziona bene per colonne a bassa cardinalità o con cardinalità prevedibile, come anni o date. Per ulteriori informazioni, vedere Esercitazione su Lakehouse - Preparare e trasformare i dati Lakehouse e Caricare i dati in Lakehouse usando la partizione.

Il clustering è ideale per le colonne a selezione elevata. Se sono presenti altre colonne che usi spesso per filtrare, diverse dalle colonne di partizionamento, prendi in considerazione la possibilità di raggruppare la tabella utilizzando optimize con la sintassi ZORDER BY Spark SQL. Per altre informazioni, vedere Ottimizzazione della tabella Delta Lake.

Visualizzazioni dei metadati delle query

• Cronologia dell'esecuzione delle query (30 giorni)

  • queryinsights.exec_requests_history
  • queryinsights.exec_sessions_history

• Dati analitici aggregati

  • queryinsights.long_running_queries
  • queryinsights.frequently_run_queries

Per ulteriori informazioni sulle queryinsights viste, consultare Informazioni dettagliate sulle query nel data warehousing di Fabric.

• Le DMV relative al ciclo di vita delle query
  • sys.dm_exec_connections
  • sys.dm_exec_sessions
  • sys.dm_exec_requests

Per altre informazioni sulle DMV del ciclo di vita delle query, vedere Monitorare connessioni, sessioni e richieste tramite DMV.

Contenuto correlato

• Superficie di attacco T-SQL
• Monitorare il data warehouse di Fabric
• Cos’è l'app Microsoft Fabric Capacity Metrics?