Progettare e implementare una strategia di clustering

L'ottimizzazione della modalità di organizzazione fisica dei dati sul disco influisce direttamente sulle prestazioni delle query e sull'efficienza di archiviazione. Quando si progetta una strategia di clustering per le tabelle Delta Lake, si determina come il motore di query individua e recupera i dati pertinenti. L'approccio corretto può ridurre notevolmente la quantità di dati analizzati durante le query, riducendo sia i tempi di risposta che i costi di calcolo.

Azure Databricks offre diverse tecniche complementari per l'organizzazione dei dati. Comprendere quando applicare vettori di clustering liquido, ordinamento Z o eliminazione consente di prendere decisioni che bilanciano le prestazioni, il lavoro di manutenzione e la compatibilità con le tabelle esistenti.

Comprendere i fondamenti dell'ignoramento dei dati

Prima di esaminare tecniche di clustering specifiche, è importante comprendere il meccanismo sottostante che sfruttano tutti: ignorare i dati. Delta Lake raccoglie automaticamente le statistiche per ogni file di dati, inclusi valori minimi e massimi, conteggi null e conteggi dei record per ogni colonna. Quando si esegue una query con condizioni di filtro, il motore di query controlla prima queste statistiche e ignora i file che non possono contenere record corrispondenti.

Ad esempio, se si eseguono query sui dati sulle vendite per gennaio 2026 e le statistiche di un determinato file mostrano che contiene solo i record di marzo 2026, il motore ignora completamente il file senza leggerne il contenuto. Questa ottimizzazione avviene automaticamente, ma l'efficacia dipende dalla modalità di organizzazione dei dati.

Il salto dei dati diventa efficace quando i record correlati vengono archiviati insieme negli stessi file. Se i record per ogni mese vengono sparsi in modo casuale in tutti i file, il motore non può ignorare alcun file perché ogni file contiene record da ogni mese. Le tecniche di clustering esistono per risolvere esattamente questo problema.

Implementare il clustering liquido per le nuove tabelle

Il clustering liquido è l'approccio consigliato per organizzare i dati nelle nuove tabelle Delta Lake ed è disponibile anche in anteprima pubblica per le tabelle Apache Iceberg gestite in Unity Catalog (Databricks Runtime 16.4 LTS e versioni successive). A differenza del partizionamento tradizionale, il clustering liquido consente di modificare la strategia di clustering senza riscrivere i dati esistenti. Questa flessibilità è utile quando i modelli di query si evolvono o quando si è incerti quali colonne verranno filtrate più frequentemente.

Per abilitare il liquid clustering, usare la clausola CLUSTER BY quando si crea una tabella:

CREATE TABLE sales.transactions (
    transaction_id STRING,
    customer_id STRING,
    product_category STRING,
    region STRING,
    transaction_date DATE,
    amount DECIMAL(12,2)
)
CLUSTER BY (region, transaction_date);

È possibile specificare fino a quattro chiavi di clustering. Scegliere le colonne che vengono visualizzate di frequente nei filtri di query. L'importanza dell'ordine delle chiavi di clustering è inferiore rispetto alla selezione delle colonne corrette, poiché l'ottimizzazione del clustering liquido avviene per tutte le chiavi specificate contemporaneamente.

Dopo aver creato una tabella cluster, eseguire il comando per applicare il OPTIMIZE clustering ai dati:

OPTIMIZE sales.transactions;

Il clustering liquido è di tipo incrementale. Ogni esecuzione OPTIMIZE raggruppa solo i dati che necessitano di riorganizzazione, rendendo efficiente la manutenzione regolare. Databricks consiglia di pianificare OPTIMIZE i processi ogni una o due ore per le tabelle con inserimenti o aggiornamenti frequenti.

Modificare le chiavi di clustering quando necessario

Un vantaggio significativo del clustering liquido rispetto al partizionamento è la possibilità di modificare la strategia di clustering. Se i modelli di query cambiano, aggiorna le chiavi di clustering con l'istruzione ALTER TABLE.

ALTER TABLE sales.transactions
CLUSTER BY (customer_id, transaction_date);

Le operazioni successive OPTIMIZE usano il nuovo approccio di clustering. I dati scritti in precedenza non vengono riscritti automaticamente. Per applicare il nuovo clustering a tutti i dati esistenti, eseguire:

OPTIMIZE sales.transactions FULL;

Abilitare la selezione automatica della chiave di clustering

Azure Databricks può selezionare in modo intelligente le chiavi di clustering in base ai modelli di query effettivi. Il clustering dinamico automatico analizza la cronologia dei carichi di lavoro e sceglie le colonne che offrono il massimo vantaggio nel salto dei dati.

CREATE TABLE sales.orders CLUSTER BY AUTO;

È possibile abilitare il clustering automatico nelle tabelle esistenti:

ALTER TABLE sales.transactions CLUSTER BY AUTO;

Il clustering liquido automatico richiede l'attivazione dell'ottimizzazione predittiva. Azure Databricks valuta periodicamente se chiavi di clustering diverse migliorano le prestazioni e regolano di conseguenza la strategia.

Eseguire la migrazione dall'ordinamento a Z al clustering fluidico

L'ordinamento Z è una tecnica legacy che organizza i dati per la colocazione di informazioni correlate negli stessi file. Anche se il clustering liquido è consigliato per le nuove tabelle, si riscontreranno tabelle esistenti che utilizzano l'ordinamento Z e sarà necessario comprendere entrambi gli approcci.

L'ordinamento Z usa il OPTIMIZE comando con una ZORDER BY clausola :

OPTIMIZE sales.legacy_transactions
ZORDER BY (region, transaction_date);

L'ordinamento Z differisce dal clustering liquido in diversi modi importanti:

Quando si eredita una tabella ordinata Z, sono disponibili due opzioni. Continuare a usare l'ordinamento Z per coerenza o eseguire la migrazione al clustering liquido per una maggiore flessibilità. Per eseguire la migrazione, abilitare innanzitutto il clustering liquido nella tabella non partizionata esistente:

ALTER TABLE sales.legacy_transactions
CLUSTER BY (region, transaction_date);

Eseguire quindi un'ottimizzazione completa per riorganizzare tutti i dati esistenti:

OPTIMIZE sales.legacy_transactions FULL;

Gestire i vettori di eliminazione per aggiornamenti efficienti

I vettori di eliminazione riguardano un aspetto diverso dell'organizzazione dei dati: come Delta Lake gestisce i record modificati o eliminati. Per impostazione predefinita, quando si aggiorna o si elimina una singola riga in un file Parquet, Delta Lake deve riscrivere l'intero file. Per le tabelle con modifiche frequenti, questo comporta un sovraccarico significativo.

Con i vettori di eliminazione abilitati, Delta Lake contrassegna le righe modificate come eliminate in un file di metadati separato anziché riscrivere immediatamente il file Parquet. Le letture successive applicano queste eliminazioni in tempo reale, combinando il file originale con il vettore di eliminazione per restituire risultati accurati.

I vettori di eliminazione sono abilitati per impostazione predefinita per le nuove tabelle create con Databricks Runtime 14.1 o versione successiva. È possibile abilitarli in modo esplicito nelle tabelle esistenti:

ALTER TABLE sales.transactions
SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);

I vettori di eliminazione vengono applicati fisicamente quando i file di dati vengono riscritti durante:

• Comando OPTIMIZE
• Trigger di compattazione automatica
• A REORG TABLE ... APPLY (PURGE) operazione

Per gli scenari di conformità in cui è necessario assicurarsi che i dati eliminati vengano rimossi fisicamente, eseguire un'operazione REORG seguita da VACUUM:

REORG TABLE sales.transactions APPLY (PURGE);
VACUUM sales.transactions;

I vettori di eliminazione abilitano anche la concorrenza a livello di riga, consentendo a più transazioni simultanee di modificare righe diverse nella stessa tabella senza conflitti. Questa funzionalità è particolarmente utile per le tabelle con volumi di aggiornamento elevati.