Condividi tramite

Informazioni sull'archiviazione per i modelli semantici Direct Lake

  • Articolo

Questo articolo presenta concetti relativi all'archiviazione di Direct Lake. Descrive le tabelle Delta e i file Parquet. Descrive anche come ottimizzare le tabelle Delta per i modelli semantici Direct Lake e come gestirle per offrire prestazioni di query affidabili e veloci.

Tabelle delta

Le tabelle Delta esistono in OneLake. Organizzano i dati basati su file in righe e colonne e sono disponibili per i motori di calcolo di Microsoft Fabric, ad esempio i notebook , Kusto , e il lakehouse e il warehouse . È possibile eseguire query su tabelle Delta usando DATA Analysis Expressions (DAX), MDX (Multidimensional Expressions), T-SQL (Transact-SQL), Spark SQL e anche Python.

Nota

Delta o Delta Lakeè un formato di archiviazione open source. Ciò significa che Fabric può anche eseguire query su tabelle Delta create da altri strumenti e fornitori.

Le tabelle Delta archiviano i dati in file Parquet, in genere archiviati in una lakehouse usata da un modello semantico Direct Lake per caricare i dati. Tuttavia, i file Parquet possono anche essere archiviati esternamente. È possibile fare riferimento ai file Parquet esterni usando un collegamento OneLake, che punta a un percorso di archiviazione specifico, ad esempio Azure Data Lake Storage (ADLS) Gen2, account di archiviazione Amazon S3 o Dataverse. In quasi tutti i casi, i motori di calcolo accedono ai file Parquet eseguendo query sulle tabelle Delta. Tuttavia, in genere, modelli semantici Direct Lake caricano dati delle colonne direttamente da file Parquet ottimizzati in OneLake utilizzando un processo noto come transcodifica .

Controllo delle versioni dei dati

Le tabelle Delta includono uno o più file Parquet. Questi file sono accompagnati da un set di file di collegamento basati su JSON, che tengono traccia dell'ordine e della natura di ogni file Parquet associato a una tabella Delta.

È importante capire che i file Parquet sottostanti hanno una natura incrementale. Ecco perché il nome Delta come riferimento alla modifica incrementale dei dati. Ogni volta che viene eseguita un'operazione di scrittura in una tabella Delta, ad esempio quando vengono inseriti, aggiornati o eliminati dati, vengono creati nuovi file Parquet che rappresentano le modifiche dei dati come versione . I file Parquet sono quindi non modificabili, ovvero non vengono mai modificati. È quindi possibile duplicare i dati più volte in un set di file Parquet per una tabella Delta. Il framework Delta si basa sui file di collegamento per determinare quali file Parquet fisici sono necessari per produrre il risultato della query corretto.

Si consideri un semplice esempio di una tabella Delta usata in questo articolo per illustrare diverse operazioni di modifica dei dati. La tabella contiene due colonne e archivia tre righe.

ProductID StockOnHand
Un 1
B 2
C 3

I dati della tabella Delta vengono archiviati in un singolo file Parquet che contiene tutti i dati ed è presente un singolo file di collegamento che contiene i metadati relativi all'inserimento dei dati (accodato).

  • File Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • File di collegamento 1:
    • Contiene il timestamp quando è stato creato Parquet file 1 e registra i dati accodati.

Operazioni di inserimento

Considera cosa succede quando viene eseguita un'operazione di inserimento: viene inserita una nuova riga per il prodotto C con una giacenza di 4. Questa operazione comporta la creazione di un nuovo file Parquet e di un file di collegamento, quindi sono presenti due file Parquet e due file di collegamento.

  • File Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • File Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • File di collegamento 1:
    • Contiene il timestamp quando è stato creato Parquet file 1 e registra i dati accodati.
  • File di collegamento 2:
    • Contiene il timestamp quando è stato creato Parquet file 2 e registra i dati accodati.

A questo punto, una query della tabella Delta restituisce il risultato seguente. Non importa che il risultato provenga da più file Parquet.

ProductID StockOnHand
Un 1
B 2
C 3
D 4

Ogni operazione di inserimento successiva crea nuovi file Parquet e file di collegamento. Ciò significa che il numero di file Parquet e i file di collegamento aumentano con ogni operazione di inserimento.

Operazioni di aggiornamento

Si consideri ora cosa accade quando si verifica un'operazione di aggiornamento: la riga per il prodotto D ha il relativo valore delle scorte a magazzino modificato in 10. Questa operazione comporta la creazione di un nuovo file Parquet e di un file di collegamento, quindi sono ora presenti tre file Parquet e tre file di collegamento.

  • File Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • File Parquet 2
    • ProductID: D
    • StockOnHand: 4
  • File Parquet 3:
    • ProductID: C
    • StockOnHand: 10
  • File di collegamento 1:
    • Contiene il timestamp quando è stato creato Parquet file 1 e registra i dati accodati.
  • File di collegamento 2:
    • Contiene il timestamp quando è stato creato Parquet file 2 e registra i dati accodati.
  • File di collegamento 3:
    • Contiene il timestamp quando è stato creato Parquet file 3 e registra i dati aggiornati.

A questo punto, una query della tabella Delta restituisce il risultato seguente.

ProductID StockOnHand
Un 1
B 2
C 10
D 4

I dati per il prodotto C sono ora presenti in più file Parquet. Tuttavia, le query sulla tabella Delta combinano i file di collegamento per determinare quali dati devono essere usati per fornire il risultato corretto.

Operazioni di eliminazione

Si consideri ora cosa accade quando si verifica un'operazione di eliminazione: la riga per il prodotto B viene eliminata. Questa operazione comporta un nuovo file Parquet e un file di collegamento, quindi sono ora presenti quattro file Parquet e quattro file di collegamento.

  • File Parquet 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • File Parquet 2:
    • ProductID: D
    • StockOnHand: 4
  • File Parquet 3:
    • ProductID: C
    • StockOnHand: 10
  • File Parquet 4
    • ProductID: A, C, D
    • StockOnHand: 1, 10, 4
  • File di collegamento 1:
    • Contiene il timestamp quando è stato creato Parquet file 1 e registra i dati accodati.
  • File di collegamento 2:
    • Contiene il timestamp quando è stato creato Parquet file 2 e registra i dati accodati.
  • File di collegamento 3:
    • Contiene il timestamp quando è stato creato Parquet file 3 e registra i dati aggiornati.
  • File di collegamento 4:
    • Contiene il timestamp quando è stato creato Parquet file 4 e registra che i dati sono stati eliminati.

Si noti che Parquet file 4 non contiene più dati per il prodotto B, ma contiene dati per tutte le altre righe della tabella.

A questo punto, una query della tabella Delta restituisce il risultato seguente.

ProductID StockOnHand
Un 1
C 10
D 4

Nota

Questo esempio è semplice perché prevede una tabella di piccole dimensioni, solo alcune operazioni e solo modifiche minime. Tabelle di grandi dimensioni che riscontrano molte operazioni di scrittura e che contengono molte righe di dati genereranno più file Parquet per versione.

Importante

A seconda del modo in cui si definiscono le tabelle Delta e la frequenza delle operazioni di modifica dei dati, potrebbero verificarsi molti file Parquet. Tenere presente che ogni licenza di capacità dell'infrastruttura ha guardrail. Se il numero di file Parquet per una tabella Delta supera il limite per lo SKU, le query passano a DirectQuery, il che potrebbe comportare un rallentamento delle prestazioni delle query.

Per gestire il numero di file Parquet, vedere manutenzione della tabella Delta più avanti in questo articolo.

Viaggio nel tempo Delta

I file di collegamento consentono di eseguire query sui dati a partire da un punto precedente nel tempo. Questa funzionalità è nota come Delta viaggio nel tempo. Il punto precedente nel tempo potrebbe essere un timestamp o una versione.

Si considerino gli esempi di query seguenti.

SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;

Mancia

È anche possibile eseguire query su una tabella usando la sintassi abbreviata @ per specificare il timestamp o la versione come parte del nome della tabella. Il timestamp deve essere in formato yyyyMMddHHmmssSSS. È possibile specificare una versione dopo @ anteponendo un v alla versione.

Ecco gli esempi di query precedenti riscritti con sintassi abbreviata.

SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;

Importante

Le versioni delle tabelle accessibili con il tempo di spostamento sono determinate da una combinazione della soglia di conservazione per i file di log delle transazioni e dalla frequenza e dalla conservazione specificata per le operazioni VACUUM (descritta più avanti nella sezione relativa alla manutenzione della tabella Delta). Se si esegue VACUUM ogni giorno con i valori predefiniti, saranno disponibili sette giorni di dati per il viaggio nel tempo.

Inquadratura

Frame è un'operazione Direct Lake che imposta la versione di una tabella Delta che deve essere usata per caricare i dati in una colonna del modello semantico. Altrettanto importante, la versione determina anche cosa deve essere escluso quando vengono caricati i dati.

Un'operazione di frame contrassegna il timestamp/versione di ogni tabella Delta nelle tabelle del modello semantico. Da questo punto, quando il modello semantico deve caricare dati da una tabella Delta, viene usato il timestamp o la versione associata all'operazione di frame più recente per determinare quali dati caricare. Eventuali modifiche ai dati successive che si verificano per la tabella Delta dopo l'ultima operazione di frame vengono ignorate (fino alla successiva operazione di frame).

Importante

Poiché un modello semantico inquadrato fa riferimento a una determinata versione della tabella Delta, l'origine deve assicurarsi di mantenere quella versione della tabella Delta fino al completamento dell'inquadramento di una nuova versione. Altrimenti, gli utenti riscontreranno errori quando i file della tabella Delta devono essere accessibili dal modello e sono stati ripuliti o altrimenti eliminati dal carico di lavoro del produttore.

Per ulteriori informazioni sull'inquadratura, vedere Panoramica di Direct Lake.

Partizionamento delle tabelle

Le tabelle delta possono essere partizionate in modo che un subset di righe venga archiviato insieme in un singolo set di file Parquet. Le partizioni possono velocizzare le query e le operazioni di scrittura.

Si consideri una tabella Delta con un miliardo di righe di dati di vendita per un periodo di due anni. Sebbene sia possibile archiviare tutti i dati in un singolo set di file Parquet, per questo volume di dati non è ottimale per le operazioni di lettura e scrittura. Al contrario, le prestazioni possono essere migliorate distribuendo le miliardi di righe di dati in più serie di file Parquet.

È necessario definire chiave di partizione durante la configurazione del partizionamento delle tabelle. La chiave di partizione determina le righe da archiviare in quale serie. Per le tabelle Delta, la chiave di partizione può essere definita in base ai valori distinti di una colonna specificata (o colonne), ad esempio una colonna mese/anno di una tabella date. In questo caso, due anni di dati verrebbero distribuiti tra 24 partizioni (2 anni x 12 mesi).

I motori di calcolo fabric non sono a conoscenza delle partizioni di tabella. Quando inseriscono nuovi valori di chiave di partizione, le nuove partizioni vengono create automaticamente. In OneLake è disponibile una sottocartella per ogni valore univoco della chiave di partizione e ogni sottocartella archivia il proprio set di file Parquet e i file di collegamento. Almeno un file Parquet e un file di collegamento devono esistere, ma il numero effettivo di file in ogni sottocartella può variare. Man mano che vengono eseguite operazioni di modifica dei dati, ogni partizione mantiene il proprio set di file Parquet e i file di collegamento per tenere traccia di cosa restituire per un timestamp o una versione specifica.

Se una query di una tabella Delta partizionata viene filtrata in base ai soli tre mesi più recenti di dati di vendita, è possibile identificare rapidamente il subset di file Parquet e i file di collegamento a cui è necessario accedere. Ciò consente quindi di ignorare completamente molti file Parquet, ottenendo prestazioni di lettura migliori.

Tuttavia, le query che non filtrano sulla chiave di partizione potrebbero non essere sempre migliori. Questo può essere il caso quando una tabella Delta archivia tutti i dati in un singolo grande set di file Parquet e si verifica una frammentazione di file o di gruppi di righe. Sebbene sia possibile parallelizzare il recupero dei dati da più file Parquet in più nodi del cluster, molti file Parquet di piccole dimensioni possono influire negativamente sulle operazioni di I/O dei file e pertanto sulle prestazioni delle query. Per questo motivo, è consigliabile evitare il partizionamento delle tabelle Delta nella maggior parte dei casi, a meno che le operazioni di scrittura, le operazioni di estrazione, trasformazione e caricamento (ETL) non traggano chiaramente vantaggio.

Il partizionamento offre vantaggi anche per le operazioni di inserimento, aggiornamento ed eliminazione, perché l'attività dei file avviene solo nelle sottocartelle corrispondenti alla chiave di partizione delle righe modificate o eliminate. Ad esempio, se un batch di dati viene inserito in una tabella Delta partizionata, i dati vengono valutati per determinare quali valori di chiave di partizione esistono nel batch. I dati vengono quindi indirizzati solo alle cartelle pertinenti per le partizioni.

Comprendere in che modo le tabelle Delta usano le partizioni consentono di progettare scenari ETL ottimali che riducono le operazioni di scrittura che devono essere eseguite durante l'aggiornamento di tabelle Delta di grandi dimensioni. Le prestazioni di scrittura migliorano riducendo il numero e le dimensioni dei nuovi file Parquet che devono essere creati. Per una tabella Delta di grandi dimensioni partizionata per mese/anno, come descritto nell'esempio precedente, i nuovi dati aggiungono solo nuovi file Parquet alla partizione più recente. Le sottocartelle dei mesi di calendario precedenti rimangono intatte. Se è necessario modificare i dati dei mesi di calendario precedenti, solo le cartelle di partizione pertinenti ricevono nuove partizioni e file di collegamento.

Importante

Se lo scopo principale di una tabella Delta è quello di fungere da origine dati per i modelli semantici (e secondariamente, altri carichi di lavoro di query), in genere è preferibile evitare il partizionamento in modo da ottimizzare il carico di colonne in memoria.

Per i modelli semantici Direct Lake o l'endpoint di analisi SQL , il modo migliore per ottimizzare le partizioni di tabella Delta consiste nell'consentire a Fabric di gestire automaticamente i file Parquet per ogni versione di una tabella Delta. Lasciare la gestione a Fabric dovrebbe comportare prestazioni elevate delle query tramite parallelizzazione, ma potrebbe non fornire necessariamente le migliori prestazioni di scrittura.

Se è necessario ottimizzare le operazioni di scrittura, è consigliabile usare le partizioni per ottimizzare le operazioni di scrittura nelle tabelle Delta in base alla chiave di partizione. Tuttavia, tenere presente che un partizionamento eccessivo di una tabella Delta può influire negativamente sulle prestazioni di lettura. Per questo motivo, è consigliabile testare attentamente le prestazioni di lettura e scrittura, creando probabilmente più copie della stessa tabella Delta con configurazioni diverse per confrontare i tempi.

Avvertimento

Se si esegue la partizione in una colonna con cardinalità elevata, può comportare un numero eccessivo di file Parquet. Tenere presente che ogni licenza di capacità di Fabric ha limiti. Se il numero di file Parquet per una tabella Delta supera il limite per lo SKU, le query fallback a DirectQuery, con conseguente rallentamento delle prestazioni delle query.

File Parquet

L'archiviazione sottostante per una tabella Delta è costituita da uno o più file Parquet. Il formato di file Parquet viene in genere usato per applicazioni di write-once e read-many. I nuovi file Parquet vengono creati ogni volta che i dati in una tabella Delta vengono modificati, indipendentemente da un'operazione di inserimento, aggiornamento o eliminazione.

Nota

È possibile accedere ai file Parquet associati alle tabelle Delta usando uno strumento, ad esempio OneLake File Explorer. I file possono essere scaricati, copiati o spostati in altre destinazioni con la facilità di spostamento di qualsiasi altro file. Tuttavia, si tratta della combinazione di file Parquet e dei file di collegamento basati su JSON che consentono ai motori di calcolo di eseguire query sui file come tabella Delta.

Formato di file Parquet

Il formato interno di un file Parquet è diverso da altri formati di archiviazione dati comuni, ad esempio CSV, TSV, XMLA e JSON. Questi formati organizzano i dati in base alle righe, mentre Parquet organizza i dati in base alle colonne. Inoltre, il formato di file Parquet è diverso da questi formati perché organizza le righe di dati in uno o più gruppi di righe .

La struttura dei dati interna di un modello semantico di Power BI è basata su colonne, il che significa che i file Parquet condividono molto in comune con Power BI. Questa somiglianza significa che un modello semantico Direct Lake può caricare in modo efficiente i dati dai file Parquet direttamente in memoria. Infatti, volumi di dati molto grandi possono essere caricati in secondi. Confrontare questa funzionalità con l'aggiornamento di un modello semantico di importazione che deve recuperare blocchi o dati di origine, quindi elaborare, codificare, archiviare e quindi caricarlo in memoria. Un'operazione di aggiornamento del modello semantico di importazione può anche utilizzare quantità significative di calcolo (memoria e CPU) e richiedere molto tempo per il completamento. Tuttavia, con le tabelle Delta, la maggior parte delle operazioni necessarie per preparare i dati adatti per il caricamento diretto in un modello semantico avviene quando viene generato il file Parquet.

In che modo i file Parquet archiviano i dati

Si consideri il set di dati di esempio seguente.

Data ID prodotto StockOnHand
16-09-2024 Un 10
2024-09-16 B 11
2024-09-17 Un 13
…

Se archiviato in formato di file Parquet, concettualmente, questo set di dati potrebbe essere simile al testo seguente.

Header:
RowGroup1:
    Date: 2024-09-16, 2024-09-16, 2024-09-17…
    ProductID: A, B, A…
    StockOnHand: 10, 11, 13…
RowGroup2:
    …
Footer:

I dati vengono compressi sostituendo le chiavi del dizionario per i valori comuni e applicando codifica a lunghezza di esecuzione (RLE). RLE cerca di comprimere una serie di stessi valori in una rappresentazione più piccola. Nell'esempio seguente viene creata una mappatura in un dizionario di chiavi numeriche ai valori all'inizio, e i valori di chiave più piccoli vengono utilizzati invece dei valori di dati.

Header:
    Dictionary: [
        (1, 2024-09-16), (2, 2024-09-17),
        (3, A), (4, B),
        (5, 10), (6, 11), (7, 13)
        …
    ]
RowGroup1:
    Date: 1, 1, 2…
    ProductID: 3, 4, 3…
    StockOnHand: 5, 6, 7…
Footer:

Quando il modello semantico Direct Lake richiede dati per calcolare la somma della colonna StockOnHand raggruppata per ProductID, sono necessari solo il dizionario e i dati associati alle due colonne. Nei file di grandi dimensioni che contengono molte colonne, è possibile ignorare parti sostanziali del file Parquet per velocizzare il processo di lettura.

Nota

Il contenuto di un file Parquet non è leggibile e quindi non è adatto per l'apertura in un editor di testo. Esistono tuttavia molti strumenti open source che possono aprire e rivelare il contenuto di un file Parquet. Questi strumenti consentono anche di esaminare i metadati, ad esempio il numero di righe e gruppi di righe contenuti in un file.

Ordine V

Fabric supporta un'ottimizzazione aggiuntiva denominata V-Order. V-Order è un'ottimizzazione in fase di scrittura nel formato di file Parquet. Dopo l'applicazione dell'ordine V, viene restituito un file più piccolo e quindi più veloce da leggere. Questa ottimizzazione è particolarmente rilevante per un modello semantico Direct Lake perché prepara i dati per il caricamento rapido in memoria e quindi rende meno richieste sulle risorse di capacità. Consente inoltre di ottenere prestazioni di query più veloci perché è necessario analizzare meno memoria.

Le tabelle Delta create e caricate da elementi di Fabric, come le pipeline di dati , i flussi di dati e i notebook , applicano automaticamente il V-Order. Tuttavia, i file Parquet caricati in un'infrastruttura lakehouse, oppure a cui fa riferimento un collegamento , potrebbero non avere questa ottimizzazione applicata. Anche se i file Parquet non ottimizzati possono ancora essere letti, è probabile che le prestazioni di lettura non siano veloci quanto un file Parquet equivalente a cui è stato applicato l'ordine V.

Nota

I file Parquet a cui è stato applicato il V-Order sono ancora conformi al formato di file Parquet open source. Pertanto, questi strumenti possono essere letti da strumenti non Fabric.

Per ulteriori informazioni, vedere l'ottimizzazione della tabella Delta Lake e il V-Order.

Ottimizzazione della tabella Delta

In questa sezione vengono descritti vari argomenti per l'ottimizzazione delle tabelle Delta per i modelli semantici.

Volume di dati

Anche se le tabelle Delta possono crescere fino ad archiviare volumi estremamente grandi di dati, le barriere di capacità di Fabric impongono limiti ai modelli semantici che le interrogano. Quando questi limiti vengono superati, le query passano a DirectQuery, con conseguente rallentamento delle prestazioni delle query.

È pertanto consigliabile limitare il numero di righe di una tabella dei fatti di grandi dimensioni aumentandone la granularità (archiviare dati riepilogati), riducendo la dimensionalità o archiviando meno cronologia.

Assicurarsi inoltre che l'ordine V venga applicato, poiché risulta in un file più piccolo e quindi più veloce da leggere.

Tipo di dati della colonna

Cercare di ridurre la cardinalità (il numero di valori univoci) in ogni colonna di ogni tabella Delta. Ciò è dovuto al fatto che tutte le colonne vengono compresse e archiviate usando la codifica hash . La codifica hash richiede l'ottimizzazione dell'ordine V per assegnare un identificatore numerico a ogni valore univoco contenuto nella colonna. Si tratta dell'identificatore numerico archiviato, che richiede una ricerca hash durante l'archiviazione e l'esecuzione di query.

Quando si usano tipi di dati numerici approssimativi (ad esempio float e real), prendere in considerazione l'arrotondamento dei valori e l'uso di una precisione inferiore.

Colonne non necessarie

Come per qualsiasi tabella di dati, le tabelle Delta devono archiviare solo le colonne necessarie. Nel contesto di questo articolo, ciò significa che è richiesto dal modello semantico, anche se potrebbero esserci altri carichi di lavoro analitici che possono eseguire query sulle tabelle Delta.

Le tabelle Delta devono includere colonne richieste dal modello semantico per il filtro, il raggruppamento, l'ordinamento e il riepilogo, oltre alle colonne che supportano le relazioni tra modelli. Anche se le colonne non necessarie non influiscono sulle prestazioni delle query del modello semantico (perché non verranno caricate in memoria), comportano dimensioni di archiviazione maggiori e quindi richiedono più risorse di calcolo per caricare e gestire.

Poiché i modelli semantici Direct Lake non supportano le colonne calcolate, è necessario materializzare tali colonne nelle tabelle Delta. Si noti che questo approccio progettuale è un anti-modello per i modelli semantici Import e DirectQuery. Ad esempio, se sono presenti FirstName e LastName colonne ed è necessaria una colonna FullName, materializzare i valori per questa colonna durante l'inserimento di righe nella tabella Delta.

Si consideri che alcuni riepiloghi semantici del modello possono dipendere da più di una colonna. Ad esempio, per calcolare le vendite, la misura nel modello somma il prodotto di due colonne: Quantity e Price. Se nessuna di queste colonne viene usata in modo indipendente, sarebbe più efficiente materializzare il calcolo delle vendite come una singola colonna rispetto all'archiviazione dei valori dei relativi componenti in colonne separate.

Dimensioni del gruppo di righe

Internamente, un file Parquet organizza le righe di dati in più gruppi di righe all'interno di ogni file. Ad esempio, un file Parquet contenente 30.000 righe potrebbe suddividerli in tre gruppi di righe, ognuno con 10.000 righe.

Il numero di righe in un gruppo di righe influisce sulla velocità di lettura dei dati da parte di Direct Lake. È probabile che un numero maggiore di gruppi di righe con meno righe influisca negativamente sul caricamento dei dati delle colonne in un modello semantico a causa di un numero eccessivo di operazioni di I/O.

In genere, non è consigliabile modificare le dimensioni predefinite del gruppo di righe. Tuttavia, è possibile modificare le dimensioni del gruppo di righe per le tabelle Delta di grandi dimensioni. Assicurarsi di testare attentamente le prestazioni di lettura e scrittura, ad esempio creando più copie delle stesse tabelle Delta con configurazioni diverse per confrontare i tempi.

Importante

Tenere presente che ogni licenza di capacità di Fabric ha protezioni. Se il numero di gruppi di righe per una tabella Delta supera il limite per lo SKU, le query fallback a DirectQuery, con conseguente rallentamento delle prestazioni delle query.

Manutenzione delle tabelle Delta

Nel corso del tempo, man mano che vengono eseguite operazioni di scrittura, le versioni delle tabelle Delta si accumulano. Alla fine, si potrebbe raggiungere un punto in cui un impatto negativo sulle prestazioni di lettura diventa evidente. Peggio ancora, se il numero di file Parquet per tabella, i gruppi di righe per tabella o le righe per tabella superano i vincoli della capacità, le query si ripiegano su DirectQuery, il che potrebbe comportare un rallentamento delle prestazioni delle query. È quindi importante mantenere regolarmente le tabelle Delta.

OTTIMIZZARE

È possibile usare OPTIMIZE per ottimizzare una tabella Delta per unire file più piccoli in quelli più grandi. È anche possibile impostare la clausola WHERE su come destinazione solo un subset filtrato di righe che corrispondono a un predicato di partizione specificato. Sono supportati solo i filtri che includono chiavi di partizione. Il comando OPTIMIZE può anche applicare V-Order per compattare e riscrivere i file Parquet.

È consigliabile eseguire questo comando su tabelle Delta aggiornate di frequente regolarmente, ad esempio ogni giorno al termine del processo ETL. Bilanciare il compromesso tra prestazioni migliori delle query e il costo dell'utilizzo delle risorse necessario per ottimizzare la tabella.

VUOTO

È possibile usare VACUUM per rimuovere i file a cui non si fa più riferimento e/o che sono precedenti a una soglia di conservazione impostata. Prestare attenzione a impostare un periodo di conservazione appropriato; in caso contrario, si potrebbe perdere la possibilità di tempo di viaggio a una versione precedente rispetto al frame stampato in tabelle del modello semantico.

Importante

Poiché un modello semantico incorniciato fa riferimento a una versione specifica della tabella Delta, l'origine deve assicurarsi di mantenere quella versione della tabella Delta fino al completamento dello framing di una nuova versione. Altrimenti, gli utenti riscontreranno errori quando i file della tabella Delta devono essere accessibili dal modello e sono stati svuotati o altrimenti eliminati dal carico di lavoro del produttore.

Riorganizzazione della tabella

È possibile usare REORG TABLE per riorganizzare una tabella Delta riscrivendo i file per eliminare i dati eliminati in modo soft, ad esempio quando si elimina una colonna usando ALTER TABLE DROP COLUMN.

Automatizzare la manutenzione delle tabelle

Per automatizzare le operazioni di manutenzione tabelle, è possibile usare l'API Lakehouse. Per ulteriori informazioni, vedere Gestione di Lakehouse tramite l'API REST di Microsoft Fabric.

Consiglio

È anche possibile usare la funzionalità di manutenzione di lakehouse tabella nel portale di Infrastruttura per semplificare la gestione delle tabelle Delta.

Contenuto correlato