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 clustering liquido è una strategia flessibile di layout dei dati per le tabelle Delta in Microsoft Fabric. Sostituisce il partizionamento statico in stile Hive e la manutenzione manuale dello Z-Order con un clustering dichiarativo adatto alle modifiche. È possibile definire le colonne in cui eseguire il cluster e il runtime di Spark Fabric gestisce automaticamente il layout dei dati fisici.
Usare questo articolo per:
- Scopri come funziona il clustering liquido e quando usarlo.
- Confronta il clustering liquido con il partizionamento e Z-Order.
- Configurare il clustering nelle tabelle.
- Comprendere il clustering liquido incrementale (Runtime 2.0+).
- Regola il comportamento del clustering con le configurazioni della sessione.
Che cos'è il clustering liquido?
Il clustering liquido organizza i dati nei file di tabella Delta in modo che le righe con valori simili nelle colonne di clustering siano raggruppate. Il layout consente un'esclusione dei file più efficace durante l'esecuzione della query: quando una query filtra in base alle colonne di clustering, il motore legge solo i file i cui intervalli di valori corrispondono al predicato, escludendo gli altri.
A differenza del partizionamento, il clustering liquido:
- Non crea strutture di directory fisiche per ogni valore di colonna.
- Non è necessario scegliere le colonne di clustering in fase di creazione della tabella (possono essere modificate in un secondo momento).
- Gestisce colonne con cardinalità elevata senza creare potenziali problemi dovuti a file di piccole dimensioni causati da migliaia di partizioni minuscole.
- Applica l'ottimizzazione del layout durante
OPTIMIZE, non in fase di scrittura.
Vantaggi del partizionamento e dell'ordine Z
Il clustering liquido offre vantaggi significativi rispetto al partizionamento in stile Hive e all'ordine Z in termini di flessibilità, manutenzione e gestione dei modelli di dati in continua evoluzione.
Confronto con il partizionamento in stile Hive
| Aspect | Partizionamento in stile Hive | Raggruppamento liquido |
|---|---|---|
| Granularità | Una directory per ogni valore distinto (o combinazione di valori) | Intervalli di valori a livello di file, senza directory |
| Cardinalità elevata | Crea migliaia di file/directory di piccole dimensioni | Gestisce in modo naturale; raggruppa i dati in file di dimensioni adeguate |
| Modifiche alle colonne | Richiede la riscrittura completa della tabella |
ALTER TABLE ... CLUSTER BY si applica al successivo OPTIMIZE |
| Percorso di scrittura | La colonna di partizione deve essere nota in fase di scrittura | Qualsiasi colonna può essere organizzata in cluster successivamente |
| Problema di file di piccole dimensioni | Comune nei casi di streaming o inserimenti frequenti | Gestito tramite OPTIMIZE compattazione |
Rispetto all'ordine Z
| Aspect | Ordine Z | Raggruppamento liquido |
|---|---|---|
| Modifiche alle colonne | È necessario rieseguire OPTIMIZE ZORDER BY (...) con nuove colonne |
ALTER TABLE ... CLUSTER BY rende persistente la definizione |
| Supporto incrementale | Nessuna modalità incrementale; usare WHERE per limitare l'ambito manualmente |
La modalità incrementale (runtime 2.0+) elabora automaticamente solo i file nuovi, modificati o non integri |
| Metadata | Nessuna definizione di colonna persistente | Colonne di clustering archiviate nei metadati della tabella |
| Layout a più colonne | Curva dell'ordine Z applicata in fase di ottimizzazione | Ordine Z per una colonna di clustering; Curva Hilbert per 2 colonne+ che offrono una località dei dati ottimizzata |
Il Liquid Clustering usa Z-Order per i layout a colonna singola e la curva di Hilbert per i layout con due o più colonne, un miglioramento rispetto a Z-Order, che per il clustering multidimensionale utilizza solo la curva Z-Order. Il clustering liquido esegue il wrapping di entrambi gli algoritmi in un framework incrementale e compatibile con i metadati che riduce i costi di manutenzione in corso.
Creare una tabella clusterizzata liquida
Definire le colonne di clustering usando la CLUSTER BY clausola in fase di creazione della tabella:
-- Create a new clustered table
CREATE TABLE dbo.sales (
order_id BIGINT,
order_date DATE,
region STRING,
amount DECIMAL(10,2)
) CLUSTER BY (order_date, region);
-- Create from query results
CREATE TABLE dbo.sales_clustered
CLUSTER BY (order_date, region)
AS SELECT * FROM raw_sales;
-- Enable on existing table
ALTER TABLE dbo.sales_txn CLUSTER BY (order_date, region);
Modificare le colonne di clustering
A differenza del partizionamento, è possibile modificare le colonne di clustering in qualsiasi momento senza riscrivere i dati:
-- Change clustering columns
ALTER TABLE sales CLUSTER BY (region, product_category);
-- Remove clustering (table becomes unclustered)
ALTER TABLE sales CLUSTER BY NONE;
Dopo aver modificato le colonne di clustering, il nuovo layout viene applicato all'esecuzione successiva OPTIMIZE . I file esistenti conservano il layout precedente finché non vengono raggruppati nuovamente.
Applicare il clustering con OPTIMIZE
Il clustering viene applicato durante il OPTIMIZE comando . Non è necessario specificare colonne nell'istruzione OPTIMIZE perché la definizione del clustering è archiviata nei metadati della tabella:
-- Cluster the table using the defined clustering columns
OPTIMIZE sales;
-- Recluster partial Z-Cubes and Z-Cubes with different clustering keys or clustering providers
OPTIMIZE sales FULL;
Usare OPTIMIZE FULL quando si modificano le chiavi di clustering e si vogliono ricompilare i cubi Z che non rispettano la strategia di clustering corrente. Un Z-Cube è l'unità logica usata dal clustering liquido per raggruppare i file che condividono le stesse colonne di clustering. I dati vengono raggruppati in un singolo cubo Z fino a quando le chiavi del cluster non cambiano o la quantità di dati supera i 100 GB.
Tip
A partire da Fabric Runtime 2.0, il motore di esecuzione nativo supporta l'esecuzione di OPTIMIZE sulle tabelle liquid clustered, offrendo prestazioni del clustering multidimensionale superiori del 30–50%. Le versioni precedenti del runtime passano alla normale esecuzione di Spark non accelerata.
Come funziona il clustering liquido
Quando si esegue OPTIMIZE in una tabella cluster liquida, si verifica quanto segue:
-
Selezione file: il motore seleziona i file che richiedono il clustering.
- In Runtime 2.0+ (strategia di clustering incrementale), vengono selezionati solo i file non raggruppati, danneggiati, piccoli o con vettori di eliminazione.
- In Runtime 1.3 vengono selezionati tutti i file all'interno di ogni cubo Z di dimensioni inferiori a 100 GB, indipendentemente dal fatto che siano già ben raggruppati.
- Imballaggio bin: i file selezionati vengono raggruppati in contenitori destinati a dimensioni ottimali del file di output.
- Ripartizione: i dati all'interno di ogni bin vengono ripartizionati usando una curva di riempimento dello spazio (curva Hilbert per più colonne, Z-Order per una singola colonna).
- Scrittura di file: i dati ripartizionati vengono scritti come nuovi file con intervalli di valori limitati nelle colonne di clustering.
- Aggiornamento dei metadati: il log Delta registra la sostituzione del file, contrassegnando i nuovi file con i metadati del clustering.
Il risultato è costituito da file con intervalli di valori non sovrapposti (o con sovrapposizione minima) nelle colonne di clustering, consentendo al motore di ignorare i file che non corrispondono ai predicati di query.
Caution
Fabric Runtime 1.3 (Delta 3.2): usare il clustering liquido con cautela. In questo runtime, Liquid Clustering utilizza una strategia di riscrittura completa dello Z-Cube: ogni file all'interno di uno Z-Cube viene riscritto a ogni esecuzione. Un cubo Z viene mantenuto (ignorato) solo quando le dimensioni superano i 100 GB. Per le tabelle di dimensioni inferiori a 100 GB, la riscrittura completa significa che ogni OPTIMIZE esecuzione riscrive tutti i dati della tabella, anche quando i dati sono già ben raggruppati. Ciò causa un'amplificazione di scrittura grave.
- Non usare la compattazione automatica con il clustering liquido in Runtime 1.3. Ogni attivazione della compattazione automatica può causare una riscrittura completa della tabella, anziché limitarsi al clustering dei dati nuovi o modificati.
- Evitare l'esecuzione
OPTIMIZEdopo ogni operazione di scrittura. In Runtime 1.3, limitare il clustering a esecuzioni strategiche e intenzionali e accettare un livello inferiore di aggiornamento del clustering tra un'esecuzione e l'altra.
Il clustering liquido incrementale, che elimina questa amplificazione di scrittura, è disponibile solo a partire da Fabric Runtime 2.0.
Clustering liquido incrementale
A partire da Fabric Runtime 2.0 (Delta 4.1), il clustering liquido usa una strategia di clustering incrementale per impostazione predefinita. La strategia incrementale è un miglioramento significativo rispetto al comportamento standard del clustering.
Importante
Il clustering liquido incrementale è disponibile solo in Fabric Runtime 2.0 e versioni successive. Nei runtime precedenti usa OPTIMIZE il comportamento standard (riscrittura completa) in cui tutti i file all'interno di un cubo Z vengono riscritti in ogni esecuzione.
Perché la strategia di clustering incrementale è importante
L'algoritmo di clustering standard riscrive tutti i file all'interno di uno Z-Cube (fino a 100 GB) a ogni OPTIMIZE esecuzione, indipendentemente dal fatto che siano già ben raggruppati. Per una tabella che riceve piccole accodamenti, i costi di clustering aumentano in modo lineare con le dimensioni della tabella, non con la quantità di nuovi dati.
La modalità incrementale risolve il problema di riscrittura completa selezionando solo i file effettivamente necessari per il clustering:
- File non clusterizzati: dati appena scritti senza metadati di clustering
- File di piccole dimensioni: file al di sotto della soglia di dimensioni del file di destinazione
- File con vettori di eliminazione: file con eliminazioni accumulate che superano la soglia di pulizia
I file già ben raggruppati e di dimensioni adeguate vengono completamente ignorati.
Clustering automatico
Il clustering liquido incrementale include il rilevamento automatico delle sovrapposizioni, noto come riclustering automatico, per mantenere nel tempo la qualità del clustering. Man mano che arrivano nuovi dati, può creare sovrapposizioni tra intervalli di valori di file, con un calo dell'efficacia del salto dei dati. La riclusterizzazione automatica rileva intervalli di valori sovrapposti tra i file e rielabora in modo selettivo solo i file interessati.
Il clustering automatico viene eseguito automaticamente come parte di OPTIMIZE ogni volta che sono presenti dati nuovi o modificati nel cluster. Non sono necessari interventi manuali né operazioni di reclustering complete pianificate. La strategia di clustering incrementale mantiene la qualità del clustering quasi ottimale man mano che i dati si evolvono.
Ripristinare il comportamento di riscrittura completo
Se è necessario disabilitare la strategia di clustering incrementale e usare il comportamento di riscrittura completa, impostare la configurazione seguente:
SET spark.microsoft.delta.optimize.clustering.strategy.incremental = FALSE;
OPTIMIZE sales;
In alternativa, usare OPTIMIZE FULL per un cluster completo monouso senza modificare le impostazioni della sessione:
OPTIMIZE sales FULL;
Note
La strategia di clustering incrementale consente intenzionalmente una deviazione secondaria dal layout teoricamente ottimale per ottenere riduzioni significative nell'amplificazione della scrittura. L'esecuzione OPTIMIZE FULL chiude tale gap ricompilando completamente gli Z-Cube al livello teorico ottimale, ma a un costo di scrittura più elevato.
Informazioni di riferimento sulla configurazione
Le configurazioni di sessione seguenti controllano il comportamento del clustering liquido in Fabric Runtime 2.0+.
Clustering incrementale
| Impostazione | TIPO | Default | Description |
|---|---|---|---|
spark.microsoft.delta.optimize.clustering.strategy.incremental |
Booleano | true |
Commutatore master per il clustering incrementale. Quando true, OPTIMIZE elabora solo file non clusterizzati, non integri, di piccole dimensioni e con vettori di eliminazione. Quando false, tutti i file per i cubi Z con dimensioni minori di 100 GB vengono riscritti (comportamento standard). |
spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster |
Booleano | true |
Abilita il rilevamento automatico e il riclustering dei file con intervalli di dati sovrapposti. Si applica solo quando è abilitato il clustering incrementale. |
Ottimizzazione del reclustering automatico
Queste configurazioni controllano la sensibilità e l'ambito del clustering automatico. Le impostazioni predefinite sono adatte per la maggior parte dei carichi di lavoro. Modificarli solo quando è necessario modificare il compromesso tra la qualità del clustering e l'amplificazione della scrittura.
| Impostazione | TIPO | Default | Description |
|---|---|---|---|
spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster.minOffendingFiles |
Int | 4 |
Numero minimo di file sovrapposti necessari per attivare il clustering. Valori più bassi riclusterizzano prima (migliori prestazioni delle query, costo di scrittura più elevato). Deve essere ≥ 2. |
spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster.minOverlapThreshold |
Double | 0.75 |
Soglia del punteggio di sovrapposizione delle dimensioni del clustering. Le coppie di file che hanno un punteggio superiore a questo valore vengono considerate sovrapposte. Deve essere compreso nell'intervallo (0,25, 1,0]. I valori inferiori sono più aggressivi. |
Scelta delle colonne di clustering
Per ottenere risultati ottimali, scegliere colonne di clustering in base ai modelli di filtro delle query più comuni:
-
Selezionare da 1 a 4 colonne che vengono visualizzate di frequente nelle
WHEREclausole. Un maggior numero di colonne riduce l'efficacia del file skipping per colonna della curva di riempimento dello spazio e aumenta il tempo necessario per raggruppare i dati. - Prendere in considerazione la cardinalità delle colonne. Le colonne a bassa cardinalità generano meno intervalli di valori distinti, riducendo così il beneficio derivante dal salto dei file se abbinate a chiavi di clustering ad alta cardinalità.
-
L'ordine delle colonne non ha alcun impatto sul clustering. L'ordine delle colonne specificate dopo
CLUSTER BYnon ha alcun impatto sul clustering multidimensionale risultante.
Tipi di colonna supportati
Non tutti i tipi di colonna possono essere usati come chiavi di clustering. Il motore valuta il tipo di dati di ogni colonna per determinare l'idoneità.
Sempre idoneo (tipi atomici):
-
NumericType(ByteType,ShortType,IntegerType,LongType,FloatType,DoubleType,DecimalType) DateTypeTimestampTypeTimestampNTZTypeStringType
Idoneo in modo condizionale:
Note
È possibile abilitare i tipi seguenti a partire da Fabric Spark Runtime 2.0 (Delta 4.1)
-
StructType: quandospark.microsoft.delta.clusteredTable.complexTypes.enabledè abilitato e tutti i campi foglia sono tipi idonei. -
ArrayType: quandospark.microsoft.delta.clusteredTable.complexTypes.enabledè abilitato e il tipo di elemento è idoneo. -
MapType: quandospark.microsoft.delta.clusteredTable.complexTypes.enabledè abilitato e i tipi chiave e valore sono ordinabili e idonei.
Non idoneo:
BinaryTypeBooleanTypeNullType
Per i corrispondenti tipi idonei utilizzati nelle statistiche a livello di file, vedere Esclusione dei file — Tipi di dati idonei.
Interazione con altre funzionalità
| Feature | Behavior |
|---|---|
| Partizionamento | Incompatibile. Per consentire il file skipping, si consiglia il liquid clustering rispetto al partizionamento. |
| Ordine Z | Incompatibile. Per il file skipping, si consiglia il clustering liquido rispetto a Z-Order. |
| Ottimizzazione rapida | Compatibile a partire da Runtime 2.0. Nei runtime precedenti, l'ottimizzazione rapida non ha alcun effetto sulle tabelle cluster liquide. Durante OPTIMIZE, il clustering viene saltato quando non ci sono abbastanza file di piccole dimensioni o i dati sono insufficienti per produrre un file di output di dimensioni adeguate. |
| Dimensioni del file di destinazione adattivo | Compatibile. Le dimensioni del file di destinazione impostate dalla valutazione adattiva vengono usate come dimensioni di destinazione per il clustering. |
| Ottimizzare la scrittura | Compatibile. Produce file consolidati in scrittura che vengono quindi raggruppati durante OPTIMIZE. |
| Compattazione automatica | Non utilizzare con il clustering liquido in Runtime 1.3 o versioni precedenti di Runtime. In questi runtime, ogni trigger di compattazione automatica riscrive tutti i dati in Z-Cubes inferiori a 100 GB, causando un'amplificazione di scrittura grave. In Runtime 2.0+, la compattazione automatica è compatibile: il clustering incrementale garantisce che solo i file nuovi o non integri vengano riscritti. La compattazione automatica gestisce il consolidamento di file di piccole dimensioni; OPTIMIZE gestisce il layout del clustering. |
| Vettori di eliminazione | I file che superano la soglia delle righe eliminate vengono selezionati per il clustering, indipendentemente dal relativo stato di clustering. |
| V-Order | Compatibile. V-Order e il liquid clustering operano lungo assi diversi (struttura interna dei file vs. intervalli di valori tra i file). Entrambi possono essere applicati insieme. |
Procedure consigliate
-
L'esecuzione
OPTIMIZEviene eseguita regolarmente dopo operazioni di scrittura batch o in base a una pianificazione per le tabelle di streaming, ma solo in Runtime 2.0+, in cui la strategia di clustering incrementale rende le esecuzioni frequenti poco costose. In Runtime 1.3 e nelle versioni precedenti, ogni esecuzioneOPTIMIZEriscrive tutti i dati negli Z-Cubes inferiori a 100 GB, quindi le esecuzioni dovrebbero essere deliberate e poco frequenti. -
Usare
OPTIMIZE FULLcon moderazione. Riservalo a dopo aver modificato le colonne di clustering o se hai bisogno di un ripristino una tantum della qualità. - Monitorare la qualità del clustering controllando le metriche di analisi delle query (file analizzati rispetto ai file totali) nell'interfaccia utente spark o nei piani di query.
- Combinare con la scrittura ottimizzata per i carichi di lavoro in streaming per garantire che ogni micro-batch produca un numero gestibile di file per il clustering.