Manutenzione e ottimizzazione delle tabelle tra carichi di lavoro in Microsoft Fabric

Le tabelle Delta in Microsoft Fabric servono più motori a consumo, ognuno con caratteristiche di prestazioni e requisiti di ottimizzazione diversi. Questa guida fornisce un framework completo per comprendere il modo in cui le tabelle scritte da un motore vengono utilizzate da altri e come ottimizzare le strategie di manutenzione delle tabelle di conseguenza.

Comprendere la relazione tra modelli di scrittura e prestazioni di lettura tra motori diversi è essenziale per la creazione di piattaforme dati efficienti. L'obiettivo è garantire che i produttori di dati creino layout di tabella che ottimizzano le prestazioni di lettura per i consumer downstream, indipendentemente dal fatto che questi consumer usino Spark, endpoint di analisi SQL, Power BI Direct Lake o Warehouse.

Matrice di scenari di scrittura e lettura

La tabella seguente riepiloga le caratteristiche di prestazioni previste per le combinazioni comuni di scrittura e lettura, insieme alle strategie di ottimizzazione consigliate. Usare questa matrice per identificare lo scenario e comprendere le indicazioni pertinenti.

Metodo di Scrittura	Motore di lettura dati	Lacune previste	Strategia consigliata
Batch di Spark	Spark	Nessun gap	Le configurazioni di scrittura di Spark predefinite sono sufficienti
Spark batch	Endpoint di analisi SQL	Nessun gap	Abilitare la compattazione automatica e ottimizzare la scrittura
Spark Streaming	Spark	File di piccole dimensioni possibili	Compattazione automatica e ottimizzazione della scrittura con pianificato OPTIMIZE
Spark Streaming	Endpoint di analisi SQL	File e checkpoint di piccole dimensioni	Compattazione automatica, scrittura ottimizzata, divisione dei livelli medaglione
Magazzino	Spark	Nessun gap	L'ottimizzazione gestita dal sistema gestisce il layout
Magazzino	Endpoint di analisi SQL	Nessun gap	L'ottimizzazione gestita dal sistema gestisce il layout

Layout di file ottimali per motore

I diversi motori di consumo hanno differenti layout di file ottimali. La comprensione di queste destinazioni consente di configurare le operazioni di scrittura e i processi di manutenzione in modo appropriato.

Linee guida per gli endpoint di analisi di SQL e il Data Warehouse di Fabric

Per ottenere prestazioni ottimali con l'endpoint di analisi SQL e Warehouse, usare le impostazioni seguenti:

Dimensioni del file di destinazione: circa 400 MB per file
Dimensioni del gruppo di righe: circa 2 milioni di righe per gruppo di righe
V-Order: migliora le prestazioni di lettura di 10%

Un magazzino usa questi criteri per individuare i candidati per la compattazione:

Il sovraccarico dei file di tabella è superiore a 10%
Le righe eliminate logicamente dalla tabella sono più di 10%
Le dimensioni della tabella sono maggiori di 1.024 righe

Durante l'esecuzione della compattazione, il processo seleziona i candidati in base a questi criteri:

Qualsiasi file è inferiore a 25% delle dimensioni ideali (in base al numero di righe)
Qualsiasi file ha più di 20% righe eliminate

Spark

Spark è affidabile durante la lettura di varie dimensioni del file. Per prestazioni ottimali:

Dimensioni del file di destinazione: da 128 MB a 1 GB a seconda delle dimensioni della tabella
Dimensioni del gruppo di righe: da 1 milione a 2 milioni di righe per gruppo di righe
V-Order: Non necessario per le prestazioni di lettura di Spark (può aggiungere un sovraccarico di scrittura del 15-33%)

La lettura di Spark beneficia delle adattive dimensioni del file di destinazione, che si adattano automaticamente in base alla dimensione della tabella.

Tabelle sotto 10 GB: destinazione di 128 MB
Tabelle superiori a 10 TB: obiettivo fino a 1 GB

Power BI Direct Lake

Per prestazioni ottimali di Direct Lake:

Dimensioni del gruppo di righe di destinazione: almeno 8 milioni di righe per gruppo di righe per prestazioni ottimali
V-Order: critico per il miglioramento del 40-60% nelle query con cache non riscaldata
Conteggio file: ridurre al minimo il numero di file per ridurre il sovraccarico di transcodifica
Dimensioni coerenti dei file: importante per prestazioni prevedibili delle query

I modelli semantici Direct Lake sono ottimali quando:

I dati delle colonne sono ordinati in V per la compressione compatibile con VertiPaq
I gruppi di righe sono sufficientemente grandi per un'unione efficiente del dizionario
I vettori di eliminazione vengono ridotti al minimo tramite la compattazione regolare

Per altre informazioni, vedere Informazioni sulle prestazioni delle query Direct Lake.

Rispecchiamento

Il mirroring ridimensiona automaticamente i file in base al volume di tabelle:

Dimensioni della tabella	Righe per gruppo di righe	Righe per file
Piccolo (fino a 10 GB)	2 milioni	10 milioni
Medio (da 10 GB a 2,56 TB)	4 milioni	60 milioni
Grande (oltre 2,56 TB)	8 milioni	80 milioni

Scrivere modelli e configurazioni

Modelli di scrittura Spark

Le scritture spark usano le configurazioni predefinite seguenti:

Configurazione	Valore predefinito	Descrzione
`spark.microsoft.delta.optimizeWrite.fileSize`	128 MB	Dimensioni del file di destinazione per scritture ottimizzate
`spark.databricks.delta.optimizeWrite.enabled`	Varia in base al profilo	Abilita l'unione automatica dei file
`spark.databricks.delta.autoCompact.enabled`	Disabled	Abilita la compattazione post-scrittura
`spark.sql.files.maxRecordsPerFile`	Unlimited	Numero massimo di record per file

Per configurare le scritture Spark per il consumo SQL downstream:

# Enable optimize write for better file layout
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable auto-compaction for automatic maintenance
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

Per altre informazioni sui profili di risorsa e sulle relative impostazioni predefinite, vedere Configurare le configurazioni del profilo di risorsa.

Modelli di scrittura dei dati del magazzino

Warehouse ottimizza automaticamente il layout dei dati durante le scritture:

L'ordine V è abilitato per impostazione predefinita per l'ottimizzazione della lettura.
La compattazione automatica viene eseguita come processo in background.
La gestione dei checkpoint viene gestita automaticamente.

Il warehouse produce file ottimizzati per l'utilizzo di SQL senza intervento manuale. Le tabelle scritte dal warehouse sono intrinsecamente ottimizzate sia per gli endpoint di analisi SQL che per le letture warehouse.

Operazioni di manutenzione tabelle

Comando OPTIMIZE

Il OPTIMIZE comando consolida i file di piccole dimensioni in file di dimensioni maggiori:

-- Basic optimization
OPTIMIZE schema_name.table_name

-- Optimization with V-Order for Power BI consumption
OPTIMIZE schema_name.table_name VORDER

-- Optimization with Z-Order for specific query patterns
OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Importante

Il OPTIMIZE comando è un comando Spark SQL. È necessario eseguirlo in ambienti Spark, ad esempio notebook, definizioni di processi Spark o l'interfaccia Lakehouse Maintenance. L'endpoint di analisi SQL e l'editor di query SQL warehouse non supportano questo comando.

Per altre informazioni, vedere Compattazione tabelle.

Compattazione automatica

La compattazione automatica valuta automaticamente l'integrità delle partizioni dopo ogni operazione di scrittura e attiva l'ottimizzazione sincrona quando viene rilevata la frammentazione dei file:

# Enable at session level
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
""")

Usare la compattazione automatica per le pipeline di inserimento con scritture frequenti (streaming o microbatch) per evitare la pianificazione manuale e mantenere automaticamente compattati i file.

La compattazione automatica e l'ottimizzazione della scrittura producono in genere i risultati migliori quando vengono usati insieme. Ottimizzare la scrittura riduce il numero di file di piccole dimensioni scritti e la compattazione automatica gestisce la frammentazione rimanente.

Per altre informazioni, vedere Compattazione automatica.

Ottimizzare la scrittura

Ottimizzare la scrittura riduce il sovraccarico di file di piccole dimensioni eseguendo la compattazione pre-scrittura, generando un minor numero di file di dimensioni maggiori:

# Enable at session level
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')
""")

Ottimizzare la scrittura è utile per:

Tabelle partizionate
Tabelle con inserimenti di piccole dimensioni frequenti
Operazioni che toccano molti file (MERGE, UPDATE, DELETE)

La compattazione pre-scrittura (ottimizzazione della scrittura) è in genere meno costosa rispetto alla compattazione post-scrittura (ottimizzazione). Per altre informazioni, vedere Ottimizzare la scrittura.

Comando VACUUM

Il VACUUM comando rimuove i file precedenti a cui non fa più riferimento un log di tabella Delta:

-- Remove files older than the default retention period (7 days)
VACUUM schema_name.table_name

-- Remove files older than specified hours
VACUUM schema_name.table_name RETAIN 168 HOURS

Il periodo di conservazione predefinito è sette giorni. L'impostazione di periodi di conservazione più brevi influisce sulle capacità di time travel di Delta e può causare problemi con lettori o scrittori simultanei.

Per altre informazioni, vedere La manutenzione delle tabelle lakehouse.

Ottimizzazione di V-Order

V-Order è un'ottimizzazione in fase di scrittura che applica l'ordinamento, la codifica e la compressione compatibili con VertiPaq ai file Parquet:

Power BI Direct Lake: 40-60% miglioramento delle query nella cache a freddo
Endpoint di analisi SQL e Warehouse: circa 10% miglioramento delle prestazioni di lettura
Spark: nessun vantaggio intrinseco nella lettura; scritture più lente del 15-33%

Quando abilitare V-Order

L'ordine V offre il massimo vantaggio per:

Tabelle di livello Gold che servono Power BI Direct Lake
Tabelle sottoposte a query frequenti tramite l'endpoint di analisi SQL
Carichi di lavoro con un numero elevato di operazioni di lettura in cui le prestazioni di scrittura sono meno critiche

Quando evitare l'ordine V

Prendere in considerazione la disabilitazione del V-Order per:

Tabelle a livello bronzo incentrate sulla velocità di inserimento
Pipeline Spark-to-Spark in cui SQL e Power BI non consumano i dati
Carichi di lavoro con intensa attività di scrittura in cui la latenza dei dati è critica

Configurare V-Order

V-Order è disabilitato per impostazione predefinita nelle nuove aree di lavoro di Fabric. Per abilitarla, effettuare i seguenti passaggi:

# Enable at session level (default for all writes)
spark.conf.set('spark.sql.parquet.vorder.default', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.parquet.vorder.enabled' = 'true')
""")

Per applicare in modo selettivo l'ordine virtuale in base all'utilizzo di Direct Lake, è consigliabile automatizzare l'abilitazione dell'ordine virtuale per le tabelle usate nei modelli semantici Direct Lake. Le tabelle non utilizzate da Direct Lake possono rimanere senza ordine V per ottenere prestazioni di scrittura migliori.

Per altre informazioni, vedere Ottimizzazione tabella Delta Lake e V-Order.

Clustering liquido e ordine Z

Clustering liquido

Liquid Clustering è l'approccio consigliato per l'organizzazione dei dati. A differenza del partizionamento tradizionale, Liquid Clustering:

Si adatta ai cambiamenti dei modelli di query
Richiede OPTIMIZE l'applicazione del clustering
Offre un migliore salto di file per le query filtrate

Abilitare Liquid Clustering durante la creazione della tabella:

CREATE TABLE schema_name.table_name (
    id INT,
    category STRING,
    created_date DATE
) CLUSTER BY (category)

Ordine Z

Z-Order colloca i dati correlati negli stessi file, in modo da ottenere migliori prestazioni delle query con i predicati di filtro.

OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Usare l'ordine Z quando:

La tabella è partizionata, perché Liquid Clustering non funziona con le tabelle partizionate.
Le query spesso filtrano due o più colonne insieme.
I predicati sono sufficientemente selettivi da trarre vantaggio dal salto dei file.

Raccomandazioni per l'architettura medallion

L'architettura medallion (Bronze, Silver, Gold layer) fornisce un framework per ottimizzare le strategie di manutenzione delle tabelle in base allo scopo di ogni livello.

Livello bronzo (zona di atterraggio)

Le tabelle bronze si concentrano sulle prestazioni di scrittura e sull'inserimento a bassa latenza:

Priorità di ottimizzazione: velocità di inserimento rispetto alle prestazioni di lettura
Partizionamento: accettabile ma sconsigliato per le nuove implementazioni
File di piccole dimensioni: accettabile perché l'attenzione è sulla velocità di inserimento
V-Order: non consigliato (aggiunge overhead di scrittura)
Compattazione automatica: consente di ridurre i file di piccole dimensioni, ma può essere sacrificata per la velocità di inserimento
Vettori di eliminazione: abilitare per le tabelle con modelli di unione

Le tabelle bronze non devono essere servite direttamente né all'endpoint di SQL analytics né agli utenti di Power BI Direct Lake.

Livello Silver (zona selezionata)

Le tabelle silver bilanciano le prestazioni di scrittura e lettura:

Priorità di ottimizzazione: Bilanciamento delle prestazioni di inserimento e query
Dimensioni dei file: moderate (128-256 MB) per supportare operazioni di scrittura e lettura
V-Order: facoltativo; abilitare se l'endpoint di analisi SQL o il consumo di Power BI è significativo
Liquid Clustering o ordine Z: consigliato per migliorare le prestazioni delle query
Compattazione automatica e scrittura ottimizzata: abilitare in base ai requisiti downstream
Vettori di eliminazione: abilitare per le tabelle con aggiornamenti frequenti
OTTIMIZZAZIONE pianificata: eseguire in modo aggressivo per mantenere il layout dei file

Livello oro (zona di servizio)

Le tabelle Gold assegnano priorità alle prestazioni di lettura per l'utilizzo degli utenti finali:

Priorità di ottimizzazione: prestazioni di lettura per l'analisi
Dimensioni dei file: grandi (da 400 MB a 1 GB) per prestazioni ottimali di SQL e Power BI
V-Order: obbligatorio per Power BI Direct Lake; utile per l'endpoint di analisi SQL
Liquid Clustering: necessario per consentire l'ottimizzazione del salto dei file
Optimize-write: obbligatorio per dimensioni di file coerenti
OTTIMIZZAZIONE pianificata: eseguire in modo aggressivo per mantenere il layout ottimale

Ottimizzare le tabelle gold in modo diverso in base al motore di consumo primario:

Motore di consumo	Ordine V	Dimensioni del file di destinazione	Dimensioni del gruppo di righe
Endpoint di analisi SQL	Sì	400 megabyte	2 milioni di righe
Power BI Direct Lake	Sì	Da 400 MB a 1 GB	8+ milioni di righe
Spark	Opzionale	Da 128 MB a 1 GB	1-2 milioni di righe

Copie multiple di tabelle

È accettabile mantenere più copie delle tabelle ottimizzate per modelli di consumo diversi:

Una tabella Silver ottimizzata per l'elaborazione Spark
Una tabella Gold ottimizzata per l'endpoint di analisi SQL e Power BI Direct Lake
Pipeline di dati che si occupano di trasformare e collocare la struttura corretta a ogni livello

L'archiviazione è poco costosa rispetto al calcolo. L'ottimizzazione delle tabelle per i modelli di utilizzo offre un'esperienza utente migliore rispetto al tentativo di gestire tutti i consumer da un singolo layout di tabella.

Identificare la salute delle tabelle

Prima di ottimizzare le tabelle, valutare l'integrità della tabella corrente per comprendere le esigenze di ottimizzazione.

Esaminare direttamente i file Parquet

È possibile sfogliare la cartella della tabella in OneLake per controllare le dimensioni dei singoli file Parquet. Le tabelle integre hanno dimensioni di file distribuite uniformemente. Cercare:

Dimensioni dei file coerenti: i file devono avere una dimensione approssimativamente uguale (entro 2x l'uno dall'altro).
Nessun file estremamente piccolo: i file di dimensioni minori di 25 MB indicano la frammentazione.
Nessun file estremamente grande: i file di dimensioni superiori a 2 GB possono ridurre il parallelismo.

La distribuzione delle dimensioni del file non uniforme spesso indica una compattazione mancante o modelli di scrittura incoerenti in processi diversi.

OTTIMIZZAZIONE DEL DRY RUN in Spark SQL

Usare l'opzione DRY RUN per visualizzare in anteprima i file idonei per l'ottimizzazione senza eseguire la compattazione:

-- Preview files eligible for optimization
OPTIMIZE schema_name.table_name DRY RUN

Il comando restituisce un elenco di file che verrebbero riscritti durante l'ottimizzazione. Usare questa opzione per:

Valutare l'ambito di ottimizzazione prima di eseguirlo.
Comprendere la frammentazione dei file senza modificare la tabella.
Stimare il tempo di ottimizzazione in base al numero di file interessati.

Distribuzione delle dimensioni dei file

Usare l'approccio seguente per analizzare le dimensioni e la distribuzione dei file:

from delta.tables import DeltaTable

# Get table details
details = spark.sql("DESCRIBE DETAIL schema_name.table_name").collect()[0]
print(f"Table size: {details['sizeInBytes'] / (1024**3):.2f} GB")
print(f"Number of files: {details['numFiles']}")

# Average file size
avg_file_size_mb = (details['sizeInBytes'] / details['numFiles']) / (1024**2)
print(f"Average file size: {avg_file_size_mb:.2f} MB")

La distribuzione può essere distorta, poiché i file prossimi alla testa della tabella o da una partizione specifica potrebbero non essere ottimizzati.

È possibile valutare la distribuzione eseguendo una query che raggruppa in base alle chiavi di partizionamento o clustering della tabella.

Determinare le esigenze di ottimizzazione

Sulla base del motore di utilizzo, confronta le dimensioni effettive dei file con le dimensioni di destinazione.

Engine	Dimensioni del file di destinazione	Se i file sono più piccoli	Se i file sono di dimensioni maggiori
Endpoint di analisi SQL	400 megabyte	Eseguire `OPTIMIZE`	I file sono accettabili
Power BI Direct Lake	Da 400 MB a 1 GB	Eseguire `OPTIMIZE VORDER`	I file sono accettabili
Spark	Da 128 MB a 1 GB	Abilitare la compattazione automatica	I file sono accettabili

Cronologia tabelle e log delle transazioni

Esaminare la cronologia delle tabelle per comprendere i modelli di scrittura e la frequenza di manutenzione:

-- View table history
DESCRIBE HISTORY schema_name.table_name

-- Check for auto-compaction runs
-- Auto-compaction shows as OPTIMIZE with auto=true in operationParameters

Procedure consigliate per la configurazione

Usare le proprietà della tabella sulle configurazioni di sessione

Le proprietà della tabella persistono tra le sessioni e garantiscono un comportamento coerente in tutti i compiti e i moduli di scrittura.

# Recommended: Set at table level for consistency
spark.sql("""
    CREATE TABLE schema_name.optimized_table (
        id INT,
        data STRING
    )
    TBLPROPERTIES (
        'delta.autoOptimize.optimizeWrite' = 'true',
        'delta.autoOptimize.autoCompact' = 'true',
        'delta.parquet.vorder.enabled' = 'true'
    )
""")

Le configurazioni a livello di sessione si applicano solo alla sessione Spark corrente e possono causare scritture incoerenti se diverse sessioni usano configurazioni diverse.

Abilitare le dimensioni del file di destinazione adattivo

Le dimensioni del file di destinazione vengono regolate automaticamente in modo adattivo in base alla dimensione della tabella.

spark.conf.set('spark.microsoft.delta.targetFileSize.adaptive.enabled', 'true')

Questa funzionalità offre i vantaggi seguenti:

Inizia con file più piccoli (128 MB) per tabelle di piccole dimensioni
Scala fino a 1 GB per tabelle superiori a 10 TB
Rivaluta automaticamente durante le operazioni OPTIMIZE

Abilitare gli obiettivi di compattazione a livello di file

Impedire la riscrittura dei file compattati in precedenza quando le dimensioni di destinazione cambiano:

spark.conf.set('spark.microsoft.delta.optimize.fileLevelTarget.enabled', 'true')

Riepilogo delle raccomandazioni

Strato	Compattazione automatica	ottimizzare la scrittura	Ordine V	Clustering liquido	Ottimizzazione pianificata
Bronzo	Abilita (facoltativo)	Enable	NO	NO	Opzionale
Argento	Enable	Enable	Opzionale	Sì	Aggressive
Oro	Enable	Enable	Sì	Sì	Aggressive

Per scenari specifici, usare le raccomandazioni seguenti:

Spark-to-Spark: Concentrarsi sull'ottimizzazione delle dimensioni dei file; V-Order facoltativo.
Spark-to-SQL: abilita ottimizzazione/scrittura e compattazione automatica; 400 MB di file con 2 milioni di gruppi di righe.
Inserimento in streaming: Abilitare la compattazione automatica; pianificare attività aggiuntive OPTIMIZE per i consumer SQL.
Power BI Direct Lake: abilitare V-Order; obiettivo 8+ milioni di gruppi di righe; eseguire OPTIMIZE VORDER.

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-02-13