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.
Il formato Lakehouse e Delta Lake è fondamentale per Microsoft Fabric. Mantenere ottimizzate le tabelle Delta è fondamentale per le prestazioni e l'efficienza dei costi per i carichi di lavoro di analisi.
Questo articolo illustra quando usare l'ordine V e illustra i modelli di configurazione e manutenzione principali per le tabelle Delta.
Usare questo articolo per:
- Comprendere i cambiamenti di V-Order e quando sono utili.
- Comprendere in che modo l'ordine Z e l'ordine V si integrano tra loro.
- Scegliere il livello di controllo corretto: sessione, proprietà della tabella o operazione di scrittura.
- Applicare i modelli di manutenzione della tabella Delta nel contesto di runtime Spark corretto.
Per indicazioni su quando applicare l'ordine V in base agli scenari di consumo, vedere Manutenzione e ottimizzazione delle tabelle trasversale ai carichi di lavoro.
Cos'è V-Order?
V-Order è un'ottimizzazione durante la scrittura per i file Parquet che può migliorare le prestazioni delle query downstream nei motori Fabric.
A colpo d'occhio:
- Dove è più utile: Modelli con elevato utilizzo di lettura, ad esempio dashboard, analisi interattiva e analisi ripetute.
- Come è utile: Riorganizza il layout Parquet (ad esempio, distribuzione, codifica e compressione dei gruppi di righe) per migliorare l'efficienza di lettura.
- Compromesso tipico: Le scritture potrebbero richiedere più tempo (spesso circa 15% in media), mentre le letture possono migliorare significativamente a seconda del carico di lavoro.
- Compatibilità del motore: I file rimangono conformi a Parquet open source e le funzionalità Delta come Z-Order rimangono compatibili.
- Ambito: V-Order è a livello di file. Con esso è possibile usare operazioni delta come compattazione, vuoto e tempo di viaggio.
Controllare le scritture degli ordini virtuali
V-Order viene usato per ottimizzare il layout dei file Parquet per prestazioni di query più veloci, in particolare negli scenari con utilizzo elevato di lettura. In Microsoft Fabric, V-Order è disabilitato per impostazione predefinita per tutte le aree di lavoro appena create per ottimizzare le prestazioni di carichi di lavoro di ingegneria dei dati con alto volume di scrittura.
Il comportamento del V-Order in Apache Spark viene controllato tramite le configurazioni seguenti:
| Impostazione | Valore predefinito | Descrizione |
|---|---|---|
spark.sql.parquet.vorder.default |
false |
Controlla la scrittura dell'ordine V a livello di sessione. Impostare su false per impostazione predefinita nei nuovi spazi di lavoro di Fabric. |
TBLPROPERTIES("delta.parquet.vorder.enabled") |
Non impostato | Controlla il comportamento predefinito del V-Order a livello di tabella. |
Opzione del writer di DataFrame: parquet.vorder.enabled |
Non impostato | Usato per controllare V-Order a livello di operazione di scrittura. |
Usare i comandi seguenti per abilitare o eseguire l'override delle scritture V-Order a seconda delle esigenze del tuo scenario.
L'V-Order è disabilitato per impostazione predefinita nelle nuove aree di lavoro di Fabric (spark.sql.parquet.vorder.default=false) per migliorare le prestazioni di scrittura delle pipeline di inserimento e trasformazione.
Per carichi di lavoro con elevato utilizzo di lettura, ad esempio query interattive o dashboard, abilitare V-Order impostando spark.sql.parquet.vorder.default su true. È anche possibile passare ai profili delle risorse readHeavyforSpark o ReadHeavy, che abilitano automaticamente il V-Order per le prestazioni incentrate sulla lettura.
In Fabric runtime 1.3 e versioni successive l'impostazione spark.sql.parquet.vorder.enable viene rimossa. Poiché L'ordine V può essere applicato automaticamente durante l'ottimizzazione Delta con OPTIMIZE, non è necessaria questa impostazione precedente. Se si esegue la migrazione da versioni di runtime precedenti, rimuovere questa impostazione dal codice.
Controllare la configurazione di V-Order nella sessione di Apache Spark
Usare questi comandi per confermare il valore della sessione corrente prima di modificarlo.
%%sql
SET spark.sql.parquet.vorder.default
Disabilitare la scrittura di V-Order nella sessione di Apache Spark
Utilizzare questi comandi quando il carico di lavoro consiste principalmente in operazioni di scrittura e si desidera un'inserimento o trasformazione più rapidi.
%%sql
SET spark.sql.parquet.vorder.default=FALSE
Abilitare la scrittura di V-Order nella sessione di Apache Spark
Quando si abilita V-Order a livello di sessione, tutte le scritture Parquet in tale sessione usano V-Order, incluse le tabelle Parquet non Delta e le tabelle Delta anche se parquet.vorder.enabled è impostata in modo esplicito su false.
%%sql
SET spark.sql.parquet.vorder.default=TRUE
Controllare V-Order, usando le proprietà della tabella Delta
Questa sezione usa Spark SQL solo perché le proprietà della tabella vengono definite tramite istruzioni e DDL ALTER TABLE SQL.
Usare le proprietà della tabella quando si desidera un valore predefinito a livello di tabella che si applica tra le sessioni.
Abilitare la proprietà della tabella V-Order durante la creazione della tabella:
%%sql
CREATE TABLE person (id INT, name STRING, age INT) USING parquet TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");
Quando la proprietà table è impostata su true, INSERT, UPDATE e MERGE, applica V Order in fase di scrittura. Le impostazioni a livello di sessione e di scrittura hanno ancora la precedenza, quindi le scritture possono comunque usare L'ordine V anche quando TBLPROPERTIES è impostato su false.
Abilitare o disabilitare V-Order modificando la proprietà della tabella:
%%sql
ALTER TABLE person SET TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");
ALTER TABLE person SET TBLPROPERTIES("delta.parquet.vorder.enabled" = "false");
ALTER TABLE person UNSET TBLPROPERTIES("delta.parquet.vorder.enabled");
Dopo aver abilitato o disabilitato V-Order usando le proprietà della tabella, sono interessate solo le scritture future nella tabella. I file Parquet mantengono l'ordinamento usato al momento della creazione. Per modificare la struttura fisica corrente per applicare o rimuovere l'ordine V, vedere Come controllare l'ordine virtuale durante l'ottimizzazione di una tabella.
Controllare direttamente V-Order nelle operazioni di scrittura
Questa sezione usa PySpark per illustrare l'API writer dei DataFrame. Lo stesso modello è disponibile nelle API del dataframe Scala con opzioni equivalenti.
Usare le opzioni a livello di scrittura quando è necessario il controllo per operazione anziché le impostazioni predefinite a livello di sessione o a livello di tabella.
Tutti i comandi di scrittura di Apache Spark ereditano l'impostazione di sessione quando non ne viene eseguito l'override in modo esplicito. Gli esempi seguenti scrivono usando V-Order ereditando la configurazione della sessione.
df_source.write\
.format("delta")\
.mode("append")\
.saveAsTable("myschema.mytable")
DeltaTable.createOrReplace(spark)\
.addColumn("id","INT")\
.addColumn("firstName","STRING")\
.addColumn("middleName","STRING")\
.addColumn("lastName","STRING",comment="surname")\
.addColumn("birthDate","TIMESTAMP")\
.location("Files/people")\
.execute()
df_source.write\
.format("delta")\
.mode("overwrite")\
.option("replaceWhere","start_date >= '2025-01-01' AND end_date <= '2025-01-31'")\
.saveAsTable("myschema.mytable")
V-Order si applica solo ai file interessati dal predicato.
In una sessione in cui spark.sql.parquet.vorder.default non è impostato o impostato su false, i comandi seguenti scrivono usando V-Order:
df_source.write\
.format("delta")\
.mode("overwrite")\
.option("replaceWhere","start_date >= '2025-01-01' AND end_date <= '2025-01-31'")\
.option("parquet.vorder.enabled","true")\
.saveAsTable("myschema.mytable")
DeltaTable.createOrReplace(spark)\
.addColumn("id","INT")\
.addColumn("firstName","STRING")\
.addColumn("middleName","STRING")\
.addColumn("lastName","STRING",comment="surname")\
.addColumn("birthDate","TIMESTAMP")\
.option("parquet.vorder.enabled","true")\
.location("Files/people")\
.execute()
Che cos'è Optimize Write?
I carichi di lavoro spark analitici offrono in genere prestazioni migliori quando le dimensioni dei file sono più coerenti e i conteggi dei file sono inferiori. I pipeline di inserimento spesso producono molti file piccoli, che porta al comune problema dei file piccoli.
Optimize Write è una funzionalità Delta Lake in Fabric e Synapse che riduce il numero di file e aumenta le dimensioni dei singoli file durante le scritture in Apache Spark. Le dimensioni del file di destinazione possono essere modificate in base ai requisiti del carico di lavoro usando le configurazioni.
La funzionalità è abilitata per impostazione predefinita in Microsoft Fabric Runtime per Apache Spark. Per altre informazioni sugli scenari di utilizzo di scrittura ottimizzati, vedere l'articolo Il bisogno di ottimizzare la scrittura in Apache Spark.
Ottimizzazione dell'unione
Delta Lake MERGE aggiorna una tabella di destinazione da una tabella di origine, una vista o un dataframe. In Delta Lake open-source, MERGE può dedicare lavoro di mescolamento non necessario su righe non modificate. Il runtime di Fabric include l'ottimizzazione del merge a basso shuffle per ridurre il sovraccarico.
L'implementazione è controllata da spark.microsoft.delta.merge.lowShuffle.enabled ed è abilitata per impostazione predefinita in fase di esecuzione. Non richiede modifiche al codice e rimane compatibile con Delta Lake open source. Per altre informazioni, vedere Ottimizzazione di fusione a bassa riorganizzazione sulle tabelle Delta.
Manutenzione delle tabelle Delta
Man mano che le tabelle Delta si evolvono, le prestazioni e l'efficienza storage possono peggiorare per diversi motivi:
- I nuovi dati aggiunti alla tabella potrebbero rendere asimmetrici i dati.
- La velocità di inserimento dei dati in batch e streaming può portare a molti file di piccole dimensioni.
- Le operazioni di aggiornamento ed eliminazione comportano un sovraccarico di lettura perché i file Parquet non sono modificabili e Delta scrive nuovi file per le modifiche.
- I file di dati e di log meno recenti possono accumularsi in storage.
Per mantenere integre le tabelle, usare regolarmente le operazioni di compattazione e pulizia:
- OPTIMIZE esegue la compattazione bin consolidando le modifiche in file Parquet di dimensioni maggiori.
- VACUUM rimuove i file dereferenziati dalla memoria.
Suggerimento
Usare Delta table maintenance in Lakehouse per il flusso di lavoro di manutenzione basato sul portale, eseguire le indicazioni sul monitoraggio e le linee guida operative focalizzate sulla conservazione.
OPTIMIZE e VACUUM sono comandi Spark SQL. Eseguirli in:
- Notebook Fabric con runtime Spark.
- Definizioni di job Spark.
- Manutenzione Lakehouse in Explorer. Consulta la pagina Manutenzione tabelle Delta Lake.
Questi comandi non sono supportati nell'endpoint SQL Analytics o Warehouse SQL query editor che supportano solo T-SQL. Per i flussi di lavoro degli endpoint SQL, usare la manutenzione della tabella Delta Lake o eseguire i comandi in un notebook di Fabric.
Progettare prima la struttura fisica della tabella in base alla frequenza di inserimento e ai modelli di lettura. In molti carichi di lavoro, la progettazione di tabelle ha un impatto maggiore rispetto ai soli comandi di ottimizzazione.
Controllare V-Order durante l'ottimizzazione di una tabella
Usare questi comandi quando si vuole che la compattazione e la riscrittura dell'ordine V vengano eseguite in un'unica operazione.
Z-Order e V-Order ottimizzano diversi aspetti delle prestazioni di lettura:
-
Z-Order (parola chiave
ZORDERSQL) raggruppa i valori correlati per migliorare il salto dei dati per i filtri selettivi. -
V-Order (parola chiave
VORDERSQL) ottimizza il layout dei file Parquet per migliorare l'efficienza di lettura nei motori Fabric.
Se le query filtrano frequentemente in colonne specifiche, Z-Order può essere utile. Se il tuo carico di lavoro è complessivamente orientato alla lettura, V-Order può essere utile. In molti casi, è possibile combinare entrambi.
Usare questa guida rapida alle decisioni:
- Usare
VORDERquando si vogliono miglioramenti generali delle prestazioni di lettura tra i motori. - Usare
ZORDER BY (...)conVORDERquando le query filtrano ripetutamente su colonne conosciute e si vogliono ottenere anche i vantaggi del layout V-Order.
Il comando seguente crea bin-compact e riscrive tutti i file interessati utilizzando il V-Order, indipendentemente da TBLPROPERTIES e dalle impostazioni di sessione.
%%sql
OPTIMIZE <table|fileOrFolderPath> VORDER;
OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> VORDER;
OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> [ZORDER BY (col_name1, col_name2, ...)] VORDER;
Quando ZORDER e VORDER vengono usati insieme in SQL, Apache Spark applica la compattazione bin, quindi Z-Order, quindi V-Order.
I seguenti comandi eseguono la compattazione binaria e riscrivono tutti i file interessati utilizzando TBLPROPERTIES. Se TBLPROPERTIES è impostato per abilitare V-Order, tutti i file interessati vengono scritti con V-Order. Se TBLPROPERTIES è disattivato o impostato su false, il comportamento eredita l'impostazione della sessione. Per rimuovere V-Order dalle riscritture della tabella, impostare la configurazione della sessione su false.
Quando si eseguono questi comandi nei notebook di Fabric, includere uno spazio tra %%sql e OPTIMIZE.
Sintassi corretta:
%%sql
OPTIMIZE table_name;
Sintassi errata: %%sqlOPTIMIZE table_name;.
%%sql
OPTIMIZE <table|fileOrFolderPath>;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate [ZORDER BY (col_name1, col_name2, ...)];
Usare VACUUM per il mantenimento e la pulizia dell'archiviazione
Uno scenario comune VACUUM è la pulizia basata su criteri di conservazione. Usarlo quando i file meno recenti, senza riferimenti sono accumulati e si vuole recuperare storage dopo aggiornamenti, eliminazioni o cicli di inserimento ripetuti.
Esegui VACUUM solo con una finestra di conservazione adatta alle aspettative di viaggio nel tempo e ripristino. Il modello predefinito mantiene sette giorni di cronologia.
Nei notebook Spark un modello compatto VACUUM è simile al seguente:
%%sql
VACUUM schema_name.table_name;
VACUUM schema_name.table_name RETAIN 168 HOURS;
Per indicazioni sul comportamento di conservazione e sulla sicurezza, vedere comando VACUUM. Per le esecuzioni di manutenzione a livello di codice, vedere Eseguire la manutenzione delle tabelle in una tabella Delta.