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

Le tabelle Delta in Microsoft Fabric possono servire Spark, endpoint SQL analytics, Power BI Direct Lake, Warehouse e altre esperienze Fabric a partire dai dati memorizzati in OneLake. La performance ottimale tra carichi di lavoro dipende da due fattori:

  • Il carico di lavoro che crea e mantiene la tabella.
  • I motori che consumano il tavolo.

Le tabelle Lakehouse sono comunemente gestite da Spark, Fabric pipeline attività Copy o Dataflow Gen2. Spark è il motore di scrittura più utilizzato e offre la più ampia gamma di controlli per il layout e la manutenzione. I processi di mirroring di data warehouse e database gestiscono automaticamente la propria struttura fisica. I cataloghi speculari mantengono il layout gestito nel sistema sorgente. I requisiti dei consumatori sono generalmente compatibili, ma Power BI Direct Lake prevede ulteriori requisiti di storage per prestazioni ottimali.

Usa una tabella condivisa ogni volta che i suoi requisiti sono compatibili. Per le eccezioni che giustificano un'altra tabella, vedi Quando creare un'altra tabella.

Comprendere la proprietà della disposizione

Inizia identificando quale workload gestisce il layout fisico della tabella. I controlli nella tabella seguente sono i controlli chiave rilevanti per la disposizione e la manutenzione della tabella di carico incrociato, non un elenco esaustivo delle capacità di ogni motore.

Archiviazione dati Metodo di scrittura o ingestione Responsabilità del layout e della manutenzione Controlli chiave
Lakehouse Spark Gestito dagli utenti Dimensione del file: dimensione target adattiva del file e obiettivi di compattazione a livello di file.
Scrittura e manutenzione: vettori di cancellazione, compattazione automatica, ottimizzazione della scrittura, OPTIMIZE, e VACUUM.
Organizzazione dei dati: liquid clustering, partizionamento, Z-Order e V-Order.
Lakehouse Attività di copia della pipeline di Fabric o Dataflow Gen2 Il servizio scrive i dati; il proprietario del lakehouse gestisce la tabella Impostazioni di scrittura specifiche per destinazione. Esegui la manutenzione compatibile separatamente utilizzando Spark, la manutenzione Lakehouse o un'attività di manutenzione di condotti.
Magazzino Fabric Data Warehouse, Fabric pipeline attività Copy, o Dataflow Gen2 Gestita da magazzino Raggruppamento dei dati e l'impostazione V-Order a livello del magazzino.
Elemento speculare Servizio di mirroring Dipende dal tipo di mirroring Il mirroring del database utilizza un layout V-Ordered Delta gestito dal sistema senza controlli diretti di layout. I cataloghi speculari mantengono la disposizione del file sorgente, che puoi ottimizzare nel sistema sorgente quando supportato.

Guida per carichi di lavoro incrociati

La tabella seguente riassume l'approccio raccomandato sia per produttore che per consumatore.

Producer Consumer Approccio consigliato
Lakehouse: Spark scrittore Spark Usa i valori predefiniti di runtime di Fabric Spark 2.0 o successivi e abilita la compattazione automatica. Prendi in considerazione liquid clustering quando i predicati monitorati beneficiano di una migliore esclusione dei file.
Lakehouse: Spark scrittore Endpoint di analisi SQL Usa lo stesso layout consigliato per Spark. Non impostare una dimensione fissa del file di destinazione, un limite arbitrario di righe o un V-Order solo per le prestazioni degli endpoint SQL analytics.
Lakehouse: Spark scrittore Power BI Direct Lake Usa lo stesso layout consigliato per Spark e abilita inoltre V-Order, oppure usa il profiloreadHeavyForPBI risorse.
Lakehouse: Fabric pipeline o Dataflow Gen2 writer Spark, endpoint di analisi SQL o Power BI Direct Lake Monitora la struttura risultante dei file e pianifica separatamente gli interventi di manutenzione compatibili del lakehouse. Alcune modalità di destinazione, come il aggiornamento incrementale di Dataflow Gen2, impongono restrizioni di manutenzione.
Magazzino Fabric Data Warehouse o Spark Usa il layout gestito dal sistema. Fabric Data Warehouse gestisce automaticamente la compattazione e altre attività di manutenzione. Usa il cluster di dati per migliorare il salto di file per carichi di lavoro con predicati selettivi ricorrenti.
Magazzino Power BI Direct Lake Mantieni l'impostazione predefinita Warehouse V-Order. Usa il clustering dei dati quando è vantaggioso per i pattern di query condivisi.
Rispecchiamento Spark, endpoint di analisi SQL o Power BI Direct Lake Per il mirroring del database, si utilizza il layout V-Ordered Delta gestito dal sistema. Per i cataloghi con mirroring, ottimizza i file di base nel sistema di origine, se supportato. Vedi Cos'è il mirroring in Fabric?.

Ottimizza le tabelle Lakehouse

Le tabelle Delta di Lakehouse richiedono una strategia di manutenzione esplicita, indipendentemente dal fatto che le scriva Spark, Pipeline attività Copy o Dataflow Gen2. Spark è l'esempio principale in questa sezione perché offre i controlli di layout e manutenzione più ampi in Fabric.

Importante

La manutenzione delle tabelle è fondamentale per le ottimali prestazioni di scrittura e lettura tra i motori. Anche i carichi di lavoro di sola aggiunta che inizialmente funzionano bene senza manutenzione possono accumulare un numero eccessivo di file di piccole dimensioni, che incidono su Spark, SQL analytics endpoint, Direct Lake e i lettori di dati esterni. Vedi Tabelle Delta di compattazione per metodi di compattazione automatici e manuali.

Usa i valori predefiniti di runtime di Spark

Quando Spark scrive la tabella, usa i valori predefiniti di Fabric Spark 2.0 o successive:

Nel runtime 1.3 di Fabric Spark, dimensione di destinazione adattiva dei file, obiettivi di compattazione a livello di file e vettori di eliminazione sono disponibili come impostazioni facoltative.

Quando Pipeline attività Copy o Dataflow Gen2 scrive la tabella, ispeziona la disposizione dei file risultante e programma la manutenzione separatamente. Non dare per scontato che questi autori applichino i valori predefiniti di runtime di Spark.

Importante

Le destinazioni lakehouse di Dataflow Gen2 che utilizzano refresh incrementale non supportano OPTIMIZE né REORG TABLE. Segui le limitazioni di aggiornamento incrementale di Dataflow Gen2.

Prevenire e compattare i file piccoli

Per le tabelle scritte da Spark, preferisci compattazione automatica. Questa caratteristica valuta la frammentazione delle tabelle dopo la scrittura ed esegue compattazione solo quando necessario. Elimina la necessità di un controllo separato dello stato della tabella prima dell’esecuzione della manutenzione.

Usa le seguenti linee guida per eccezioni e caratteristiche complementari:

Scenario Approccio consigliato
Tabella scritta da Spark Abilita la compattazione automatica come strategia di manutenzione predefinita.
Scrittura in streaming o in micro-batch Abilita la compattazione automatica e ottimizza la scrittura per ridurre l'accumulo di file piccoli.
Carichi di lavoro con requisiti rigorosi di latenza di scrittura Pianifica OPTIMIZE separatamente invece di eseguire la compattazione automatica sincrona.
Tabella esistente con piccoli file accumulati Esegui una sola OPTIMIZEvolta, poi attiva la compattazione automatica per la manutenzione continua.
Tabelle con aggiornamenti frequenti, cancellazioni o fusioni Mantieni attivati i vettori di cancellazione e la compattazione automatica .

OPTIMIZE compatta i file e elimina automaticamente i vettori di cancellazione di un file quando più di 5% dei suoi record sono riferiti da vettori di cancellazione. Usalo REORG TABLE ... APPLY (PURGE) solo quando devi eliminare fisicamente i record al di sotto di quella soglia o soddisfare un requisito specifico di conformità.

Note

Compattazione automatica rimuove i vettori di eliminazione solo quando la partizione soddisfa anche la soglia di attivazione per i file di piccole dimensioni. Se un carico di lavoro esegue aggiornamenti o cancellazioni senza generare piccoli file, esegui OPTIMIZE periodicamente per eliminare i vettori di cancellazione qualificati. Usa REORG TABLE ... APPLY (PURGE) quando è necessario forzare una purga fisica.

Esegui VACUUM secondo una pianificazione separata per rimuovere i file non referenziati dopo il periodo di conservazione. VACUUM Recupera lo spazio di archiviazione ma non migliora la disposizione attiva dei file.

Avvertimento

Non accorciare il VACUUM periodo di conservazione senza valutare i requisiti di viaggio nel tempo e i lettori o scrittori contemporanei. Rimuovere i file troppo presto può rendere indisponibili le versioni richieste delle tabelle.

Organizza i dati per il salto dei file

Usa il cluster liquido quando i modelli ricorrenti di filtri o di elaborazione traggono beneficio da un miglioramento nel salto dei file. Le tabelle clusterizzate liquide richiedono OPTIMIZEo compattazione automatica per organizzare i dati appena scritti.

Evita di partizionare di default. Usalo quando un requisito specifico giustifica i compromessi operativi, come isolare autori concorrenti che aggiornano, cancellano o uniscono dati tra partizioni disgiunte. Per maggiori informazioni, vedi Quando usare la partizionazione.

Per tabelle partizionate esistenti, consideriamo l'Ordine Z quando i predicati selettivi filtrano comunemente sulle stesse colonne all'interno di una partizione.

Ottimizzare le tabelle gestite da Warehouse

Fabric Data Warehouse gestisce la disposizione fisica della tabella Delta indipendentemente dal metodo di ingestione.

Usa i controlli strategici che Warehouse espone per regolare la disposizione dei dati:

  • Applica il clustering dei dati a tabelle grandi quando le query utilizzano ripetutamente predicati selettivi sulle stesse colonne.
  • Mantieni V-Order abilitato per carichi di lavoro orientati alla lettura e misti. V-Order è abilitato di default.
  • Considera di disabilitare V-Order per carichi di lavoro di warehouse che richiedono molta scrittura.

Avvertimento

Disabilitare V-Order è un'operazione irreversibile a livello di magazzino. Testa il carico completo di lettura e scrittura prima di disabilitarlo.

Per indicazioni complete sul Magazzino, consulta le linee guida sulle prestazioni in Fabric Data Warehouse.

Ottimizzare i dati speculari

La tua capacità di migliorare il layout fisico dipende dal fatto che Fabric replichi i dati o faccia riferimento ai file sorgente:

  • Mirroring di database: Fabric replica i dati di origine nelle tabelle Delta in OneLake e gestisce il layout e la manutenzione dei file con ordinamento V. Non puoi configurare direttamente la dimensione del file di destinazione, la pulizia del vettore di cancellazione, il clustering liquido, la partizionazione o il V-Order sulla destinazione speculare.
  • Cataloghi mirrorati: Fabric sincronizza i metadati e usa collegamenti OneLake per fare riferimento direttamente ai dati di origine. Fabric non riscrive né mantiene questi file. Migliora il layout fisico e la pulizia nel sistema sorgente quando le funzionalità supportate lo permettono. Questi cambiamenti sono visibili attraverso le scorciatoie senza creare un'altra copia in Fabric.

Per i dati sottoposti a mirroring del database:

  • Usa predicati selettivi ed evita colonne non necessarie nelle query Spark e SQL.
  • Progettare modelli semantici Power BI e misure DAX per un consumo efficiente di Direct Lake.

Per cataloghi speculari:

  • Utilizza le funzionalità di manutenzione e layout delle tabelle supportate dalla piattaforma di origine.
  • Valuta il file sorgente e la distribuzione dei gruppi di righe per i consumatori Fabric che interrogano le scorciatoie.
  • Per Direct Lake, valutare la creazione di un ulteriore livello di servizio V-Ordered basato sulla modellazione dimensionale quando la struttura dei dati di origine non è in grado di soddisfare i requisiti di prestazioni.

Per concetti, tipi e fonti supportate nel mirroring, vedi Cos'è il Mirroring in Fabric? e Come funziona il mirroring dei metadati.

Applicare l'ottimizzazione specifica per il consumatore

Spark e SQL Analytics Endpoint funzionano bene sullo stesso layout adattivo di lakehouse. Utilizzare la dimensione di destinazione adattiva dei file, evitare file troppo piccoli e applicare il liquid clustering quando i predicati monitorati beneficiano di una migliore esclusione dei file. Non abilitare V-Order solo per le prestazioni degli endpoint di Spark o SQL analytics. Per dettagli specifici del motore, vedi considerazioni sulle prestazioni degli endpoint di analisi SQL.

Power BI Direct Lake

Direct Lake utilizza le stesse tabelle Delta di base, ma aggiunge raccomandazioni relative alla transcodifica e al framing incrementale:

Note

Direct Lake generalmente si comporta meglio con gruppi di file tra 1 e 16 milioni di file. Valuta la distribuzione per gruppi di righe e le prestazioni di Direct Lake prima di cambiare l'impostazione del produttore supportato.

Per le tabelle scritte da Spark, spark.sql.parquet.native.writer.maxRowGroupRowCount imposta il numero massimo di righe per gruppo di righe quando il motore di esecuzione nativo scrive i file Parquet. Il valore predefinito è 0, che non impone un massimo. Se l'analisi mostra che la dimensionazione dei gruppi di righe sta influenzando le prestazioni del Direct Lake, stabilire un limite testato prima di scrivere o riscrivere la tabella. Per esempio:

spark.conf.set("spark.sql.parquet.native.writer.maxRowGroupRowCount", 8_000_000)

Non impostare il limite solo per raggiungere un numero specifico di righe. La larghezza delle righe, la compressione, la distribuzione dei file e il parallelismo di capacità influenzano anch'essi le prestazioni. Usa Delta Analyzer per valutare la disposizione risultante.

Per indicazioni dettagliate su framing, transcodifica, gruppi di righe, pattern di aggiornamento e Delta Analyzer, vedi Comprendere le prestazioni delle query Direct Lake.

Applica la guida agli strati medaglione

Bronzo, Argento e Oro descrivono lo scopo e la raffinatezza dei dati. Non determinano se il layout è gestito dall'utente o dal sistema, e non richiedono copie separate per ogni consumatore.

Strato Obiettivo primario Guida per carichi di lavoro incrociati
Bronzo (atterraggio) Preservare la fedeltà della sorgente e la velocità di ingestione Dai priorità alla velocità di scrittura mantenendo tabelle scritte da Spark con compattazione automatica. Evita i modelli semantici Power BI Direct Lake su tabelle Bronze grezze a meno che il modello e la forma dei dati non siano progettati intenzionalmente per quell'uso.
Argento (curato) Fornire dati validati e conformi per il riutilizzo Riutilizza la tabella tra i client Fabric compatibili. Per le tabelle lakehouse scritte da Spark, abilita V-Order solo quando Direct Lake è un consumer principale.
Oro (servizio) Offri dimensioni, fatti, aggregati e modelli analitici pronti per il business Preferisco questo strato per i modelli semantici di Direct Lake. Riutilizza la tabella tra i consumatori compatibili e applica i controlli specifici per produttore descritti in questo articolo.

Risolvere problemi di layout e manutenzione

Usa una bonifica consapevole del produttore. Applica comandi di manutenzione Spark alle tabelle lakehouse quando la modalità destinazione supporta tali operazioni. Considera i segnali come indicatori piuttosto che soglie universali, e validali rispetto al modello di scrittura della tabella e alle prestazioni del consumatore.

Condizione Segnale Tabella Lakehouse Tavolo del magazzino
File eccessivamente piccoli Il numero dei file aumenta più rapidamente della dimensione della tabella attiva e i file rimangono al di sotto del target adattivo. Con Spark, esegui un'operazione una tantum OPTIMIZE per il backlog esistente, quindi abilita la compattazione automatica. Per le scritture dell'attività Pipeline Copy o di Dataflow Gen2, pianificare separatamente la manutenzione supportata del lakehouse. Nessuna azione. La compattazione del magazzino è automatica.
File sovradimensionati precedenti I file rimangono molto più alti rispetto al target adattivo attuale, e troppo pochi file limitano il parallelismo di scansione. Riscrivi la tabella utilizzando una sovrascrittura o CREATE OR REPLACE TABLE AS SELECT con dimensione adattiva del file di destinazione abilitata. Nessuna azione. Il magazzino gestisce automaticamente la dimensione del file.
Accumulo di vettori di delezione DESCRIBE HISTORY Le metriche mostrano che i vettori di cancellazione vengono aggiunti o aggiornati più rapidamente di quanto la compattazione li rimuova, aumentando potenzialmente il sovraccarico di lettura. Mantieni la compattazione automatica attiva. Se i vettori di cancellazione si accumulano senza attivare la compattazione dei file di piccole dimensioni, programmare OPTIMIZE. Usa REORG TABLE ... APPLY (PURGE) solo per requisiti espliciti di purga. Nessuna azione. La pulizia è gestita dal sistema.
Salto dei file non corretto I predicati selettivi scansionano una grande parte della tabella, oppure la valutazione di qualità per clustering mostra una scarsa organizzazione. Con Spark, configura il clustering liquido o usa Z-Order per una tabella partizionata esistente. Configura il clustering dei dati del Warehouse.
Overhead della transcodifica Direct Lake Delta Analyzer mostra file eccessivi, piccoli gruppi di righe o ritrascodifica ampia dopo gli aggiornamenti. Compattare piccoli file, rivedere i gruppi di righe e applicare il V-Order alle tabelle scritte da Spark. Facoltativamente, configura liquid clustering per migliorare la qualità della compressione nei file Parquet. Mantieni V-Order abilitato e valuta il clustering dei dati.
Crescita dell'archiviazione file senza riferimento Lo storage OneLake cresce più velocemente della dimensione attiva della tabella dopo operazioni di modifica dei dati. Gestisci VACUUM secondo i requisiti di mantenimento. Nessuna azione. La pulizia è gestita dal sistema.

Per i dati con mirroring, segui la procedura di risoluzione specifica del produttore in Ottimizzare i dati con mirroring. La duplicazione del database è gestita dal sistema; per i cataloghi con mirroring, eseguire la manutenzione supportata nella piattaforma di origine.

Per le tabelle lakehouse, le opzioni di ispezione supportate da Spark includono:

  • Esegui DESCRIBE DETAIL per ispezionare il numero dei file, la dimensione totale e la proprietà valutata delta.targetFileSize.adaptive .
  • Esegui DESCRIBE HISTORY per esaminare gli schemi di scrittura e la cronologia della manutenzione.
  • Usa Delta Analyzer quando hai bisogno di un'analisi dettagliata dei gruppi di righe Direct Lake e di aggiornamenti dei pattern.

Ispezionare la dimensione media del file

Usare DESCRIBE DETAIL per calcolare la dimensione media del file come indicatore iniziale della disposizione della tabella:

details = spark.sql("DESCRIBE DETAIL schema_name.table_name").first()

table_size_gb = details["sizeInBytes"] / (1024**3)
num_files = details["numFiles"]
avg_file_size_mb = (
    details["sizeInBytes"] / num_files / (1024**2)
    if num_files
    else 0
)

print(f"Table size: {table_size_gb:.2f} GB")
print(f"Number of files: {num_files}")
print(f"Average file size: {avg_file_size_mb:.2f} MB")

Una media può nascondere un'asimmetria tra le partizioni oppure tra i file recenti e quelli compattati in precedenza. Se la media indica un possibile problema di layout, ispezionare i singoli file Parquet o utilizzare Delta Analyzer per valutare la distribuzione prima di modificare le impostazioni di manutenzione.

Quando creare un'altra tabella

Non creare un'altra tabella fisica solo perché più motori Fabric consumano i dati.

Crea un'altra tabella quando ha uno scopo indipendente, ad esempio:

  • Una trasformazione o aggregazione che cambia il granulo o il significato commerciale dei dati.
  • Requisiti diversi di sicurezza, conservazione o qualità dei dati.
  • Un requisito di latenza o di aggiornamento che la tabella condivisa non può soddisfare.
  • Una struttura specifica per il consumatore i cui benefici misurati superano i costi di archiviazione, elaborazione, tracciabilità e governance.

Contenuti correlati

  • Last updated on